[arch-dev-public] Removing the vim-systemd package
Hi, systemd syntax support is now included in both vim and neovim. I'm removing the vim-systemd package from [community]. -- Best regards, Alexander F. Rødseth
Re: [arch-dev-public] Moving KDE3 and Gtk1 from [extra]
Hi, Great, thanks! Just tested the updated imlib and fvwm packages from [extra] here, and both builds without problems. Best regards, Alexander / xyproto
Re: [arch-dev-public] Moving KDE3 and Gtk1 from [extra]
There was a message on arch-general, noting that kiwi does not depend on gtk1. As I understand the situation, the holdups concerning gtk1, kdelibs3 and qt3 are now resolved, and there is a strong consensus that moving these packages is a good idea. We don't want to act as upstream for old, unmaintained, obsolete and potentially insecure libraries. Best regards, Alexander / xyproto
Re: [arch-dev-public] Moving KDE3 and Gtk1 from [extra]
Hi, I made a few changes to imlib and it compiles without Gtk1 now. Here is the source package: http://roboticoverlords.org/arch/imlib-1.9.15-14.src.tar.gz I wanted to test it with fvwm, but I could not, because ftp://ftp.fvwm.org/pub/fvwm/version-2/fvwm-2.6.5.tar.bz2 is no longer available. Please update the imlib package. If it is now possible to move the old and unmaintained gtk1, qt3 and kdelibs3 packages from the official repositories to AUR, that would be great. Best regards, Alexander Rødseth xyproto / TU
Re: [arch-dev-public] Moving KDE3 and Gtk1 from [extra]
Hi, 2014-04-04 21:13 GMT+02:00 Eric Bélanger snowmanisc...@gmail.com: * imlib: needed by dfm, fvwm (should be possible to compile without depending on imlib), Last time I check, it wasn't possible. As fvwm is the WM I use (I believe it has also decent usage statistics), I would like to keep them in the repos. Last time you checked, it was possible. Gentoo builds imlib without Gtk1. Let me refresh your memory by linking to your own reply on the matter: https://mailman.archlinux.org/pipermail/arch-dev-public/2013-May/024976.html +1 for also moving qt3 -- Best regards, Alexander Rødseth xyproto / TU
[arch-dev-public] Moving KDE3 and Gtk1 from [extra]
Hi, KDE3 and Gtk1 are pretty old by now. Upstream development has stopped and the few pages that still needs the kdelibs3 or gtk package seems to be of less importance. The topic was discussed briefly on IRC and there were only positive comments about making this move. One of the many arguments for moving them is that when upstream development stops, we don't want to take on the responsibility of fixing security problems with kde3/gtk1. So, can we move kdelibs3 and gtk from [extra] to either [community] or AUR? Here are the packages that depends on kdelibs3 (maintained by Eric Bélanger), together with the name of the current maintainer(s): kleansweep, Sergej Pupykin kovpn, Sergej Pupykin ksniffer, Sergej Pupykin ktechlab, Sergej Pupykin pwmanager, Sergej Pupykin qalculate-kde, Eric Bélanger tork, Felix Yan Here are the packages that depends on gtk (maintained by Eric Bélanger): dfm, Sergej Pupykin gdk-pixbuf, Sergej Pupykin imlib, Eric Bélanger kiwi, Federico Cinelli lib32-gtk, Pierre Schmitz madman, Sergej Pupykin manedit, Giovanni Scafora xmms, Eric Bélanger libdv (optional+make), Jan de Groot twin (optional), Sergej Pupykin librcc (make), Sergej Pupykin The only two packages I think might be worth extra concern here is: * imlib: needed by dfm, fvwm (should be possible to compile without depending on imlib), kuickshow and tksystray. * libdv: used by a lot of packages. gtk is listed as both optional and a make dependency. I assume this means that it can be compiled without Gtk1. Which packages should be moved to [community] or AUR as a result of kdelibs3 and gtk being moved, is up for discussion. I think the timing is right for this and there seems to be consensus that moving them is a good idea. -- Best regards, Alexander Rødseth xyproto / TU
Re: [arch-dev-public] Upgrading Apache to 2.4
One suggestion is creating the Apache 2.4 PKGBUILD first, then talk to Jan de Groot. If he should not be interested in the endeavor, talk to another dev. -- Sincerely, Alexander Rødseth xyproto / TU
Re: [arch-dev-public] [arch-general] The Final Cleanup
Hi Gaetan, Normally, only --pkgname and --pkgdesc are needed. The sage-mathematics PKGBUILD is an extreme example. Compare with other PKGBUILDs that uses gendesk for a more balanced picture. Thanks for the new arguments, though, I added them to the list of arguments for/against gendesk: Here are the arguments for generating the .desktop files with a tool like gendesk: * There is much duplication of code by having one .desktop file per (GUI) package. * If the .desktop specification should change in the future, there is only one tool that has to be changed, not bazillions of little .desktop files. * If there should be alternative ways of providing desktop shortcuts in the future, possibly for other desktop environments, the transition will be easier. * It's more elegant than including manually crafted files everywhere. * It provides one consistent look of .desktop files and avoids problems (for instance, one hand crafted (or upstream provided?) .desktop file used Terminal=1 instead of Terminal=true, which caused problems). Generated files are consistent, which avoids problems. * gendesk is already being used for several packages (and has been used for a while), and it seems to work fine. * Many files are generating during the prepare or build process. .desktop files should be generated too. * I've just tried gendesk and it's pretty neat actually. * Removes complexity from the package, since fewer files are needed. Here are the arguments against generating the .desktop files with a tool like gendesk: * It is just like including base64 encoded files directly in the PKGBUILD. (No, it's not. Contrast with other build-time generated files) * Current .desktop files should be left as they are. * Generating the .desktop files does not make the packages more vanilla. (.desktop files are inherently non-vanilla, though). * It takes a bit of work to create a package in the first place. Adding a .desktop file or not won't make a difference in the overall burden. * The functionality should rather be in makepkg.. * The maintainer still needs to relate to .desktop files one way or the other. * Using gendesk relies on a tool to do what can be done just as easily by hand. * This adds more complexity to the prepare() function. * This adds an extra makedepends (Only a small build-time dependency, though. Most users will never see this). - Alexander / xyproto
Re: [arch-dev-public] Fwd: The Final Cleanup
Hi Allan, Thanks for your opinion on this. I agree with your comments and conclusion. 2013/12/7 Allan McRae al...@archlinux.org: There is no need to do anything here apart from packages that do not provide a .desktop file that should need one added. In light of all this, would it be okay if I just close FS#23387? (https://bugs.archlinux.org/task/23387) After having discussed the topic here on the mailing list, I am hopeful that it will not be immediately re-opened again. -- Best regards, Alexander Rødseth xyproto / TU
Re: [arch-dev-public] Fwd: The Final Cleanup
Hi Gaetan, 2013/12/7 Gaetan Bisson bis...@archlinux.org: You missed most of my points. That's okay. Ditto. Could you explain to me why an application needs a desktop file when nobody on earth cares whether it has one or not? It is odd to be asked to explain a point of view that I never had nor expressed. If nobody on earth cares whether an application has a desktop file, I don't think it needs one either. It's quite patronizing for you to assume that the silent majority is on your side. Actually, I'll take it on mine: Hope you are aware that you are also calling yourself patronizing here. I will revert all the changes you make to packages of which the maintainers have not explicitly given their consent to your actions in this thread. Except of course if those maintainers explicitly contact me to opt out of the revert. Very well. Your objection is noted. - Alexander / xyproto
Re: [arch-dev-public] Fwd: The Final Cleanup
Hi Gaetan, 2013/12/7 Gaetan Bisson bis...@archlinux.org: [2013-12-07 20:46:26 +0100] Alexander Rødseth: If nobody on earth cares whether an application has a desktop file, I don't think it needs one either. Great. So we can stop this nonsense. Your assumption that nobody on earth cares whether an application has a desktop file is wrong. And calling it nonsense is misguided. Your objection is noted. Thank you mister chairman. If we are down to the level of name calling here, I'll use the opportunity to call you mr grumpypants. - Alexander / xyproto
[arch-dev-public] Fwd: The Final Cleanup
be generated too. * I've just tried gendesk and it's pretty neat actually. Here are the arguments against generating the .desktop files with a tool like gendesk: * It is just like including base64 encoded files directly in the PKGBUILD. (no, it's not. Contrast with other build-time generated files) * It's better to just leave the current .desktop files as they are. * Generating the .desktop files does not make the packages more vanilla. (.desktop files are inherently non-vanilla, though) * It takes a bit of work to create a package in the first place. Adding a .desktop file or not won't make a difference in the overall burden. * The functionality should rather be in makepkg. * The maintainer still needs to relate to .desktop files one way or the other I think .desktop files should be generated with gendesk, or a similar tool. (Note that gendesk has evolved and improved quite a bit since the time when it was first introduced and commented on in the bug report). Here are the arguments for creating a TODO list: * It's time to get this done and close the age old bug report. * People can still choose to reserve their packages from being affected (simply by marking their packages as complete, for instance). * A TODO list is the appropriate method for solving this situation. * I'm convinced TODO is more appropriate. Also I think the TODO interface (Complete/Incomplete) is better suited for this task. Here are the arguments against creating a TODO list: * Todos are things that require 100% completion ASAP for the distro to go forward I think we should have a TODO for this. Specifically, I think we should have a TODO for removing all .desktop files from our package sources. They should ideally be provided by upstream, but in the mean time, they should be generated. If there are no protests, I will, after some time (say, three days without any replies to this thread): * Create a TODO for this * Start fixing the packages (I will not fix the packages of maintainers that wish to reserve themselves from this, of course). We all appreciate a good discussion, but before replying with a flamey flame of a flaming reply, please think a minute if you have a better solution than this for achieving the goal of closing FS#23387 in the near future (not in 10 years). All the best. -- Sincerely, Alexander Rødseth xyproto / TU
Re: [arch-dev-public] Fwd: The Final Cleanup
Hi, 2013/12/6 Gaetan Bisson bis...@archlinux.org: Regardless of if it is correct that upstream should provide the .desktop files or not, the current plan is not working. TUs and devs are slow at reporting this as bugs and upstream are slow at responding. At the current rate, this will take years, perhaps decades. The current plan is not working. Why not? As I wrote, I believe it is because TUs and devs are slow at reporting this as bugs and upstream are slow at responding. If this was not the answer you are looking for, please be more specific than just why not?. I am less concerned with the exact mechanisms behind why the bug has been open for so long, and more concerned with finding a solution. If a given package does not have a desktop file and nobody is bothered enough to write one up and submit it through our bug tracker, then that package does not really need a desktop file. That depends on your point of view. From the point of view of users, it may very well need a desktop file. From my point of view, I think every package maintainer should bother. So you suggest we use pacman hooks to deal with desktop files? No, that is not what I am suggesting. I think I expressed clearly what I am suggesting. Should service files be autogenerated as well? (I don't think so.) Yes, I think that would work as well, but that is another topic entirely. * Start fixing the packages (I will not fix the packages of maintainers that wish to reserve themselves from this, of course). I object to any mass automated update of our PKGBUILDs. No automated updates was mentioned and no automated updates were planned. My intentions and my plan were expressed clearly in what I wrote. No need to invent things to object to. Why are you making such a big deal I disagree that I am. out of such an insignificant issue? I disagree that it is insignificant. Why do you care about the things you care about? I can call them insignificant too, but for what purpose other than belittling you? I happen to care about this particular issue. Packages for whom nobody has yet bothered to write a desktop file just have no need for one... I disagree with this too. I think all desktop applications needs a .desktop file. - Alexander / xyproto
Re: [arch-dev-public] [arch-general] The Final Cleanup
Hi, 2013/12/6 Rashif Ray Rahman sc...@archlinux.org: On 7 December 2013 01:15, Alexander Rødseth rods...@gmail.com wrote: If there are no protests, I will, after some time (say, three days I don't think that's enough time to get the representative opinion. You cut away the important part of the quote. Here is what I wrote: three days without any replies to this thread That means that after the last person has replied (there may be replies for days and weeks), I will wait three days. Do you think I should wait even longer after the last reply? Anyway, on topic, I know I have at least a couple of packages where I provide the desktop file, but don't know if upstream presently includes one in their sources. I will have to attend to these. Good point! Where upstream desktop files are available, that is preferable, of course. So, I say +1 to include desktop files as long as upstream does not provide them. You can file a bug report with them, but the desktop file stays until they attend to it. Also, it doesn't matter how it was created, as long as the package includes it. I disagree, I think all .desktop files should be removed from our repositories, with the only exception being if a package maintainer wishes to keep his packages like they are right now. If a packager wants to go out of her way to provide a desktop file for software that traditionally do not ship with one, I say we allow her to do it. I say we make it a requirement to provide one, for all GUI applications, but not by putting easily generated .desktop files into our repos. Do you know of any female Arch Linux package maintainers? I don't. - Alexander / xyproto
Re: [arch-dev-public] Fwd: [arch-commits] Commit in (9 files)
Nice work on the docker package! Thanks for pushing it. And thanks to Bartłomiej for renaming. - Alexander / xyproto
Re: [arch-dev-public] Fwd: [arch-commits] Commit in (9 files)
Could a dev please rename docker in [extra] to docker-tray and add
replaces=('docker=1.5')?
Daniel Isenmann has already okayed this.
- Alexander / xyproto
Re: [arch-dev-public] Fwd: [arch-commits] Commit in (9 files)
Ike, No, because the new docker package will have epoch=1, like discussed above. - Alexander / xyproto
Re: [arch-dev-public] Fwd: [arch-commits] Commit in (9 files)
Hi, The lxc-docker package as work in progress and was never pushed anywhere (only checked in to SVN). The post_install function was copied directly from the lxc-docker-nightly package on AUR (and proper credits were given), but testing, fixing and polish had not yet been applied to the PKGBUILD and the accompanying .install file. Also, docker probably needs to be built from a specific git revision (or tag/branch, if upstream makes that available). I fully agree that instructions that verbose does not belong in official packages. -- Sincerely, Alexander Rødseth xyproto / TU
Re: [arch-dev-public] Fwd: [arch-commits] Commit in (9 files)
Good question. Could pre_upgrade bail out if the old version of docker is present on the system, giving a message that the user probably wants to install docker-tray instead? - Alexander / xyproto
Re: [arch-dev-public] Fwd: [arch-commits] Commit in (9 files)
Something like:
replaces=('docker=1.5')
in the docker-tray PKGBUILD?
Isn't that equally problematic, since that could cause problems if
docker (currently at version 0.7) reached version 1.5?
- Alexander / xyproto
Re: [arch-dev-public] Fwd: [arch-commits] Commit in (9 files)
A bit sad to be starting out the new docker package with the mark of
shame (epoch=1), but so be it. ;)
Summary / suggsted plan:
1. Rename docker (the old one) to docker-tray and add replaces=('docker=1.5')
2. Upload and add epoch=1 to docker (the new one)
I can do step 2 if someone can handle step 1.
- Alexander / xyproto
Re: [arch-dev-public] Fwd: [arch-commits] Commit in (9 files)
Shouldn't that be 'docker=1.5'? I thought users were not supported if they did not have an up to date system, but I guess it doesn't hurt. - Alexander / xyproto
[arch-dev-public] Moving two unneeded orphans from [community] to AUR
Hi, gnome-commander was last updated 2011-12-10, is currently an orphan and no other package needs it. https://www.archlinux.org/packages/community/x86_64/gnome-commander/ perl-config-ini was last updated 2013-10-28, is currently an orphan and no other package needs it. https://www.archlinux.org/packages/community/any/perl-config-ini/ I'm planning to move these two from [community] to AUR. -- Best regards, Alexander Rødseth xyproto / TU
Re: [arch-dev-public] Moving two unneeded orphans from [community] to AUR
Note that perl-config-ini has been maintained by seblu since 2012-01-27, so he must have either actively disowned it, or never adopted it in the first place. This is not a case of wanting to move a package that has just been uploaded, but not adopted yet. See: https://projects.archlinux.org/svntogit/community.git/log/trunk?h=packages/perl-config-ini Seblu, just adopt the package if you still want it, I won't move it until after having heard from you. -- Best regards, Alexander Rødseth xyproto / TU
Re: [arch-dev-public] Moving two unneeded orphans from [community] to AUR
Hi, Ok, adopted gnome-commander. Looking forward to seeing a release from upstream in the future. - Alexander
Re: [arch-dev-public] Moving two unneeded orphans from [community] to AUR
Hi, gnome-commander doesn't compile. Do you still mind if I move it to AUR? Here is one of the errors: In file included from gnome-cmd-tags.cc:36:0: ./../dict.h: In instantiation of 'void DICTKEY, VAL::add(KEY, const VAL) [with KEY = GnomeCmdTag; VAL = GnomeCmdTagName]': ./../dict.h:155:10: required from 'void load_data(DICTKEY, VAL, void*, unsigned int) [with KEY = GnomeCmdTag; VAL = GnomeCmdTagName]' gnome-cmd-tags.cc:540:68: required from here ./../dict.h:58:101: error: 'make_pair' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive] std::pairtypename KEY_COLL::iterator,bool k_pos = k_coll.insert(make_pair(k,(const VAL *) NULL)); ^ In file included from /usr/include/c++/4.8.2/bits/stl_algobase.h:64:0, from /usr/include/c++/4.8.2/vector:60, from gnome-cmd-tags.cc:26: /usr/include/c++/4.8.2/bits/stl_pair.h:286:5: note: 'templateclass _T1, class _T2 std::pair_T1, _T2 std::make_pair(_T1, _T2)' declared here, later in the translation unit make_pair(_T1 __x, _T2 __y) ^ -- Best regards, Alexander Rødseth xyproto / TU
[arch-dev-public] Dropping freeorion from [community]
Hi, Freeorion is extremely troublesome to maintain. There are no releases of source tarballs for Linux, it takes ages to compile, it fails if it's built by using more than one thread (needs make -j1), it needs patching, the make install procedure does not work, there are (or has been) missing includes, it has no .desktop file, it needs special cmake flags in order to use the correct version of python, special cmake flags for C++, modifications to the ogre configuration, a custom script in order to launch correctly, huge amounts of memory to compile and it comes with it's own fork of gigi, a GUI library for C++, which it does not compile without. Upstream is somewhat cooperative, but needs convincing before looking at any problem and doesn't seem to care for Linux. Several TUs have previously maintained it, but orphaned it in frustration. It also takes up a lot of space in the repository. When asking if someone would be interested in maintaining it in, the immediate response from three others was orhpan it. Hence, I'll move it to AUR. -- Best regards, Alexander Rødseth xyproto / TU
Re: [arch-dev-public] Add guile support to make-4.0?
Are there alternative versions of make that could be placed in [core] that works with the rest of the [core] packages (BSD make?) If there is, GNU Make with support for guile, toasters and everything could be relocated to [extra]. - Alexander / xyproto
Re: [arch-dev-public] Add guile support to make-4.0?
No objections, then. - Alexander / xyproto
Re: [arch-dev-public] Orphans
All packages have been handled. Thanks for participating in this year's Midyear Cleanup! - Alexander / xyproto
Re: [arch-dev-public] Orphans
Today is 2013-10-07 in my timezone. If there's this one special orphan you have been thinking about adopting, today is the day. I'm planning on starting moving the packages later today. All ok? - Alexander / xyproto
Re: [arch-dev-public] Git
The following text was sent to me by Kevin Mihelich @ Arch Linux ARM, with permission to post it here as well: We poll the svntogit repo regularly to bring up updates to packages that are made by Arch maintainers, and build everything as-is. For packages that require modifications (configure settings, patches, etc.) to build on ARM systems, we take the package and put it into our github repo in the same spot under core/extra/community with the needed changes. Our build system software then recognizes that the same package is in github and svntogit under the same repo, and uses the github version over svntogit. We also maintain two separate repos out of our github, one called 'alarm' for packages we create, and an 'aur' repo for some of the highly requested AUR packages (since many ARM systems lack the ability to build packages in timely manner, or at all). Like has been mentioned, github's ability to clone and submit pull requests has been a huge feature for us, as it allows contributions and fixes to packages from people that don't want to be a maintainer. It allows us to quickly review the changes, and if everything is fine it get merged and built automatically by the build system -- a huge time saver for us. Additionally, you can dig into commits or existing files and comment on particular lines, creating separate conversation threads on points of issue that need to be resolved. Now, if I may, here's how your decisions on how you set up a git repo in place of svn affect us. Right now, with the svntogit providing a merged repo of all the packages in two places (core/extra in one, community in another) allows me to simply poll the two git repos for changes and operate on that changeset. This means that when packages get added, removed, or modified, I'm able to see everything that takes place. If each package was to be split into its own git repo, I would need to devise some (potentially ugly) solution to scrape all of the current repos from somewhere, match them against what I know to exist, add packages (repos) that just got created and delete packages (repos) that just got removed, then further correlate which pacman repo each belongs to, if repos have changed, etc. It would also require that I either find some way to determine which package git repos changed and only poll them, or potentially have to poll the ~4500 git repos that would exist individually. In short, I don't know how I would accomplish this off the top of my head, and it could be a massive pain to implement. My two cents toward the repo structuring would be to follow the same structure that is in place now with svntogit: have a packages.git that contains core and extra, which Arch developers have access to change, and a community.git that contains community, which devs and TUs have access to change. Unless there is some overbearing need to individually delegate write access per package, individual git repos per package seems like it would be more of an administrative headache than it is worth (aside from destroying my current development model for Arch Linux ARM). Should you decide to use a service like github, a combined package repo also means that community-generated pull requests are also combined, allowing more people to be notified of changes, submit their input, or merge changes when someone is on vacation. A combined repo also means that you can delegate a 'testing' branch to contain all the testing versions of all the packages, allowing one to push/pull to all of the testing packages in one move, or merge a large set of changes back to stable, without having to go through and do the same operation on multiple git repos (I'm specifically thinking of things like the Gnome and KDE package sets). One could potentially create a 'gnome-testing' branch, do all the changes and builds based on that branch, then when it's ready merge that branch back into stable and you're done.
Re: [arch-dev-public] Orphans
Hi, The wiki page has been up for a while now (thanks Balló György) and activity seems to have stopped in terms of adoptions. I'll start moving over the packages that are on the list shortly: https://wiki.archlinux.org/index.php/Midyear_Cleanup/2013#Packages_that_will_be_dropped New TUs that want to learn how to move packages from [community] to AUR: feel free to join in on the moving process. Just ask on IRC if you are stuck or want to know how it can be done. The following orphans should (IMO) be adopted by the people that consider them too important to be moved to AUR. Please adopt them now: libclastfm libgit2-glib libircclient libmatio libnids libx86emu lxde-icon-theme lxinput lxlauncher lxmenu-data lxmusic lxshortcut python2-bsddb, python-bsddb qt4-private-headers raptor1 speakup-utils urlgrabber wvstreams Thank you for participating in the 2013 Midyear Cleanup! -- Best regards, Alexander Rødseth xyproto / TU
Re: [arch-dev-public] Git
Hi, Thanks for the feedback! As a summary: * The reception of the idea of introducing git varies from strongly in favor to no objection (or implicitly in favor). There is only one suggestion that svn might be easier for our use. * At least one person is happy to work on the transition (Tom Gundersen). * I see that Florian Pritz has made great strides with regards to the tooling, ref. the thread with the subject Rewriting dbscripts (packagers should read this!) * The ideas here about using one git repo per package (as suggested by Pierre and Tom) is exactly what has been used in the other thread. * The ideas about using one branch per package or packages as submodules seems to have been disregarded. * The ideas about supporting on a host like github or gitorious have only had a positive reception so far, but someone needs to write a few words about specifically how a service like github or gitorious could be used together with the new tooling (possibly giving references to how Arch Linux ARM are running things). Ideas for next action once the tooling is in place are also needed. I imagine that it mainly is a question of someone with access to the servers flipping the right switches. -- Best regards, Alexander Rødseth xyproto / TU
Re: [arch-dev-public] Orphans
Adopted xdelta3. --- Alexander / xyproto
Re: [arch-dev-public] Making !staticlibs the default in makepkg.conf
Sounds good. The few packages that should need options=(!staticlibs) can just use that. Also, it would be possible to create a TODO for the packages that currently include static libraries. --- Best regards, Alexander Rødseth xyproto / TU
[arch-dev-public] Git
Hi, As I gather, we all like git better than svn, for a long list of reasons. Are there any objections to switching over from svn to git for repositories for the official packages? Yes, this can not be done in a heartbeat. The tools and documentation needs to be updated and the workflow needs to be tested, but are there objections to starting the transition process? -- Best regards, Alexander Rødseth xyproto / TU
[arch-dev-public] Orphans
Posting this one here as well (first posted to arch-general), as requested by Gaetan Bisson. In connection with the newly created TODO lists for rebuilds of packages formerly maintained by people that are no longer involved with Arch Linux, I wondered if there would be any objections if I moved the following packages from [community] to AUR: (They are currently unneeded orphans, ref https://www.archlinux.org/devel/reports/unneeded-orphans/). abe aircrack-ng archlinux-artwork archlinux-lxdm-theme bchunk bpython bpython2 cdck cherrytree cmus consonance ekg ekg2 fdupes fssos-nsvs ginac gkrellm gnome-themes-extras lastfmsubmitd libcgns2 luarocks lxinput lxlauncher lxmusic lxshortcut mpdscribble obkey openclonk openocd perlbrew pkgtools pypy3 python2-basemap python2-mpi4py python2-pyproj python2-virtkey python-apsw python-basemap python-bsddb python-html5lib python-mpi4py python-pyproj python-virtkey smokeping synaptiks tremulous v8 vim-buftabs vobcopy xdelta xdelta3 Several, but not all of these, are on the newly created TODO-lists. All of them are unneeded orphans (https://www.archlinux.org/devel/reports/unneeded-orphans/). If you wish to adopt one of these, just reply to this email (or adopt it). Objections to moving them should preferrably also lead to someone adopting the orphans. -- Best regards, Alexander Rødseth xyproto / TU
Re: [arch-dev-public] systemd 207 ignores /etc/sysctl.conf
Sounds good. Well written and informative, with clear instructions. --- Alexander / xyproto
Re: [arch-dev-public] gcc 4.8 breaking libdrm for me
Well done narrowing the issue down. I haven't had the chance to compare the assembly output yet, but does it work if you compile with -fno-aggressive-loop-optimizations? Ref: http://postgresql.1045698.n5.nabble.com/Back-branches-vs-gcc-4-8-0-td5750997.html - Alexander / xyproto
Re: [arch-dev-public] Removing glib 1, gtk 1 and qt3
Hi, 2013/5/22 Eric Bélanger snowmanisc...@gmail.com: Well gtk is a depends for imlib wich is required by fvwm, the WM I use. fvwm compiles without imlib and thus without gtk1 (As a former fvwm user, for years, I can recommend pekwm or i3 instead). +1 for moving old cruft to AUR -- Sincerely, Alexander Rødseth xyproto / TU
[arch-dev-public] gendesk - a tool for generating .desktop files
Dear TUs and Devs, Some packages uses gendesk, a tool for generating .desktop files. Configurations can be specified by environment variables, commandline options or by giving a path to a PKGBUILD file. If no options are given, gendesk looks for a PKGBUILD in the parent directory. This has been unproblematic up until now, but I just received a report that this could cause problems when building packages on pkgbuild.com. Should you encounter a Could not find ../PKGBUILD error when building a package, just add: --pkgname $pkgname --pkgdesc $pkgdesc to the gendesk line (usually in the prepare() or build() function). This is probably recommended in any case. Other options are available too, and may be required if you, for instance, need the application shourtcut to execute a non-standard executable (not /usr/bin/$pkgname). See gendesk --help or the gendesk man page for more information and a smoergaasboard of possibilities. -- Best regards, Alexander Rødseth xyproto / TU
Re: [arch-dev-public] [announcement draft] MariaDB replaces MySQL in repositories
The latest draft by Jan Alexander Steffens looks good to me. - Alexander
Re: [arch-dev-public] Proposal to change the nvidia-utils package to allow for better bumblebee integration
+1 Sounds reasonable. But, is there a way to achieve the same result without using a helper package? -- Sincerely, Alexander Rødseth xyproto / TU
Re: [arch-dev-public] cleaning up unneeded static libraries?
Hi, Note that one of the two most popular Go compilers relies on static compilation and .a files: pacman -Ql go | grep \.a$ | wc -l 261 Go was created by some of the same people that created Plan9, so I assume the choice of using static compilation is inspired by that: http://www.plan9.bell-labs.com/wiki/plan9/why_static/ -- Sincerely, Alexander Rødseth xyproto / TU
Re: [arch-dev-public] [RFC] Migration to MariaDB
In related news, Fedora and OpenSUSE are supposedly switching over to MariaDB too: http://www.zdnet.com/oracle-who-fedora-and-opensuse-will-replace-mysql-with-mariadb-710640/ - Alexander
Re: [arch-dev-public] Drop VI from [core] (was Re: [arch-general] Winter Cleanup of [community])
Regardless of the outcome of symlink vs. fix hardcoded values, could the vi package be dropped? If people wish to configure sudo before installing their preferred vi-compatible editor with pacman, EDITOR=nano visudo can be used. - Alexander
Re: [arch-dev-public] Drop VI from [core] (was Re: [arch-general] Winter Cleanup of [community])
Hi again, If I understand correctly, vim has now been included on the live medium. The vi package has been an orphan for some time now, and remains an orphan. Judging by the comments in this thread, most devs wish to use vim instead of vi. A symlink can be added so that vim provides /usr/bin/vi. (This is not as good as fixing hard-coded values in several packages IMO, but good enough for now). Can the vi package be dropped? Best regards, Alexander Rødseth xyproto / TU
Re: [arch-dev-public] Winter Cleanup of [extra]
I guess that concludes this winter's (for some part of the world) cleanup of [extra]. Thanks everyone. - Alexander
Re: [arch-dev-public] Drop VI from [core] (was Re: [arch-general] Winter Cleanup of [community])
Hi, 5 days have passed. There are exactly 8 packages in [core] that falls back on vi. === visudo === People can either run visudo like this: # EDITOR=vim visudo Or this could be added to /etc/sudoers (possibly by default): Defaults editor=/usr/bin/vim This can be configured by the user, or changed in the sudo package. Both methods work, and vi is not needed in either case. === cronie and glibc === The same goes for crontab. This works fine: EDITOR=vim crontab -e In order to set the default editor for crontab at compile time, _PATH_VI has to be set correctly in glibc. Here's the relevant code from src/pathnames.h in cronie: #if defined(_PATH_VI) # define EDITOR _PATH_VI #else # define EDITOR /usr/ucb/vi #endif For changing the default editor (_PATH_VI) to vim in glibc, just add this line to the build() function: sed -i 's:/vi:/vim:' sysdeps/generic/paths.h sysdeps/unix/sysv/linux/paths.h === less and util-linux === These tries to start an editor when the v key is pressed. They both respect EDITOR and VISUAL but falls back on vi. (Is less really needed in [core], when more is supplied by util-linux? It seems a bit redundant). The fallback editor for less can be changed at compile time by adding the --with-editor flag: ./configure --with-editor=vim For the more utility in the util-linux package, set the fallback editor to vim by adding this line to the build() function: sed -i 's/vi\t/vim\t/' text-utils/more.c === bash === bashbug that comes with bash falls back on vi. Add this line to the build() function to change this to vim: sed -i 's/\([^a-zA-Z]\)vi/\1vim/' support/bashbug.sh For all of the changes for all of the above packages, I've rebuilt the packages and tested the functionality by unsetting EDITOR and VISUAL and removing /usr/bin/vi. === hairloom-mailx === In the build() function in the PKGBUILD, add: sed -i 's:vi:vim:' edit.c === shadow === Set the define DEFAULT_EDITOR to vim when compiling. I know that patching files with sed isn't really The Arch Way (even though a large numbers of packages do this), so if the remaining argument is that the switch from vi to vim has to come from upstream, I'm willing to submit patches/bug reports for all of the above that needs changes in the sourcecode (preferably without vi being hardcoded). === In summary === * All packages should respect the EDITOR or VISUAL environment variables (or at least _PATH_VI), so users can select whichever editor they like. * It's fully possible to change the fallback editor for all [core] packages to be vim instead of vi. * Switching from vi to vim should be unproblematic. +1 for dropping vi from [core] and including vim on the install medium instead. -- Sincerely, Alexander Rødseth xyproto / TU
Re: [arch-dev-public] Drop VI from [core] (was Re: [arch-general] Winter Cleanup of [community])
It's not a given that a vi clone is the most desirable replacement. If an editor that is not a vi clone should be preferred, now or in the future, a symlink named vi looks funny. But mainly, the motivation for a thorough examination of where vi is actually used in [core] was to bring some peace of mind to those who were afraid of breakage. Hopefully someone appreciated the effort. - Alexander
Re: [arch-dev-public] [arch-general] Winter Cleanup of [community]
Hi, Several of the uneeded orphans has been adopted, which is great. === [community] === Here is the list for [community], that I'll now move to unsupported: dcron espeakup gmerlin-avdecoder iksemel isomaster libmatio libtlen libxml-perl lua-sql-mysql lua-sql-postgres lua-sql-sqlite mget multipath-tools nvclock pam-krb5 perl-text-wrapi18n pidgin-musictracker python2-gasp python2-pypdf python-simplejson udunits vim-nerdcommenter vim-timestamp The only new addition to the list is python-simplejson (also an uneeded orphan and also not a make dependency of any of the other [community] packages). A total of 23 [community] packages will be moved to unsupported. 1 package were already moved to unsupported and 4 other packages were adopted. === [core] === For [core], there are two uneeded orphans, that also aren't make dependencies for any other [core] packages: openldap vi If I may be so bold, maybe vim or another editor (still providing the vi command) could take over for the vi package? And perhaps openldap could be moved to [extra] or [community]. === [extra] === For [extra], these are the packages that are uneeded orphans and are also not make dependencies for any other package in [extra]: alacarte archlinux-wallpaper aspell-hu aspell-nl aspell-pt aspell-ru avfs bin86 bluez-hcidump bmp-musepack bmp-wma bochs botan cdargs dcfldd devilspie emelfm2 evilwm evolution-ews festival-english festival-us fltk-docs fltk-games fssos-nsvs gcdmaster gimp-dbp gimp-gap gimp-ufraw gmpc gtkpod hercules herqq hunspell-hu hyphen-hu hyphen-it hyphen-nl kradio kshutdown libmusicbrainz4 libofx-doc mahjong misdnuser monica mythes-hu mythes-it mythes-nl nicotine opendesktop-fonts oprofile orage perl-event perl-file-tail perl-unicode-string pidgin-encryption proftpd pymad python-httplib2 python-isodate python-xdg python-zope-interface qiv ratpoison rox xdelta xdelta3 xdg-user-dirs-gtk xfburn xfce4-artwork xfce4-battery-plugin xfce4-clipman-plugin xfce4-cpufreq-plugin xfce4-cpugraph-plugin xfce4-datetime-plugin xfce4-dict xfce4-diskperf-plugin xfce4-eyes-plugin xfce4-fsguard-plugin xfce4-genmon-plugin xfce4-mailwatch-plugin xfce4-mixer xfce4-mount-plugin xfce4-mpc-plugin xfce4-netload-plugin xfce4-notes-plugin xfce4-quicklauncher-plugin xfce4-sensors-plugin xfce4-smartbookmark-plugin xfce4-systemload-plugin xfce4-taskmanager xfce4-time-out-plugin xfce4-timer-plugin xfce4-verve-plugin xfce4-wavelan-plugin zile If no devs wish to maintain these, perhaps they could be moved to [community]. -- Best regards, Alexander Rødseth xyproto / TU
Re: [arch-dev-public] [arch-general] Winter Cleanup of [community]
Hi, 2013/1/24 Allan McRae al...@archlinux.org: I agree with just dumping vi and moving [vim] to core... But we can not put split packages across repos and gvim and deps are not going there so that is a no... That is fully understandable. I guess unsplitting vim/gvim is not a viable option either. I see that nano is already in core, but if there's a wish for a vi-compatible editor in [core], there is e3 in [community] which also provides /usr/bin/e3vi for vi-compatibility. It's really tiny and fast, and only takes up 76 KiB of space after installation. Perhaps that could be an alternative? And perhaps openldap could be moved to [extra] or [community]. Split package with libldap... so no. These are the packages in [core] that depend on libldap: dirmngr nfsidmap krb5 dirmngr and nfsidmap are maintained by Tobias Powalowski, while krb5 is maintained by Stéphane Gaudreault. Perhaps one of them would like to adopt libldap, since only their packages in [core] depends on it. -- Best regards, Alexander Rødseth xyproto / TU
Re: [arch-dev-public] Drop VI from [core] (was Re: [arch-general] Winter Cleanup of [community])
Hi, As far as I can tell from FS#20778, e3 was not evaluated. e3 provides Wordstar, Emacs, Pico, Vi and Nedit-like behavior, by using differently named symbolic links to /usr/bin/e3. It is unclear why the default editor _has to_ be a vi-replacement, as that excludes editors such as joe, jed or various emacs-clones. If ed really is the golden UNIX standard, perhaps the default editor doesn't have to be a vi-replacement at all? If only fully fledged editors are good enough, why not include both emacs and gvim. (or the no X equivalents, like emacs-nox). Is there not room on the image? Is the bandwith cost too high? Are they not useful? I think they are. I know this isn't my decision, but my suggestion is to either go for the most lightweight editor, e3, or go all in with both emacs and vim. -- Sincerely, Alexander Rødseth xyproto / TU
Re: [arch-dev-public] [arch-general] Winter Cleanup of [community]
Hi, @Fons Adriaensen Didn't think of that, here's the current list: dcron espeakup gmerlin-avdecoder i2c-tools iksemel isomaster libmatio libtlen libtxc_dxtn libxml-perl lua-sql-mysql lua-sql-postgres lua-sql-sqlite mget multipath-tools ndisc6 nvclock pam-krb5 perl-text-wrapi18n pidgin-musictracker python2-gasp python2-pypdf ttf-envy-code-r udunits vim-nerdcommenter vim-timestamp winefish I also checked that none of these packages are makedepends of any of the [community] packages. @Gaetan Bisson: Please send such messages to arch-dev-public in the future: adopting packages are dev's and TU's decision, and not all read arch-general. I also think non-devs and non-TUs may have valuable insights for why for instance a package should be considered to be too important to not be moved to unsupported. The ibus and lxdm packages were considered to be too important to move to unsupported during the last cleanup. Perhaps someone (the upstream developers?) may have a reason or opinion for why one of the listed packages should not be moved. The decision would still be in the hands of devs and TUs, but there could still be potentially useful information coming from the outside. 45.8 degrees beg to differ. Point taken, and suggestions for a better name are welcome. How about New Year Cleanup? -- Sincerely, Alexander Rødseth xyproto / TU
[arch-dev-public] Winter Cleanup of [community]
Hi, Posting this here as well, after a suggestion from Gaetan Bisson: It's time again for the yearly cleanup of the [community] repository. Somehow, time passed, and it's now too late for a Christmas Cleanup like last year. Instead I'm announcing a Winter Cleanup, which I think is a better name as well. (Or perhaps New Year Cleanup is better, as there isn't winter everywhere at the same time. Suggestions for a better name is welcome). The wonderful developers of Arch Web have added a report of Uneeded Orphans since last time, which should make this cleanup considerably easier. (Thanks Dan McGee: https://projects.archlinux.org/archweb.git/commit/?id=5379348c9337a4abe27e807fef7956e11eebed30) Another positive development is that all the ibus-packages that nobody seemed to want to adopt, are no longer orphans. Thanks goes out to Felix Yan, one of our latest TUs, for that. The list of unneeded orphans can be viewed at this page: https://www.archlinux.org/devel/reports/unneeded-orphans/ Here is the current list: dcron espeakup gmerlin-avdecoder i2c-tools iksemel isomaster libmatio libtlen libtxc_dxtn libxml-perl lua-sql-mysql lua-sql-postgres lua-sql-sqlite mget multipath-tools ndisc6 nvclock pam-krb5 perl-text-wrapi18n pidgin-musictracker python2-gasp python2-pypdf ttf-envy-code-r udunits vim-nerdcommenter vim-timestamp winefish I also checked that none of these packages are makedepends of any of the other [community] packages. If you know of other packages that deserves to be cleaned up somehow, in [community], AUR or any of the other repositories, please reply to this e-mail and let us know. (If there should be too many requests, we'll start a wiki page this year as well). If there aren't any protests, I'll wait a couple of days and then move all the unneeded orphans in [community] to AUR. Developers and maintainers of [core], [extra] and [multilib] should feel free to join in on the cleanup, of course. I'll round off this invitation with a somewhat pretentious and slightly akward slogan: :] Happy Winter Cleanup. Let our repositories shine! Sincerely, Alexander Rødseth xyproto / TU
Re: [arch-dev-public] Fix SVN commit mistakes
Hi, I'm guilty of python-pymongo, go and erlang-cl. I was unaware of the need to use communitypkg instead of extrapkg for community packages, until now, and will start using communitypkg instead. -- Sincerely, Alexander Rødseth xyproto / TU
Re: [arch-dev-public] Fix SVN commit mistakes
Hi, That doesn't make much sense to me. I mean, how have you been maintaining packages so far without using communitypkg? Sorry, I was a bit too quick there. I have been using communitypkg all along. I confused it with extra-i686-build and extra-x86_64-build, which I do use for community packages. I have not used extrapkg at all, only communitypkg. -- Sincerely, Alexander Rødseth xyproto / TU
Re: [arch-dev-public] Fix SVN commit mistakes
Hi again, 2013/1/3 Evangelos Foutras evange...@foutrelis.com: On 3 January 2013 15:09, Alexander Rødseth rods...@gmail.com wrote: That does make more sense; thanks for clearing that up. :) Thanks for clearing that up yourself. :) But, now I'm confused, because I never used extrapkg at all on those three packages that I maintain. I don't see any indication anywhere in the changelog for those three that extrapkg have been used either (if that's where it would show up). Allan, what is your source for that extrapkg has been used on these three? python-pymongo go erlang-cl And what could be the reason that someone would run extrapkg on these? Thanks. -- Sincerely, Alexander Rødseth xyproto / TU
Re: [arch-dev-public] Fix SVN commit mistakes
Hi, 2013/1/3 Allan McRae al...@archlinux.org: There were directories in the repos/ directory of SVN that should not be there. Dirrectories like extra-x86_64.Either than or directories name x86_64 which implied using archrelease manually and wrong... I must have created a directory named just repos/x86_64 and repos/i686 by accident. Sorry about that. In any case, extrapkg was not involved. And what could be the reason that someone would run extrapkg on these? Stupidity. Stupidity in response to creating two directories by mistake and svn commit messages like fix shit. Are you 12? - Alexander
Re: [arch-dev-public] pekwm in [extra]
Thanks. :) -- Sincerely, Alexander Rødseth xyproto / TU
[arch-dev-public] pekwm in [extra]
Hi, My favorite windowmanager is currently an orphan. If someone would move it to [community], I would be happy to maintain it. -- Best regards, Alexander Rødseth xyproto / TU
Re: [arch-dev-public] Clarity about initscripts and systemd status
Good idea, +1. To find deleted files that ends with .rc: svn log -v | grep '^ *D.*/trunk/.*\.rc$' D /fail2ban/trunk/fail2ban.rc D /multipath-tools/trunk/multipathd.rc D /virtualbox/trunk/vbox-service.rc D /oidentd/trunk/oidentd.rc D /ufw/trunk/ufw.rc D /backuppc/trunk/backuppc-httpd.rc D /oss/trunk/oss.rc D /tor/trunk/tor.rc D /pulseaudio/trunk/pulseaudio.rc This does not catch every single deleted rc script, but may perhaps catch one or two that should have been submitted to the rc git repo, in the future, but weren't. -- Best regards, Alexander Rødseth xyproto / TU
Re: [arch-dev-public] Dropping all packages with missing systemd units
Hi, 2012/10/31 Tom Gundersen t...@jklm.no: Alexander: Would you like to take over pdns-recursor too? As to noip, as it is already in community and has been on the TODO for ages, you might as well add yourself as co-maintainer and update it. Ok, sure. Will do. - Alexander
Re: [arch-dev-public] Unannounced mass edit of community PKGBUILDs
Hi, A former TU has kindly made me aware that it looks like I disagree with the overall point here, which is that one should not make changes like the ones I made without first discussing it with the rest of the maintainers. I fully agree with this, and has already apologized for doing so, just to make it clear. Best regards, Alexander Rødseth
Re: [arch-dev-public] Unannounced mass edit of community PKGBUILDs
Hi Xyne, 2012/10/27 Xyne x...@archlinux.ca: Of course the PKGBUILDs and everything else in the repos belong to Arch, not each individual packager. I didn't mean that it was disrespectful in the sense of encroaching on others' property. I meant that it was disrespectful in the sense that you concluded that most of the other packagers were producing substandard packages and that you needed to help them do it right. Let me quote the Arch Packaging Guidelines [1]: When creating a package description for a package, do not include the package name in a self-referencing way. For example, Nedit is a text editor for X11 could be simplified to A text editor for X11. And the DeveloperWiki:Bash Coding Style page [2]: Use single quotes if a string does not contain parseable content. These are not policies and guidelines that have originated from my own head, from belief in my own superiority nor out of any disrespect. If you think otherwise, you're wrong. I wanted to implement lots of small changes, that people otherwise won't bother with, that are in compliance with the current guidelines. I am having a hard time believing you find this to be disrespectful. I could clarify further but this is already too far off topic and likely to create tension. No please, do clarify further, if there is anything you haven't made clear yet. I found your implication that my intentions may not have been good troubling... Good intentions or not is an idiomatic expression. It conveys that I thought your intentions were good, but that it doesn't change what follows. Compare believe it or not [1]. It was satire, since I believe you're making a big deal out of a miniscule issue. - Alexander [1] https://wiki.archlinux.org/index.php/Arch_Packaging_Standards [2] https://wiki.archlinux.org/index.php/DeveloperWiki:Bash_Coding_Style
Re: [arch-dev-public] Unannounced mass edit of community PKGBUILDs
Hello, First of all, sorry for not communicating this before making the changes. I honestly thought this would be considered to be such a minor change and such a minor issue (even though it affects many packages), that it would not be worth communicating first. If I had been aware of previous cases where similar changes were made (by a script), and the changes were communicated first, I would have attempted to follow the example of those. Secondly, this change did not cause any technical problems. There was one case where the description was broken (0.0004% of all affected packages), thanks Gaetan Bisson for pointing it out. As far as I know, that was the exception to the rule (and the package would still build), but any bug is inexcusable, of course. When it comes to double vs single quoting, can we change PKGBUILD.proto to use single quotes? The character '$' only occurs in the package description in 3 of the community packages, and those 3 can still use double quotes. All that aside, would it be okay for you all if I removed An ..., A ... and Application is ... from the start of all package descriptions (and making the first letter an uppercase letter)? This adds no information to the description and (IMO) looks ugly. Just this change, no changes to indentation, trailing periods or quoting? Thanks for your understanding. May any distressed individuals find it in their hearts to let go of the outrage and search innner peace and ponies. -- Sincerely, Alexander Rødseth Arch Linux Trusted User (xyproto on IRC, trontonic on AUR)
Re: [arch-dev-public] Unannounced mass edit of community PKGBUILDs
Hi Dan, 2012/10/25 Dan McGee dpmc...@gmail.com: I think you also missed this case, given that the single quote ' is used quite regularly in the English language: You're jumping to conclusions here. If you check the changes I made, you will see that single quotes within double quotes were checked for: https://projects.archlinux.org/svntogit/community.git/diff/checkinstall/trunk/PKGBUILD?id=9f040fd30a39c05d750d670ca40fc80f6c648b71 -- Cordially, Alexander Rødseth Arch Linux Trusted User (xyproto on IRC, trontonic on AUR)
Re: [arch-dev-public] Unannounced mass edit of community PKGBUILDs
Hello Xyne, 2012/10/25 Xyne x...@archlinux.ca: The lack of communication really is the key issue here. It is disrespectful to other packagers to improve their packages this way. I disagree with you here, for two reasons. Firstly, I view the package ownership as a collective ownership, where the package maintainers of Arch Linux maintain all the packages together. At least for [community]. This is reflected on how we help each other out on TODO-lists, with bugs and with updates on packages. I certainly wouldn't mind if someone fixed a problem with one of the PKGBUILDs I maintain, or ran a script (that could easily be rolled back) that made a series of minor positive changes (like converting every PKGBUILD in [community] to UTF-8). Secondly, the changes were made on so many packages, that it's hard to believe anyone would take it personally or view the change as disrespectful. Of course, if people cling to their packages, believe every man is an island and put much pride in their package descriptions, I can understand why it can be perceived as disrespectful, but I still insist that it is not. It is also dangerous to have one dev or TU who thinks he knows best and who will push sweeping changes without so much as a discussion about his intentions. This is two different things. I don't think I know best, but I think I had a good idea, and I knew the changes were both harmless and easy to revert. However, I agree that I should have communicated my intentions first. For this, I have already apologized. But, I disagree that it's a big deal, and I protest the use of a word like dangerous in this context. I won't comment on the stylistic aspects of PKGBUILDs you mention. Good intentions or not, I find the lack of consideration troubling. I found your implication that my intentions may not have been good troubling... -- Best regards, Alexander Rødseth Arch Linux Trusted User (xyproto on IRC, trontonic on AUR)
Re: [arch-dev-public] Unannounced mass edit of community PKGBUILDs
I fully agree with Rashif on this. Thank you. - Alexander
Re: [arch-dev-public] Unannounced mass edit of community PKGBUILDs
Hi, Den 25. okt. 2012 23:41 skrev Gaetan Bisson bis...@archlinux.org følgende: Adding insult to injury - way to go my friend! Way to ignore all my points. Guess where the only pride I can see comes from... Pride is a large topic. I think it's good to be proud of the work you do and whatever good intentions you have. However, I don't think it's constructive to be overly protective of the revision history of PKGBUILD files you maintain. Please do tell where the only pride you can see comes from. - Alexander
Re: [arch-dev-public] New developer: Gerardo Exequiel Pozzi
Congrats :)
Re: [arch-dev-public] TU Removal -- Kaiting Chen
That was a thoughtful, accurate and well written TU removal post. I'm glad it was included that Kaiting may reapply if he finds the time in the future. Now to find a TU that uses and wants to maintain all the ibus packages in [community]... -- Best regards, Alexander Rødseth Arch Linux Trusted User (xyproto on IRC, trontonic on AUR)
Re: [arch-dev-public] TU Removal -- Kaiting Chen
Just to be clear, I meant to commend Lukas Fleischer for writing a message of this type, since I know can be hard to write. Sorry if it came across as irony or if I was unclear. - Alexander
Re: [arch-dev-public] [RFC] Python 3.3.0 and PEP 394
Would it be feasible to install the needed files for both python2 and python3? If John said Fetch me 'pyalpm', could he not get a few files installed in both /usr/lib/python2.7/ and /usr/lib/python3.2/? The disk usage is negligible and having both installed would be unproblematic (or at least be likely to solve more problems than it creates). There are other examples of packages including more files than strictly requested, like header files in lib* packages and additional documentation and examples for some packages. If this feels to un-Arch-like, a clean cut alternative would be to drop python2 completely and move everything that has to do with python2 to AUR, only keeping python3 and just prepend all python package names with python-. Just my two cents, please don't flame me. -- Best regards, Alexander Rødseth, TU
[arch-dev-public] multilib
Hi, Chuck has recently released a 64-bit compatible source tarball, so the multilib package is no longer needed for x86_64. Can I have access to [multilib] so I can remove chuck? (and possibly make other useful changes to multilib in the future). Thanks. -- Cordially, Alexander Rødseth Arch Linux Trusted User (xyproto on IRC, trontonic on AUR)
Re: [arch-dev-public] multilib
Thank you, Thomas. -- Best regards, Alexander Rødseth Arch Linux Trusted User (xyproto on IRC, trontonic on AUR)
