[SOLVED] Error importing a packag into AUR4

Aerion · 2015-07-14 14:10:17

severach wrote:

To translate progandy, adding a file after a commit does not fix the first commit. The first commit goes, doesn't have the file, then fails, and the second commit never happens. There is a git command to undo the commit but I just rm -rf .git and clone again.
You must add all the files.
git add PKGBUILD .SRCINFO brother-hl2030.install brother-hl2030.patch
git status

Thanks for this 'translation'; I have now successfully migrated the package to the AUR4.

Running git status initially produced nothing:

$ git status        
On branch master
nothing to commit, working directory clean

After removing .git, cloning again, running mksrcinfo and adding all files again everything worked :

$ git status
On branch master

Initial commit

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

        new file:   .SRCINFO
        new file:   PKGBUILD
        new file:   brother-hl2030.install
        new file:   brother-hl2030.patch
$ git commit -m "Initial import"
$ git commit -m "Initial import"
[master (root-commit) fced68f] Initial import
 4 files changed, 218 insertions(+)
 create mode 100644 .SRCINFO
 create mode 100644 PKGBUILD
 create mode 100644 brother-hl2030.install
 create mode 100644 brother-hl2030.patch
$ git push origin master
Host key fingerprint is SHA256:L71Q91yHwmHPYYkJMDgj0xmUuw16qFOhJbBr1mzsiOI
Enter passphrase for key '/home/aerion/.ssh/aur_rsa': 
Counting objects: 6, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 2.88 KiB | 0 bytes/s, done.
Total 6 (delta 0), reused 0 (delta 0)
To ssh://aur@aur4.archlinux.org/brother-hl2030.git
 * [new branch]      master -> master

severach wrote:

Your main problem is that the package is orphaned. Go adopt and try again.

Hmm, the package is still showing as maintained in the AUR3, and of course it wasn't listed in the AUR4 yet due to my problems submitting it. In any case, it is now in the AUR4.

severach wrote:

Aerion wrote:
I really appreciate the help as contributing to the AUR has become a lot harder with the move to Git; uploading to AUR3 couldn't be simpler but this adds a steep learning curve for those unfamiliar with Git.
The good news is that package quality should go way up due to the difficulty of submitting. I did all my packages at the last minute because what I saw looked nothing like what was outlined in the AUR4 migration guide. I still can't believe anyone would approve discarding the PKGBUILD history or the packages without active maintainers. People are going to stop by to find that we've been bombed back into 2008.
As an example, ksh would be on the chopping block had I not been roped into it as a dependency on another package.
Maybe it's just a bad implementation. Most git remote errors make no sense. You must guess at the problem and try again.

Exactly my feeling. There now are numerous packages missing which, unless the original maintainer gets his act together or another good soul steps in and adopts it, are now 'lost' to Arch users. For example, I have a Canon MG7150, but the canon-pixma-mg7100-complete package has not been migrated. I could adopt it, but I don't really have the time to maintain this package, and I certainly can't do this for all other packages I use but have not been migrated to AUR4.

The whole thing could (should?) have been handled differently. For starters, the grace period should have been longer. While I was fully aware of the upcoming changes to the AUR, a month wasn't long enough for me due to a very busy and hectic schedule. Other maintainers may not even be aware of the AUR shake-up at all and so their packages will now be lost. The maintainers could have been contacted directly, either directly via email, or through a bot comment on their respective AUR package page(s).

There probably is a lot of cruft in the AUR that will nicely get purged this way, but in doing so we are also losing a lot of good and useful packages.

Scimmia · 2015-07-14 14:19:38

Aerion wrote:

The maintainers could have been contacted directly, either directly via email, or through a bot comment on their respective AUR package page(s).

They were. Every AUR maintainer was emailed using the email listed in their account.

Aerion · 2015-07-14 14:22:42

progandy wrote:

severach wrote:
None of the AUR packages need to work to be valuable.
It's much easier to correct an existing PKGBUILD than to come up with everything from scratch. Fortunately ksh has a decent Gentoo ebuild but many I'd have given up on without a boost from a half working PKGBUILD. Presence on the AUR shows that someone at least tried and probably had it working at one time.
If we keep the a searchable archive for the old PKGBUILDs somewhere and add a link in the new AUR, might that help you?

I agree with severarch here. I have learnt a lot from looking at other people's PKGBUILDs to see how things were done; much easier than trying to write one from scratch. A searchable archive for old PKGBUILDs would be a good solution for packages not migrated to AUR4.

Scimmia · 2015-07-14 14:25:48

Aerion wrote:

I agree with severarch here. I have learnt a lot from looking at other people's PKGBUILDs to see how things were done; much easier than trying to write one from scratch. A searchable archive for old PKGBUILDs would be a good solution for packages not migrated to AUR4.

The 21000+ that were migrated aren't enough?

Last edited by Scimmia (2015-07-14 14:26:25)

Aerion · 2015-07-14 14:27:57

Scimmia wrote:

Aerion wrote:
The maintainers could have been contacted directly, either directly via email, or through a bot comment on their respective AUR package page(s).
They were. Every AUR maintainer was emailed using the email listed in their account.

