tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Cargo.lock change impacting url2pkg



Thanks, I'll try your patch as soon as I find some time.

I don't know either if someone else has spotted the Cargo change, I've just
happen to find it by hitting the wall when updating ncspot.

Also, I like your patch as it works with both versions. Just because Cargo
changed doesn't necessarily mean all project will adopt the new version
straight away.

Once again thanks for the hints and hopefully this can be merged into
url2pkg and save future headaches.

pin


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, October 13, 2020 5:25 AM, snow flurry <snow%datagirl.xyz@localhost> wrote:

> I completely missed half of what I wrote being in one of the comments in
> the issue you linked. Sorry about that!
>
> Here's a patch I wrote to support both versions of the Cargo.lock format
> in url2pkg, borrowing from the awk command used by make
> print-cargo-depends. I haven't tested it much past the package that was causing
> issues here, but it provided the same results as print-cargo-depends in that
> case.
>
> --- pkgtools/url2pkg/files/url2pkg.py.orig 2020-10-13 02:49:07.744300947 +0000
> +++ pkgtools/url2pkg/files/url2pkg.py
> @@ -922,9 +922,30 @@ class Adjuster:
> if not self.wrksrc_isfile('Cargo.lock'):
> return
>
> -          # "checksum cargo-package-name cargo-package-version
>
>
> -          for (name, version) in self.wrksrc_grep('Cargo.lock', r'^"checksum\\s(\\S+)\\s(\\S+)'):
>
>
> -              self.build_vars.append(Var('CARGO_CRATE_DEPENDS', '+=', f'{name}-{version}'))
>
>
>
> -          # pull name and version from package entries
>
>
> -          with self.wrksrc_open('Cargo.lock') as f:
>
>
> -              name = None
>
>
> -              version = None
>
>
> -              for line in f:
>
>
> -                  if re.match(r'^\\[\\[package\\]\\]', line) != None:
>
>
> -                      # new package, reset name and version to be safe
>
>
> -                      name = None
>
>
> -                      version = None
>
>
> -                      continue
>
>
> -
> -                  m = re.match(r'^name\\s=\\s"(\\S+)"', line)
>
>
> -                  if m != None:
>
>
> -                      name = m[1]
>
>
> -
> -                  m = re.match(r'^version\\s=\\s"(\\S+)"', line)
>
>
> -                  if m != None:
>
>
> -                      version = m[1]
>
>
> -
> -                  if re.match(r'^source\\s=\\s"(\\S+)"', line) != None:
>
>
> -                      self.build_vars.append(Var('CARGO_CRATE_DEPENDS', '+=', f'{name}-{version}'))
>
>
> -                      # reset name and version
>
>
> -                      name = None
>
>
> -                      version = None
>
>
>
> self.includes.append('../../lang/rust/cargo.mk')
>
> On Mon, Oct 12, 2020 at 06:12:50PM -0700, snow flurry wrote:
>
> > Looks like the format of Cargo.lock changed from having a single
> > [metadata] section with all the checksums to a new format where the
> > checksums are included in each package section
> > (https://github.com/rust-lang/cargo/pull/7070 has more info). As of
> > commit b9dfc09421b9f8cd19f4abbffe63c8bb48744ab6, ncspot started using
> > that new format.
> > Looking at Adjuster.adjust_cargo() in url2pkg, only the old format is
> > checked. I'm not sure of a good way to handle the new format cleanly, or
> > if others are already aware of the change to the lock file.
> > In the meantime, I tried running "make print-cargo-depends" and that
> > seemed to work fine with the version you have committed. Might be a
> > usable workaround for now?
> > On Mon, Oct 12, 2020 at 12:17:26PM +0000, voidpin wrote:
> >
> > > Cargo.lock format change making url2pkg unable to generate CARGO_CRATE_DEPENDS
> > > list.
> > > See https://github.com/hrkfdn/ncspot/issues/286
> > > I've managed to update ncspot by generating the list from a few commits prior
> > > to release and adjusting the versions according to upstream Cargo.lock file.
> > > Although, going forward would be good to fix the issue.
> > > I have no clue how to handle this. Anyone?
> > > Sent with ProtonMail Secure Email.




Home | Main Index | Thread Index | Old Index