[aur-general] AUR 3.3.0 released
Hello, I am pleased to announce that AUR 3.3.0 has just been released. The official AUR setup [1] has already been updated. This release includes several improvements to the package request feature and a couple of bug fixes. For a comprehensive list of changes, please consult the Git log [2]. As usual, bugs should be reported to the AUR bug tracker [3]. [1] https://aur.archlinux.org/ [2] https://projects.archlinux.org/aur.git/log/?id=v3.3.0 [3] https://bugs.archlinux.org/index.php?project=2
Does anyone else think there is now just one thing missing from the "request" feature (or a different link)? I keep thinking "this package is broken" or "this package needs attention" (for reasons other than being out of date or abandoned), and there isn't a suitable button! Yes, the maintainer *should* be watching the comments, but that's very often not the case. Currently, I think my only choices are: 1. Flag as "to be orphaned" (even though I know the maintainer is still active) 2. Flag as "out of date" (even though it isn't) Examples might include: VCS packages that no longer build properly; or PKGBUILDs that do something unintentional (copy a file to the wrong directory, etc); or packages that don't build anymore because of a changed dependency. Just wondered if those would be considered reasons for flagging as "out of date", or if anyone agrees this would be useful to have? Thanks, Steven. On 5 July 2014 14:23, Lukas Fleischer <archlinux@cryptocrack.de> wrote:
Hello,
I am pleased to announce that AUR 3.3.0 has just been released. The official AUR setup [1] has already been updated.
This release includes several improvements to the package request feature and a couple of bug fixes.
For a comprehensive list of changes, please consult the Git log [2]. As usual, bugs should be reported to the AUR bug tracker [3].
[1] https://aur.archlinux.org/ [2] https://projects.archlinux.org/aur.git/log/?id=v3.3.0 [3] https://bugs.archlinux.org/index.php?project=2
On Sat, 2014-07-05 at 18:29 +0100, Steven Honeyman wrote:
Does anyone else think there is now just one thing missing from the "request" feature (or a different link)? I keep thinking "this package is broken" or "this package needs attention" (for reasons other than being out of date or abandoned), and there isn't a suitable button! Yes, the maintainer *should* be watching the comments, but that's very often not the case.
Currently, I think my only choices are: 1. Flag as "to be orphaned" (even though I know the maintainer is still active) 2. Flag as "out of date" (even though it isn't)
Examples might include: VCS packages that no longer build properly; or PKGBUILDs that do something unintentional (copy a file to the wrong directory, etc); or packages that don't build anymore because of a changed dependency.
Just wondered if those would be considered reasons for flagging as "out of date", or if anyone agrees this would be useful to have?
How about adding a "needs attention" checkbox when submitting a comment that, when checked, would email the maintainer and raise an "attention requested" flag on the package display page? The maintainer could check an "AR reset" checkbox when submitting his/her own comment, which would clear the flag. Carl
On 5 July 2014 14:23, Lukas Fleischer <archlinux@cryptocrack.de> wrote:
Hello,
I am pleased to announce that AUR 3.3.0 has just been released. The official AUR setup [1] has already been updated.
This release includes several improvements to the package request feature and a couple of bug fixes.
For a comprehensive list of changes, please consult the Git log [2]. As usual, bugs should be reported to the AUR bug tracker [3].
[1] https://aur.archlinux.org/ [2] https://projects.archlinux.org/aur.git/log/?id=v3.3.0 [3] https://bugs.archlinux.org/index.php?project=2
Carl Schaefer wrote:
How about adding a "needs attention" checkbox when submitting a comment that, when checked, would email the maintainer and raise an "attention requested" flag on the package display page? The maintainer could check an "AR reset" checkbox when submitting his/her own comment, which would clear the flag. Carl
This is calling for abuse. Almost everybody will consider their problem to be worth of attention. Maintainers should be subscribed to be notified of comments in their packages. If they're not, then they're not doing their job properly and requesting orphaning is justified IMO.
Wouldn't this push more work towards the AUR maintainers though? What actually happens when someone requests a package is to be orphaned? Can the package maintainer "un-request" it by doing something? I guess I just assumed (like the ML previously) that a bunch of people would get an email with the request in it - which nobody really wants to see! Definitely agree on the comment+checkbox idea being a bad one. As you said, everyone's problem would demand attention. Steven. On 5 July 2014 19:39, A Rojas <nqn1976list@gmail.com> wrote:
Carl Schaefer wrote:
How about adding a "needs attention" checkbox when submitting a comment that, when checked, would email the maintainer and raise an "attention requested" flag on the package display page? The maintainer could check an "AR reset" checkbox when submitting his/her own comment, which would clear the flag. Carl
This is calling for abuse. Almost everybody will consider their problem to be worth of attention. Maintainers should be subscribed to be notified of comments in their packages. If they're not, then they're not doing their job properly and requesting orphaning is justified IMO.
There are two types of comments imho: a) discussion about how the package should be improved, etc; b) the package doesn't build in some cases, which *needs* attention from the maintainer. Even in case the maintainer is subscribed to notifications, they can miss these b) kinds of comments if there are lots of discussion no the package. For this there should be a "flag not working" next to the "flag out of date" button. Just my two cents. r1pp3rj4ck On 07/05/2014 09:59 PM, Steven Honeyman wrote:
Wouldn't this push more work towards the AUR maintainers though? What actually happens when someone requests a package is to be orphaned? Can the package maintainer "un-request" it by doing something?
I guess I just assumed (like the ML previously) that a bunch of people would get an email with the request in it - which nobody really wants to see! Definitely agree on the comment+checkbox idea being a bad one. As you said, everyone's problem would demand attention.
Steven.
On 5 July 2014 19:39, A Rojas <nqn1976list@gmail.com> wrote:
Carl Schaefer wrote:
How about adding a "needs attention" checkbox when submitting a comment that, when checked, would email the maintainer and raise an "attention requested" flag on the package display page? The maintainer could check an "AR reset" checkbox when submitting his/her own comment, which would clear the flag. Carl
This is calling for abuse. Almost everybody will consider their problem to be worth of attention. Maintainers should be subscribed to be notified of comments in their packages. If they're not, then they're not doing their job properly and requesting orphaning is justified IMO.
The trouble is there are too many people that don't (or can't) think about *why* something might not be working. It's often the users' fault :) Suppose someone sets ld.gold as their default linker "because the internet told them it was better"... and then tries to compile imagemagick... Steven. On 8 July 2014 12:30, Attila Bukor <r1pp3rj4ck@w4it.eu> wrote:
There are two types of comments imho: a) discussion about how the package should be improved, etc; b) the package doesn't build in some cases, which *needs* attention from the maintainer.
Even in case the maintainer is subscribed to notifications, they can miss these b) kinds of comments if there are lots of discussion no the package. For this there should be a "flag not working" next to the "flag out of date" button. Just my two cents.
r1pp3rj4ck
On 07/05/2014 09:59 PM, Steven Honeyman wrote:
Wouldn't this push more work towards the AUR maintainers though? What actually happens when someone requests a package is to be orphaned? Can the package maintainer "un-request" it by doing something?
I guess I just assumed (like the ML previously) that a bunch of people would get an email with the request in it - which nobody really wants to see! Definitely agree on the comment+checkbox idea being a bad one. As you said, everyone's problem would demand attention.
Steven.
On 5 July 2014 19:39, A Rojas <nqn1976list@gmail.com> wrote:
Carl Schaefer wrote:
How about adding a "needs attention" checkbox when submitting a comment that, when checked, would email the maintainer and raise an "attention requested" flag on the package display page? The maintainer could check an "AR reset" checkbox when submitting his/her own comment, which would clear the flag. Carl
This is calling for abuse. Almost everybody will consider their problem to be worth of attention. Maintainers should be subscribed to be notified of comments in their packages. If they're not, then they're not doing their job properly and requesting orphaning is justified IMO.
On 07/08/2014 06:27 PM, Steven Honeyman wrote:
The trouble is there are too many people that don't (or can't) think about *why* something might not be working. It's often the users' fault :)
Suppose someone sets ld.gold as their default linker "because the internet told them it was better"... and then tries to compile imagemagick...
Steven.
What if it would be a vote-like structure and one reporter wouldn't be enough to flag it as not working? r1pp3rj4ck
On Wed, 09 Jul 2014 at 09:56:18, Attila Bukor wrote:
On 07/08/2014 06:27 PM, Steven Honeyman wrote:
The trouble is there are too many people that don't (or can't) think about *why* something might not be working. It's often the users' fault :)
Suppose someone sets ld.gold as their default linker "because the internet told them it was better"... and then tries to compile imagemagick...
Steven.
What if it would be a vote-like structure and one reporter wouldn't be enough to flag it as not working?
Dan suggested something similar some time ago [1] and I quite like that idea. One "Mark package broken" button and an option to sort package search results by the number of users that marked a package.
r1pp3rj4ck
[1] http://mailman.archlinux.org/pipermail/aur-dev/2011-June/001698.html
On 07/09/2014 10:15 AM, Lukas Fleischer wrote:
What if it would be a vote-like structure and one reporter wouldn't be enough to flag it as not working?
Dan suggested something similar some time ago [1] and I quite like that idea. One "Mark package broken" button and an option to sort package search results by the number of users that marked a package.
I see that there actually is a feature request FS#18829[1] for reporting broken packages. Maybe there should be an auto-orphan feature after x days/weeks if the package was out-of-date or being flagged for broken y times. Of course the maintainer should unflag or "unbreak" the package without updating it as we can now. The mark as broken should also be useful for stuff like when we switched for systemd. Many packages were (and probably still are) "broken" as they didn't conform the new infrastructure, yet - strictly speaking - they weren't out of date. Also, about Dan's idea... it's a great idea, but there is a problem with those 16k packages. Many of them weren't downloaded probably for years and no-one uses them, so no-one will flag them as sh*t.
r1pp3rj4ck
[1] http://mailman.archlinux.org/pipermail/aur-dev/2011-June/001698.html
Maybe there should be an auto-orphan feature after x days/weeks if the package was out-of-date or being flagged for broken y times.
Just reported https://bugs.archlinux.org/task/41140 Reference: https://mailman.archlinux.org/pipermail/aur-general/2014-May/028506.html Regarding out-of-date (not updated to the latest version), broken (build fails), incomplete (no systemd units), bad name (should be ruby-blah not rubyblah) or whatever else can be invented. The package needs to be updated no matter the reason for being flagged - thus, auto-orphaned so interested people can take care of it. Therefore I don't think differentiating between out-of-date, broken or whatever is useful for anything.
Many packages were (and probably still are) "broken" as they didn't conform the new infrastructure, yet - strictly speaking - they weren't out of date.
Think of "Flag package out-of-date" as "Package needs updating" not "Package version is out-of-date". -- Kind regards, Damian Nowak StratusHost www.AtlasHost.eu
On 09/07, Nowaker wrote:
Maybe there should be an auto-orphan feature after x days/weeks if the package was out-of-date or being flagged for broken y times.
Just reported https://bugs.archlinux.org/task/41140 Reference: https://mailman.archlinux.org/pipermail/aur-general/2014-May/028506.html
Regarding out-of-date (not updated to the latest version), broken (build fails), incomplete (no systemd units), bad name (should be ruby-blah not rubyblah) or whatever else can be invented. The package needs to be updated no matter the reason for being flagged - thus, auto-orphaned so interested people can take care of it. Therefore I don't think differentiating between out-of-date, broken or whatever is useful for anything.
The problem is that sometimes a package is out-of-date but can't be updated for various reasons. Like the openhexagon package, it's pretty much impossible to build it from scratch without replacing the build system with doing it manually in the PKGBUILD, and in the binary package of the new version there's tonnes of broken symlinks and weird conflicting files. (Someone complained about not being able to run it, he responded by copying the contents of his /usr/lib into the package.) I've tried to get it working properly, but it seem pretty much impossible. I've also tried to talk to upstream, but his answers basicaly came down to "I don't know cmake properly" and seems to have no intention of actually learning or listening. -- Sincerely, Johannes Löthberg PGP Key ID: 3A9D0BB5
On Wed, Jul 09, 2014 at 02:44:56PM +0200, Johannes Löthberg wrote:
On 09/07, Nowaker wrote:
... I don't think differentiating between out-of-date, broken or whatever is useful for anything.
The problem is that sometimes a package is out-of-date but can't be updated for various reasons.
I don't see the relevance to the point this seemed to be a response to. That package may be hard/impossible to maintain, true - but separate flags for 'out of date', 'broken', 'wont compile' wouldn't aid that situation any. In fact they might make it worse. I'd be concerned with having several such flags because most real life situations may not fit cleanly into one or the other flag category. So some users may flag the difficult to maintain package as "out of date", others might flag is as "broken", etc. Maintainers could even then use a passing-of-blame strategy to avoid doing anything: they can remove an "out of date" flag with the justification that it is not *technically* out of date, etc. If one flag just signifies that something is wrong that requires the maintainer's attention, it should be easier for users and for maintainers. -Jesse aka 'Trilby' on forums/AUR
I don't see the relevance to the point this seemed to be a response to. That package may be hard/impossible to maintain, true - but separate flags for 'out of date', 'broken', 'wont compile' wouldn't aid that situation any. In fact they might make it worse. Agreed
If one flag just signifies that something is wrong that requires the maintainer's attention, it should be easier for users and for maintainers. Yes, don't get hung up on a name. That button could just as easily have said: "Needs attention" and then it would cover all the bases.
-- Evert Vorster Chief Observer WG Cook
On Jul 9, 2014 8:59 AM, "Evert Vorster" <evorster@gmail.com> wrote:
I don't see the relevance to the point this seemed to be a response to. That package may be hard/impossible to maintain, true - but separate flags for 'out of date', 'broken', 'wont compile' wouldn't aid that situation any. In fact they might make it worse. Agreed
If one flag just signifies that something is wrong that requires the maintainer's attention, it should be easier for users and for maintainers. Yes, don't get hung up on a name. That button could just as easily have said: "Needs attention" and then it would cover all the bases.
Naming is important. Here's an idea: lets call them "comments". They can be freeform text so that you can explain why the package needs attention, rather than just pressing some weirdly labeled button and hoping the maintainer figures it out.
-- Evert Vorster Chief Observer WG Cook
On 9 July 2014 15:01, Dave Reisner <d@falconindy.com> wrote:
Naming is important. Here's an idea: lets call them "comments". They can be freeform text so that you can explain why the package needs attention, rather than just pressing some weirdly labeled button and hoping the maintainer figures it out.
+1. A very powerful solution indeed.
Naming is important. Here's an idea: lets call them "comments". They can be freeform text so that you can explain why the package needs attention, rather than just pressing some weirdly labeled button and hoping the maintainer figures it out.
+1. A very powerful solution indeed.
Good, but limit the number of characters allowed. Is there not already a comments to the packages in aur? -- Evert Vorster Chief Observer WG Cook
On 9 July 2014 15:08, Evert Vorster <evorster@gmail.com> wrote:
Naming is important. Here's an idea: lets call them "comments". They can be freeform text so that you can explain why the package needs attention, rather than just pressing some weirdly labeled button and hoping the maintainer figures it out.
+1. A very powerful solution indeed.
... Is there not already a comments to the packages in aur?
I'm pretty sure that that's what falconindy meant.
On Wed, 2014-07-09 at 14:08 +0100, Evert Vorster wrote:
Is there not already a comments to the packages in aur?
;) Good point :).
On 09/07, Dave Reisner wrote:
Naming is important. Here's an idea: lets call them "comments". They can be freeform text so that you can explain why the package needs attention, rather than just pressing some weirdly labeled button and hoping the maintainer figures it out.
Why is it even possible for maintainers to unsubscribe from comment emails of their packages? -- Sincerely, Johannes Löthberg PGP Key ID: 3A9D0BB5
On 09/07, Jesse McClure wrote:
On Wed, Jul 09, 2014 at 02:44:56PM +0200, Johannes Löthberg wrote:
On 09/07, Nowaker wrote:
... I don't think differentiating between out-of-date, broken or whatever is useful for anything.
The problem is that sometimes a package is out-of-date but can't be updated for various reasons.
I don't see the relevance to the point this seemed to be a response to. That package may be hard/impossible to maintain, true - but separate flags for 'out of date', 'broken', 'wont compile' wouldn't aid that situation any. In fact they might make it worse.
I was responding to auto-orphaning of all packages, even the ones that aren't out-of-date due to maintainer negligence, not specifically about having just one flag. -- Sincerely, Johannes Löthberg PGP Key ID: 3A9D0BB5
On Wed, Jul 09, 2014 at 03:31:10PM +0200, Johannes Löthberg wrote:
Why is it even possible for maintainers to unsubscribe from comment emails of their packages?
I wasn't aware of this possibility. That does not seem like a good idea to me either. Perhaps if any change is needed, we could just get rid of the 'flag out of date' button and remove the possibility to unsubscribe from comments. This way comments would be the unified mechanism of informing a maintainer that there attention is needed. On Wed, Jul 09, 2014 at 03:29:30PM +0200, Johannes Löthberg wrote:
I was responding to auto-orphaning of all packages ...
That makes more sense. Thanks. -Jesse aka 'Trilby'
On 07/09/2014 04:07 PM, Jesse McClure wrote:
On Wed, Jul 09, 2014 at 03:31:10PM +0200, Johannes Löthberg wrote:
Why is it even possible for maintainers to unsubscribe from comment emails of their packages?
I wasn't aware of this possibility. That does not seem like a good idea to me either. Perhaps if any change is needed, we could just get rid of the 'flag out of date' button and remove the possibility to unsubscribe from comments. This way comments would be the unified mechanism of informing a maintainer that there attention is needed.
I think it's ok for maintainers to opt out in case there's too much discussion in the comments, but at least they should receive a daily digest by default which they shouldn't be optional. r1pp3rj4ck
Perhaps if any change is needed, we could just get rid of the 'flag out of date' button and remove the possibility to unsubscribe from comments. This way comments would be the unified mechanism of informing a maintainer that there attention is needed.
Totally disagree. I always go to "My Packages" page to see if there's anything to take care of. That's because packages flagged out-of-date are red, which is awesome. Doing `for p in packages; do read latest comment done` manually doesn't sound like a good idea to me.
I think it's ok for maintainers to opt out in case there's too much discussion in the comments, but at least they should receive a daily digest by default which they shouldn't be optional.
The maintainer has to care about the discussion about their package. "Disable notifications" should point to "Disown package". <trollface/> -- Kind regards, Damian Nowak StratusHost www.AtlasHost.eu
There are three very recent instances I'd like to use in examples here where the situation "didn't seem right" regarding the Request/Flag out of date features: 1. mdocml[1] - The maintainer is a nice friendly guy, I've emailed him back and forth to help him with the recent issues... but he doesn't appear to subscribe to the comments, or have the free time to maintain the package fully. (i'm referencing the recent comments on it) P.S. it still isn't right, and yes, I have even provided him with a fixed PKGBUILD [2]... but as mentionned, he is busy elsewhere, and wrote in a comment "don't flag out of date if there is no new upstream version" 2. musl[3] - The maintainer is not willing/able to support clang users (all it really needs is a simple if/else adding for cflags). I submitted an orphan request, it was accepted[4] - but before I got home from work, he re-adopted the package and still hasn't fixed it! 3. pnmixer[5] - I'm now an active developer in this project and we've just finished updating it to gtk3 and fixed some major bugs. The package was already flagged out of date, so I submitted an orphan request, and it was rejected[6] stating "email the maintainer" - which seemed to be the opposite of what I was told by Lukas[7] Sorry that's a little bit link-heavy! Also thanks to the people that are working hard on improving the AUR - I've had many requests accepted in less than a couple of hours which is great, the above 3 I'm just highlighting as the "bad" occasions as they might help someone come up with an idea for how the process could become more refined. Thanks, Steven. [1] https://aur.archlinux.org/packages/mdocml/ [2] https://gist.github.com/stevenhoneyman/e1abfd3a434974b125bd [3] https://aur.archlinux.org/packages/musl [4] https://mailman.archlinux.org/pipermail/aur-requests/2014-July/000313.html [5] https://aur.archlinux.org/packages/pnmixer/ [6] https://mailman.archlinux.org/pipermail/aur-requests/2014-July/000307.html [7] https://mailman.archlinux.org/pipermail/aur-general/2014-July/029048.html On 9 July 2014 15:34, Nowaker <enwukaer@gmail.com> wrote:
Perhaps if any change is needed, we could just get rid of the 'flag out of date' button and remove the possibility to unsubscribe from comments. This way comments would be the unified mechanism of informing a maintainer that there attention is needed.
Totally disagree. I always go to "My Packages" page to see if there's anything to take care of. That's because packages flagged out-of-date are red, which is awesome. Doing `for p in packages; do read latest comment done` manually doesn't sound like a good idea to me.
I think it's ok for maintainers to opt out in case there's too much discussion in the comments, but at least they should receive a daily digest by default which they shouldn't be optional.
The maintainer has to care about the discussion about their package. "Disable notifications" should point to "Disown package". <trollface/>
-- Kind regards, Damian Nowak StratusHost www.AtlasHost.eu
On Wed, Jul 09, 2014 at 05:58:02PM +0100, Steven Honeyman wrote:
There are three very recent instances I'd like to use in examples here where the situation "didn't seem right" regarding the Request/Flag out of date features:
1. mdocml[1] - The maintainer is a nice friendly guy, I've emailed him back and forth to help him with the recent issues... but he doesn't appear to subscribe to the comments, or have the free time to maintain the package fully. (i'm referencing the recent comments on it) P.S. it still isn't right, and yes, I have even provided him with a fixed PKGBUILD [2]... but as mentionned, he is busy elsewhere, and wrote in a comment "don't flag out of date if there is no new upstream version"
Well, he's right. I see nothing resembling a "pending issue" here, so clearly the current workflow was successful. This is orthogonal to the idea that it could be improved.
2. musl[3] - The maintainer is not willing/able to support clang users (all it really needs is a simple if/else adding for cflags). I submitted an orphan request, it was accepted[4] - but before I got home from work, he re-adopted the package and still hasn't fixed it!
Wow, really? That's a seriously dick move on your part. The maintainer has chosen to make the package work with the Arch defaults. That you want to add extra complexity to support non-standard setups is something that he's entirely in the right to ignore. *You* should be the one accepting the extra burden.
3. pnmixer[5] - I'm now an active developer in this project and we've just finished updating it to gtk3 and fixed some major bugs. The package was already flagged out of date, so I submitted an orphan request, and it was rejected[6] stating "email the maintainer" - which seemed to be the opposite of what I was told by Lukas[7]
Seems like a matter of broken human processes. The maintainer seems idle, with their last login being ~6 months ago.
Sorry that's a little bit link-heavy! Also thanks to the people that are working hard on improving the AUR - I've had many requests accepted in less than a couple of hours which is great, the above 3 I'm just highlighting as the "bad" occasions as they might help someone come up with an idea for how the process could become more refined.
Just remember that it's a two way street...
Thanks, Steven.
[1] https://aur.archlinux.org/packages/mdocml/ [2] https://gist.github.com/stevenhoneyman/e1abfd3a434974b125bd [3] https://aur.archlinux.org/packages/musl [4] https://mailman.archlinux.org/pipermail/aur-requests/2014-July/000313.html [5] https://aur.archlinux.org/packages/pnmixer/ [6] https://mailman.archlinux.org/pipermail/aur-requests/2014-July/000307.html [7] https://mailman.archlinux.org/pipermail/aur-general/2014-July/029048.html
On 9 July 2014 15:34, Nowaker <enwukaer@gmail.com> wrote:
Perhaps if any change is needed, we could just get rid of the 'flag out of date' button and remove the possibility to unsubscribe from comments. This way comments would be the unified mechanism of informing a maintainer that there attention is needed.
Totally disagree. I always go to "My Packages" page to see if there's anything to take care of. That's because packages flagged out-of-date are red, which is awesome. Doing `for p in packages; do read latest comment done` manually doesn't sound like a good idea to me.
I think it's ok for maintainers to opt out in case there's too much discussion in the comments, but at least they should receive a daily digest by default which they shouldn't be optional.
The maintainer has to care about the discussion about their package. "Disable notifications" should point to "Disown package". <trollface/>
-- Kind regards, Damian Nowak StratusHost www.AtlasHost.eu
1. The man pages are installed in /usr/share/man1 instead of /usr/share/man/man1 (etc) in the current PKGBUILD. Don't guess based on something you haven't tried or tested. 2. I couldn't care less about clang right now. I've never used it. I aim to support as many configurations as possible though. If it was a "dick move" then it should have been rejected. On 9 July 2014 18:18, Dave Reisner <d@falconindy.com> wrote:
On Wed, Jul 09, 2014 at 05:58:02PM +0100, Steven Honeyman wrote:
There are three very recent instances I'd like to use in examples here where the situation "didn't seem right" regarding the Request/Flag out of date features:
1. mdocml[1] - The maintainer is a nice friendly guy, I've emailed him back and forth to help him with the recent issues... but he doesn't appear to subscribe to the comments, or have the free time to maintain the package fully. (i'm referencing the recent comments on it) P.S. it still isn't right, and yes, I have even provided him with a fixed PKGBUILD [2]... but as mentionned, he is busy elsewhere, and wrote in a comment "don't flag out of date if there is no new upstream version"
Well, he's right. I see nothing resembling a "pending issue" here, so clearly the current workflow was successful. This is orthogonal to the idea that it could be improved.
2. musl[3] - The maintainer is not willing/able to support clang users (all it really needs is a simple if/else adding for cflags). I submitted an orphan request, it was accepted[4] - but before I got home from work, he re-adopted the package and still hasn't fixed it!
Wow, really? That's a seriously dick move on your part. The maintainer has chosen to make the package work with the Arch defaults. That you want to add extra complexity to support non-standard setups is something that he's entirely in the right to ignore. *You* should be the one accepting the extra burden.
3. pnmixer[5] - I'm now an active developer in this project and we've just finished updating it to gtk3 and fixed some major bugs. The package was already flagged out of date, so I submitted an orphan request, and it was rejected[6] stating "email the maintainer" - which seemed to be the opposite of what I was told by Lukas[7]
Seems like a matter of broken human processes. The maintainer seems idle, with their last login being ~6 months ago.
Sorry that's a little bit link-heavy! Also thanks to the people that are working hard on improving the AUR - I've had many requests accepted in less than a couple of hours which is great, the above 3 I'm just highlighting as the "bad" occasions as they might help someone come up with an idea for how the process could become more refined.
Just remember that it's a two way street...
Thanks, Steven.
[1] https://aur.archlinux.org/packages/mdocml/ [2] https://gist.github.com/stevenhoneyman/e1abfd3a434974b125bd [3] https://aur.archlinux.org/packages/musl [4] https://mailman.archlinux.org/pipermail/aur-requests/2014-July/000313.html [5] https://aur.archlinux.org/packages/pnmixer/ [6] https://mailman.archlinux.org/pipermail/aur-requests/2014-July/000307.html [7] https://mailman.archlinux.org/pipermail/aur-general/2014-July/029048.html
On 9 July 2014 15:34, Nowaker <enwukaer@gmail.com> wrote:
Perhaps if any change is needed, we could just get rid of the 'flag out of date' button and remove the possibility to unsubscribe from comments. This way comments would be the unified mechanism of informing a maintainer that there attention is needed.
Totally disagree. I always go to "My Packages" page to see if there's anything to take care of. That's because packages flagged out-of-date are red, which is awesome. Doing `for p in packages; do read latest comment done` manually doesn't sound like a good idea to me.
I think it's ok for maintainers to opt out in case there's too much discussion in the comments, but at least they should receive a daily digest by default which they shouldn't be optional.
The maintainer has to care about the discussion about their package. "Disable notifications" should point to "Disown package". <trollface/>
-- Kind regards, Damian Nowak StratusHost www.AtlasHost.eu
On Wed, Jul 09, 2014 at 06:28:21PM +0100, Steven Honeyman wrote:
1. The man pages are installed in /usr/share/man1 instead of /usr/share/man/man1 (etc) in the current PKGBUILD. Don't guess based on something you haven't tried or tested.
I'm going by the comments. If there's (still) a problem, you haven't brought it up in the past 4 days since the maintainer updated the package. Orphaning the package in this case isn't reasonable.
2. I couldn't care less about clang right now. I've never used it. I aim to support as many configurations as possible though. If it was a "dick move" then it should have been rejected.
You clearly do care, otherwise you wouldn't have: a) tried to hijack the package b) brought it up here Please don't top post.
On 9 July 2014 18:39, Dave Reisner <d@falconindy.com> wrote:
I'm going by the comments. If there's (still) a problem, you haven't brought it up in the past 4 days since the maintainer updated the package. Orphaning the package in this case isn't reasonable.
I have, just through e-mail directly to the maintainer. I didn't request it was to be orphaned; someone flagged it as "out of date" because there was no other option to click such as "needs fixing" (which is how this discussion started...)
You clearly do care, otherwise you wouldn't have: a) tried to hijack the package b) brought it up here
My AUR packages don't support/aren't tested with clang... but if someone commented on one requesting and explaining a simple change so that more people are able to use it, then I would implement it.
On 09/07, Steven Honeyman wrote:
You clearly do care, otherwise you wouldn't have: a) tried to hijack the package b) brought it up here
My AUR packages don't support/aren't tested with clang... but if someone commented on one requesting and explaining a simple change so that more people are able to use it, then I would implement it.
Hijacking aside, there's a bug in some recent gcc's (reported in 4.8.2 and 4.9.0) which is avoided by that extra CFLAG. -- Sincerely, Johannes Löthberg PGP Key ID: 3A9D0BB5
On 09/07, Johannes Löthberg wrote:
On 09/07, Steven Honeyman wrote:
You clearly do care, otherwise you wouldn't have: a) tried to hijack the package b) brought it up here
My AUR packages don't support/aren't tested with clang... but if someone commented on one requesting and explaining a simple change so that more people are able to use it, then I would implement it.
Hijacking aside, there's a bug in some recent gcc's (reported in 4.8.2 and 4.9.0) which is avoided by that extra CFLAG.
And interestingly enough there's even a comment on the package about just this. -- Sincerely, Johannes Löthberg PGP Key ID: 3A9D0BB5
On Wed, 9 Jul 2014 19:00:10 +0100 Steven Honeyman <stevenhoneyman@gmail.com> wrote:
On 9 July 2014 18:39, Dave Reisner <d@falconindy.com> wrote:
I'm going by the comments. If there's (still) a problem, you haven't brought it up in the past 4 days since the maintainer updated the package. Orphaning the package in this case isn't reasonable.
I have, just through e-mail directly to the maintainer. I didn't request it was to be orphaned; someone flagged it as "out of date" because there was no other option to click such as "needs fixing" (which is how this discussion started...)
Yes, I have accepted the request, then realized it's completely untrue and asked the maintainer to re-adopt it. Additionally I'm the one who flagged the package because, obviously, there is a newer release, not because it's broken. Do you really see the point in fixing compilation using clang when literally nothing in PKGBUILD references it? I do not. Please stop wasting time, either people's and yours. -- Bartłomiej Piotrowski http://bpiotrowski.pl/
On 9 July 2014 20:37, Bartłomiej Piotrowski <b@bpiotrowski.pl> wrote:
Yes, I have accepted the request, then realized it's completely untrue and asked the maintainer to re-adopt it. Additionally I'm the one who flagged the package because, obviously, there is a newer release, not because it's broken. Do you really see the point in fixing compilation using clang when literally nothing in PKGBUILD references it? I do not.
Please stop wasting time, either people's and yours.
-- Bartłomiej Piotrowski http://bpiotrowski.pl/
That makes less sense than falconandy's responses. Firstly, musl 1.0.3 was released June 6th [1]. The AUR package was updated to this version on June 7th [2] - there is not a newer release, and 1.0.3 is still the current stable version. So if you did flag as out of date, it's *you* wasting his time. As for your second point, that's as stupid as saying "literally nothing in the linux kernel references <brand new laptop> so there's no point in fixing drivers for it" [1] http://git.musl-libc.org/cgit/musl/commit/?h=rs-1.0&id=30bd499ae1f62e9d2fad4282d42057083709e0eb [2] http://pkgbuild.com/git/aur-mirror.git/commit/musl/PKGBUILD?id=5588dabbf0bc6...
On Wed, 9 Jul 2014 21:03:51 +0100 Steven Honeyman <stevenhoneyman@gmail.com> wrote:
On 9 July 2014 20:37, Bartłomiej Piotrowski <b@bpiotrowski.pl> wrote:
Yes, I have accepted the request, then realized it's completely untrue and asked the maintainer to re-adopt it. Additionally I'm the one who flagged the package because, obviously, there is a newer release, not because it's broken. Do you really see the point in fixing compilation using clang when literally nothing in PKGBUILD references it? I do not.
Please stop wasting time, either people's and yours.
-- Bartłomiej Piotrowski http://bpiotrowski.pl/
That makes less sense than falconandy's responses.
Firstly, musl 1.0.3 was released June 6th [1]. The AUR package was updated to this version on June 7th [2] - there is not a newer release, and 1.0.3 is still the current stable version. So if you did flag as out of date, it's *you* wasting his time.
As for your second point, that's as stupid as saying "literally nothing in the linux kernel references <brand new laptop> so there's no point in fixing drivers for it"
[1] http://git.musl-libc.org/cgit/musl/commit/?h=rs-1.0&id=30bd499ae1f62e9d2fad4282d42057083709e0eb [2] http://pkgbuild.com/git/aur-mirror.git/commit/musl/PKGBUILD?id=5588dabbf0bc6...
If only you were curious enough to actually use musl at least once it would be clear to you that the branch naming scheme used by upstream is at least misleading. Whatever you do 1.1.x is newer than 1.0 and in many cases is more useful. But sure, better whine about clang and make unrelated comparison to developemnt of drivers in Linux kernel. Good luck, you are going to need it a lot. -- Bartłomiej Piotrowski http://bpiotrowski.pl/
On 9 July 2014 21:28, Bartłomiej Piotrowski <b@bpiotrowski.pl> wrote:
If only you were curious enough to actually use musl at least once it would be clear to you that the branch naming scheme used by upstream is at least misleading. Whatever you do 1.1.x is newer than 1.0 and in many cases is more useful.
But sure, better whine about clang and make unrelated comparison to developemnt of drivers in Linux kernel. Good luck, you are going to need it a lot.
-- Bartłomiej Piotrowski http://bpiotrowski.pl/
"treat others as you would be treated; respect them and their views, even if you disagree with them." - Arch Wiki Are you really that ignorant/stupid/insulting? Here let me help you: (from http://www.musl-libc.org/download.html) ----------------------- Current Versions Mainline - 1.1.3 Stable - 1.0.3 ----------------------- Oh! did I forget to mention that it helps if you use bother to use the search facility once in a while. Click this: https://aur.archlinux.org/packages/musl-latest/ ...and check the submitter/maintainer/packager Steven. (aka stevenhoneyman if you STILL haven't realised!)
On Wed, 9 Jul 2014 21:39:50 +0100 Steven Honeyman <stevenhoneyman@gmail.com> wrote:
"treat others as you would be treated; respect them and their views, even if you disagree with them." - Arch Wiki
Thanks for making me realize that I'm the one who's trying to outsmart everyone on aur-general and is so rude to say that your response makes no sense.
Are you really that ignorant/stupid/insulting? Here let me help you:
(from http://www.musl-libc.org/download.html) ----------------------- Current Versions Mainline - 1.1.3 Stable - 1.0.3 -----------------------
Oh boy, how could I miss it! I'm not a contributor to a musl-based project and without your help I wouldn't find the website of this so-funny-named library I always wanted to compile with clang.
Oh! did I forget to mention that it helps if you use bother to use the search facility once in a while. Click this: https://aur.archlinux.org/packages/musl-latest/
...and check the submitter/maintainer/packager
Steven. (aka stevenhoneyman if you STILL haven't realised!)
I'll consider it as a merge request, as it should be named either musl-dev or musl-mainline. Fortunately the latter has been already submitted, so guess what I'm going to do. Now the peace has returned to my life. Take this as an EOT from my side. -- Bartłomiej Piotrowski http://bpiotrowski.pl/
On Wednesday, July 09, 2014 09:39:50 PM Steven Honeyman wrote:
On 9 July 2014 21:28, Bartłomiej Piotrowski <b@bpiotrowski.pl> wrote:
If only you were curious enough to actually use musl at least once it would be clear to you that the branch naming scheme used by upstream is at least misleading. Whatever you do 1.1.x is newer than 1.0 and in many cases is more useful.
But sure, better whine about clang and make unrelated comparison to developemnt of drivers in Linux kernel. Good luck, you are going to need it a lot.
-- Bartłomiej Piotrowski http://bpiotrowski.pl/
"treat others as you would be treated; respect them and their views, even if you disagree with them." - Arch Wiki
Are you really that ignorant/stupid/insulting? Here let me help you:
(from http://www.musl-libc.org/download.html) ----------------------- Current Versions Mainline - 1.1.3 Stable - 1.0.3 -----------------------
Not to butt-in, but based on the website's description of the Mainline branch, that is the one that should be packaged by default, and the Stable branch should be the special case. "Mainline - 1.1.3 This series is actively developed but intended for use in production environments as long as appropriate testing is performed, and should be preferred whenever there is a need for supporting an arbitrary, expanding set of packages or environments."[1] "Stable - 1.0.3 This series does not add new features and avoids changes that might affect building packages against musl or using applications in environments where they are already known to work. It is intended mostly for developers targetting a fixed profile of application software and kernel, such as in embedded development. "[1]
Oh! did I forget to mention that it helps if you use bother to use the search facility once in a while. Click this: https://aur.archlinux.org/packages/musl-latest/
...and check the submitter/maintainer/packager
Steven. (aka stevenhoneyman if you STILL haven't realised!)
On Wed, 09 Jul 2014 16:34:20 +0200 Nowaker <enwukaer@gmail.com> wrote:
I think it's ok for maintainers to opt out in case there's too much discussion in the comments, but at least they should receive a daily digest by default which they shouldn't be optional.
The maintainer has to care about the discussion about their package. "Disable notifications" should point to "Disown package". <trollface/>
I agree with this sentiment. If a package owner finds the occasional email comment about their package to be too much of a bother, sounds like disowning is in order. I don't think you should be able to unsubscribe from the email. And if the email bounces, the package should be automagically disowned. -- Jonathan Arnold Webstream: http://hieronymus.soup.io If you want to go fast, go alone. If you want to go far, you need a team ~ John Wooden
On 9 July 2014 21:40, Jonathan Arnold <jdarnold@buddydog.org> wrote:
And if the email bounces, the package should be automagically disowned.
Not a good idea, if there was a temporary problem with a mailserver it would result in unsolicited orphaning of packages.
On 09.07.2014 22:20, Lukas Jirkovsky wrote:
On 9 July 2014 21:40, Jonathan Arnold <jdarnold@buddydog.org> wrote:
And if the email bounces, the package should be automagically disowned.
Not a good idea, if there was a temporary problem with a mailserver it would result in unsolicited orphaning of packages.
Email doesn't bounce because of temporary issues, otherwise stuff like graylisting would be even more annoying than it already is. Normal retry times are 3 to 5 days with 5 being the postfix (and probably other software) default. If a mail couldn't be delivered after that time the sending server will bounce it.
On 09/07, Florian Pritz wrote:
On 09.07.2014 22:20, Lukas Jirkovsky wrote:
On 9 July 2014 21:40, Jonathan Arnold <jdarnold@buddydog.org> wrote:
And if the email bounces, the package should be automagically disowned.
Not a good idea, if there was a temporary problem with a mailserver it would result in unsolicited orphaning of packages.
Email doesn't bounce because of temporary issues, otherwise stuff like graylisting would be even more annoying than it already is.
Normal retry times are 3 to 5 days with 5 being the postfix (and probably other software) default. If a mail couldn't be delivered after that time the sending server will bounce it.
Still seems excessive from just bouncing once. Having an email sent to one of the AUR mailinglists seems like a better option, that way it can be investigated if the maintainer really is gone or if he just forgot to update his email on the AUR. -- Sincerely, Johannes Löthberg PGP Key ID: 3A9D0BB5
participants (16)
-
A Rojas
-
Attila Bukor
-
Bartłomiej Piotrowski
-
Carl Schaefer
-
Dave Reisner
-
Evert Vorster
-
Florian Pritz
-
Jesse McClure
-
Johannes Löthberg
-
Jonathan Arnold
-
Kevin Ott
-
Lukas Fleischer
-
Lukas Jirkovsky
-
Nowaker
-
Ralf Mardorf
-
Steven Honeyman