So they were, I stand corrected. Ironically I didn't see that email myself, buried amongst all the other emails, hence my comment

Aerion · 2015-07-14 14:41:32

Scimmia wrote:

Aerion wrote:
I agree with severarch here. I have learnt a lot from looking at other people's PKGBUILDs to see how things were done; much easier than trying to write one from scratch. A searchable archive for old PKGBUILDs would be a good solution for packages not migrated to AUR4.
The 21000+ that were migrated aren't enough?

When it comes to learning from an existing PKGBUILD, that is of course more than sufficient. Having said that, there are quite possibly a number of packages with unique PKGBUILDs that may end up getting lost. Fringe cases, most likely, but still…

But when it comes to packages that haven't been migrated, I'd argue no, for the moment a package that someone relies on and that was available in AUR3 is no longer available in AUR4, not enough packages were migrated. An example being the Canon MG7100 Series driver I mentioned earlier; it is not exactly an old and obscure printer (less than two years old). The maintainer hasn't migrated it, I don't have the time to adopt and maintain it, so I have now resolved to building the package using the AUR3 PKGBUILD and keeping the compiled package in my backups.

This is the very reason I decided to migrate the Brother HL-2030 driver to AUR4, even though I no longer have that printer and the package only received 29 votes. Chances are that that driver will never get updated again as the printer is over 10 years old, but those who still have that printer will be able to use it when they move to Arch or reinstall their system.

Scimmia · 2015-07-14 14:45:28

Aerion wrote:

An example being the Canon MG7100 Series driver I mentioned earlier; it is not exactly an old and obscure printer (less than two years old). The maintainer hasn't migrated it, I don't have the time to adopt and maintain it...

I would argue that if nobody wants to take the time to migrate it, it can't be that important.

Aerion · 2015-07-14 14:46:22

Forgot to say thanks to everyone who has contributed to the solution, so here goes: thank you!

I've learnt a bit more about basic Git usage so this will help with any new package I may add in the future, as well as with updates to the existing ones.

Aerion · 2015-07-14 15:00:44

Scimmia wrote:

Aerion wrote:
An example being the Canon MG7100 Series driver I mentioned earlier; it is not exactly an old and obscure printer (less than two years old). The maintainer hasn't migrated it, I don't have the time to adopt and maintain it...
I would argue that if nobody wants to take the time to migrate it, it can't be that important.

It is important to those who use it. And in my case it certainly isn't a case of not wanting to migrate it, but not having the time. In my view adopting or submitting a package to the AUR is taking on a responsibility to maintain that package, and if you can't commit to that you shouldn't take it on in the first place.

Printer drivers can be quite complicated to set up, so without this AUR package for the MG7100 Series I wouldn't have a working printer. I could, of course, try to figure out myself how to get the driver installed, but I wouldn't know that, for example, the UDEV rule needs to be fixed for this particular printer, so the hard work done by the maintainer makes it possible for me (and others) to have this printer working on Arch Linux without any fuss — and isn't that the whole point of the AUR in the first place?

Would it be acceptable to migrate any packages not (yet) migrated by their maintainers, then orphan them immediately upon successful migration, solely to get them into the AUR4 ? If yes, I'm happy to have a go at migrating said MG 7100 driver, but I cannot commit to taking over maintainership for it.

progandy · 2015-07-14 15:08:27

Would it be acceptable to migrate any packages not (yet) migrated by their maintainers, then orphan them immediately upon successful migration, solely to get them into the AUR4 ? If yes, I'm happy to have a go at migrating said MG 7100 driver, but I cannot commit to taking over maintainership for it.

I think that is acceptable for a printer driver if you need the package, can guarantee that the migrated PKGBUILD works on a clean up-to-date arch system and that it follows the packaging standards as closely as possible.
Edit: In the case of printers the PKGBUILDs should be pretty static since new drivers are rarely released. Mostly you just have to fix the build process on pacman upgrades and the dependencies when the package requires outdated libraries.

By the way, the old PKGBUILDS will remain available

https://lists.archlinux.org/pipermail/a … 30724.html
[...] the former aur.archlinux.org source tarballs will be made available for reference.
[...]

I hope that the old git mirror stays available. Still, I have a local clone so I won't lose anything, I can even search in it.

Last edited by progandy (2015-07-14 15:34:45)

WorMzy · 2015-07-14 15:21:03

Aerion wrote:

Would it be acceptable to migrate any packages not (yet) migrated by their maintainers, then orphan them immediately upon successful migration, solely to get them into the AUR4 ?

If you mean en-masse, then no. One of the reasons that the transition from AUR3 to AUR4 is being carried out as it is, is to clear out a lot of the dead wood[1]. The old PKGBUILDs that don't make it over will still be available for reference[2].

[1] https://lists.archlinux.org/pipermail/a … 30880.html

It is expected (and intended) that some (hopefully not too many) AUR
package maintainers back out due to the new system. It is also intended
that a huge number of packages is not imported into the new AUR and
anything that automatically transfers packages is undesirable. We only
want users to resubmit their stuff if they want to take care of it in
the future. Think of it as a huge AUR cleanup.

