Re: [arch-general] A suggestion for the devs regarding rebuilds
2010/1/10 Xavier > On Sun, Jan 10, 2010 at 7:08 PM, Jeff Horelick wrote: > > This would likely require 2 changes to pacman to implement: > > 1. Pacman would have to know that libpng8 is the newer version of libpng7 > > and prompt users to install that (or do it as a upgrade keeping the old > > package). > > Is that needed ? Newly rebuilt packages that need libpng8 would depend > on libpng8, so libpng8 would be picked up that way. > If you have no packages requiring libpng8, there is no need to install it. > > > 2. Pacman would have to know something was removed from the repo and > somehow > > notify the user and possibly give them a [Y/n] to remove it from their > > system. (I personally think this is a good idea to implement anyway). > > > > pacman -Qm > (GMail sucks at mailing lists, this is the best way i can handle this without wanting to hurt myself) 1. I suppose it isn't needed, i was just thinking more about user perception. If it looks like a upgrade, users generally are less likely to complain as opposed to if it looks like a new dependency for a package they have. Just a thought. 2. pacman -Qm has 2 flaws that i see. For one, it'll also list all your AUR packages, it'd be nice to maybe just list packages that were installed from the repos but are no longer there and ignore any manually installed packages. For two, i was thinking something a bit more obvious to the user (i've been using Arch for 2 years now and i didn't know about pacman -Qm) that would display on 'pacman -Syu' that after the packages were installed, something like: "libpng12 and libjpeg7 are no longer being used by any packages, would you like to remove them [Y/n]". I'm thinking this would be good because there could be a lot of clutter on the system if you have to check for "deprecated" packages manually.
[arch-general] A suggestion for the devs regarding rebuilds
Hey all, I have a suggestion to possibly make rebuilds a bit less painful (or non-existant). I think this is a good idea because it seems like right now, even before there was a new rebuild (ffmpeg/x264) in testing, there's already another on the horizon (linjpeg/libpng, and it's a big one) and when this isn't the case, there's usually a rebuild, when it leaves testing, another rebuild comes in within days and so on. My suggestion would be to do what Debian does and when there's a library release with a new soname, bump the old package and "rename" it (or for new packages just do it from the start) and make the package name include the soname version (like libjpeg7, libpng12, libtorrent-rasterbar4 and so on) and when the soname is bumped upstream, just make libjpeg8 or libpng13 or libtorrent-rasterbar5. This does clutter the repos a bit, but it pretty much negates the need for rebuilds since (i believe) when the new GNOME for example is released, it'll automagically build against libjpeg8 and libpng13 instead of the old ones and eventually, almost no packages will be using the old ones. Once the package list for a large rebuild like the libpng/libjpeg one is down to 3 or 4 items after like 3 months, you can probably rebuild them and pull libjpeg7/libpng12 from the repos. This would likely require 2 changes to pacman to implement: 1. Pacman would have to know that libpng8 is the newer version of libpng7 and prompt users to install that (or do it as a upgrade keeping the old package). 2. Pacman would have to know something was removed from the repo and somehow notify the user and possibly give them a [Y/n] to remove it from their system. (I personally think this is a good idea to implement anyway). -JD
Re: [arch-general] [arch-dev-public] [signoff] xfsprogs-3.0.3-1
You may want to post that you're looking for a signoff in the [testing] repo section of the forums. They seem to have much higher user traffic than the mailing lists as far as i can see. 2009/10/11 Tobias Powalowski > Am Sonntag 11 Oktober 2009 schrieb Dario: > > Hi! > > > > In data domenica 11 ottobre 2009 02:32:20, Allan McRae ha scritto: > > > Use the xfsprogs package from [testing] and see if everything still > > > works. It should be safe to upgrade only that package from the > > > [testing] repo. If it works, send a message here saying so and what > > > architecture you use. > > > > Ok. I've tried the "safe" progs with expected results and no problems of > > any sort (safe = the programs that don't do something radical as > > xfs_mdrestore). I'm running arch i686. For me, it's all right. Hope this > > helps:) > > > > ciao! > > > > Dario > > Chiacchiera con i tuoi amici in tempo reale! > > http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com > > > Waiting for x86_64 signoff now. > greetings > tpowa > > -- > Tobias Powalowski > Archlinux Developer & Package Maintainer (tpowa) > http://www.archlinux.org > tp...@archlinux.org >
Re: [arch-general] New PKGBUILD for libtorrent-rasterbar
Ignore the symlinking stuff i said earlier. :P It had that issues because i had the old libtorrent-rasterbar version installed while building the new one and that seems to have confused it. I removed all traces of libtorrent-rasterbar from the system, did a rebuild and everything works fine without any nasty symlinking.
Re: [arch-general] New PKGBUILD for libtorrent-rasterbar
Normally, i'd agree with you, but in this case, I wouldn't. First off, looking through the changelog and the commits that make up the release, there are really only API additions, not really any API breaks/removals. Second, I compiled/installed Deluge *AFTER* I compiled/installed libtorrent-rasterbar 0.14.6 and it still was looking for libtorrent-rasterbar.so.4 which makes me think lazy/stupid developer. 2009/10/8 Ray Kohler > On Thu, Oct 8, 2009 at 2:33 PM, Jeff Horelick wrote: > > Quick thing to change that i just noticed. The libtorrent-rasterbar.so > > version was bumped (from libtorrent-rasterbar.so.4 to > > libtorrent-rasterbar.so.5) and that confuses at the very least Deluge and > > possibly other clients as well that use the versioned library rather than > > the plain .so. Perhaps add a symlink in the PKGBUILD to link > > libtorrent-rasterbar.so.5 to libtorrent-rasterbar.so.4 or > > libtorrent-rasterbar.so to libtorrent-rasterbar.so.4. > > That is a bad idea. The soname version changed for a reason. You don't > want to give apps expecting version 4 a version 5 library. Instead, > all apps that link this library need to be rebuilt. >
Re: [arch-general] New PKGBUILD for libtorrent-rasterbar
Quick thing to change that i just noticed. The libtorrent-rasterbar.so version was bumped (from libtorrent-rasterbar.so.4 to libtorrent-rasterbar.so.5) and that confuses at the very least Deluge and possibly other clients as well that use the versioned library rather than the plain .so. Perhaps add a symlink in the PKGBUILD to link libtorrent-rasterbar.so.5 to libtorrent-rasterbar.so.4 or libtorrent-rasterbar.so to libtorrent-rasterbar.so.4.
[arch-general] New PKGBUILD for libtorrent-rasterbar
Hey all, libtorrent-rasterbar is pretty out of date (2 months and 2 package versions), so here's a PKGBUILD for the new version. I bumped the pkgver (obviously), added python to the dependency list since we *ARE* building the python bindings... and I set the package to use the system libgeoip/geoip rather than the one bundled in the libtorrent tarball (which is a new configure option in libtorrent-rasterbar 0.14.6). It also checks out fine with namcap (no warnings or errors) and it compiled perfectly on the i686 box I tested it on. Part of the reason i'd like to see this updated is that Deluge 1.2.0_rc1 is out and myself and probably a few other Arch users would like to use it, but it requires libtorrent-rasterbar >=0.14.5 . The PKGBUILD is attached, but in case it gets filtered out, here's a pastebin link for it: http://dpaste.com/10/plain/ Thanks in advance for building/uploading, JD PKGBUILD Description: Binary data
Re: [arch-general] which package provides ifup & ifdown command ?
As Sven-Hendrik said, you need to use ifconfig $interface up and ifconfig $interface down. If you really need ifup and ifdown, put this in your .bashrc: alias 'ifup eth0'='ifconfig eth0 up' alias 'ifdown eth0'='ifconfig eth0 down" It's likely that you could replace hardcoding eth0 with using something like $2, but it's 4AM and i'm too lazy to write up a example for that.
Re: [arch-general] [arch-dev-public] GNOME 2.28 - changes ahead
On Mon, Aug 10, 2009 at 2:20 PM, Jan de Groot wrote: > There's a release of GNOME 2.27.90 scheduled for this week, which means > that GNOME will enter a code freeze. This is the point where I usually > pick up packaging the next major version. > > For GNOME 2.27/28, some things will change in the distribution: > - DeviceKit-Disks (new package) > - PolicyKit 1.0 replacing 0.9 > - PulseAudio (new package) > - Esound > > Then there's PulseAudio. Though I still don't feel the need for this one > on the systems I own, a lot of users have requested this. PA has matured > a lot in the meanwhile, and PA is more than just an ordinary ESD > replacement. > > Another issue is ESD. This package is not really maintained upstream > anymore, and I don't think it makes sense to have two sound servers as > dependency for one desktop. Given the fact that Fedora disables esound > support since 2.23.4, I think it won't be a problem to remove it from > the dependency chain. Esound will stay in the repositories, but won't be > used by GNOME as sound server anymore. > > > I'm personally unhappy that PulseAudio will be my only sound system choice if i use GNOME. Yes, i realize that PulseAudio has improved massively in the past year or so, but it still breaks quite a few apps and in my experience, skips/stutters more than you want unless you're using a realtime kernel. I really hope PulseAudio will be a optdepend or a actual part of the gnome or gnome-extra groups so that if someone decides they don't want it, they don't have to use it.
