Re: many packages fail to build twice in a row again
Le Tue, Dec 20, 2011 at 10:01:44PM +0200, Peter Eisentraut a écrit : > With recent dpkg(-source) changes, many packages are again failing to > build twice in a row, because of uncommitted upstream changes. Fixing > this was a lenny release goal, maybe it should be one again?!? Most > importantly, maybe someone who has access to one of those build grids > can run the old tests again, because I feel by accidentally stumbling > upon these problems we will not be able to find and fix many of them any > time soon. Personally I have given up making packages buildable twice in a row using “debian clean” for the packages I maintain with git, as it is really easy to reset the repository with “git clean” and “git checkout”. Half of the source packages that declare a VCS are managed with Git. I think that instead of making complex workarounds, we would benefit of allowing the 3.0 (git) source format, where “git clean” and “git checkout” could be ran from the clean target of debian/rules, if there is agreement that it does not violate the principle of least surprise, as it also wipes out changes made in the debian directory. About acceptability of that format for our archive, I have not seen direct evidence that it is unsuitable, see http://bugs.debian.org/642801. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111221093053.GH18013@chouca.igloo
Re: many packages fail to build twice in a row again
On 20/12/11 at 23:16 +, brian m. carlson wrote: > On Tue, Dec 20, 2011 at 09:36:47PM +0100, Lucas Nussbaum wrote: > > On 20/12/11 at 22:01 +0200, Peter Eisentraut wrote: > > > With recent dpkg(-source) changes, many packages are again failing to > > > build twice in a row, because of uncommitted upstream changes. Fixing > > > this was a lenny release goal, maybe it should be one again?!? Most > > > importantly, maybe someone who has access to one of those build grids > > > can run the old tests again, because I feel by accidentally stumbling > > > upon these problems we will not be able to find and fix many of them any > > > time soon. > > > > Is it really worth it? There are many ways to work-around this, such as > > using a temporary git repo to be able to 'git clean' and return to a > > clean state before each build. > > If I'm fixing an RC bug, it's very convenient to be able to test a patch > and then rebuild with a different patch if necessary. If the package > doesn't build cleanly N times in a row, or if there are other problems > with the packaging that make it difficult to fix, I usually go on to fix > other bugs instead. Also, when I file a bug report, the harder you make > it to fix your package, the less likely you are to receive a patch with > that report, workaround or not. I'm not saying that it's not convenient. But on the other hand, several hundreds of packages probably need to be fixed, which will require a large amount of manpower that could be used instead to fix problems affecting our users. Maybe it's better to fix those bugs when they are encountered, rather than have a systematic effort to fix them all? If you are interested into mass bug filing about issues that affect our users, see http://lists.debian.org/debian-qa/2011/08/msg00091.html for a list of 1073 packages failing to install, remove, or upgrade from squeeze. Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111221094135.ga14...@xanadu.blop.info
Re: from / to /usr/: a summary
Enrico Weigelt, 2011-12-21 05:35+0100: > The reasons for that separation in FHS are far more than just > historical slowless/expensiveness of larger spindles. > > / should only contain things needed for boot up into singleuser, > /usr should hold all the rest. I tend to agree. At least, this is how I interpret the FHS, and it seems appropriate to me. Although it may not be useful in most cases, I do not see it as harmful. -- ,--. : /` ) Tanguy Ortolo | `-'Debian Maintainer \_ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jcsb0i$icl$1...@dough.gmane.org
Re: from / to /usr/: a summary
On Wed, 21 Dec 2011, Tanguy Ortolo wrote: > I tend to agree. At least, this is how I interpret the FHS, and it seems > appropriate to me. Although it may not be useful in most cases, I do not > see it as harmful. The harm is if it takes us extra development time because other distributions don't support it, provide configuration options for it, or test it. http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard http://en.wikipedia.org/wiki/History_of_hard_disk_drives#Timeline The FSSTD started in 1994 when 1GB was a big hard drive. It became known as the FHS in 1997 when 10G was a big drive. The last FHS release was in 2004 when 100G was a big drive. Nowadays 100G disks are small by laptop standards and for desktops 1TB is about the smallest that anyone would buy. During the same time period there has been a lot of work on filesystem technologies to support larger storage (both directly through addressing limits and indirectly through fsck speed etc). Finally there has been development of OS technology such as a tmpfs for /dev and the recent addition to Testing and Unstable of a tmpfs for /run which reduces the use of the root filesystem. Things have changed a lot since the FSSTD first came out. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201112212155.23361.russ...@coker.com.au
Re: from / to /usr/: a summary
On Wed, Dec 21, 2011 at 09:55:23PM +1100, Russell Coker wrote: The harm is if it takes us extra development time because other distributions don't support it, provide configuration options for it, or test it. Well, this happens with other things as well. There was a time, when Debian was the test platform for XFree86 on other platforms besides x86, because upstream didn’t care for them. Today Debian has still a lot of CPU architectures and has to spent time debugging different programs because upstream does not care for Sparc or ARM. The strict licence politics of Debian are no time savers as well. So your argument can not really be an excuse. Nowadays 100G disks are small by laptop standards and for desktops 1TB is about the smallest that anyone would buy. I know a lot of new desktop systems with 300G, 500G or 750G. And it many cases people don’t know what to do with this space. Finally there has been development of OS technology such as a tmpfs for /dev and the recent addition to Testing and Unstable of a tmpfs for /run which reduces the use of the root filesystem. I don’t really believe this. An old tar archive of /dev is about 670k, /run is a symlink to /var/run, and /var is a different partition of course. Things have changed a lot since the FSSTD first came out. True, but / as emergency system is still a valid reason. That’s why I keep / and /boot outside LVM, so that I can repair/rename/change the LVM system. I did this more than once. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: from / to /usr/: a summary
On Wed, 21 Dec 2011, Stephan Seitz wrote: > True, but / as emergency system is still a valid reason. That’s why > I keep / and /boot outside LVM, so that I can repair/rename/change the > LVM system. I did this more than once. When was the last time you needed to do that? AFAIK the only reason you need to do LVM stuff from outside LVM nowadays is if you want to rename a VG - that's not a common operation. On one of my AMD64 servers the sum of /usr/bin, /usr/sbin, and /usr/lib is 160M. On my AMD64 workstation (which has heaps of things installed) it is 165M for /usr/bin and /usr/sbin and 1.3G for /usr/lib of which 214M is for Libre Office. Probably the best thing we could do in this regard is to move some stuff from /usr to /usr/share or some other tree that is more convenient for placing on a different filesystem. I've got a 1GB USB stick (which is too small for most uses of USB sticks) which is setup for system recovery, it has a complete text-mode Debian installation. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201112212329.24674.russ...@coker.com.au
Re: many packages fail to build twice in a row again
Hi, Am Dienstag, den 20.12.2011, 21:36 +0100 schrieb Lucas Nussbaum: > On 20/12/11 at 22:01 +0200, Peter Eisentraut wrote: > > With recent dpkg(-source) changes, many packages are again failing to > > build twice in a row, because of uncommitted upstream changes. Fixing > > this was a lenny release goal, maybe it should be one again?!? Most > > importantly, maybe someone who has access to one of those build grids > > can run the old tests again, because I feel by accidentally stumbling > > upon these problems we will not be able to find and fix many of them any > > time soon. > > Is it really worth it? There are many ways to work-around this, such as > using a temporary git repo to be able to 'git clean' and return to a > clean state before each build. I also find this a worthy goal. It is not always forseeable that a package will be affected, so if you forget to prepare (e.g. by creating a git repo), you can easily get into a situation where your changes are entangled with a bunch of non-intentional changes that are hard to fix manually and I’ve had to restart from scratch and manually picking my changes from the large diff a few times. I, for one, welcome new FTBTIAR bugs :-) Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
Steve Langasek writes: > On Fri, Dec 16, 2011 at 07:32:35PM +0100, Michael Biebl wrote: >> On 16.12.2011 18:38, Joey Hess wrote: >> > Christian PERRIER wrote: >> >> I'm inclined to follow this advice and would indeed propose that the >> >> "atomic" partman-auto recipe is kept, however without a separate /usr >> >> partition (discussions on -devel and the current practice convinced me >> >> that a separate /usr is seomthing that probably belongs to the former >> >> century..:-) > >> > I don't think that d-i should be on the leading edge of this discussion. >> > Once Debian has made up its mind, d-i can be updated to follow the >> > consensus. > >> To me it looks like there is broad consensus that a separate /usr >> partition should be considered deprecated and this option removed from >> the installer. > > There isn't. There's just a broad consensus among those who are talking > about changing things. > > Some of us think this is completely bogus and are really sick of the same > already-rebutted arguments being repeated over and over on the list as if > that makes them true. Then please once more for the record speak up and tell us why / and /usr must be seperate partitions? We are not talking about dropping support for having a seperate /usr here. Just about D-I not creating / and /usr as seperate partition in the "make more than one partition" automatic partitioning choice. It is obvious that Debian still needs to support /usr being seperate. But that isn't the issue. That is also why I don't agree with Joey. D-I is the only one that makes the choice for the user and as such is the one that can change the recepie. MfG Goswin PS: I myself like a seperate /usr but I wouldn't use it for my parents. I do want a seperate /var and /home for them though so they can't DOS the system by filling up their home. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bor2vz3o.fsf@frosties.localnet
Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
Josselin Mouette writes: > Le samedi 17 décembre 2011 à 17:42 +0800, Thomas Goirand a écrit : >> I do recommend a separate /usr to anyone. It's *not* safe to say that, >> and I know many people that agree with me. To me, it has, and still is, >> the best choice. You have no rights to arbitrary decide what should >> be/was/will be the recommended configuration. Your choice is not more >> valid than mine, and (computer) science isn't about majorities anyway. > > True. But the fact that you are in minority doesnât necessarily mean you > are right, either. > >> Doing this has many advantage. Like, if your laptop has to unexpectedly >> reboot (like when you inadvertently removed power cord when batteries >> were not plugged, which happens often in real life), having separated >> partitions usually makes the fsck faster. > > This is complete bullshit. With a journaled filesystem, the boot time > will greatly increase with the number of filesystems to check. If no > files were modified in /usr, they wonât be mentioned in the journal, and > thatâs all. But having one journal to parse for all the system is > definitely a measurable improvement. Also / and /usr can be read-only and definetly should be on a systems likely to have power outages like laptops. And with a read-only partition you have neither fsck nor journal replay. But even mounting an extra filesystem does cost time. If you want to save the last millisecond boot time you want / and /usr as one read-only filesystem. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877h1qvyqv.fsf@frosties.localnet
Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
On Thu, 22 Dec 2011, Goswin von Brederlow wrote: > PS: I myself like a seperate /usr but I wouldn't use it for my parents. > I do want a seperate /var and /home for them though so they can't DOS > the system by filling up their home. How would filling up /home DOS the system? The only common program I can think of which fails hard when it runs out of disk space is Squid. I expect that some DB servers also have serious problems but I don't think that they will be running a DB server on their home workstation. My experience with systems I run for people who aren't computer experts (which includes my parents) is that filling /home causes various parts of their desktop environment to cease working (thus effectively DOSing the system) and they also just can't save files. I have a separate partition for /home on such workstations, but this is just for ease of backups. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201112220031.56019.russ...@coker.com.au
Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
Russell Coker writes: > On Sun, 18 Dec 2011, Josselin Mouette wrote: >> > Doing this has many advantage. Like, if your laptop has to unexpectedly >> > reboot (like when you inadvertently removed power cord when batteries >> > were not plugged, which happens often in real life), having separated >> > partitions usually makes the fsck faster. >> >> This is complete bullshit. With a journaled filesystem, the boot time >> will greatly increase with the number of filesystems to check. If no >> files were modified in /usr, they wonât be mentioned in the journal, and >> thatâs all. But having one journal to parse for all the system is >> definitely a measurable improvement. > > If we want to improve fsck time then the best thing to do would be to > consider > a different default value for the -i option of mke2fs. > > The current default is to have one Inode per 16K of disk space. Of the > Maildir format mail servers that I run the one with the smallest disk space > used per Inode has 307G and 4773821 Inodes in use for an average of 67K per > Inode. A randomly selected Debian workstation with a lot of packages > installed has for it's root filesystem 9.1G and 19 Inodes for an average > of 49K. > > As it seems quite unlikely that any non-root filesystem is going to have a > smaller average Inode space usage than the root filesystem (I had expected > Maildir to be the pathological case of small files) it seems quite safe to > make the default be -i 49152 for non-root filesystems and be -i 32768 for > root > filesystems. > > Finally using ext4 features either through "mke2fs -t ext4" or "mke4fs" will > give you better fsck performance. Are we doing ext4 by default nowadays? The feature relevant here is that the filesystem knows how many inodes have been used ever and only needs to scan those inodes. So if you only ever used the first 1 inodes out of 1000 that is a huge time saver. > As an aside "mke2fs -t ext4" includes huge_file, dir_nlink, and extra_isize > while mke4fs doesn't. This difference seems wrong to me. Urgs. +1. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8739cevylx.fsf@frosties.localnet
Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
Roger Leigh writes: > On Sun, Dec 18, 2011 at 06:48:53PM +0100, Goswin von Brederlow wrote: >> Josh Triplett writes: >> >> > I disagree; I think it leads to a significant burden. Having /var >> > separate requires pre-determining an appropriate size for it, and that >> > will vary wildly between systems. At a minimum it needs enough space >> > for /var/cache/apt, which can grow to many gigabytes. Servers with mail >> >> Dude, run apt-get autoclean in cron daily. :) > > To be honest, I've always found apt's inability to manage its > cache without manual intervention somewhat annoying. It should > be perfectly capable of pruning its own cache rather than > pointlessly filling up /var with thousands of downloaded > packages. I'm surprised it doesn't automatically remove > outdated .debs when you update, and require special configuration > not to do that. > > > Regards, > Roger There is a really good reason not to do this on upgrade. Say you do upgrade a package and it no longer works then you may want to downgrade to the previous version, which would have been deleted on update. I think the autoclean feature of apt-get is still too clean. It should not clean packages that are installed exactly for the reson of being able to undo a bad upgrade. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5u6ujtd.fsf@frosties.localnet
Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
On Thu, 22 Dec 2011, Goswin von Brederlow wrote: > Also / and /usr can be read-only and definetly should be on a systems > likely to have power outages like laptops. And with a read-only > partition you have neither fsck nor journal replay. You don't have a fsck if the time/count for a fsck hasn't been met. If you have mounted a filesystem ro every time but the 6 months (or whatever time period) has elapsed then you will get a fsck. You could use tune2fs (or an equivalent for other filesystems) to make it an indefinite period. As for power outages, last time I was using a Debian/Unstable laptop I noticed that ext2/3/4 filesystems were remounted with different timeouts according to the power state. So it seems that we already have some better measures to avoid data loss in the event of power failure. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201112220043.50594.russ...@coker.com.au
Re: from / to /usr/: a summary
Darren Salt writes: > I demand that Ben Hutchings may or may not have written... > >> On Sat, 2011-12-17 at 20:42 +, Philip Hands wrote: >> We're now debating what, if any, effort we should make to continue to >> support running init scripts without /usr mounted. There is also >> discussion of whether separate / and /usr partitions should be supported or >> deprecated, but I think that's quite separate. > > If /usr gets mounted earlier, fine. I'm happy if / can be used without > needing /usr for basic recovery. > > I fully intend to continue with lilo, separate /usr and no initramfs/initrd. > I *may* decide to stop using a separate /usr should I need to replace > hardware â but probably not before then. > > I will NOT use an initramfs just to have /usr mounted early enough. Hopfully the consensus will be, and that is what it seems to be at the moment, that a seperate /usr remains supported but the 0.1% crazy septups will need to use initramfs or a similar mechanism to still be able to mount /usr with just /. So as long as you don't do something crazy like have /usr on nfs4 over wireless that won't be a problem. Having an init script that mounts /usr from a local partition is easy enough and only needs a tiny and managable set of packages to be in /. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ty4uuja3.fsf@frosties.localnet
Re: many packages fail to build twice in a row again
Lucas Nussbaum writes: > On 20/12/11 at 23:16 +, brian m. carlson wrote: >> On Tue, Dec 20, 2011 at 09:36:47PM +0100, Lucas Nussbaum wrote: >> > On 20/12/11 at 22:01 +0200, Peter Eisentraut wrote: >> > > With recent dpkg(-source) changes, many packages are again failing to >> > > build twice in a row, because of uncommitted upstream changes. Fixing >> > > this was a lenny release goal, maybe it should be one again?!? Most >> > > importantly, maybe someone who has access to one of those build grids >> > > can run the old tests again, because I feel by accidentally stumbling >> > > upon these problems we will not be able to find and fix many of them any >> > > time soon. >> > >> > Is it really worth it? There are many ways to work-around this, such as >> > using a temporary git repo to be able to 'git clean' and return to a >> > clean state before each build. >> >> If I'm fixing an RC bug, it's very convenient to be able to test a patch >> and then rebuild with a different patch if necessary. If the package >> doesn't build cleanly N times in a row, or if there are other problems >> with the packaging that make it difficult to fix, I usually go on to fix >> other bugs instead. Also, when I file a bug report, the harder you make >> it to fix your package, the less likely you are to receive a patch with >> that report, workaround or not. > > I'm not saying that it's not convenient. But on the other hand, several > hundreds of packages probably need to be fixed, which will require a > large amount of manpower that could be used instead to fix problems > affecting our users. > > Maybe it's better to fix those bugs when they are encountered, rather > than have a systematic effort to fix them all? I think it is beter to have them fixed before someone needs to write a patch for them. The way I prepare a patch for a debian package goes like this: 1. apt-get source (or git/svn) 2. debuild -us -uc -b (see if it actually builds before changes) 3. dch --nmu 4. edit files 5. debuild 6. dpkg -i && test 7. go back to 4 till it works 8. debuild -us -uc -S 9. rename debain/patches/debian-changes-version or debdiff the dsc files 10. reportbug -A patch package If the package does not build N times then steps 4/5/6 are more work. But also step 9 often becomes much more work. The patch becomes a lot larger, usualy because auto* files are included, and then needs extra cleanup before being able to send it. > If you are interested into mass bug filing about issues that affect our > users, see http://lists.debian.org/debian-qa/2011/08/msg00091.html for a > list of 1073 packages failing to install, remove, or upgrade from > squeeze. How large is the intersection of those 1073 with the packages that don't build multiple times? Lets fix that subset first. Easier to fix 2 bugs with a single upload. :) > Lucas MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqfiuiqq.fsf@frosties.localnet
Re: many packages fail to build twice in a row again
Charles Plessy writes: > Le Tue, Dec 20, 2011 at 10:01:44PM +0200, Peter Eisentraut a écrit : >> With recent dpkg(-source) changes, many packages are again failing to >> build twice in a row, because of uncommitted upstream changes. Fixing >> this was a lenny release goal, maybe it should be one again?!? Most >> importantly, maybe someone who has access to one of those build grids >> can run the old tests again, because I feel by accidentally stumbling >> upon these problems we will not be able to find and fix many of them any >> time soon. > > Personally I have given up making packages buildable twice in a row using > âdebian cleanâ for the packages I maintain with git, as it is really easy > to > reset the repository with âgit cleanâ and âgit checkoutâ. > > Half of the source packages that declare a VCS are managed with Git. I think > that instead of making complex workarounds, we would benefit of allowing the > 3.0 (git) source format, where âgit cleanâ and âgit checkoutâ could > be ran from > the clean target of debian/rules, if there is agreement that it does not > violate the principle of least surprise, as it also wipes out changes made in > the debian directory. > > About acceptability of that format for our archive, I have not seen direct > evidence that it is unsuitable, see http://bugs.debian.org/642801. > > Have a nice day, That totaly violates the principle of least surprise. debian/rules clean should never undo changes made by the user. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87liq6uinc.fsf@frosties.localnet
Erlang transition to R15B
Hi! As the new Erlang R15B is out I'd like to upload it to unstable. There are a few backwardly incompatible changes, so it's better to test whether the packages which reverse-depend on Erlang work successfully with R15B. The packages which require testing are: ejabberd (certainly will not work, requires at least patching external drivers and getting rid of 'regexp' module usage). couchdb (could work after rebuild, but likely will require patching external driver, see http://www.erlang.org/doc/man/erl_driver.html for details). erlang-guestfs from libguestfs sources (should just work after rebuild). rabbitmq-server (should not require any changes or rebuild). tsung (uses 'regexp' in its build script) uwsgi-plugin-erlang from uwsgi sources (should work as is) Erlang R15B is already in experimental, so please, test and modify your packages if necessary. I'd like to upload R15B into unstable by the end of December. Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caoq2pxe_2rtxxgype4qurkwd4enhz4tv9kbusba_18qrnoo...@mail.gmail.com
Bug#652891: ITP: nerdtree -- Nerdtree is a vim plugin which gives a tree view of all the directories
Package: nerdtree Severity: wishlist Owner: medhamsh * Package name: nerdtree Version : 4.1.0 Upstream Author : Marty Grenfell * URL : http://www.vim.org/scripts/script.php?script_id=1658 * License : (Public Domain) Programming Lang: (Ruby) Description : Nerdtree is a vim plugin which gives a tree view of all the directories The NERD tree allows you to explore your filesystem and to open files and directories. It presents the filesystem to you in the form of a tree which you manipulate with the keyboard and/or mouse. It also allows you to perform simple filesystem operations. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111221135458.14358.33993.report...@hackersbox.iiit.ac.in
Re: Erlang transition to R15B
Sergei Golovan (21/12/2011): > Erlang R15B is already in experimental, so please, test and modify > your packages if necessary. I'd like to upload R15B into unstable by > the end of December. I suggest you get in touch with the release team to plan this transition. Mraw, KiBi. signature.asc Description: Digital signature
Re: Erlang transition to R15B
On Wed, Dec 21, 2011 at 6:12 PM, Cyril Brulebois wrote: > Sergei Golovan (21/12/2011): >> Erlang R15B is already in experimental, so please, test and modify >> your packages if necessary. I'd like to upload R15B into unstable by >> the end of December. > > I suggest you get in touch with the release team to plan this > transition. Sorry, I'll write message to the release team shortly. Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caoq2pxfh_8hzb_7grx7d6b2-6f2wbnh5d7vx3j9bvgqhwfx...@mail.gmail.com
Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
Josh Triplett writes: > On Sun, Dec 18, 2011 at 06:48:53PM +0100, Goswin von Brederlow wrote: >> Josh Triplett writes: >> > spools (/var/spool/mail), large websites in the default location >> > (/var/www), or large databases (/var/lib/postgresql or similar) will >> > need a lot more. The same applies in reverse, when /var has space to >> > spare but other partitions don't. And even experienced sysadmins find >> > it painful to either resize disk partitions or create magic bind mounts >> > to partitions that have space. >> >> lvresize, resize2fs, done > > Doesn't make it any less painful. (Also, don't forget the resize2fs and > lvresize of some other partition first, and figuring out the appropriate > amount of space to move around.) This also assumes LVM, which we don't > default to. As I said the initial partitions should be small with free space left over to grow them as needed. Most filesystems don't support shrinking, not even offline so leaving free space is the only way to go. And I think multiple partitions without lvm makes no sense as non custom setup. Resizing is likely to be required at some point and basically impossible with real partitions. MfG Goswin PS: Lvm1 had a tool to resize the LV and FS with one command. I miss that for lvm2. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871uryugye.fsf@frosties.localnet
Re: authbind (LD_PRELOAD) and multiarch
Raphael Hertzog writes: > On Mon, 12 Dec 2011, Ian Jackson wrote: >> * I will need to arrange for the same LD_PRELOAD setting to load the >>correct libauthbind for each arch. So I guess I do >>LD_PRELOAD=libauthbind.so.1 rather than supplying an absolute path, >>and trust ld.so to get the right one out of /usr/lib/. >>Is that right ? > > I don't know, ld.so(8) does not document this. (But it doesn't look wrong > at least) > >> * AFAICT there is no way on a multiarch system to say in my >>dependencies "I need this package on all architectures supported on >>this system". I went and looked at testing's fakeroot but I'm not >>sure I should be using what it does as an example. How should an >>LD_PRELOAD hack approach this problem ? > > What does fakeroot do? My first idea would be to fail early and provide a > useful error message. fake(ch)root sets LD_PRELOAD=lib.so and LD_LIBRARY_PATH="/usr/lib/fakeroot:/usr/lib32/fakeroot:/usr/lib64/fakeroot:$LD_LIBRARY_PATH" or nowadays the same using the multiarch dirs. So the library remains a private library but ld.so is tasked with searching for the one mathing the elf format it is loading. > Find out the arch of the executable, verify if the corresponding preload > library is available. If it's not, then fail and instruct the user to > install the missing library. > > But this means that you have done (part of) the work that you were > intending to offload to ld.so. > >> To best avoid transitional problems I guess piece 2 should go into >> "authbind" (Multi-arch: same; Depends: authbind-support) and pieces 1 >> and 3 would in "authbind-support" (Multi-arch: foreign; no >> dependency). But I'm not sure. > > Yes. > > Cheers, The hard part comes with extending this past the simple biarch cases and support for example arm binaries run via binfmt-misc on amd64. The list of directories to add to LD_LIBRARY_PATH needs to be dynamic depending on what architectures are configured for the system. Since we have a few packages that do LD_PRELOAD tricks (eatmydata is another one) maybe we should have a common tool that extends the LD_LIBRARY_PATH, e.g. LD_LIBRARY_PATH="$(extend-library-path --pkg fakeroot)" LD_LIBRARY_PATH="$(extend-library-path --pkg fakechroot --sysroot /srv/chroot)" The tool would then contain the know-how to figure out which multiarch directories to include in a single point instead of eveyone duplicating that code. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjket1lw.fsf@frosties.localnet
Re: authbind (LD_PRELOAD) and multiarch
Goswin von Brederlow writes ("Re: authbind (LD_PRELOAD) and multiarch"):
> Raphael Hertzog writes:
> > What does fakeroot do? My first idea would be to fail early and provide a
> > useful error message.
>
> fake(ch)root sets LD_PRELOAD=lib.so and
> LD_LIBRARY_PATH="/usr/lib/fakeroot:/usr/lib32/fakeroot:/usr/lib64/fakeroot:$LD_LIBRARY_PATH"
> or nowadays the same using the multiarch dirs. So the library remains a
> private library but ld.so is tasked with searching for the one mathing
> the elf format it is loading.
This is addressing the question of where to put the library and still
keep it private. But TBH I'm not sure that there's actually a good
reason for the .so not to go in /usr/lib. That would obviate the need
for the kind of helper you are suggesting here:
> The tool would then contain the know-how to figure out which multiarch
> directories to include in a single point instead of eveyone duplicating
> that code.
An alternative would be to have a single subdirectory of /usr/lib, say
/usr/lib/preload-weird-shit/, which was always searched by
the linker.
I think the harder problem is how to get the right libraries
installed. If you want to run fakeroot you need the library for every
configured architecture.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20210.766.152962.442...@chiark.greenend.org.uk
Re: Bug#652891: ITP: nerdtree -- Nerdtree is a vim plugin which gives a tree view of all the directories
On Wed, Dec 21, 2011 at 07:24:58PM +0530, medhamsh wrote: > * Package name: nerdtree The binary package should be vim-nerdtree. > Version : 4.1.0 > Upstream Author : Marty Grenfell > * URL : http://www.vim.org/scripts/script.php?script_id=1658 > * License : (Public Domain) It's WTFPL, not Public Domain. > Programming Lang: (Ruby) It's vimscript, not Ruby. > Description : Nerdtree is a vim plugin which gives a tree view of all > the directories The short description should be everything after "Nerdtree is a". See §6.2.2 of the developer's reference. I'd been delaying adding this, or any new script, to vim-scripts (as requested in #624661) since vim-addon-manager needs to be fixed to better handle new/removed/renamed files. Currently, if any of that happens, the user has to notice it and remove/re-add the plugin. Seeing how NERD tree now has plugins, this may be something you run into in later versions. -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#652904: ITP: solarpowerlog -- logging photovoltaic data
Package: wnpp Severity: wishlist Owner: Tobias Frost * Package name: solarpowerlog Version : 0.21 Upstream Author : Tobias Frost * URL : http://solarpowerlog.coldtobi.de * License : GPL, LGPL Programming Lang: C++ Description : logging photovoltaic data The program's purpose is to track and log data from photo-voltaic inverters, collect power data and store them. Also a purpose is to provide an interface to extract these data, allowing applications like web site stats of the system. Solarpowerlog supports at the moment Solarmax inverters, connected via ethernet or serial interface, however it is programmed in a way to easy add support for other inverters as well The program supports logging to the console, logging to CVS and writing HTML files to be serverd by a web server. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111221172559.13467.83305.report...@mordor.loewenhoehle.ip
Re: Bug#652891: ITP: nerdtree -- Nerdtree is a vim plugin which gives a tree view of all the directories
Hi, Should I close this bug and resubmit with proper information? Thanks, -- Medhamsh On Wed, December 21, 2011 10:49 pm, James McCoy wrote: > On Wed, Dec 21, 2011 at 07:24:58PM +0530, medhamsh wrote: > >> * Package name: nerdtree >> > > The binary package should be vim-nerdtree. > > >> Version : 4.1.0 >> Upstream Author : Marty Grenfell >> * URL : http://www.vim.org/scripts/script.php?script_id=1658 >> * License : (Public Domain) >> > > It's WTFPL, not Public Domain. > > >> Programming Lang: (Ruby) >> > > It's vimscript, not Ruby. > > >> Description : Nerdtree is a vim plugin which gives a tree view of >> all the directories > > The short description should be everything after "Nerdtree is a". See > §6.2.2 of the developer's reference. > > > I'd been delaying adding this, or any new script, to vim-scripts (as > requested in #624661) since vim-addon-manager needs to be fixed to better > handle new/removed/renamed files. Currently, if any of that happens, the > user has to notice it and remove/re-add the plugin. Seeing how NERD tree > now has plugins, this may be something you run into in later versions. > > -- > James > GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy > > -- Medhamsh Hacktivist | http://medhamsh.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/15257.122.169.163.158.1324491122.squir...@mail.medhamsh.org
Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
On Wed, Dec 21, 2011 at 03:39:37PM +0100, Goswin von Brederlow wrote: > Josh Triplett writes: > > > On Sun, Dec 18, 2011 at 06:48:53PM +0100, Goswin von Brederlow wrote: > >> Josh Triplett writes: > >> > spools (/var/spool/mail), large websites in the default location > >> > (/var/www), or large databases (/var/lib/postgresql or similar) will > >> > need a lot more. The same applies in reverse, when /var has space to > >> > spare but other partitions don't. And even experienced sysadmins find > >> > it painful to either resize disk partitions or create magic bind mounts > >> > to partitions that have space. > >> > >> lvresize, resize2fs, done > > > > Doesn't make it any less painful. (Also, don't forget the resize2fs and > > lvresize of some other partition first, and figuring out the appropriate > > amount of space to move around.) This also assumes LVM, which we don't > > default to. > > As I said the initial partitions should be small with free space left > over to grow them as needed. Most filesystems don't support shrinking, > not even offline so leaving free space is the only way to go. People expect that they can use all the capacity of their disk without having to take unusual steps like resizing partitions and filesystems. After installing Debian on a 1TB drive, "df -h" should say that you have just under 1TB of free space, not just a handful of GB. > And I think multiple partitions without lvm makes no sense as non custom > setup. Resizing is likely to be required at some point and basically > impossible with real partitions. Agreed, with the notable exception of separate /boot when needed. - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111221184256.GA28262@leaf
Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
On 2011-12-21 10:42:56 -0800 (-0800), Josh Triplett wrote:
> People expect that they can use all the capacity of their disk
> without having to take unusual steps like resizing partitions and
> filesystems. After installing Debian on a 1TB drive, "df -h"
> should say that you have just under 1TB of free space, not just a
> handful of GB.
[...]
Which is why I suggested that half the challenge with shifting that
paradigm is education, to reset those expectations among the user
base. I didn't mean to imply it would be easily accomplished...
after all, there's an entire computing lifetime of momentum behind
us which set the original expectation of all your disk being
formatted ahead of time. It's not a change in behavior the average
user is going to warm to overnight, but more user-friendly tools to
manage that procedure and keep track of the situation (available
space on filesystems in each logical volume versus unallocated
extents in the volume group) might go a long way toward easing the
transition.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111221190816.gj...@yuggoth.org
Re: Bug#652891: ITP: nerdtree -- Nerdtree is a vim plugin which gives a tree view of all the directories
On Wed, Dec 21, 2011 at 11:42:02PM +0530, Medhamsh wrote: > Should I close this bug and resubmit with > proper information? No, you don't need to. The intent of the bug (declaring your intent to package NERD tree) is still valid. These are just comments to keep in mind as you prepare the packaging. -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
On Wed, Dec 21, 2011 at 07:08:17PM +, The Fungi wrote: > On 2011-12-21 10:42:56 -0800 (-0800), Josh Triplett wrote: > > People expect that they can use all the capacity of their disk > > without having to take unusual steps like resizing partitions and > > filesystems. After installing Debian on a 1TB drive, "df -h" > > should say that you have just under 1TB of free space, not just a > > handful of GB. > [...] > > Which is why I suggested that half the challenge with shifting that > paradigm is education, to reset those expectations among the user > base. I didn't mean to imply it would be easily accomplished... > after all, there's an entire computing lifetime of momentum behind > us which set the original expectation of all your disk being > formatted ahead of time. And things may change yet again in the future. With Btrfs, one can have a single filesystem with multiple subvolumes. The subvolumes can be mounted independently, and also snapshotted independently, but have a common pool for free data, so unlike partitions any subvolume can grow/shrink as required. I understand that limits will also be able to be set for subvolumes in the future. This gives the ability to have multiple "partitions", but without the limitations and inflexibility of real partitions, or even logical volumes. With Btrfs, it would make logical sense to have dpkg-managed locations under a single subvolume (two if including /var), which would enable ~instantaneous checkpointing/rollback during upgrades. User data in a separate subvolume would thus never be rolled back. I've not checked it recently, but support for subvolumes in the d-i partitioner would be a nice feature for wheezy. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111221191653.gj5...@codelibre.net
Bug#652913: ITP: libdevel-stacktrace-withlexicals-perl -- Perl module for stack traces with access to lexical variables
Package: wnpp Severity: wishlist Owner: "Ernesto Hernández-Novich (USB)" * Package name: libdevel-stacktrace-withlexicals-perl Version : 0.10 Upstream Author : Shawn M Moore * URL : http://search.cpan.org/dist/Devel-StackTrace-WithLexicals/ * License : Artistic Programming Lang: Perl Description : Perl module for stack traces with access to lexical variables Devel::StackTrace::WithLexicals extends Devel::StackTrace allowing the generation of stack traces where it is possible to inspect or change callers' lexical variables via PadWalker. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111221193217.29952.35156.report...@deepthought.ius.cc
Bug#652919: ITP: libdbix-connector-perl -- fast and safe DBI connection and transaction management
Package: wnpp Severity: wishlist Owner: Florian Schlichting * Package name: libdbix-connector-perl Version : 0.47 Upstream Author : David E. Wheeler * URL : http://search.cpan.org/~dwheeler/DBIx-Connector-0.47/ * License : GPL-1+ or Artistic Programming Lang: Perl Description : fast and safe DBI connection and transaction management DBIx::Connector provides a simple interface for fast and safe DBI connection and transaction management. Connecting to a database can be expensive; you don't want your application to re-connect every time you need to run a query. The efficient thing to do is to hang on to a database handle to maintain a connection to the database in order to minimize that overhead. DBIx::Connector lets you do that without having to worry about dropped or corrupted connections. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111221205422.10730.8769.report...@island.zedat.fu-berlin.de
Bug#652920: ITP: libalgorithm-combinatorics-perl -- module for the efficient generation of combinatorial sequences
Package: wnpp Severity: wishlist Owner: Florian Schlichting * Package name: libalgorithm-combinatorics-perl Version : 0.26 Upstream Author : Xavier Noria (FXN), * URL : http://search.cpan.org/~fxn/Algorithm-Combinatorics-0.26/ * License : GPL-1+ or Artistic Programming Lang: Perl Description : module for the efficient generation of combinatorial sequences Algorithm::Combinatorics is an efficient generator of combinatorial sequences. Algorithms are selected from the literature (work in progress). Iterators do not use recursion, nor stacks, and are written in C. See Math::Combinatorics for a pure-Perl module with similar features. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111221210047.12249.60256.report...@island.zedat.fu-berlin.de
Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
On Wed, Dec 21, 2011 at 07:16:53PM +, Roger Leigh wrote: > On Wed, Dec 21, 2011 at 07:08:17PM +, The Fungi wrote: > > On 2011-12-21 10:42:56 -0800 (-0800), Josh Triplett wrote: > > > People expect that they can use all the capacity of their disk > > > without having to take unusual steps like resizing partitions and > > > filesystems. After installing Debian on a 1TB drive, "df -h" > > > should say that you have just under 1TB of free space, not just a > > > handful of GB. > > [...] > > > > Which is why I suggested that half the challenge with shifting that > > paradigm is education, to reset those expectations among the user > > base. I didn't mean to imply it would be easily accomplished... > > after all, there's an entire computing lifetime of momentum behind > > us which set the original expectation of all your disk being > > formatted ahead of time. > > And things may change yet again in the future. With Btrfs, one can > have a single filesystem with multiple subvolumes. The subvolumes > can be mounted independently, and also snapshotted independently, > but have a common pool for free data, so unlike partitions any > subvolume can grow/shrink as required. Ie, almost all upsides of LVM. > I understand that limits will also be able to be set for subvolumes in the > future. Done but not merged into Linus' tree yet. > This gives the ability to have multiple "partitions", but without the > limitations and inflexibility of real partitions, or even logical volumes. Basically, everything but some fragmentation concerns and the possibility to have different filesystem types on different subvolumes. And there's no concern about running out of space on one subvolume while having plenty on another, which is pretty much what this thread is about. > With Btrfs, it would make logical sense to have dpkg-managed locations > under a single subvolume (two if including /var), which would enable > ~instantaneous checkpointing/rollback during upgrades. /var has the problem of including three kinds of data: * Most (by count) are things indirectly managed by dpkg. * Some are ambiguous: apt cache, system logs. You can argue for them to be included in snapshots, or not. * User data (Postgres, etc). I'd say these belong in /srv/ or such instead. If we could split /var into system and user parts, it would be great. On the other hand, I disagree with you that snapshotting multiple subvolumes would be manageable. It'd be a nightmare of multiple parts going out of sync. /etc, /bin, /lib, /sbin, /usr and /var [system] need to go together. I kind of wonder if all of these couldn't be moved into /usr. > User data in a separate subvolume would thus never be rolled back. Snapshotting a subvolume doesn't recurse past mount points, so if your / is a subvolume that includes /etc, /bin, /usr, ... and empty mount points for /home and /srv, you can roll the system back and forward to your heart's content without affecting the data. > I've not checked it recently, but support for subvolumes in the d-i > partitioner would be a nice feature for wheezy. Hell yeah. The most important part IMHO would be letting it place stuff into a subvolume other than [filesystem]:/, even if you had no option of mounting other subvolumes initially. -- 1KB // Yo momma uses IPv4! signature.asc Description: Digital signature
Bug#652945: Atrocious interactions between CDBS, libtool and source format 3.0 (quilt)
Package: cdbs Version: 0.4.100 Severity: grave Justification: zero documentation, wasting hours of development time, causing many bugs I've just wasted multiple hours trying to fix up the mess in an NMU (#652369). That bug itself isn't necessarily caused by CDBS itself, but a lot of the time I've spent trying to fix it definitely is. I've just had to update the dvbstreamer package's local copy of libtool to make it build binaries in a current unstable chroot. After fighting through the CDBS code to decipher how to do that (yay for total lack of documentation!), I've found DEB_AUTO_UPDATE_LIBTOOL that seems to do what I need. Unfortunately, it doesn't take copies of any of the existing upstream files to be able to put them back during a "debian/rules clean" run. That means that dpkg-source v3 (quilt) bitches and refuses to run again once I've done a build due to uncommitted changes. Hence, I can't tweak things and re-run dpkg-buildpackage/debuild while debugging things (as already complained about elsewhere this week). I've looked in vain for any way to make this work, but cannot find one. Therefore, I'm about to upload my new NMU with working packages but (as far as I'm concerned) a buggy build system that will reliably fail to build twice in a row. If this wasn't an NMU and therefore I wasn't trying to keep changes minimal, I would be fixing the package more deeply by repackaging it without CDBS. Please remove this under-documented and badly-designed rubbish from the archive. It's been responsible for bad maintainer behaviour and lots of RC bugs in the past, and I can see this happening again and again in future. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/bash cdbs depends on no packages. Versions of packages cdbs recommends: ii autotools-dev 20110511.1 Versions of packages cdbs suggests: ii devscripts 2.11.2 -- no debconf information -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111222004552.ga16...@einval.com
Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Hi! On Thu, 2011-12-15 at 13:43:19 -0400, Joey Hess wrote: > Roger Leigh wrote: > > I think an important point to consider is that /usr would not > > disappear. It could be replaced by a symlink for new installs. > > This would permit older installs to continue to use /usr, but > > the files would end up on / for new installs. So no changes > > to --prefix would be needed, and the Debian packages themselves > > could still provide files in /usr. > > Didn't the hurd port try this several years ago? My impression was that > they didn't feel it had been worth the pain, perhaps it's not so easy. The old default was changed for GNU/Hurd not because the setup in itself was considered particularly painful, more because doing so for a single port w/o getting the distribution at large to agree this was something worth supporting was painful as overwrite problems were continuously introduced. regards, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111222030044.gc31...@gaara.hadrons.org
Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
On 12/22/2011 02:42 AM, Josh Triplett wrote: > People expect that they can use all the capacity of their disk without > having to take unusual steps like resizing partitions and filesystems. > After installing Debian on a 1TB drive, "df -h" should say that you have > just under 1TB of free space, not just a handful of GB. > Please define "people". I don't consider myself included, and I know many who wouldn't either. I'm *tired* of reading the assumptions that Debian users should be considered dumb ass with zero knowledge by default, when I have the strong feeling it's quite the opposite. So please do not make such generalities and assumptions without any check. Did you actually do a poll to check if they were expecting that? What numbers to you have to back it up? Also, if "people" don't know, why can't they learn? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ef2b678.4050...@goirand.fr
Bug#652954: ITP: logisim -- graphical tool for designing and simulating logic circuits
Package: wnpp Severity: wishlist Owner: Vincent Cheng * Package name: logisim Version : 2.7.1 Upstream Author : Carl Burch * URL : http://ozark.hendrix.edu/~burch/logisim/ * License : GPL-2+ Programming Lang: Java Description : graphical tool for designing and simulating logic circuits Logisim is an educational tool for designing and simulating digital logic circuits. With its simple toolbar interface and simulation of circuits as you build them, it is simple enough to facilitate learning the most basic concepts related to logic circuits. With the capacity to build larger circuits from smaller subcircuits, and to draw bundles of wires with a single mouse drag, Logisim can be used (and is used) to design and simulate entire CPUs for educational purposes. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111222075149.25954.82280.reportbug@vincent-laptop