[2] https://lists.archlinux.org/pipermail/a … 30724.html

On August 8th, the archive at
aur.archlinux.org will be replaced by aur4.archlinux.org and the former
aur.archlinux.org source tarballs will be made available for reference.

Aerion · 2015-07-14 16:23:37

progandy wrote:

Would it be acceptable to migrate any packages not (yet) migrated by their maintainers, then orphan them immediately upon successful migration, solely to get them into the AUR4 ? If yes, I'm happy to have a go at migrating said MG 7100 driver, but I cannot commit to taking over maintainership for it.
I think that is acceptable if you can guarantee that the migrated PKGBUILD works on a clean up-to-date arch system and follows the packaging standards as closely as possible.

Guaranteeing that it works is easy as I have the printer here in the house, and my Arch system is up-to-date (freshly installed a couple of weeks ago, in fact). The current PKGBUILD looks good, only the CARC if-then-else block needs replacing as far as I can tell from a quick glance. The problem here is that a few of the AUR dependencies (lib32-libusb-compat, libtiff4, lib32-libtiff4) have not been migrated to AUR4. This would mean migrating and orphaning them too, and if they in turn depend on AUR packages that haven't been migrated either (I haven't looked) I'd end up in dependency hell simply trying to migrate a single package to AUR4. And this is where the time issue comes in again, so I have to abandon the idea of migrating the MG7100 drivers to AUR4 myself.

By the way, I hope that at least the old git mirror stays available. Still, I have a local clone so I won't lose anything, I can even search in it.

I'd be interested in knowing how to do this, if you don't mind…

Aerion · 2015-07-14 16:35:17

WorMzy wrote:

Aerion wrote:
Would it be acceptable to migrate any packages not (yet) migrated by their maintainers, then orphan them immediately upon successful migration, solely to get them into the AUR4 ?
If you mean en-masse, then no. One of the reasons that the transition from AUR3 to AUR4 is being carried out as it is, is to clear out a lot of the dead wood[1]. The old PKGBUILDs that don't make it over will still be available for reference[2].

Most certainly not en-masse! More on a scratching-an-itch basis.

We only want users to resubmit their stuff if they want to take care of it in
the future. Think of it as a huge AUR cleanup.

That is precisely my point about not wanting to take the time vs not having the time to migrate someone else's package to the AUR4

On August 8th, the archive at
aur.archlinux.org will be replaced by aur4.archlinux.org and the former
aur.archlinux.org source tarballs will be made available for reference.

Just read that, after discovering the email I thought never got sent . Great stuff, it'll certainly help people porting 'forgotten' packages to the AUR4.

progandy · 2015-07-14 17:03:23

Aerion wrote:

By the way, I hope that at least the old git mirror stays available. Still, I have a local clone so I won't lose anything, I can even search in it.
I'd be interested in knowing how to do this, if you don't mind…

The mirror is mentioned here: https://wiki.archlinux.org/index.php/Ar … repository
Clone it e.g. with

git clone --bare git://pkgbuild.com/aur-mirror.git

Then you have different search commands: (Some things are easier if you keep a working tree around, but I didn't want to pollute my file system)

# search changes that contain a string/pattern
git log -S<searchstring>
git log -G<searchpattern>

# search current files 
git grep -e <pattern> HEAD

# get PKGBUILD
git archive HEAD <pkgname> | bsdtar -C /tmp/ -xf - 
cd /tmp/<pkgname>

Aerion · 2015-07-17 13:59:18

Thanks, progandy, for pointing me in the right direction, and even giving me a couple of usage tips, much appreciated!

Arch Linux

#26 2015-07-14 14:10:17

Re: [SOLVED] Error importing a packag into AUR4

#27 2015-07-14 14:19:38

Re: [SOLVED] Error importing a packag into AUR4

#28 2015-07-14 14:22:42

Re: [SOLVED] Error importing a packag into AUR4

#29 2015-07-14 14:25:48

Re: [SOLVED] Error importing a packag into AUR4

#30 2015-07-14 14:27:57

Re: [SOLVED] Error importing a packag into AUR4

#31 2015-07-14 14:41:32

Re: [SOLVED] Error importing a packag into AUR4

#32 2015-07-14 14:45:28

Re: [SOLVED] Error importing a packag into AUR4

#33 2015-07-14 14:46:22

Re: [SOLVED] Error importing a packag into AUR4

#34 2015-07-14 15:00:44

Re: [SOLVED] Error importing a packag into AUR4

#35 2015-07-14 15:08:27

Re: [SOLVED] Error importing a packag into AUR4

#36 2015-07-14 15:21:03

Re: [SOLVED] Error importing a packag into AUR4

#37 2015-07-14 16:23:37

Re: [SOLVED] Error importing a packag into AUR4

#38 2015-07-14 16:35:17

Re: [SOLVED] Error importing a packag into AUR4

#39 2015-07-14 17:03:23

Re: [SOLVED] Error importing a packag into AUR4

#40 2015-07-17 13:59:18

Re: [SOLVED] Error importing a packag into AUR4

Board footer