Re: [aur-general] TU application
Le 2013-01-17 14:46, Alexandre Filgueira a écrit : Hi everybody, This whole thing of becoming a TU began after talking by email with Allan about one article of his where he talked about one project of mine. He put me in contact with Evangelos Foutras to be my sponsor, and here I am trying to become a TU. My name is Alexandre Filgueira. I'm a galician guy (Spain), 22 to 23 years old and computer lover. I'm a sysadmin and teacher. I like bash, python and vala, but I have knowledge in some other languages. I also like web programming. I'm a tv-show/cinema addict and music lover, from classic to blues, jazz, rock, punk... I installed Arch the first time in 2008, at 18 years old. I was with Ubuntu since 2006 and I always wanted to have more control over some things, so I began trying distros... (Fedora, Gentoo, Debian...). When I saw what Arch was about, my head thought... oh yeah baby! ...and when I had my first Arch Linux system installed... I simply felt in love. My first forum post is dated 2009.02.18 asking about help with the grub when I deleted my ubuntu partition to have just Arch on my system. I'm better now xD I just have 2 packages in AUR simply because everything I wanted was in the official repos or already in AUR [1]. After all these years using Arch Linux, I thought that I wasn't helping the community as I could. I have a couple of forum posts, most of them asking. I did years ago a script to automatically install and configure a gnome system (gnome 2 in that time)[2]. My last contribution to the Arch Linux world is Cinnarch, being a bridge to show how good is our base system, showing them across a beautiful window, keeping the real rolling release soul intact. Thanks to my work on Cinnarch, I could find a bug in libalpm and I tried to fix it, with the help of David Reisner, the patch has already been merged.[3] My plan is to bring cinnamon to Arch Linux, a classic desktop built with modern technologies. I think is a good one to have in our official repos. I don't own the cinnamon package in AUR, when I began with Cinnarch, that package already existed. But I fixed some of the problems with that package, like the switch to systemd (I was awake until 3am fixing that thing in Cinnarch and then I reported the fix to the Arch Linux community), or the screensaver fix when gnome 3.6 came. And I think that's all. Thanks for considering me to become a TU. [1]https://aur.archlinux.org/packages/?K=faidocSeB=m [2]http://archive.org/details/Videotutorial [3]https://mailman.archlinux.org/pipermail/pacman-dev/2013-January/016283.html I am happy that you apply and I wish you success. What do you see for the future of the Cinnarch project after you will be accepted as a TU? Is the project going to disappear or it will continue in another form? Cheers, Stéphane
Re: [aur-general] Naming convention for Python 2 and 3 apps
Le 2012-11-28 01:53, Allen Li a écrit : On Tue, Nov 27, 2012 at 07:43:07PM -0500, Yichao Yu wrote: On Tue, Nov 27, 2012 at 2:48 PM, 小龙 陈 chillermillerl...@hotmail.com wrote: Hi Allen, I think the convention is to make two packages for software that support both Python 2 and 3. For example, in the extra repo, there's python-cairo and python2-cairo python-cchardet and python2-cchardet python-memcached and python2-memcached etc. Well, both of them are python libraries, which cannot support both python2 and python3 in the same binary package (OK, you can, by including both python2 and python3 modules but that's not the point) According to a previous email on the same list[1], you probably still need to create two packages for pyton2 and python3 if you want to support both of them (and probably rename the binary to avoid conflict.) [1] http://www.mail-archive.com/aur-general@archlinux.org/msg19241.html Well, the problem is flake8 is a python app, not a library. Maybe I'm worrying about nothing, but should the python-*, python2-* naming convention also be used in this case? If it is an application and does not provide a module that could be included in another application, then I suggest to depend on python3 only and keep the name flake8. Stéphane
Re: [aur-general] away
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 2012-08-01 12:04, Ike Devolder a écrit : Op woensdag 1 augustus 2012 18:03:20 schreef u: Op woensdag 1 augustus 2012 11:49:58 schreef Dave Reisner: On Wed, Aug 01, 2012 at 05:47:17PM +0200, Ike Devolder wrote: Op maandag 30 juli 2012 06:43:52 schreef Xyne: Ike Devolder wrote: Hi, I'll be away for a couple of days, normally everything should get updated automatically while i'm out. How are you updating things automatically? Regards, Xyne cronjobs on a server :) i have to add more but most are already to be found: https://github.com/BlackIkeEagle/archbuild --Ike So you're blindly signing and pushing packages based on the fact that they compile? yes why not ? --Ike i could modify the script that they land in community-testing first --Ike Compiling != Working, so I think it is a good practice for a maintainer to test packages before uploading them. In some case this could be difficult to do (eg massive rebuild for a libname change) and in these cases it is ok to blindly push package on the basis that is compile and test it later. In any case, I would expect that a package is minimally tested before it goes to the repos. Stéphane -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQGVYvAAoJEOpoNuGrRBGWT7QIALr88yM242d4ub4eQQQgZYJk Ub6M+6IYwzho8rkO6YwyoNDCREVBWCf30LBbCobBjeUy+s93BByhd9CG7UL9JBaa UtRc1LCKMczzmJheoH/fAdxHy+my6Ye8NaAh+v8vuK0pd86nJLxkw1TsSCcwtjSi +F4jLy/FrigkCClPFEY8CKDQY4pl6mbvP4NE559ufZHdLJQTlMMD0HLYCmedb2W4 OWbbMylmXGEmPL9Enx7nk67nh17HceAZVkIUKGwfx1SwWBdDynwZ4/eMISImpSX2 qoYOE5Th7c7I/zpXYRaDWzVzRR32rI4MZE8xsAjMV/kFR6UtQrhBp4vRsMWJIPM= =nVW1 -END PGP SIGNATURE-
[aur-general] TU Application - Ike Devolder - voting period
Dear TUs, Judgement period has come for Ike Devolder. Please vote: https://aur.archlinux.org/tu.php?id=54 As discussed previously, I will not participate in the vote. Cheers Stéphane
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 - 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 - Ike Devolder
Le 2012-03-01 02:33, Ike Devolder a écrit :
Hi,
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.
Some personal stuff: born 1982, webdeveloper (php, with some jquery tricks),
mad about all sorts of metal music, and loving to watch movies and sitcoms.
I live in Belgium so I should speak at least Dutch, French and German but i
speak and write Dutch, English, bad French, very bad German.
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)
as reference, some packages i was maintaining in AUR were already
picked up
- clementine (picked up by Stéphane Gaudreault)
- par2cmdline (picked up by Sébastien Luttringer)
- pick up some orphans from community
- v8 (this is the only one from the list i'm currently using)
- usualy i'm reading most of the issues reported so i could help
sorting the tickets and assign them to their respective owners
Last but not least, my sponsor is Stéphane Gaudreault.
[1] http://aur.archlinux.org/packages.php?SeB=mL=2K=BlackIkeEagle
[2] http://repo.herecura.be
[3] https://github.com/BlackIkeEagle/herecura
I agree to sponsor Ike. Let the discussion period begin.
Cheers,
Stéphane
[aur-general] Drop mplayer2 from [community]
Mplayer2 was very promising last year when they forked from the original mplayer project. One of the main goal of this project was to provide more frequent release and updates. Unfortunatly, they failled to provide something else after the initial release. This initial release no longer build with current tools/libs and contain several major bugs. A workaround was to update our pkg to a recent git snapshot. Since then, I do not see any reason to continue to update this package which is currently broken. If there is no objection, I will drop the package from [community]. Users should consider to follow mplayer2-git from AUR or the original mplayer from [extra]. Cheers, Stéphane
Re: [aur-general] Drop mplayer2 from [community]
Le 3 janvier 2012 22:40:30 Angel Velásquez a écrit : On 03/01/12 22:35, Heiko Baums wrote: Am Tue, 03 Jan 2012 22:25:46 -0300 schrieb Angel Velásquez an...@archlinux.org: If it's broken move it to AUR .. or ask if some tu wants to maintain on community. If it's broken and doesn't compile anymore, why should it be moved to AUR? Just drop it. Heiko Because if maybe somebody find it orphan and lonely and knows how to fix it, can adopt it ;) instead to re-upload to AUR .. can be moved to AUR and with a comment that is broken. Usually our workflow is that .. going to AUR and if it's dead and unbuildable by some time.. then just drop it. There is already an mplayer2-git pkg in AUR that is more up to date. Anyway, it cost nothing to drop it to AUR if someone else could find it useful. Stéphane
Re: [aur-general] TU Application
Le 27 Septembre 2011 18:02:51 Bartek Piotrowski a écrit : Hi, Part (Mateusz Herych) decided to sponsor my TU application. My name is Bartłomiej Piotrowski. I live in Szczecin (Poland). I learn and work here. I'm a Linux user since 2005 when I bought Suse 9.3 on 4 CDs. My hardware was too cheap to run it comfortably, so I gave up. I changed my computer in 2008, and after a year with Ubuntu and Debian I decided to install Arch. Arch is a perfect distro for me for many reasons - it has clean dependencies, it's bleeding edge and I don't need to compile anything (but if I want, it's not a problem). I forgot to mention KISS and the great community. It's just obvious to me. ;) I maintain 21 packages in AUR[1]. Only 3 were submitted by me, and the rest was orphaned and/or untidy - corrected by me, now they follow packaging guidelines. Every package has some votes and is tested on my machines. One of them, mplayer2[2] was taken to [community] by Stéphane Gaudreault. I was also contributing to it from time to time. I'm a coordinator and (the only one) Polish translator of Arch projects in Transifex[3]. Pacman translation is not ready for the 4.0 release yet, and I hope it will be done in some time. I had to skip dev/TU specific strings in my AUR translation - it's hard to translate something without knowledge about context. I help people from the Polish community board. When Polish Wiki works (now it doesn't), I translate small articles. I know basics of C, C++ and Perl, but I'm not a programmer. I juggle between school and sysadmin job in a small hosting[4]/shell[5] company. (We currently work on the website.) I (co)administer 5 machines, 4 Debian ones (2x hosting, Nagios, and Xen) and 1 Gentoo one (shell). If I become a TU I would be interested in adopting simple-scan and mpdscribble in [community]. That's all, I hope I mentioned everything. Bartek Piotrowski [1] https://aur.archlinux.org/packages.php?SeB=mL=2K=Barthalion [2] https://projects.archlinux.org/svntogit/community.git/tree/trunk?h=packages /mplayer2 [3] https://www.transifex.net/accounts/profile/Barthalion/ [4] http://host.org.pl/ [5] http://shell.org.pl/ I had the opportunity to collaborate a few times with Bartek. I think he has the required technical skills, but also (and most importantly) the right attitude. I think that he would be a great addition to the TU team. Stéphane
[aur-general] geos rebuild
Hi, geos-3.3.0 is in [community-staging] and the small todo list is on http://www.archlinux.org/todo/82/ Happy rebuilding ! Stéphane
Re: [aur-general] [arch-dev-public] Integrity Check x86_64: core, extra, community, multilib 27-05-2011
extra/libreoffice depends on community/cppunit (0 extra (make)deps to pull) extra/libreoffice-extension-ct2n depends on community/cppunit (0 extra (make)deps to pull) extra/libreoffice-extension-diagram depends on community/cppunit (0 extra (make)deps to pull) extra/libreoffice-extension-hunart depends on community/cppunit (0 extra (make)deps to pull) extra/libreoffice-extension-nlpsolver depends on community/cppunit (0 extra (make)deps to pull) extra/libreoffice-extension-numbertext depends on community/cppunit (0 extra (make)deps to pull) extra/libreoffice-extension-oooblogger depends on community/cppunit (0 extra (make)deps to pull) extra/libreoffice-extension-pdfimport depends on community/cppunit (0 extra (make)deps to pull) extra/libreoffice-extension-presentation-minimizer depends on community/cppunit (0 extra (make)deps to pull) extra/libreoffice-extension-presenter-screen depends on community/cppunit (0 extra (make)deps to pull) extra/libreoffice-extension-report-builder depends on community/cppunit (0 extra (make)deps to pull) extra/libreoffice-extension-typo depends on community/cppunit (0 extra (make)deps to pull) extra/libreoffice-extension-watch-window depends on community/cppunit (0 extra (make)deps to pull) extra/libreoffice-extension-wiki-publisher depends on community/cppunit (0 extra (make)deps to pull) extra/libreoffice-sdk depends on community/cppunit (0 extra (make)deps to pull) If there is no objection, I will move (and adopt) cppunit into [extra] before rebuiding for hunspell 1.3.x / icu 4.8. Stéphane
Re: [aur-general] [arch-dev-public] glew rebuild
Le 25 mai 2011 16:29:08, Stéphane Gaudreault a écrit : Hi, A todo list was create for a glew rebuild https://www.archlinux.org/todo/77/ It is a fairly small rebuild (22 pkgs). The glew package now include a GLEWmx library that provide support for multiple rendering contexts. Cheers, Stéphane Only 3 pkg remaining : * extra/koffice-krita * community/freewrl * community/xbmc Koffice does not build and the error does not seems to be related to glew. Cheers, Stéphane
Re: [aur-general] AUR message notification
Le 3 avril 2011 22:23:42, Loui Chang a écrit : On Sun 03 Apr 2011 23:16 +0200, Lukas Fleischer wrote: On Sun, Apr 03, 2011 at 11:00:24PM +0200, Baptiste wrote: On Sun, Apr 03, 2011 at 10:36:03PM +0200, Pierre Bourdon wrote: On Sun, Apr 3, 2011 at 22:30, Baptiste zersto...@free.fr wrote: I know there is a way to get an email notification when somebody writes a comment on a given package. Simply click the Notify button on a package page (http://aur.archlinux.org/packages.php?ID=XX). Thanks a lot ... that was so obvious! By the way, I was mistaken by the incorrect french translation for `notify' : `annoncer', meaning `announce'. Seriously, was the AUR translated using the automatic google thing ? Better have used a babel fish or something similar :) (see wikipedia page : http://bit.ly/eVDCNX ) Nah, I sent a patch fixing that to aur-dev a long time ago [1] - Loui rejected it back then for some reason tho. I'll probably just push it now... [1] http://mailman.archlinux.org/pipermail/aur-dev/2010-September/001260.htm l Mainly because 'suivre' means 'follow' rather than 'notify'. I didn't want to be pushing something incorrect that someone else would complain about again. The word Annoncer is very missleading. I would rather suggest Avertir. Stéphane
[aur-general] python 3.2 rebuild into [testing]
The python 3.2 rebuild is completed. Everything that needed (and hopefully nothing that did not...) was moved into [testing]. Thank you to everyone who helped out on this rebuild ! Stéphane
Re: [aur-general] Moving packages to Community
Le 5 février 2011 13:45:20, Thomas S Hatch a écrit : On Sat, Feb 5, 2011 at 11:31 AM, Gergely Imreh imr...@gmail.com wrote: Hi, Recently a couple of my packages have been moved to Community but the process feels a little uneasy to me. My impression is that AUR is treated as a second class source of packages compared to the official repos. Not surprising, of course, so many packages have problems. This is also underlined by the fact that yaourt and other AUR managers are not allowed in the official repos, as not to give the impression that AUR is official (paraphrasing what I've read before). If there is indeed this divide, it feels more than little weird, that popular packages are just taken in to Community without even asking the current managers. It gives me the message that AUR has no value, except when we say it has, at which time thanks for your work but now bugger off. I beg your pardon, if it comes through too harsh. I wouldn't have objected to have those packages moved. I, however, object to unilateral decisions. My proposition is: could it be a policy to check with the maintainer first before initiating a move? If someone wants to keep a package then they should be able to, especially since they could not have been doing such a a bad job if their package has become popular. Cheers, Greg Greg, You have a valid point, personally I have always asked the maintainer of a package for objections before moving a package into community. I also want to continue to express my deep gratitude for the packagers who contribute to the AUR. They are really the frontline in Arch development, the blood on the knife's edge. We as trusted users need to show the devs in the AUR the utmost respect and appreciation. I would also like to point out: https://wiki.archlinux.org/index.php/TU_Person_Specification All TUs we should adhere to the first bullet under At Least on this wiki entry. I hope that my fellow TUs agree that we should give AUR contributors the utmost respect, they deserve it. A behavior of respect will help us, the TUs, improve Arch, it will allow us to bring more people onto the Arch development teams, and continue our march to making Arch greater. -Thomas S Hatch -Arch Linux Trusted User It is important to recognize the work done by the AUR contributor. Also we should not forget that TUs and Jr Devs are frequently selected among them. I can give a personal example. I was contacted by Thomas Dziedzic some weeks after being accepted as a Jr dev. He asked me if he could add the openmpi package into [community]. My nomination was not well known at that time. This mail gives me the possibility to tell him that I wanted to continue to maintain it and that I planned to add it to [community] later. I maintain it in [community] now. I really appreciated that he asked me instead of just taking the package. Stéphane
[aur-general] Add pyopencl to [community]
Dear Tus, I would like to add pyopencl [1] to [community]. I maintain this package in AUR and it has 14 votes. Pyopencl depends, among other, on libcl (OpenCL library, provided by either nvidia-utils or amdstream [2]) and a package that provides OpenCL C/C++ headers. Here is my plan : * Add pyopencl to [community] (I will use a better name, something like python2-pyopencl) * Tidy up and add opencl-headers [3] (66 votes) to [community] [4]. * Leave amdstream in AUR The opencl-headers package provides headers from the Khronos group. It could also be possible to use a different source to get *exactly* the same headers (Nvidia for example). Any comment or objections in adding these packages to the [community] repository? Stéphane [1] http://aur.archlinux.org/packages.php?ID=31416 [2] http://aur.archlinux.org/packages.php?ID=21933 [3] http://aur.archlinux.org/packages.php?ID=35367 [4] I contacted hsyl20 (maintainer of opencl-headers). He has no objection if I take his package.
Re: [aur-general] Proposal for the reinstatement of AUR Cleanup Day.
Le janvier 24, 2011 07:50:34 PM, Thomas Dziedzic a écrit : Hello fellow Users/TUs, I have come across a rather old wiki entry [1] which was used for AUR Cleanup Day. It seems like we haven't had this day in quite some time, so I would like to have another AUR Cleanup Day where the community along with the TUs participate to clean things up in the AUR. We would use the wiki link to keep track of progress after cleaning it up a bit since the last time it was used. If I have enough people on board with this, I would like to make it an AUR Cleanup Weekend so that they can contribute whenever they have time. I would like to stress that this wouldn't be limited to only TU participation. Anyone would be able to see if there are broken packages, and list them on the wiki to have a TU look at it. I would like to make AUR Cleanup Weekend either this or next weekend. What do you think? [1] - https://wiki.archlinux.org/index.php/AUR_Cleanup_Day offtopic While talking about cleanup, what is the status of the Community Cleanup 2011 ? /offtopic Cheers, Stéphane
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
Le 19 janvier 2011 08:07:00, Allan McRae a écrit : On 19/01/11 22:49, Magnus Therning wrote: On Wed, Jan 19, 2011 at 12:50, Allan McRaeal...@archlinux.org wrote: On 19/01/11 22:20, Thomas Bächler wrote: Am 19.01.2011 08:08, schrieb Allan McRae: If we want to be really pedantic about dependencies, we should list _ALL_ dependencies and not remove the ones that are dependencies of dependencies. Why don't we just do the correct thing: If package A depends on package B, and B depends on C, then A might depend on C explicitly because it accesses C directly. Or it might only depend on indirectly C because B accesses C. We should reflect that in dependencies (in the first case, A depends on C, in the second case it doesn't). The result is this: Whenever the dependencies of B change (e.g., C is removed), A will still work correctly. I agree that would be the correct thing to do. In fact, I looked at doing this to the extent of including ever package that a program linked to in its dependencies. This increases the number of dependencies needed for the average package in the repos greatly (from memory it averaged a several fold increase). I don't quite understand what you mean, did you add the transitive closure of all dependencies to the package, or did you only add all direct dependencies? Essentially readelf -d on the files and add all needed packages to the dependencies. I.e. list all packages that are directly linked. Its has been many years since I did graph theory... but isn't a transitive closure essentially what we have been doing with only listing the top level of dependencies and having them cover the rest? Allan I think Allan is right here. If we look at the problem from another angle, thing are very simple : 1) There is a groupe of packages that are required. Theses packages are necessary for the proper functioning of the system (eg. a kernel, a boot loader, initscript, glibc, etc). The system will not run well or be usable without will be here. It is not necessary for other package to depends on them, because they **should** be there (although it does not hurt if a package depends on them). 2) Starting from this base, package A depends on Package B if B absolutely must be installed in order to run A. In some cases, A depends not only on B, but on a version of B. In this case, the version dependency is usually a lower limit, in the sense that A depends on any version of B more recent than some specified version. This gives a simple receipie : When you want to list the dependency fo a package, simply look at what is directly used (for binary it is essentially readelf -d on the files) and you get the dependency list for your package. You can then assume that everything will be correct as maintainers of the listed packages did the same up to the required group. If there is something missing in the dependencies of your dependencies send a bug report. Stéphane
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
Le 19 janvier 2011 08:36:04, Cédric Girard a écrit : On Wed, Jan 19, 2011 at 2:30 PM, Stéphane Gaudreault steph...@archlinux.org wrote: This gives a simple receipie : When you want to list the dependency fo a package, simply look at what is directly used (for binary it is essentially readelf -d on the files) and you get the dependency list for your package. You can then assume that everything will be correct as maintainers of the listed packages did the same up to the required group. It means then that if we have this (dependency are direct dependencies): - Package A: depends=(B C) - Package B: depends=(C) C should *not* be removed from the dependency array of A. Exact, you list what you directly use. It also means that if we have this (dependency are direct dependencies): - Package A: depends=(B C) - Package B: depends=(D) Maintainer of package A should not worry about dependency of B unless something is broken. Then simply fill a bug report. Stéphane
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
Le 19 janvier 2011 09:07:33, Pierre Chapuis a écrit : On Wed, 19 Jan 2011 23:59:55 +1000, Allan McRae al...@archlinux.org wrote: Huh? How is no dependency checks (-Sd) equivalent to complete dependency checking (-S with a transitive closure of dependencies)? They are polar opposites. What I mean is that if a transitive closure of dependencies is performed at packaging time, then there is no need to check for dependencies when installing the original package. Here is an example: A depends on B and D B depends on C C depends on D and E Currently the deps will be: A - B,D B - C C - D,E When installing A, Pacman will: 1) check deps for A, start installing B and D 2) check deps for B and D, start installing C 3) check deps for C, start installing E With a transitive closure scheme at packaging time, the deps would be: A - B,C,D,E B - C,D,E C - D,E When installing A, Pacman could simply install B, C, D and E *without* checking their deps (-Sd) because these deps are necessarily already included in those for A. As the maintainer of A, it is not your job to track dependencies of B and D. Again, look at the problem from a different point of view. If tomorrow dependencies of B change to B - C F (direct dependecies) does it mean that A (and **all** other pkgs that depends on B) should be updated to include a dependecy on F ? What if dependency on E is removed from C PKGBUILD ? Maintaining a package with such rules will be a nightmare. Stéphane
[aur-general] qt3 backend in python-matplotlib
Dear TUs, I am preparing an update of python-matplotlib to version 1.0.1. This package supports multiple backends for rendering graphics and plotting windows. So far, our PKGBUILD supported QTAgg which requires the old qt3. Considering that qt3 has no future, I wonder if it is still necessary to provide this backend. Any objections if I drop it ? I will also set the default backend to QT4Agg (user will still be able to change the default in the matplotlibrc file or in their scripts). Stéphane
Re: [aur-general] qt3 backend in python-matplotlib
Le 14 janvier 2011 16:47:39, Evangelos Foutras a écrit : On Fri, Jan 14, 2011 at 11:12 PM, Stéphane Gaudreault steph...@archlinux.org wrote: I am preparing an update of python-matplotlib to version 1.0.1. This package supports multiple backends for rendering graphics and plotting windows. So far, our PKGBUILD supported QTAgg which requires the old qt3. Considering that qt3 has no future, I wonder if it is still necessary to provide this backend. Any objections if I drop it ? I will also set the default backend to QT4Agg (user will still be able to change the default in the matplotlibrc file or in their scripts). From what I understand Qt4 is supported, right? If so, I agree that it's reasonable to drop support for Qt3. You are right, QT4 is still supported. Stéphane
Re: [aur-general] Various new packages in [community]
Le mardi 16 novembre 2010 20:03:14, Gaetan Bisson a écrit : Dear TUs, I'm Gaetan, a (discreet) junior dev, mentored by Allan. I recently got access to sigurd and thought I would use that opportunity to maintain in [community] a few packages I have been maintaining on the AUR so far, but which are just a bit too unpopular to go to [extra]: pari (fast advanced calculator) http://aur.archlinux.org/packages.php?ID=19196 dnstracer (DNS diagnosis tool) http://aur.archlinux.org/packages.php?ID=3229 collectd (performance collecting daemon) http://aur.archlinux.org/packages.php?ID=2341 They have over thirty votes each. Is it okay by everyone? Cheers. As Gaetan, I am a junior dev mentored by Allan. I got access to sigurd where I would like to maintain openmpi (128 votes) and cppcheck (48 votes) and eventually pyopencl (only 10 votes now, will wait). openmpi http://aur.archlinux.org/packages.php?ID=5477 cppcheck http://aur.archlinux.org/packages.php?ID=23294 pyopencl http://aur.archlinux.org/packages.php?ID=31416 Cheers, Stéphane
Re: [aur-general] Various new packages in [community]
Le mercredi 17 novembre 2010 07:18:43, Lukáš Jirkovský a écrit :
On 17 November 2010 13:15, Imanol Celaya ornitorrin...@archlinux-es.org
wrote:
pyopencl
http://aur.archlinux.org/packages.php?ID=31416
Cheers,
Stéphane
problem with packages which use opencl(at least with nvidia) is that
it requires the cuda toolkit, a binary package that I'm not sure about
the redistribution rights(should read the license)
and then look how to handle the opencl dependiencies as both amd and
nvidia provide icd and in theory both can cohexist(so maybe a
provides=('opencl') ?)
so, yes, opencl maybe better to wait
Imanol
I don't think they need cuda toolkit. I'm using OpenCL on nvidia with
just nvidia-utils and opencl-headers installed.
You are right. I never had problem compiling or running.
Regards,
Stéphane
Re: [aur-general] Various new packages in [community]
and then look how to handle the opencl dependiencies as both amd and
nvidia provide icd and in theory both can cohexist(so maybe a
provides=('opencl') ?)
so, yes, opencl maybe better to wait
Imanol
This is a part of the reason why I said I will wait before uploading. See
FS#20558
Stéphane
Re: [aur-general] graphviz perl module package
Le samedi 13 novembre 2010 12:15:35, Lukas Fleischer a écrit :
On Sat, Nov 13, 2010 at 06:06:13PM +0100, Florian Pritz wrote:
You should:
- move everything after make into package()
- remove || return 1
- replace $startdir/{pkg,src} by ${pkg,src}dir
- remove the 3rd line (useless comment)
That should look similar to this http://paste.xinu.at/oksL2/
Optimally also put directories containing variables (especially
${srcdir} or ${pkgdir}) in double quotes ('').
Most of these errors are present in the wiki template. I just changed it.
By the way, Abs templates in /usr/share/pacman/ are also old style PKGBUILD. I
will see with Allan to change that.
Stéphane
[aur-general] [deletion request] nvidia-opencl-headers
Could you please remove the nvidia-opencl-headers package ? http://aur.archlinux.org/packages.php?ID=42430 It is no longer needed as these headers are availables again in nvidia-utils. Thanks, Stéphane
Re: [aur-general] [arch-dev-public] [extra] repository cleanup
Le mercredi 10 novembre 2010 05:33:32, Andrea Scarpino a écrit : Hi DEVs/TUs, currently we have 700 (counting both arches and any) orphans packages in [extra]. As member of the orphans team, I made a list[1] of these packages and I'd like to move them to Unsupported. If some DEV wants to keep a package simply cross it out (adoption is not required, but it would be nice) or reply to this mail. If some TU wants to maintain a package in [community], please write the name into the Candidate to [community] section, *DO NOT* cross it out. Or reply to this mail. I think that a week is enough time for this job. 17th November I will move the remaining packages to Unsupported and the candidates to [community]. Cheers [1] https://wiki.archlinux.org/index.php/DeveloperWiki:Repo_Cleanup I no longer use synergy, so I added it to the list. Stéphane
