- Aur-general - lists.archlinux.org

[aur-general] shotwell...
by oliver 10 Apr '12

10 Apr '12

Hello, shotwell is here: http://www.archlinux.org/packages/community/i686/shotwell/ and it's marked out of date. And shotwell also is here: http://aur.archlinux.org/packages.php?ID=48503 Here I don't know if it's up to date... But it uses git,.. can this just be rebuilt from git, even the package itsels is old? Also it confuses me that shotwell is on http://www.archlinux.org as well as http://aur.archlinux.org Can you explain me this? And: can the package maintainers be reminded to update? Shotwell 0.12.1 is out since a whiole and maybe even a newer verison (0.13.x) is underway... Ciao, Oliver

6 12

Re: [aur-general] Automated Package Removal
by Daniel Campbell 09 Apr '12

09 Apr '12

Are you being glib? I achieved what I was aiming for (deleting a package). Given the reponse I got on my observation ('patches welcome'), I don't feel inclined to go through another hoop in yet another department just to be told 'no, do it yourself and we _might_ consider it'. No sense in repeating the popular opinion in another format. And if most people are happy with the bureaucracy, who am I to change it? It's not my project or my website. I carry no clout or weight among the staff. It would be a waste of time to submit a feature request for something that is clearly against the consensus. I'd have more luck forking the AUR and hacking it privately, assuming I felt passionately enough about it to spend even more time on the issue. Tldr: no, it won't achieve anything. Sent from my Nokia phone -----Original Message----- From: Karol Blazewicz Sent: 2012-04-09 17:40:55 Subject: Re: [aur-general] Automated Package Removal On Mon, Apr 9, 2012 at 10:38 PM, Daniel Campbell <dlcampbell(a)gmx.com> wrote: > Most systems already do the paper-trailing for us. They're known as logs. Yup. Even if regular users don't have access to said log, asking a TU once in a blue moon to check wtf is/was going on with some package is OK. Have you opened a feature request on the bugtracker for this?

1 0

Re: [aur-general] Automated Package Removal
by Daniel Campbell 09 Apr '12

09 Apr '12

Most systems already do the paper-trailing for us. They're known as logs. ----- Original Message ----- From: Karol Blazewicz Sent: 04/09/12 04:23 PM To: dlcampbell(a)gmx.com, Discussion about the Arch User Repository (AUR) Subject: Re: [aur-general] Automated Package Removal On Mon, Apr 9, 2012 at 8:16 PM, Daniel Campbell <dlcampbell(a)gmx.com> wrote: >> It would also contribute less clutter to the mailing list and less hassle for people that make innocuous mistakes like mine. Bureaucracy cripples everything. > Yes, it's annoying (and inefficient and illogical) to require someone to sign up to another service to ask for something to be done on the service they're having issue with. Departmentalizing things is a sign of bureaucracy. Most people dislike it in government, hospitals, business, and other institutions; why on Earth would we voluntarily do it in FOSS? Especially when the majority of problems (e.g. Deleting packages) can be solved by a machine. The 'paper trail' in bureaucracy is often used for accountability purpose. > Politics aside, I agree that a grace period would be good. But perhaps a little longer than a single day? Maybe 3-7 days, to account for real life getting in the way. You say you didn't properly test the package and you need up to a week to fix it? I guess the current system allows for such things too (albeit via a TU) so why not ...

1 0

Re: [aur-general] Automated Package Removal
by Karol Blazewicz 09 Apr '12

09 Apr '12

On Mon, Apr 9, 2012 at 8:16 PM, Daniel Campbell <dlcampbell(a)gmx.com> wrote: >> It would also contribute less clutter to the mailing list and less hassle for people that make innocuous mistakes like mine. Bureaucracy cripples everything. > Yes, it's annoying (and inefficient and illogical) to require someone to sign up to another service to ask for something to be done on the service they're having issue with. Departmentalizing things is a sign of bureaucracy. Most people dislike it in government, hospitals, business, and other institutions; why on Earth would we voluntarily do it in FOSS? Especially when the majority of problems (e.g. Deleting packages) can be solved by a machine. The 'paper trail' in bureaucracy is often used for accountability purpose. > Politics aside, I agree that a grace period would be good. But perhaps a little longer than a single day? Maybe 3-7 days, to account for real life getting in the way. You say you didn't properly test the package and you need up to a week to fix it? I guess the current system allows for such things too (albeit via a TU) so why not ...

1 0

Re: [aur-general] Automated Package Removal
by Daniel Campbell 09 Apr '12

09 Apr '12

