Re: [aur-general] Abandonware: lgeneral-data
On 1 March 2012 10:27, Anton Bazhenov anton.bazhe...@gmail.com wrote: Package 'lgeneral-data' [1] contains data files for the game LGeneral [2]. But these files are taken from the original game - Panzer General, the rights to which are now owned by Ubisoft. I could update the package and remove the link to the archive, but is it worth it? The user need to enter only one command to install data files (and I added an example to .install file in the package 'lgeneral'). So I think that 'lgeneral-data' can be deleted. [1] lgeneral-data - https://aur.archlinux.org/packages.php?ID=44211 [2] lgeneral - https://aur.archlinux.org/packages.php?ID=6112 I think message in install file is enough. I'l remove lgeneral-data.
[aur-general] Signoff report for [community-testing]
=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 22 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 0 fully signed off packages * 47 packages missing signoffs * 2 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 (22 total) == * gtk2hs-buildtools-0.12.1-2 (x86_64) * haskell-binary-0.5.1.0-1 (x86_64) * haskell-bytestring-show-0.3.5.1-2 (x86_64) * haskell-cairo-0.12.2-2 (x86_64) * haskell-dataenc-0.14.0.3-1 (x86_64) * haskell-glib-0.12.2-2 (x86_64) * haskell-gtk-0.12.2-2 (x86_64) * haskell-haskeline-0.6.4.6-1 (x86_64) * haskell-hslogger-1.1.5-6 (x86_64) * haskell-pango-0.12.2-2 (x86_64) * haskell-stm-2.2.0.1-3 (x86_64) * haskell-syb-0.3.6-1 (x86_64) * haskell-tar-0.4.0.0-1 (x86_64) * haskell-terminfo-0.3.2.3-1 (x86_64) * haskell-utf8-string-0.3.7-1 (x86_64) * haskell-x11-1.5.0.1-2 (x86_64) * haskell-x11-xft-0.3.1-3 (x86_64) * hedgewars-0.9.17-2 (x86_64) * virtualbox-modules-4.1.8-5 (x86_64) * xmobar-0.14-2 (x86_64) * xmonad-0.10-3 (x86_64) * xmonad-contrib-0.10-2 (x86_64) == Incomplete signoffs for [community] (47 total) == * dbmail-3.0.0_rc3-1 (i686) 0/2 signoffs * ext4magic-0.3.0-1 (i686) 0/2 signoffs * gtk2hs-buildtools-0.12.1-2 (i686) 0/2 signoffs * haskell-binary-0.5.1.0-1 (i686) 0/2 signoffs * haskell-bytestring-show-0.3.5.1-2 (i686) 0/2 signoffs * haskell-cairo-0.12.2-2 (i686) 0/2 signoffs * haskell-dataenc-0.14.0.3-1 (i686) 0/2 signoffs * haskell-glib-0.12.2-2 (i686) 0/2 signoffs * haskell-gtk-0.12.2-2 (i686) 0/2 signoffs * haskell-haskeline-0.6.4.6-1 (i686) 0/2 signoffs * haskell-hslogger-1.1.5-6 (i686) 0/2 signoffs * haskell-pango-0.12.2-2 (i686) 0/2 signoffs * haskell-stm-2.2.0.1-3 (i686) 0/2 signoffs * haskell-syb-0.3.6-1 (i686) 0/2 signoffs * haskell-tar-0.4.0.0-1 (i686) 0/2 signoffs * haskell-terminfo-0.3.2.3-1 (i686) 0/2 signoffs * haskell-utf8-string-0.3.7-1 (i686) 0/2 signoffs * haskell-x11-1.5.0.1-2 (i686) 0/2 signoffs * haskell-x11-xft-0.3.1-3 (i686) 0/2 signoffs * hedgewars-0.9.17-2 (i686) 0/2 signoffs * xmobar-0.14-2 (i686) 0/2 signoffs * xmonad-0.10-3 (i686) 0/2 signoffs * xmonad-contrib-0.10-2 (i686) 0/2 signoffs * dbmail-3.0.0_rc3-1 (x86_64) 0/2 signoffs * ext4magic-0.3.0-1 (x86_64) 0/2 signoffs * gtk2hs-buildtools-0.12.1-2 (x86_64) 0/2 signoffs * haskell-binary-0.5.1.0-1 (x86_64) 0/2 signoffs * haskell-bytestring-show-0.3.5.1-2 (x86_64) 0/2 signoffs * haskell-cairo-0.12.2-2 (x86_64) 0/2 signoffs * haskell-dataenc-0.14.0.3-1 (x86_64) 0/2 signoffs * haskell-glib-0.12.2-2 (x86_64) 0/2 signoffs * haskell-gtk-0.12.2-2 (x86_64) 0/2 signoffs * haskell-haskeline-0.6.4.6-1 (x86_64) 0/2 signoffs * haskell-hslogger-1.1.5-6 (x86_64) 0/2 signoffs * haskell-pango-0.12.2-2 (x86_64) 0/2 signoffs * haskell-stm-2.2.0.1-3 (x86_64) 0/2 signoffs * haskell-syb-0.3.6-1 (x86_64) 0/2 signoffs * haskell-tar-0.4.0.0-1 (x86_64) 0/2 signoffs * haskell-terminfo-0.3.2.3-1 (x86_64) 0/2 signoffs * haskell-utf8-string-0.3.7-1 (x86_64) 0/2 signoffs * haskell-x11-1.5.0.1-2 (x86_64) 0/2 signoffs * haskell-x11-xft-0.3.1-3 (x86_64) 0/2 signoffs * hedgewars-0.9.17-2 (x86_64) 0/2 signoffs * virtualbox-modules-4.1.8-5 (x86_64) 0/2 signoffs * xmobar-0.14-2 (x86_64) 0/2 signoffs * xmonad-0.10-3 (x86_64) 0/2 signoffs * xmonad-contrib-0.10-2 (x86_64) 0/2 signoffs == All packages in [community-testing] for more than 14 days (2 total) == * dbmail-3.0.0_rc3-1 (i686), since 2012-01-15 * dbmail-3.0.0_rc3-1 (x86_64), since 2012-01-16 == Top five in signoffs in last 24 hours == 1. ttopper - 9 signoffs 2. ronald - 5 signoffs 3. ibiru - 5 signoffs 4. stephane - 4 signoffs 5. allan - 2 signoffs
Re: [aur-general] AUR helpers and AUR standards
Am Thu, 1 Mar 2012 20:12:29 -0600 schrieb Nick Miller nick.k...@gmail.com: As far as I know it's not since aur helpers are not and will never be officially supported. And what? Almost everybody uses them. And split packages are also not officially supported. But while AUR helpers are useful and usually working, split packages in AUR don't work. Heiko
Re: [aur-general] TU Application - György Balló
Am Fri, 2 Mar 2012 11:59:56 +1100 schrieb Gaetan Bisson bis...@archlinux.org: Like I said, nobody cares. Oh, you are nobody? Interesting. If you have problems reading between the lines, try growing up. Between the lines are spaces otherwise there would be other lines. I'd say, the one who needs to grow up is you, so that you can get rid of your childish and bad attitude. Heiko
Re: [aur-general] AUR helpers and AUR standards
Am Fri, 2 Mar 2012 15:23:16 +0800 schrieb Oon-Ee Ng ngoonee.t...@gmail.com: As I understand it the reason the AUR doesn't support split packages is more along the lines of hard to implement and/or noone has bothered to add it rather than the AUR shall not have split packages. As long as there's not support for them in AUR for whatever reasons they are not supported by AUR. If a workaround allows split packages to work fine without having to rewrite the AUR, that's a GOOD thing to me. Note: 'work' means with makepkg. That does not mean only with makepkg. And even with makepkg there could be several issues. I have tried this workaround before for checking if it's an option for my package linux-fbcondecor, since the package linux has become a split package. But for very good reasons I change that package to a single package. A workaround is not a fix. A workaround can but doesn't need to work. In this case it does not work. Helpers are only helpers. Nothing wrong with using them, but they're:- a) not official Split packages in AUR are not official. b) not a suitable substitute for knowing how to download a tarball and run makepkg I know how to download tarballs and run makepkg. But I want to easily maintain my system and not to check every package individually. That's what the AUR helpers are for. Otherwise I could switch to Windoze again. In Windoze I have to check on the websites of every single software if there's an update and to download and install it manually. If a user can't do b) AUR helpers do them a dis-service, IMO. Better to learn what's going on behind the scenes. And what? I can do b), but if you have 100+ packages installed from AUR then it's not possible anymore to keep your system up-to-date without a helper. And again, split packages are NOT supported by AUR, a workaround is NOT a fix, so it's NOT the helper's fault that they can NOT handle split packges. They just can NOT find the subpackages of a split package on AUR, because AUR does NOT show them, because AUR does NOT support split packages. I've used yaourt and bauerbill before, and they DO make things easier, but if we ever reach the point that a large group of users only know how to use the AUR through helpers Arch would be a very different (and worse) place. That's a totally different topic and has nothing to do with this split package issue. That's the reason why the AUR helpers are not officially supported and won't be moved to [community]. Btw., this is the only reason for that. Just that simple. Either build support for split packages into AUR or just don't upload split packages to AUR, not either with such a dirty workaround. And, yes, it is dirty. Heiko
Re: [aur-general] TU Application - György Balló
Am Fri, 02 Mar 2012 00:27:39 +0100 schrieb Balló György ballog...@gmail.com: I understand Heiko's opinion and now I replaced these hackish split packages by individual packages even if it's requires more maintenance time on updates. So now users should able to install all of my packages with AUR helpers, however I don't use these tools at all. I hope that AUR once will have better support for split packages. Thanks, looks a lot better now. But there's still an issue. Your makedepends should all be depends since they are runtime, not only buildtime dependencies. And libindicate doesn't build, but I'll file a comment to AUR for this. On the first glance I'm not sure if this is a downstream or an upstream issue. Still remains the issue with indicator-messages-gtk2 having indicator-messages as a dependency. Here you should comply with the naming conventions. Build two or three different packages like I explained. -gtk2 implies that this is only the GTK2 port. Heiko
Re: [aur-general] AUR helpers and AUR standards
On Mar 2, 2012 6:31 AM, Heiko Baums li...@baums-on-web.de wrote: Am Fri, 2 Mar 2012 15:23:16 +0800 schrieb Oon-Ee Ng ngoonee.t...@gmail.com: As I understand it the reason the AUR doesn't support split packages is more along the lines of hard to implement and/or noone has bothered to add it rather than the AUR shall not have split packages. As long as there's not support for them in AUR for whatever reasons they are not supported by AUR. If a workaround allows split packages to work fine without having to rewrite the AUR, that's a GOOD thing to me. Note: 'work' means with makepkg. That does not mean only with makepkg. And even with makepkg there could be several issues. I have tried this workaround before for checking if it's an option for my package linux-fbcondecor, since the package linux has become a split package. But for very good reasons I change that package to a single package. A workaround is not a fix. A workaround can but doesn't need to work. In this case it does not work. Helpers are only helpers. Nothing wrong with using them, but they're:- a) not official Split packages in AUR are not official. b) not a suitable substitute for knowing how to download a tarball and run makepkg I know how to download tarballs and run makepkg. But I want to easily maintain my system and not to check every package individually. That's what the AUR helpers are for. Otherwise I could switch to Windoze again. In Windoze I have to check on the websites of every single software if there's an update and to download and install it manually. If a user can't do b) AUR helpers do them a dis-service, IMO. Better to learn what's going on behind the scenes. And what? I can do b), but if you have 100+ packages installed from AUR then it's not possible anymore to keep your system up-to-date without a helper. And again, split packages are NOT supported by AUR, a workaround is NOT a fix, so it's NOT the helper's fault that they can NOT handle split packges. They just can NOT find the subpackages of a split package on AUR, because AUR does NOT show them, because AUR does NOT support split packages. I've used yaourt and bauerbill before, and they DO make things easier, but if we ever reach the point that a large group of users only know how to use the AUR through helpers Arch would be a very different (and worse) place. That's a totally different topic and has nothing to do with this split package issue. No, in fact if you weren't using something like yaourt, you wouldn't be here wasting bits on the mailing list. Its entirely related, but like so many other or your useless tirades, you completely fail to see the forest from the trees. That's the reason why the AUR helpers are not officially supported and won't be moved to [community]. Btw., this is the only reason for that. You keep speaking about policy like you're the one behind it. I'd appreciate it if you would stop this behavior. Just that simple. Either build support for split packages into AUR or just don't upload split packages to AUR, not either with such a dirty workaround. And, yes, it is dirty. Patches welcome for the former. It'd be awfully nice to see you doing something productive in this community for a change. D
Re: [aur-general] TU Application - György Balló
On 03/02/2012 08:17 AM, Heiko Baums wrote: Am Fri, 2 Mar 2012 11:59:56 +1100 schrieb Gaetan Bisson bis...@archlinux.org: Like I said, nobody cares. Oh, you are nobody? Interesting. If you have problems reading between the lines, try growing up. Between the lines are spaces otherwise there would be other lines. I'd say, the one who needs to grow up is you, so that you can get rid of your childish and bad attitude. Heiko Seriously Heiko, you got some issues. Maybe some kind of disorder like Asperger[1]. You should look for a doctor if you can't sort this out by yourself. No joke, seek some help and stop bullying Arch devs/TUs. [1] https://en.wikipedia.org/wiki/Asperger_syndrome signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Application - György Balló
On 02/03/12 21:38, Heiko Baums wrote: Am Fri, 02 Mar 2012 00:27:39 +0100 schrieb Balló György ballog...@gmail.com: I understand Heiko's opinion and now I replaced these hackish split packages by individual packages even if it's requires more maintenance time on updates. So now users should able to install all of my packages with AUR helpers, however I don't use these tools at all. I hope that AUR once will have better support for split packages. Thanks, looks a lot better now. But there's still an issue. Your makedepends should all be depends since they are runtime, not only buildtime dependencies. I see what was done there... makedepends in split packages probably need to become depends when built as individual packages. @György: Let that be a lesson in being careful when making reactionary changes to packages. Don't worry... it is a surprisingly common occurrence when people first become a TU and start getting bug reports. There are always annoying and persistent users that think they are right, so you are better of not making reactionary changes to packages. It is important to learn when a change does not need implemented, and this change was probably not needed when no TU had posted about having issues with the split packages. Now that you have had it happen to you, I trust that you will not make the same mistake again and so will be an even better TU! I have seen some of your other contributions from the sidelines and think you are a good candidate. Good luck, Allan
Re: [aur-general] TU Application - Ike Devolder
Am 01.03.2012 15:31, schrieb Peter Lewis: On Thursday 01 Mar 2012 07:51:47 Stéphane Gaudreault wrote: This is a bit picky of me, but technically the sponsor is supposed to be a TU and as far as I can tell Stéphane is a dev rather than a TU... So ... Following this logic I have the power to break everything on your system ... but not to sponsor a future member of our trusted users team ? (Just kidding :D ). Heh, quite. I didn't claim to have logic on my side, I was just highlighting what our byelaws currently say. I said it was picky, but if we're happy for Devs to sponsor TU-ship, then we should just change the rules. I didn't want to create a big discussion out of this (unless of course people do disagree with devs being sponsors), so if there aren't any reasons contra, I'll put in a proposal to amend the byelaws. I guess this came from an original idea that the group of TUs are self- governing, independently of the developers. I always highlight that the Arch core developers usually don't interfere with the affairs of the TU group. In that sense, the bylaws make sense by saying you need to TU to sponsor him. However, the important part (voting) is done by TUs only. Personally, I always considered the sponsor requirement an unnecessary formality anyway. signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Application - Ike Devolder
On 01/03/12 17:33, Ike Devolder wrote: Hi, Hey, I recognise your name, and even better it is not in a bad way! That is my #1 criterion for recruiting new TUs. Even better is that you pass my #2 criterion, which is appearing competent. Good luck, Allan
Re: [aur-general] TU Application - Ike Devolder
Le 2012-03-02 07:03, Thomas Bächler a écrit : Am 01.03.2012 15:31, schrieb Peter Lewis: On Thursday 01 Mar 2012 07:51:47 Stéphane Gaudreault wrote: This is a bit picky of me, but technically the sponsor is supposed to be a TU and as far as I can tell Stéphane is a dev rather than a TU... So ... Following this logic I have the power to break everything on your system ... but not to sponsor a future member of our trusted users team ? (Just kidding :D ). Heh, quite. I didn't claim to have logic on my side, I was just highlighting what our byelaws currently say. I said it was picky, but if we're happy for Devs to sponsor TU-ship, then we should just change the rules. I didn't want to create a big discussion out of this (unless of course people do disagree with devs being sponsors), so if there aren't any reasons contra, I'll put in a proposal to amend the byelaws. I guess this came from an original idea that the group of TUs are self- governing, independently of the developers. I always highlight that the Arch core developers usually don't interfere with the affairs of the TU group. In that sense, the bylaws make sense by saying you need to TU to sponsor him. However, the important part (voting) is done by TUs only. Personally, I always considered the sponsor requirement an unnecessary formality anyway. I thought about it andI have nointention to participate to the vote as I do not want to interfere with the required quorum. I am only sponsoring here and the final choice will be made by TUs only. Stéphane
Re: [aur-general] TU Application - György Balló
Le 2012-03-02 06:17, Heiko Baums a écrit : Am Fri, 2 Mar 2012 11:59:56 +1100 schrieb Gaetan Bissonbis...@archlinux.org: Like I said, nobody cares. Oh, you are nobody? Interesting. If you have problems reading between the lines, try growing up. Between the lines are spaces otherwise there would be other lines. I'd say, the one who needs to grow up is you, so that you can get rid of your childish and bad attitude. Heiko STOP. Heiko, you had the chance to express you opinion about this application (and you did it in a totally inappropiate way). Now, let's TUs discuss and vote. REPEAT: Please stop such nonconstructive messages. Stéphane
Re: [aur-general] TU Application - Ike Devolder
On Fri, Mar 02, 2012 at 10:08:54PM +1000, Allan McRae wrote: On 01/03/12 17:33, Ike Devolder wrote: Hi, Hey, I recognise your name, and even better it is not in a bad way! That is my #1 criterion for recruiting new TUs. Even better is that you pass my #2 criterion, which is appearing competent. Good luck, Allan thank you a lot, i really appreciate this support and if i get accepted these kind of comments will make me strive for the best quality to the best of my abilities -- Ike pgpZ32phkP2TC.pgp Description: PGP signature
Re: [aur-general] TU Application - Ike Devolder
On Fri, Mar 02, 2012 at 07:09:36AM -0500, Stéphane Gaudreault wrote: Le 2012-03-02 07:03, Thomas Bächler a écrit : Am 01.03.2012 15:31, schrieb Peter Lewis: On Thursday 01 Mar 2012 07:51:47 Stéphane Gaudreault wrote: This is a bit picky of me, but technically the sponsor is supposed to be a TU and as far as I can tell Stéphane is a dev rather than a TU... So ... Following this logic I have the power to break everything on your system ... but not to sponsor a future member of our trusted users team ? (Just kidding :D ). Heh, quite. I didn't claim to have logic on my side, I was just highlighting what our byelaws currently say. I said it was picky, but if we're happy for Devs to sponsor TU-ship, then we should just change the rules. I didn't want to create a big discussion out of this (unless of course people do disagree with devs being sponsors), so if there aren't any reasons contra, I'll put in a proposal to amend the byelaws. I guess this came from an original idea that the group of TUs are self- governing, independently of the developers. I always highlight that the Arch core developers usually don't interfere with the affairs of the TU group. In that sense, the bylaws make sense by saying you need to TU to sponsor him. However, the important part (voting) is done by TUs only. Personally, I always considered the sponsor requirement an unnecessary formality anyway. I thought about it andI have nointention to participate to the vote as I do not want to interfere with the required quorum. I am only sponsoring here and the final choice will be made by TUs only. Stéphane In general i'm sure Stéphane will do a great job sponsoring (which in most of the cases means, guarantee that the packages i will deliver have the required quality), but on the other hand i think this whole TU group should support newly accepted TU's in learning and improving their skills. Sponsored by this whole ArchLinux community i would like to help improve the overall ArchLinux experience. thx -- Ike pgpR94pdIKgZD.pgp Description: PGP signature
Re: [aur-general] TU Application - Ike Devolder
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/03/12 05:47, Peter Lewis wrote:
Hi Ike,
Thanks for applying :-)
On Thursday 01 Mar 2012 08:33:17 Ike Devolder wrote:
Currently I'm using Archlinux as my primary operating system for
over 6 years and for several years I'm maintaining a small number
of packages in AUR[1]. I also keep a repository with arch
packages for everyone to use[2] and view the pkgbuilds on
github[3]. Originally the repository got created so i could
easily install some non-{core,extra,community}-packages on my
different computers.
Hi Ike!
I didn't get you by your name but by your nickname, oh yeah, as Allan
said I had a good memory about you, so this is good ;).
I had a quick look, and these packages all look pretty good to me.
It seems that you know your way around.
I would like to become a TU for several reasons:
- bring in some packages from AUR to community - apper (kde
packagekit frontend, the gnome/gtk ones are already in) - lcdproc
(drive your lcd displays) - closure-{compiler,linter} (googles
javascript toys) - vim-qt (or provide a patch for addition to the
extra package)
It would be nice to see another TU interested in KDE / Qt things
:-)
Good you have your goals.
Last but not least, my sponsor is Stéphane Gaudreault.
This is a bit picky of me, but technically the sponsor is supposed
to be a TU and as far as I can tell Stéphane is a dev rather than a
TU...
Good luck with the application!
Pete.
About this, as an ex-TU and ex-DEV I thought for Devs this should be
unnecesary, I mean Trusted Users are Trusted by the community but
first by the Devs (or nobody of TU would have access to our servers).
So if we trust you, and we doesn't oppose against your decitions of
who bring to the TU land, why TUs have to untrust Devs? IMHO TUs
should trust devs by default, and that means, no complains about TU
applications, have more sense to me. But please, I don't want to start
a debate in this thread, I don't was to make noise on the Ike's
application, if somebody want to reply me about it and start a
brainstorming, discussion or whatever please do it other thread.
That said, good luck with your application Ike, you have been an
impressive work and you're a good candidate.
- --
Angel Velásquez
angvp @ irc.freenode.net
Linux Counter: #359909
http://www.angvp.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPUMf0AAoJEEKh2xXsEzutuVsH/3rXPY8mMWKaOmo4KAJtKXYE
U7KPLzZ8g9Bh1+ZmC6zAPyLP/CYR3n6jGv3EcePx68M/ULFOwuDl4utg0phyEKto
eb91DwO+VT/lA3jSxlUxnTJ9qDKmp8nyCegicgEYoi5xqRsB9xQnFWr3iNE6dLX7
QR3fYqox/Y47r5BKmYNeg0AcwcRaaUp9lfc1QsnaCpJj8FJvhg6Md0xpyB2elJZO
qdJHj/CkfY5N5y28HAt4N5y5dxBR66vx3xvgVFy3A40uu+F+kQEu+XjUJ1+/FdVo
u3gGk57cubpJ8Mb83pp4bZOaBlx694tos91eE8JBuBvk6M9Yxq7xTS63ruGlpQM=
=w7Pi
-END PGP SIGNATURE-
Re: [aur-general] TU Application - György Balló
Am Fri, 02 Mar 2012 07:11:21 -0500 schrieb Stéphane Gaudreault steph...@archlinux.org: STOP. Heiko, you had the chance to express you opinion about this application (and you did it in a totally inappropiate way). I didn't do it in a inappropriate way. I did it in a factual way and explained why I am concerned and what was going wrong. I even said that I probably do him wrong with some of my questions. Nevertheless it's fact that this package couldn't be built. You can't argue it away. It was some other people who thought to need to offend me in an inappropriate way. So they get an adequate answer. REPEAT: Please stop such nonconstructive messages. Sorry, but my concerns aren't nonconstructive. But as the question, so the answer. Stop offending me, discuss in a factual way with me and you will get factual answers from me. If I'm so wrong with my concerns then explain it to me. I only got answers like grow up, AUR helpers are not officially supported even if split packages are not supported, neither officially nor unofficially, by AUR, Wow, I never seen somebody who maintains so many packages etc. Quantity is not the same as quality, btw. Give factual reasons why his packages are so good and I'm so wrong, and everything is good. Otherwise think if he is really that good and trustworthy resp. that his knowledge is already good enough. E.g. explain to me why a package needs to have two completely different depends arrays one also with a true before. For me this looks like bad packaging, sorry. Btw., I didn't want to say that he personally is not trustworthy. But I'm not sure if he has sufficient knowledge, yet. Heiko
Re: [aur-general] TU Application - György Balló
Am Fri, 02 Mar 2012 22:01:59 +1000 schrieb Allan McRae al...@archlinux.org: I see what was done there... makedepends in split packages probably need to become depends when built as individual packages. @György: Let that be a lesson in being careful when making reactionary changes to packages. Don't worry... it is a surprisingly common occurrence when people first become a TU and start getting bug reports. There are always annoying and persistent users that think they are right, If I'm so annoying and I'm so wrong then explain why his packages are so good and I'm so wrong, but this time try it with facts. Explain to me e.g. - I know I already asked that Stéphane - why it is such a good packaging quality to have two totally different depends arrays in one PKGBUILD of which one is also prefixed with a true . Where in the Arch Packaging Standards is this written down? In which PKGBUILD proto can this be found? Since when it is a good packaging quality to upload packages which can't be installed? Just explain it factually to me. And don't tell me anything about not officially supported. Neither the helpers nor the split packages are officially supported. This is not an argument in this case. so you are better of not making reactionary changes to packages. It is important to learn when a change does not need implemented, and this change was probably not needed when no TU had posted about having issues with the split packages. This change was neither reactionary nor unneeded, just because it was not possible to install this package. So this change was needed. So don't mix up the facts. In the repos like [community] split packages are supported and are no problem. And in the repos there's no need for such dirty workarounds. In AUR it is totally different. And that is just a fact, even if you don't want to hear that. Heiko
Re: [aur-general] TU Application - György Balló
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/03/12 10:06, Heiko Baums wrote: Am Fri, 02 Mar 2012 07:11:21 -0500 schrieb Stéphane Gaudreault steph...@archlinux.org: STOP. Heiko, you had the chance to express you opinion about this application (and you did it in a totally inappropiate way). I didn't do it in a inappropriate way. I did it in a factual way and explained why I am concerned and what was going wrong. I even said that I probably do him wrong with some of my questions. Nevertheless it's fact that this package couldn't be built. You can't argue it away. It was some other people who thought to need to offend me in an inappropriate way. So they get an adequate answer. REPEAT: Please stop such nonconstructive messages. Sorry, but my concerns aren't nonconstructive. But as the question, so the answer. Stop offending me, discuss in a factual way with me and you will get factual answers from me. If I'm so wrong with my concerns then explain it to me. I only got answers like grow up, AUR helpers are not officially supported even if split packages are not supported, neither officially nor unofficially, by AUR, Wow, I never seen somebody who maintains so many packages etc. Quantity is not the same as quality, btw. Give factual reasons why his packages are so good and I'm so wrong, and everything is good. Otherwise think if he is really that good and trustworthy resp. that his knowledge is already good enough. E.g. explain to me why a package needs to have two completely different depends arrays one also with a true before. For me this looks like bad packaging, sorry. Btw., I didn't want to say that he personally is not trustworthy. But I'm not sure if he has sufficient knowledge, yet. Heiko Heiko, I've always had several discussions with you, now Gaetan, and many people seems to have disagree with your opinion. A personal advice is when so much people are saying that you're wrong at least try to think about it and try to put on the otherside of the line. Gyorgy have good skills, and you personally are nothing to say that he doesn't have it, are you a TU? Dev? were you a Fellow, I don't remember on those sides, so please, stop complaining, start contributing, if you can't do this, then you will be remembered always like the noising user who like to break our balls. Now please let continue with Gyorgy's application. - -- Angel Velásquez angvp @ irc.freenode.net Linux Counter: #359909 http://www.angvp.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPUMmmAAoJEEKh2xXsEzutdUMH+wRQNj45wrpqVwDpdDgWDXrE WuZDekUIYT81b8MOasPOq2gu9qDqanTuxyIYdzc09CY1xkY0ffm5v1mzYpwoGKx9 JAhekKB+AXBDhISGRVOpfYTjaC2WnrbuAtPF026ib3b5qEmSiMPnpP9sY0l2u7O/ PnWfmmVqKrK5hkvFgy2MX0kO6OTzaywqCLnvDhU/5O6qSsNzUmNxhlnXxYawcDTl NMJETbzFgso8pVnbMRiyxeCCjzVcLz9GzmxzKlq3/yTvFPmqCamJQrNTIUGAhyZ5 j6PwF6Kbd35/zFp8Oo7kiCJ/RBGbAXGW5ZSXi6vAcgAtYwdDvfjXUM6TdbnapZU= =ZFHD -END PGP SIGNATURE-
Re: [aur-general] TU Application - György Balló
On 02/03/12 23:16, Heiko Baums wrote: Am Fri, 02 Mar 2012 22:01:59 +1000 schrieb Allan McRae al...@archlinux.org: I see what was done there... makedepends in split packages probably need to become depends when built as individual packages. @György: Let that be a lesson in being careful when making reactionary changes to packages. Don't worry... it is a surprisingly common occurrence when people first become a TU and start getting bug reports. There are always annoying and persistent users that think they are right, If I'm so annoying and I'm so wrong then explain why his packages are so good and I'm so wrong, but this time try it with facts. Fact. I never said you were annoying or wrong in that sentence. Someone is a bit sensitive... probably because he is annoying and wrong. Explain to me e.g. - I know I already asked that Stéphane - why it is such a good packaging quality to have two totally different depends arrays in one PKGBUILD of which one is also prefixed with a true . That fixed the issues you were complaining about with AUR helpers unable to find dependencies. So hang on... this was a complete solution to having a split package in the AUR while still being able to use an AUR helper. So what was your problem again? Apart from ignorance... Where in the Arch Packaging Standards is this written down? In which PKGBUILD proto can this be found. Where is it written that you can't do that? PKGBUILDs are bash. Any valid bash is a valid PKGBUILD. Show me an PKGBUILD proto that shows specifying different dependencies for i686 and x86_64? Given there is none, should all packages doing this be removed? Note that also screws AUR helpers. Since when it is a good packaging quality to upload packages which can't be installed? They can be installed. Or do you mean can not be installed by an AUR helper? In which case you are still wrong due to the extra dependency line. Just explain it factually to me. And don't tell me anything about not officially supported. Neither the helpers nor the split packages are officially supported. This is not an argument in this case. It is a valid PKGBUILD that provided split packages with a modified dependency line to fix AUR helper issues. so you are better of not making reactionary changes to packages. It is important to learn when a change does not need implemented, and this change was probably not needed when no TU had posted about having issues with the split packages. This change was neither reactionary nor unneeded, just because it was not possible to install this package. So this change was needed. So don't mix up the facts. Absolute shit... the package installed just fine. In the repos like [community] split packages are supported and are no problem. And in the repos there's no need for such dirty workarounds. In AUR it is totally different. And that is just a fact, even if you don't want to hear that. I agree that in the AUR it is totally different to the repos. You have to use workarounds in the AUR. So everything said in that paragraph is true. Allan
Re: [aur-general] TU Application - Ike Devolder
On Fri, Mar 02, 2012 at 10:15:32AM -0300, Angel Velásquez wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/03/12 05:47, Peter Lewis wrote:
Hi Ike,
Thanks for applying :-)
On Thursday 01 Mar 2012 08:33:17 Ike Devolder wrote:
Currently I'm using Archlinux as my primary operating system for
over 6 years and for several years I'm maintaining a small number
of packages in AUR[1]. I also keep a repository with arch
packages for everyone to use[2] and view the pkgbuilds on
github[3]. Originally the repository got created so i could
easily install some non-{core,extra,community}-packages on my
different computers.
Hi Ike!
I didn't get you by your name but by your nickname, oh yeah, as Allan
said I had a good memory about you, so this is good ;).
I had a quick look, and these packages all look pretty good to me.
It seems that you know your way around.
I would like to become a TU for several reasons:
- bring in some packages from AUR to community - apper (kde
packagekit frontend, the gnome/gtk ones are already in) - lcdproc
(drive your lcd displays) - closure-{compiler,linter} (googles
javascript toys) - vim-qt (or provide a patch for addition to the
extra package)
It would be nice to see another TU interested in KDE / Qt things
:-)
Good you have your goals.
Last but not least, my sponsor is Stéphane Gaudreault.
This is a bit picky of me, but technically the sponsor is supposed
to be a TU and as far as I can tell Stéphane is a dev rather than a
TU...
Good luck with the application!
Pete.
About this, as an ex-TU and ex-DEV I thought for Devs this should be
unnecesary, I mean Trusted Users are Trusted by the community but
first by the Devs (or nobody of TU would have access to our servers).
So if we trust you, and we doesn't oppose against your decitions of
who bring to the TU land, why TUs have to untrust Devs? IMHO TUs
should trust devs by default, and that means, no complains about TU
applications, have more sense to me. But please, I don't want to start
a debate in this thread, I don't was to make noise on the Ike's
application, if somebody want to reply me about it and start a
brainstorming, discussion or whatever please do it other thread.
That said, good luck with your application Ike, you have been an
impressive work and you're a good candidate.
- --
Angel Velásquez
angvp @ irc.freenode.net
Linux Counter: #359909
http://www.angvp.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPUMf0AAoJEEKh2xXsEzutuVsH/3rXPY8mMWKaOmo4KAJtKXYE
U7KPLzZ8g9Bh1+ZmC6zAPyLP/CYR3n6jGv3EcePx68M/ULFOwuDl4utg0phyEKto
eb91DwO+VT/lA3jSxlUxnTJ9qDKmp8nyCegicgEYoi5xqRsB9xQnFWr3iNE6dLX7
QR3fYqox/Y47r5BKmYNeg0AcwcRaaUp9lfc1QsnaCpJj8FJvhg6Md0xpyB2elJZO
qdJHj/CkfY5N5y28HAt4N5y5dxBR66vx3xvgVFy3A40uu+F+kQEu+XjUJ1+/FdVo
u3gGk57cubpJ8Mb83pp4bZOaBlx694tos91eE8JBuBvk6M9Yxq7xTS63ruGlpQM=
=w7Pi
-END PGP SIGNATURE-
thanks, i hope i can live up to all of your expectations
--
Ike
pgpvWvUBxGbWw.pgp
Description: PGP signature
Re: [aur-general] TU sponsorship.
On Friday 02 Mar 2012 13:03:47 Thomas Bächler wrote: I always highlight that the Arch core developers usually don't interfere with the affairs of the TU group. In that sense, the bylaws make sense by saying you need to TU to sponsor him. However, the important part (voting) is done by TUs only. Sure, that is probably the important thing. But we should at least ensure the rules are consistent with our practice (or vice versa). Personally, I always considered the sponsor requirement an unnecessary formality anyway. Well, if that is a widely held view, then an alternative would be to remove this sponsorship thing all together and just allow direct applications to the list. Presumably it is designed to provide some sort of pre-application vetting of candidates, to not waste everyone's time? Pete.
Re: [aur-general] TU Application - György Balló
Am Fri, 02 Mar 2012 10:22:46 -0300 schrieb Angel Velásquez an...@archlinux.org: Heiko, I've always had several discussions with you, now Gaetan, and many people seems to have disagree with your opinion. If they disagree with my opinion, they can happily explain why. I explained my concerns. But I only got answers like grow up, not officially supported, etc., not to mention the offences, particularly those of Gaetan. I don't say that I'm always right. And having concerns does not mean that a person about whom I have concerns is really that bad. But it means that one should have a closer look at him before he is fully trusted. But what I have read in the answers looked rather like an unreflecting hype. And I also know that there are people who every now and then do agree with me. Just the people who disagree are usually the loudest. And once a TU even told me personally face to face that my comments are usually worth reading. I don't remember it literally. I also discovered several times, that I was offended here on the mailing lists by a lot of people. But I still gave my arguments. And lo and behold after a while the discussion got factual and it turned out in the end that I wasn't so wrong and that I wasn't the only one with this opinion. So you indeed should sometimes think about my comments. I really don't write so many times, at least I don't give so many times my concerns. But if I give them, then there's usually a reason for that. Of course, I can be wrong. But then explain it and don't tell me anything about I should grow up and it was inappropriately or the like. That's the point. A personal advice is when so much people are saying that you're wrong at least try to think about it and try to put on the otherside of the line. Why? I mean, of course, I think about it, but only if I get some reasonable arguments. On the other hand the fact that so many people are saying that I'm wrong doesn't necessarily mean that I'm this wrong. That can mean that those people are just the loudest and that those people probably haven't thought about my arguments or even haven't read them completely. Like I said before, I'm certainly not always right, but sometimes. Gyorgy have good skills, and you personally are nothing to say that he doesn't have it, Because I tried to install one of his packages, looked at those PKGBUILDs, found several issues, and written comments about those problems in the AUR. This was, btw., shortly before he has written his TU application. So I didn't check his AUR packages because of his TU application. And from those PKGBUILDs which indeed looked pretty weird I had my concerns that he is probably not the right one for being a TU. That was not meant personally, that was just because of what I saw. are you a TU? Dev? were you a Fellow, I don't remember on those sides, so please, stop complaining, Where am I complaining? I gave my concerns about someone who has written a TU application. And I said that either split package support should be added to AUR or that split packages shouldn't be uploaded to AUR. How is that complaining? And, no, I'm neither a TU or a dev, yet. Does this mean that I mustn't say my opinion? I don't think so. And that doesn't mean that I don't have any knowledge. start contributing, I already do this. 21 packages in AUR, a not too short part of the code in /etc/rc.sysinit, a few lines - only a very few, I admit that - of code in the vanilla kernel. Is this not contributing? if you can't do this, then you will be remembered always like the noising user who like to break our balls. No, only people who either don't read my arguments completely, have prejudices against me or just dislike me for whatever reason will remember me as a noising user. Other people probably know that I'm not just noising. Like I said in another e-mail: As the question, so the answer. Heiko
Re: [aur-general] TU Application - György Balló
This thread is kind of fun to read, from a sociological perspective :) It is however sad when one considers that all the energy put into writing these emails could have been put into either - address AUR's shortcomings when it comes to split packages, or - address the different AUR builders inability to handle split packages as they appear in AUR. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus
Re: [aur-general] TU Application - György Balló
On 02/03/12 23:40, Allan McRae wrote: On 02/03/12 23:16, Heiko Baums wrote: Am Fri, 02 Mar 2012 22:01:59 +1000 schrieb Allan McRae al...@archlinux.org: I see what was done there... makedepends in split packages probably need to become depends when built as individual packages. @György: Let that be a lesson in being careful when making reactionary changes to packages. Don't worry... it is a surprisingly common occurrence when people first become a TU and start getting bug reports. There are always annoying and persistent users that think they are right, If I'm so annoying and I'm so wrong then explain why his packages are so good and I'm so wrong, but this time try it with facts. Fact. I never said you were annoying or wrong in that sentence. Someone is a bit sensitive... probably because he is annoying and wrong. Explain to me e.g. - I know I already asked that Stéphane - why it is such a good packaging quality to have two totally different depends arrays in one PKGBUILD of which one is also prefixed with a true . That fixed the issues you were complaining about with AUR helpers unable to find dependencies. So hang on... this was a complete solution to having a split package in the AUR while still being able to use an AUR helper. So what was your problem again? Apart from ignorance... I'll put my hand up and say I am partially wrong here. This broke AUR helpers that blindly source the PKGBUILD in order to get the dependency list. I.e. broken AUR helpers became further broken... The AUR helper I use worked because it very sensibly does not do that and ends up with the same (working) dependency list as was displayed on the AUR. In conclusion... a good hack that did not work in shitty AUR helpers. Where in the Arch Packaging Standards is this written down? In which PKGBUILD proto can this be found. Where is it written that you can't do that? PKGBUILDs are bash. Any valid bash is a valid PKGBUILD. Show me an PKGBUILD proto that shows specifying different dependencies for i686 and x86_64? Given there is none, should all packages doing this be removed? Note that also screws AUR helpers. Since when it is a good packaging quality to upload packages which can't be installed? They can be installed. Or do you mean can not be installed by an AUR helper? In which case you are still wrong due to the extra dependency line. Just explain it factually to me. And don't tell me anything about not officially supported. Neither the helpers nor the split packages are officially supported. This is not an argument in this case. It is a valid PKGBUILD that provided split packages with a modified dependency line to fix AUR helper issues. so you are better of not making reactionary changes to packages. It is important to learn when a change does not need implemented, and this change was probably not needed when no TU had posted about having issues with the split packages. This change was neither reactionary nor unneeded, just because it was not possible to install this package. So this change was needed. So don't mix up the facts. Absolute shit... the package installed just fine. In the repos like [community] split packages are supported and are no problem. And in the repos there's no need for such dirty workarounds. In AUR it is totally different. And that is just a fact, even if you don't want to hear that. I agree that in the AUR it is totally different to the repos. You have to use workarounds in the AUR. So everything said in that paragraph is true. Allan
Re: [aur-general] Disown request: batterymon-clone
On 03/01/2012 09:44 PM, Jarek Sedlacek wrote: Packagae batterymon-clone[1] is out of date and broken, and has been for a while. I tried to email the maintainer, monstermudder78, but the email he has listed ( ca...@archlinux.us) doesn't exist. I see he doesn't maintain any other packages, so I'd assume he's inactive. Could this package be orphaned? I'd love to pick it up (and ideally have it replace the batterymon package, since the former is broken without a kernel built with CONFIG_ACPI_PROCFS_POWER, which the stock arch kernels aren't) [1] https://aur.archlinux.org/packages.php?ID=52974 Thanks, Jarek Sedlacek Done. -- Bartłomiej Piotrowski Arch Linux Trusted User http://archlinux.org/ signature.asc Description: OpenPGP digital signature
Re: [aur-general] Package Deletion/Merge: batterymon
On 03/02/2012 05:37 PM, Jarek Sedlacek wrote: Package batterymon [1] is broken and will remain broken as long as arch kernels are built without CONFIG_ACPI_PROCFS_POWER. It can be replaced by batterymon-clone [2] which is a fork of the same project that gets battery information from /sys instead of /proc. Could batterymon be deleted and the votes merged? [1] https://aur.archlinux.org/packages.php?ID=24694 [2] https://aur.archlinux.org/packages.php?ID=52974 Thanks, Jarek Sedlacek And done. Thanks. -- Bartłomiej Piotrowski Arch Linux Trusted User http://archlinux.org/ signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Application - György Balló
Allan McRae wrote: Since when it is a good packaging quality to upload packages which can't be installed? They can be installed. Or do you mean can not be installed by an AUR helper? In which case you are still wrong due to the extra dependency line. I think this point should be stressed. Yaourt and other AUR helpers do not determine the validity of a PKGBUILD. If you can download the tarball from the AUR and build the package with makepkg, then the PKGBUILD is *valid* as far as the AUR is concerned. Having said that, I disagree that the criteria for a *good* PKGBUILD is only that it build. PKGBUILDs should try to conform to certain patterns and not exploit the fact that they are written in Bash (unless absolutely necessary, and even then only reluctantly). All metapackaging tools would have been much easier to write if PKGBUILDs were perfectly parsable without arbitrary code execution. The choice of Bash was myopic and lazy in my opinion, and something that should be reversed as far as possible, not glorified.
Re: [aur-general] TU Application - György Balló
Xyne wrote: Allan McRae wrote: Since when it is a good packaging quality to upload packages which can't be installed? They can be installed. Or do you mean can not be installed by an AUR helper? In which case you are still wrong due to the extra dependency line. I think this point should be stressed. Yaourt and other AUR helpers do not determine the validity of a PKGBUILD. If you can download the tarball from the AUR and build the package with makepkg, then the PKGBUILD is *valid* as far as the AUR is concerned. Having said that, I disagree that the criteria for a *good* PKGBUILD is only that it build. PKGBUILDs should try to conform to certain patterns and not exploit the fact that they are written in Bash (unless absolutely necessary, and even then only reluctantly). All metapackaging tools would have been much easier to write if PKGBUILDs were perfectly parsable without arbitrary code execution. The choice of Bash was myopic and lazy in my opinion, and something that should be reversed as far as possible, not glorified. Hmmm, I should have finished reading all of the threads before replying. This would have been more appropriate elsewhere. Sorry.
Re: [aur-general] TU Application - György Balló
Am Fri, 2 Mar 2012 18:49:47 + schrieb Xyne x...@archlinux.ca: The choice of Bash was myopic and lazy in my opinion, and something that should be reversed as far as possible, not glorified. Don't say that too loud, because Gentoo's ebuilds are principally bash, too, but Gentoo has its own functions to allegedly provide sort of a quality assurance. The problem with this is, that it's a lot harder to write ebuilds than PKGBUILDs. Heiko
Re: [aur-general] TU Application - György Balló
Am Fri, 02 Mar 2012 23:40:55 +1000 schrieb Allan McRae al...@archlinux.org: Where is it written that you can't do that? PKGBUILDs are bash. Any valid bash is a valid PKGBUILD. So, what if I would build a package which contains an .install file with an `rm -Rf /` in its post_install() function and upload it to AUR? That's a totally valid package, totally valid bash, which can easily be uploaded to AUR and flawlessly installed with makepkg and every AUR helper. Is it a qualitative good package? So, it's obvious that a valid bash is not the only quality criterion. Heiko
Re: [aur-general] TU Application - György Balló
On Fri, Mar 2, 2012 at 9:39 PM, Heiko Baums wrote: Am Fri, 02 Mar 2012 23:40:55 +1000 schrieb Allan McRae al...@archlinux.org: Where is it written that you can't do that? PKGBUILDs are bash. Any valid bash is a valid PKGBUILD. So, what if I would build a package which contains an .install file with an `rm -Rf /` in its post_install() function and upload it to AUR? That's a totally valid package, totally valid bash, which can easily be uploaded to AUR and flawlessly installed with makepkg and every AUR helper. Is it a qualitative good package? So, it's obvious that a valid bash is not the only quality criterion. Quality and validity are two different things. -- Cédric Girard
[aur-general] Misconceptions about the AUR?
On Fri 02 Mar 2012 00:49 +0100, Heiko Baums wrote: Am Fri, 02 Mar 2012 09:21:33 +1000 schrieb Allan McRae al...@archlinux.org: You do realize who first came up with the workaround for adding split packages to the AUR... Because from memory it was figured out in the TU IRC channel. I don't know, because I'm not in the IRC channels. But if I recall correctly this workaround was also discussed in the forums and/or the mailing lists. This was at a time when it was still discussed if AUR shall support split packages or not. The package splittest which was meant to test this workaround and to give a sample PKGBUILD was uploaded to AUR by Harvie, a normal user. And if I recall correctly it was him who first came up with it. But I can be wrong. The problem is if you add a subpackage of a split package into a depends array as György did it just can't be installed, because AUR don't know anything about those subpackages, because it doesn't support split packages. And thus the AUR wrappers can't find them. So it's not possible to install those packages. First of all I'll deplore you for hijacking György's TU Application thread to rant about your own qualms. You should be ashamed. You should apologise. You are wrong. Secondly. If a PKGBUILD can be built with makepkg then it IS a valid PKGBUILD. No matter what you say. If an AUR helper cannot process it, then there is a problem with the AUR helper, not the AUR and not the PKGBUILD. Third. The AUR is not meant to help you build source packages. It hosts them, and parses the tarballs only for convenience. You are supposed to install it by your own means. If your means are buggy, that's your problem. Finally, yes, there are problems with Arch source packages but you're missing the solution by lightyears. These things have been discussed on the list, the forums, and the bugtracker. You would be keen to do a little research and perhaps propose solutions (patches?) rather than wasting precious oxygen. Cheers.
Re: [aur-general] TU Application - Ike Devolder
Thanks for applying and best of luck. :) -- Sincerely, Alexander Rødseth Arch Linux Trusted User (xyproto on IRC, trontonic on AUR)
Re: [aur-general] Misconceptions about the AUR?
Am Fri, 2 Mar 2012 17:16:16 -0500 schrieb Loui Chang louipc@gmail.com: First of all I'll deplore you for hijacking György's TU Application thread to rant about your own qualms. You should be ashamed. You should apologise. You are wrong. I'm not wrong, I didn't hijack anything, and I didn't rant. I gave my concerns about György's TU application and explained them. Afterwards I just answered some not so nice reactions and kept giving my arguments. So nothing to be ashamed, nothing to apologise. And, no, I'm not wrong. Just because you say so? Like I already said, give some factual and reasonable arguments. You, too, didn't give even one. Secondly. If a PKGBUILD can be built with makepkg then it IS a valid PKGBUILD. No matter what you say. If an AUR helper cannot process it, then there is a problem with the AUR helper, not the AUR and not the PKGBUILD. Also wrong. If a PKGBUILD has no syntax errors does not mean that it is valid resp. good. See my example of the package with the `rm -Rf /` in its post_install(). This package is totally valid, because it's totally valid bash without any syntax errors. This package can perfectly uploaded to AUR, is fully supported by AUR and every AUR helper, and can flawlessly be installed. Is it a good package, just because it is valid and has no syntax errors? Just think about that and think about the meaning of quality, quality assurance (QA) and good packaging. The AUR helpers - all of them - support everything what AUR supports. AUR does NOT support split packages. Otherwise such a hackish workaround wouldn't be needed. So there's no problem with the AUR helpers. Would this be a problem with an AUR helper I would have filed a bug report for this. Third. The AUR is not meant to help you build source packages. It hosts them, and parses the tarballs only for convenience. You are supposed to install it by your own means. If your means are buggy, that's your problem. Wrong again. AUR is meant to provide PKGBUILDs so that other people can use and install them without rewriting them by themselves. They don't parse them only for my convenience, they parse the PKGBUILDs to assure that the PKGBUILDs are valid and most likely working. Finally, yes, there are problems with Arch source packages but you're missing the solution by lightyears. These things have been discussed on the list, the forums, and the bugtracker. You would be keen to do a little research and perhaps propose solutions (patches?) rather than wasting precious oxygen. I know these discussions, and I know the results of these discussions. You seem to have forgotten them. And, yes, the result of the discussion about implementing support for split packages into AUR, which was requested by a lot of people, btw., was that it does not going to be supported, because nobody wanted to write the patches. Maybe you have missed this discussion. Heiko
Re: [aur-general] Misconceptions about the AUR?
Am Fri, 2 Mar 2012 21:00:54 -0500 schrieb Loui Chang louipc@gmail.com: Yes. Because I say so. Because everyone else says so. Because you are one of those imbeciles that don't stop to listen and simply talk over everyone so that you can only hear yourself shouting. So, you are everybody, and what you say is law? Are you nuts? Now you are the one who should apologise for these insults. It's not worth to answering to this and the other totally stupid nonsense. Read my e-mails, give factual and reasonable facts and arguments. Then we can discuss. Otherwise you should just stop insulting other people. Heiko
Re: [aur-general] TU Application - György Balló
Le 2012-03-01 13:00, Balló György a écrit : Hello everybody, I'm applying to be a Trusted User. I'm a 24 years old Hungarian web developer, and I'm using Arch Linux as my main system since 2010 summer. Before that I used a Debian-based distro for one year. In my free time I like surfing on the net, contributing to OpenStreetMap, bicycling, hiking, take photos about trams, and of course, packaging. I really like Arch Linux's transparency, the pacman and the build system, the website and the great wiki. I'm maintaining packages[1] a long time ago, and I already contributed to wiki by creating a page about libcanberra[2], and updated, extended some other articles. I reported many issues[3] with GNOME packages (including upstream and packaging bugs) to make Arch Linux better. I usually try to find the solution and send patch to upstream if needed before open bug reports. I helped to Ioni e.g. on updating some C# packages, and I also cooperated with AndyRTR on splitting out extensions from libreoffice package. I currently have 150 packages in AUR with a total of 5775 votes. I already maintain more than 200 packages as source packages on github[4] and as built i686 packages in my [ayatana] repo[5]. I don't want to move all of these packages to [community], only the popular ones. I always try to make the best packages and I hate poorly written PKGBUILDs. Some packages that I would like to add to [community]: - deja-dup (115 votes) - gwibber (299 votes) - pinta (186 votes) Some orphan packages in [community] that I could adopt: - agave - buoh My goal with becoming a TU is to provide more popular GTK+ applications in [community] and keep GNOME stable and consistent by fixing packages on large updates if needed. I hope that I could support Arch Linux as a TU in the next months and years. Alexander Rødseth is my sponsor. Best regards, György Balló My PGP key: https://raw.github.com/City-busz/Arch-Linux-Repository/master/ballog...@gmail.com-public.asc [1] https://aur.archlinux.org/packages.php?SeB=mK=City-busz [2] https://wiki.archlinux.org/index.php/Libcanberra [3] https://bugs.archlinux.org/index.php?project=1status[]=opened=City-buszdo=index [4] https://github.com/City-busz/Arch-Linux-Repository [5] http://ayatana.info/ Hi György, Thank you for applying. I think you will be a great contributor. I looked at your AUR packages and saw that you are maintaining the unity desktop. I never used this desktop environment, but as a curiosity is it something you want to eventually bring into [community] ? I am looking forward to having you join the TUs team. Stéphane
Re: [aur-general] TU Application - György Balló
Hi, I'm also in favor of György. He is the best candidate I have seen lately and his presentation is clean. I would like someone like him around to help the community. Also, if I pay attention to the other posts, my opinion is... the AUR is a HELPER tool. It's only used as a time saver, but it doesn't dictates how the AUR works in any way. Meaning when there's a change to the AUR system, so must the tools adapt to that change. I think it's their job to support split packages, as long as we can provide some sort of coding/design standard to help them a bit with their task. It's a known feature, it's also an interesting feature. The more split packages we have, it's gonna pressure the Yaourt team to do something about it. So yeah. On Fri, Mar 2, 2012 at 9:34 PM, Stéphane Gaudreault steph...@archlinux.orgwrote: Le 2012-03-01 13:00, Balló György a écrit : Hello everybody, I'm applying to be a Trusted User. I'm a 24 years old Hungarian web developer, and I'm using Arch Linux as my main system since 2010 summer. Before that I used a Debian-based distro for one year. In my free time I like surfing on the net, contributing to OpenStreetMap, bicycling, hiking, take photos about trams, and of course, packaging. I really like Arch Linux's transparency, the pacman and the build system, the website and the great wiki. I'm maintaining packages[1] a long time ago, and I already contributed to wiki by creating a page about libcanberra[2], and updated, extended some other articles. I reported many issues[3] with GNOME packages (including upstream and packaging bugs) to make Arch Linux better. I usually try to find the solution and send patch to upstream if needed before open bug reports. I helped to Ioni e.g. on updating some C# packages, and I also cooperated with AndyRTR on splitting out extensions from libreoffice package. I currently have 150 packages in AUR with a total of 5775 votes. I already maintain more than 200 packages as source packages on github[4] and as built i686 packages in my [ayatana] repo[5]. I don't want to move all of these packages to [community], only the popular ones. I always try to make the best packages and I hate poorly written PKGBUILDs. Some packages that I would like to add to [community]: - deja-dup (115 votes) - gwibber (299 votes) - pinta (186 votes) Some orphan packages in [community] that I could adopt: - agave - buoh My goal with becoming a TU is to provide more popular GTK+ applications in [community] and keep GNOME stable and consistent by fixing packages on large updates if needed. I hope that I could support Arch Linux as a TU in the next months and years. Alexander Rødseth is my sponsor. Best regards, György Balló My PGP key: https://raw.github.com/City-**busz/Arch-Linux-Repository/** master/ballog...@gmail.com-**public.aschttps://raw.github.com/City-busz/Arch-Linux-Repository/master/ballog...@gmail.com-public.asc [1] https://aur.archlinux.org/**packages.php?SeB=mK=City-buszhttps://aur.archlinux.org/packages.php?SeB=mK=City-busz [2] https://wiki.archlinux.org/**index.php/Libcanberrahttps://wiki.archlinux.org/index.php/Libcanberra [3] https://bugs.archlinux.org/**index.php?project=1status[]=** opened=City-buszdo=indexhttps://bugs.archlinux.org/index.php?project=1status[]=opened=City-buszdo=index [4] https://github.com/City-busz/**Arch-Linux-Repositoryhttps://github.com/City-busz/Arch-Linux-Repository [5] http://ayatana.info/ Hi György, Thank you for applying. I think you will be a great contributor. I looked at your AUR packages and saw that you are maintaining the unity desktop. I never used this desktop environment, but as a curiosity is it something you want to eventually bring into [community] ? I am looking forward to having you join the TUs team. Stéphane
Re: [aur-general] TU Application - György Balló
Hi, thanks for the question. I looked at your AUR packages and saw that you are maintaining the unity desktop. I never used this desktop environment, but as a curiosity is it something you want to eventually bring into [community] ? I worked a lot on making Unity and indicators usable on Arch Linux, but I don't want to add any of these packages[1] into [community], because Ubuntu heavily patched gtk2, gtk3[2], metacity and compiz, and it's impossible to build and/or use some packages with the upstream, unmodified packages. They patched a lot of other packages also for better integration into the panel and the launcher. So if GNOME developers accept some must have patches, then I could imagine to add these packages, but until it does not happen, it's better to keep them in a separated repo. (However I'm not sure that Ubuntu sent all required patches to upstream yet.) [1] Nearly all packages in ubuntu-unity and apps-unity directories on https://github.com/City-busz/Arch-Linux-Repository [2] E.g.: https://bugzilla.gnome.org/show_bug.cgi?id=658563 -- György Balló signature.asc Description: OpenPGP digital signature
