You are not logged in.
Hi all,
I've uploaded package on aur in january, but it is not listed when I search for it
https://aur.archlinux.org/cgit/aur.git/ … ings-0.2.2
https://aur.archlinux.org/cgit/aur.git/ … auth-0.5.4
Probably I've missed some command for it, can someone help me to understand and fix it?
Thanks
Last edited by valantin (2018-03-13 17:25:26)
Offline
I can't find any record of a removal/rejection of those packages - but it would have been called for.
Those packages are already in the AUR and maintained. Apparently you believe they are out of date, but they have not been flagged out of date, commented on. So why did you try to just upload your own version instead of fixing what was already there?
EDIT: it looks like one of them is out of date - but the other is current and exactly the same version that you tried to submit. On a related note, version numbers should not be in the package name - that just results in a need to delete them as soon as there is an update (so maybe someone was proactive and deleted these now).
Last edited by Trilby (2018-03-13 14:18:28)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
I've upload fixed version for these package because I need it as dependency for other package to stay at a fixed version.
related to your note, following this wiki page I've do the correct things (in my mind for my usecase)
https://wiki.archlinux.org/index.php/Ru … d_packages
regards Bob
EDIT recheck my PGKBUILD I've used the correct pkgname
Last edited by valantin (2018-03-13 14:34:12)
Offline
I've upload fixed version for these package because I need it as dependency for other package to stay at a fixed version.
Then you specify a versioned dependency in that other package, that's all. You still don't put version numbers in package names (I just rechecked ... it's there), you also don't submit new packages for something that is already in the AUR. You can do whatever you want on your own computer, but submitting these to the AUR is for others to use, not just you; and at that point you're expected to follow some community standards.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
https://lists.archlinux.org/pipermail/a … 22607.html
https://lists.archlinux.org/pipermail/a … 22437.html
If you would like to continue creating updated duplicates of existing out-of-date packages, I will suspend your account. If you create outdated slot packages like ruby-activesupport-4.2.10, that is perfectly okay as the gemspec for occi-cli requires it...
As the Wiki article says:
An exception for this rule is when "approximately greater" dependency matches the latest version of the gem - in this case avoid introducing a new versioned package and use just ruby-$gemname instead (the HEAD version).
Finally, *all* your ruby packages are broken as they erroneously claim to conflict against the non-versioned edition, even though Gem packages can coexist. See for example https://github.com/anatol/quarry/
Also the Wiki article explicitly tells you to remove conflicting files in /usr/bin to prevent conflicts...
Last edited by eschwartz (2018-03-13 16:29:20)
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
https://lists.archlinux.org/pipermail/a … 22607.html
https://lists.archlinux.org/pipermail/a … 22437.htmlIf you would like to continue creating updated duplicates of existing out-of-date packages, I will suspend your account. If you create outdated slot packages like ruby-activesupport-4.2.10, that is perfectly okay as the gemspec for occi-cli requires it...
As the Wiki article says:
An exception for this rule is when "approximately greater" dependency matches the latest version of the gem - in this case avoid introducing a new versioned package and use just ruby-$gemname instead (the HEAD version).
Finally, *all* your ruby packages are broken as they erroneously claim to conflict against the non-versioned edition, even though Gem packages can coexist. See for example https://github.com/anatol/quarry/
Also the Wiki article explicitly tells you to remove conflicting files in /usr/bin to prevent conflicts...
thanks for the explanation and sorry for my bad behavior
I want to fix my packages, can you help me to do the right things.
I see you mark occi-core outdated but version 4.3.6 is needed by occi-cli and occi-api, the developer have pushed the 5.0 version but not new occi-cli and occi-api, so occi-core 5.0 broke the occi client. what to do? update occi-core and create occi-core-4.3.6 to provide the correct occi-core version to use the client?
for fixing versioned package, activesupport and hashie not use /usr/bin, so to "fix" I can just remove the conflict?
What is the correct flow to adopt the packages if the maintainer don't update it?
thanks again,
regards bob
Offline
BTW you should have gotten an email for the initial deletion requests, so I expected you to have already seen:
Eschwartz [1] filed a deletion request for ruby-apipie-bindings-0.2.2[2]:
duplicate of ruby-apipie-bindings
Please flag outdated packages as out of date and if necessary file an
orphan request -- don't add needles slotted packages to the AUR as a
workaround for upgrading to the latest version.
If occi-core cannot be updated yet, maybe you could ask upstream to release a new version? Meanwhile, you could just leave it out of date for now, e.g. with a comment explaining why.
ruby-awesome_print is even orphaned, so you can just adopt it... for the rest, if the maintainers do not update their packages in a week or two you can submit an orphan request so you can take over. This is not hard.
for fixing versioned package, activesupport and hashie not use /usr/bin, so to "fix" I can just remove the conflict?
Before adding a conflict, you should test to see if they actually provide any of the same files. But yes, in this case the fact that they only provide the standard ruby versioned ruby modules means it is easy to test, so yes you can just remove the conflict.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
BTW you should have gotten an email for the initial deletion requests, so I expected you to have already seen:
Eschwartz [1] filed a deletion request for ruby-apipie-bindings-0.2.2[2]:
duplicate of ruby-apipie-bindings
Please flag outdated packages as out of date and if necessary file an
orphan request -- don't add needles slotted packages to the AUR as a
workaround for upgrading to the latest version.If occi-core cannot be updated yet, maybe you could ask upstream to release a new version? Meanwhile, you could just leave it out of date for now, e.g. with a comment explaining why.
ruby-awesome_print is even orphaned, so you can just adopt it... for the rest, if the maintainers do not update their packages in a week or two you can submit an orphan request so you can take over. This is not hard.
for fixing versioned package, activesupport and hashie not use /usr/bin, so to "fix" I can just remove the conflict?
Before adding a conflict, you should test to see if they actually provide any of the same files. But yes, in this case the fact that they only provide the standard ruby versioned ruby modules means it is easy to test, so yes you can just remove the conflict.
I need to change my filter, I don't read the mail, sorry.
for occi, it's a problem to have version update , they just follow egi repo so if is correct here nobody claim. it's hard to have deb package to ...
awesome_print adopted thanks.
I've think I do something wrong, I've request to orphaned httparty, not updated since 2015, commented activesupport with update request, commented occi-core but erroneously remove outdated flag
thanks Eschwartz
regards bob
Offline
awesome_print is not an x86_64/i686 package, it is an any package. It doesn't contain a compiled C extension in the gemspec's "spec.extensions".
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
awesome_print is not an x86_64/i686 package, it is an any package. It doesn't contain a compiled C extension in the gemspec's "spec.extensions".
fixed
Offline