Yes, it's annoying (and inefficient and illogical) to require someone to sign up to another service to ask for something to be done on the service they're having issue with. Departmentalizing things is a sign of bureaucracy. Most people dislike it in government, hospitals, business, and other institutions; why on Earth would we voluntarily do it in FOSS? Especially when the majority of problems (e.g. Deleting packages) can be solved by a machine. Politics aside, I agree that a grace period would be good. But perhaps a little longer than a single day? Maybe 3-7 days, to account for real life getting in the way. Another thing came to me as I was thinking about this issue. People that adopt an orphan package are able to upload a new src tarball, right? If so, then perhaps all that needs to be done is expanding the table to indicate which user created the package (first uploaded it) and give them permission to delete for the given grace period. I assume the required 'infrastructure' such as upload timestamps, user permissions, etc are in place already. Just an idea. Sent from my Nokia phone -----Original Message----- From: Xyne Sent: 2012-04-09 13:15:13 To: aur-general(a)archlinux.org Cc: dlcampbell(a)gmx.com Subject: Re: [aur-general] Automated Package Removal > It would also contribute less clutter to the mailing list and less hassle for people that make innocuous mistakes like mine. Bureaucracy cripples everything. Is it really "crippling" to send an email to this list to request deletion? Regardless, I'm not against allowing submitters to delete their own packages, but there should probably be some time limit to prevent abuse, e.g. within 24 hours of submission.

1 0

Re: [aur-general] Automated Package Removal
by Xyne 09 Apr '12

09 Apr '12

> It would also contribute less clutter to the mailing list and less hassle for people that make innocuous mistakes like mine. Bureaucracy cripples everything. Is it really "crippling" to send an email to this list to request deletion? Regardless, I'm not against allowing submitters to delete their own packages, but there should probably be some time limit to prevent abuse, e.g. within 24 hours of submission.

1 0

[aur-general] rednotebook package
by Dmitry Korzhevin 09 Apr '12

09 Apr '12

Hello, guys I am maintainer of rednotebook package in AUR: https://aur.archlinux.org/packages.php?ID=21984 I owned and updating this package about a year, and now i wish to maintain this package in official Community repository in Arch Linux. How can i do this, and what i need to do? Here is some of my contributions on Arch Wiki: https://wiki.archlinux.org/index.php?title=Special:Contributions&dir=prev&o… Also i have some packages in AUR. And subscribed to all arch linux mailing lists. My nickname in arch linux irc channels: dkorzhevin Please, give me advice -- Best regards, Dmitry Korzhevin Tel: +38 (039) 295-0000 Office Phone: +38 (044) 383-14-12 E-mail: dkorzhevin(a)lsupport.net Jabber ID: dkorzhevin(a)lsupport.net Skype: dkorzhevin URL: http://lsupport.net Linux Support LLC

2 1

Re: [aur-general] Automated Package Removal
by Allan McRae 09 Apr '12

09 Apr '12

On 09/04/12 17:56, Daniel Campbell wrote: > I would contribute if a. My dev machine had internet and b. If i thought my work had a chance of being considered. Given that I'm not a TU or a regular among the devs, my work would not likely be accepted. What a load of crap... Everyone submitted their first patch at one stage.

2 1

[aur-general] Signoff report for [community-testing]
by Arch Website Notification 09 Apr '12

09 Apr '12

=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 2 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 0 fully signed off packages * 16 packages missing signoffs * 5 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [community-testing] in last 24 hours (2 total) == * libgexiv2-0.4.1-2 (i686) * libgexiv2-0.4.1-2 (x86_64) == Incomplete signoffs for [community] (16 total) == * avr-libc-1.8.0-3 (any) 0/2 signoffs * pacman-contrib-4.0.3-1 (any) 0/2 signoffs * avr-binutils-2.22-3 (i686) 0/2 signoffs * avr-gcc-4.7.0-1 (i686) 0/2 signoffs * clanlib-2.3.6-2 (i686) 0/2 signoffs * contacts-0.12-6 (i686) 0/2 signoffs * dates-0.4.11-5 (i686) 0/2 signoffs * libgexiv2-0.4.1-2 (i686) 0/2 signoffs * tasks-0.20-2 (i686) 0/2 signoffs * avr-binutils-2.22-3 (x86_64) 0/2 signoffs * avr-gcc-4.7.0-1 (x86_64) 0/2 signoffs * clanlib-2.3.6-2 (x86_64) 0/2 signoffs * contacts-0.12-6 (x86_64) 0/2 signoffs * dates-0.4.11-5 (x86_64) 0/2 signoffs * libgexiv2-0.4.1-2 (x86_64) 0/2 signoffs * tasks-0.20-2 (x86_64) 0/2 signoffs == All packages in [community-testing] for more than 14 days (5 total) == * avr-binutils-2.22-3 (i686), since 2012-03-24 * avr-gcc-4.7.0-1 (i686), since 2012-03-24 * avr-binutils-2.22-3 (x86_64), since 2012-03-25 * avr-gcc-4.7.0-1 (x86_64), since 2012-03-25 * avr-libc-1.8.0-3 (any), since 2012-03-25 == Top five in signoffs in last 24 hours == 1. dreisner - 2 signoffs 2. foutrelis - 1 signoffs 3. dan - 1 signoffs

1 0

Re: [aur-general] Automated Package Removal
by Daniel Campbell 09 Apr '12

09 Apr '12

I would contribute if a. My dev machine had internet and b. If i thought my work had a chance of being considered. Given that I'm not a TU or a regular among the devs, my work would not likely be accepted. I guess things will stay as they are until someone important dislikes them. I'm not one for jumping through hoops. Sent from my Nokia phone

1 0