ia32-libs transition
Hi, I've just spent over an hour writing and rewriting this mail, and determined that I can't think of a single constructive thing to say. So I'll just ask a couple of questions instead: Is there any way of preventing this kind of major breakage in the future? I don't think many people expect that upgrading one package will FUBAR the packaging system. Is there any chance of Wine becoming functional on amd64 in the forseeable future? Did anyone who isn't on crack get to see 'ia32-apt-get.preinst' and 'ia32-apt-get.postinst' before they were perpetrated upon an unsuspecting populace? Reading them in the process of trying to unfuck my system made me feel more than slightly ill. -Nye -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs transition
On Tue, Jun 30, 2009 at 05:11, Goswin von Brederlow wrote: > Aneurin Price writes: > >> Hi, >> >> I've just spent over an hour writing and rewriting this mail, and determined >> that I can't think of a single constructive thing to say. Not wanting to leave it at that, I've spent a couple of hours today trying to pin down some specifics. Unfortunately I've not had much success. Purging everything related to 32bit compatibility and reinstalling doesn't ever seem to have exactly the same effect - so far I've seen numerous problems, but none of them reproducibly, and many of them making no sense at all - eg how in the world did I lose /usr/bin/dpkg-deb at one point? No clue. The apt segfault went away after setting Cache-Limit to 50331648 - but why did it only start doing that after a couple of goes? Couldn't say. I suspect that all of my problems are secondary damage rooted in a problem I had the first time I tried the update: installing ia32-apt-get requires a ton of entropy to generate a private key (why? beats me). Unfortunately, my system didn't seem to be able to generate sufficient randomness even after an evening of use, so eventually I ^Cd it just so that at least the dpkg database lock would be released. I'm aware that this isn't a good idea, but I didn't feel that I had a great deal of choice - plus I've never had a partial package install be such a headache to clean up before. Curiously, in my later repeats of the process it never took more than a couple of minutes to generate enough entropy, and usually it was less than a minute, so I'm not sure why it had such a problem the first time. Or maybe that, once cleaned up, wasn't the end of the world after all. Another possibility is that I didn't realise until I'd read the other thread that you need to use apt-get to complete the process, so I just used aptitude the first couple of goes, as I usually do. >> >> So I'll just ask a couple of questions instead: >> >> Is there any way of preventing this kind of major breakage in the future? >> I don't think many people expect that upgrading one package will FUBAR >> the packaging system. >> >> Is there any chance of Wine becoming functional on amd64 in the forseeable >> future? > > # apt-get install ia32-wine Except that it's really: apt-get update apt-get upgrade apt-get update apt-get install ia32-wine Rather than: aptitude update aptitude install wine At least that's what I assume. I can't get past the second apt-get update without something breaking. > Reading package lists... Done > Building dependency tree > Reading state information... Done > The following extra packages will be installed: > ia32-libwine ia32-libwine-alsa ia32-libwine-cms ia32-libwine-gl > ia32-libwine-gphoto2 ia32-libwine-ldap ia32-libwine-print ia32-libwine-sane > ia32-wine-bin ia32-wine-utils > Suggested packages: > wine-doc binfmt-support ttf-mscorefonts-installer winbind avscan klamav > clamav > Recommended packages: > ttf-liberation > The following NEW packages will be installed: > ia32-libwine ia32-libwine-alsa ia32-libwine-cms ia32-libwine-gl > ia32-libwine-gphoto2 ia32-libwine-ldap ia32-libwine-print ia32-libwine-sane > ia32-wine ia32-wine-bin ia32-wine-utils > 0 upgraded, 11 newly installed, 0 to remove and 187 not upgraded. > Need to get 11.0MB of archives. > After this operation, 51.4MB of additional disk space will be used. > Do you want to continue [Y/n]? y > ... > > % winemine > > Have fun. Works both with sid and experimental wine. Provided you have > a lib32ncurses5 and lib32readline5 with the lib32 transition completed > that is. Bug the respective maintainers for that one. > >> Did anyone who isn't on crack get to see 'ia32-apt-get.preinst' and >> 'ia32-apt-get.postinst' before they were perpetrated upon an unsuspecting >> populace? Reading them in the process of trying to unfuck my system made me >> feel more than slightly ill. > > Since my package was sponsored I would assume at least one other > person looked over it. You are the first to mention illness. I can't > change what it does. But do you have suggestion to improve how it does > things in preinst/postinst/postrm? > To be honest, I say we take off and nuke the entire site from orbit. You can't just hack together a quick shell script for something that major. It's far too brittle. > Latest source is on svn.debian.org pkg-ia32-libs: > http://svn.debian.org/wsvn/pkg-ia32-libs/trunk/ia32-libs-tools/#_trunk_ia32-libs-tools_ > This entire direction is a dead end. Having these extra package databases and dpkg-diversions only works in a very narrow set of circumstances. It
The multiarch conundrum
Hi, I've just been trying to dig through some of the multitude of past discussions on the planning and implementation of multiarch in Debian (and Ubuntu). The short version of this for TLDR folks is that nobody seems to have coherently written down all the problems in a way that they can be addressed, so far as I can see. The longer version: It seems clear that there is no consensus yet on what exactly needs to be done, let alone how to get there; discussions seem to go round in circles, then eventually peter out to begin anew at a later date. If there is anywhere where real progress is being made, then I can't find it, but I think a large part of the problem is down to poor communication. My proposal for one way to try moving forward with this is as follows: Currently the collective discussions about multiarch have taken place in numerous threads on numerous mailing lists, which makes it hard to find any specific information. I believe that a wiki or similar centralised collaborative process is a good way of tying this together. If there is already some location where this is being actively worked on in such a fashion then I apologise, and much of this mail will be rather pointless - in which case that location really ought to be easier to find :P. Start with https://wiki.ubuntu.com/MultiarchSpec. The reason for choosing the Ubuntu wiki page is that there is already some real content there, in an organised form. If http://wiki.debian.org/multiarch is a better place then fine, but either way it would be good to have the same content, or at least not disagreement between the two. Ideally one would act as a pointer to the other - this is assuming that everyone wants Ubuntu and Debian heading in the same direction here, which seems to be the consensus. Within the spec page there are sections describing the design and some notes on the implementation. One major point which is missing is that each section needs some description of the objections to it - which surely exist, otherwise we'd already have multiarch by now, wouldn't we? Currently it looks more like 'well that's a nice plan; why isn't it happening?' Further, there has already been some work done which has been rejected or ignored - this needs to be presented and the reasons documented; it doesn't really help anyone to forget about past attempts. So far I've found the patches by Goswin on the Alioth multiarch project page[0]; there must be more scattered about the place? Finally, there needs to be some organisation of the many existing threads on the topic. A good first start would be to search through the list archives and add links to related discussions on the wiki page - we need to be able to go to one place and get an overview of the issues, proposals, and objections, without having to hunt that information down. This way we can hopefully avoid going over the same issues and making the same mistakes and arguments repeatedly. If there is no objection, I would like to do the following: * Merge multiarch information from the Debian wiki into the Ubuntu wiki. (I'm not too sure about tho organisation of the Ubuntu wiki; would the spec page be inappropriate for this? Where would be better?) * Add pointers to any existing patches, and links to any discussions about them if I can find them in the ML archives. * Start a list of related discussions and dig out archive links from whatever mailing lists are appropriate. So far I can think of debian-devel, debian-dpkg, debian-glibc (?), debian-amd64. Are there others? I don't know about any Ubuntu lists but I imagine it's been discussed to death there too. * Start monitoring those lists for multiarch-related discussions and update the wiki appropriately. * Possibly stub out some empty 'objections' sub-headings in the spec design, in the naive hope that somebody reading will see them and think 'no objections? Lies! I have objections!', and actually fill them in. Does anybody have opinions on whether any of this would be even remotely useful? -Nye [0] https://alioth.debian.org/projects/multiarch/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Moving /tmp to tmpfs makes it useful
On 26 May 2012 19:20, Carlos Alberto Lopez Perez wrote: > *Important*: use "df -h /tmp" NOT "du -hs /tmp", since the flash player > deletes the file entry from /tmp as soon as it gets the inode allocated. > I believe this a measure to "prevent" piracy (people ripping the video > from /tmp) I think you're too willing to assume bad faith. If I were writing similar software, that's exactly what I'd do: create a temporary file, which will be in /tmp except in the marginal corner-case that the user has set another $TMPDIR, then unlink it and continue using it. This means that you don't need to worry about deleting it afterwards, even if your application crashes or is killed, and has no obvious downsides. -- 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/cahb+spdrxfpd1e6dovwfg8pttbezduqgchskcwb0l+oc3p3...@mail.gmail.com
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
On 8 June 2012 12:04, Bjørn Mork wrote: > Any file system will run out of space given the broken applications > mentioned in this thread. It is not productive to redefine applications as 'broken' simply because they do not conform to an arbitrary set of requirements that you have just added, especially when you haven't even given any indication of what you consider 'non-broken' behaviour. The use of /tmp (or TMPDIR if set) to store temporary files is its *purpose*. If suddenly that use is considered 'broken' behaviour, then who is to say what other standard behaviour will be declared 'broken' tomorrow? I could declare that from now on I'm going to use FAT32 for my /tmp, and all applications which expect a case-sensitive filesystem are broken, but it would be similarly absurd. -- 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/CAHb+SPBD-t34i_z6o=mg0sk9j2qurga1kzvjtodes73w5u4...@mail.gmail.com
Re: Lets (eventually) find a good solution for /tmp
On 10 June 2012 19:31, Thomas Goirand wrote: > On 06/11/2012 12:06 AM, Don Armstrong wrote: >> swap file on / [...] is >> really the direction that we should be going > NO ! > > Does this need to be explained? :/ > Not quite sure what you're objecting to. If you are against the use of swap files rather than swap partitions then yes, it does need to be explained, because as far as I am aware a swap file is the better choice in virtually all situations (and is what I've been using exclusively since Linux 2.6 removed the downsides). If in fact there are any remaining downsides I'm unaware of, it would be good to see them documented. -- 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/CAHb+SPC=jww-faxu_uc9xsotiy3p69wudznfwemrog0y983...@mail.gmail.com
Re: Lets (eventually) find a good solution for /tmp
On 11 June 2012 15:21, Simon McVittie wrote: > On 11/06/12 15:01, Aneurin Price wrote: >> as far as I am aware a swap file is the better >> choice in virtually all situations > > Assuming > <http://wiki.debian.org/Hibernation/Hibernate_Without_Swap_Partition> is > still current: > > If you want to use hibernation (suspend-to-disk), you need roughly[0] as > much partion-based swap as you have RAM, unless you're using the setup > on that wiki page (using uswsusp, which is not installed by default; > have allocated a contiguous swap file; have made sure to use a > filesystem which will not move that file; done some dangerous[1] manual > configuration for uswsusp). > Thanks. that's useful information. It's not relevant to me personally which is why I was unaware of it, but certainly that would count as a good reason not to use a file by default (at least until that limitation is overcome). -- 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/CAHb+SPDNnZkSHcuOm6w2de=NuBt_jrSUFEisRaR+_0MMcQ=w...@mail.gmail.com
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
On 11 June 2012 22:59, Bjørn Mork wrote: > Aneurin Price writes: > >> (Note that we are talking about applications which fail gracefully >> when confronted with ENOSPC, > > Are we? What's the problem then? > Honestly, I have no idea. It's clear that some people think storing 'large' temporary files in /tmp is 'broken', for unspecified values of 'large', but I don't understand why and nobody seems interesting in explaining the reasoning when they can just declare it axiomatic. My best reasoning is that the application shouldn't fail at all in this case, but should find some way of working despite running out of storage space. Obviously that would be great, but I can't really imagine all that many cases where it's likely to be possible (or really *any* cases where it's likely to be worth going to the extra trouble). It does annoy me quite a lot that people are calling applications broken without even *attempting* to define what they might deign to call *not* broken. >> but which are likely to do so more often when the size of /tmp is >> restricted.) > > Yes, but the tmpfs correlation is weak. There is absolutely no > guarantee that there will be more space available on the root file > system than a default tmpfs. In anything resembling a 'normal' system (ie. the kind where one might be using the defaults) I would say that the tmpfs correlation is so strong as to be very nearly 1:1, and this seems like the crux of the matter; that is after all the reason that these applications are failing when /tmp is switched to tmpfs. It is almost a complete certainty that on any given system there will be more space available on the root filesystem than a default tmpfs, unless that system has requirements so specific that the choice of defaults is moot. Sure there's no *guarantee*, but it is exceptionally likely; if you do seriously believe otherwise (ie. you're not just pointing out that it *might* not be the case), I'd say that's sufficiently extraordinary a claim as to require extraordinary evidence. -- 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/cahb+spbfe0zcryetorxbnu0mfdfoncmme_qcykhznyjj73v...@mail.gmail.com
Re: /tmp as tmpfs and consequence for imaging software
On 15 November 2011 08:17, Neil Williams wrote: > On Tue, 15 Nov 2011 07:41:54 +0100 > Andrew Shadura wrote: > >> Hello, >> >> On Mon, 14 Nov 2011 00:14:18 +0100 >> Josselin Mouette wrote: >> >> > > No it does not work like you said. We know the matrix structure, not >> > > the kernel. We map and unmap manually. Doing as you said is >> > > inneficient and trash a lot cache and so on. >> >> > This is getting insane. Please learn how to use madvise and >> > posix_fadvise and let the kernel deal with paging. The kernel knows >> > everything about the underlying hardware; the application does not. >> >> And what about the software being cross-platform? What about other >> systems which don't have such system calls? > > Ever heard of #ifdef #else #endif ? > > If similar calls exist, use them conditionally. Where they do not > exist, you need to decide if that system can be supported and accept > the limitations of doing so. Where the calls DO exist it is inexcusable > NOT to use the support available. > > Do not cripple all platforms with the sins of the weakest. I think this discussion needs a sanity check. Please remember, the topic of conversation is whether an application can reasonably make the assumption that the system defined tmp directory is a suitable place to store temporary data. You appear to be saying "Of course not; every application should include a small compatibility layer to call the appropriate syscalls or other relevant interface for every possible platform to indicate to the kernel exactly what it wants to do with its data. Yes, that doesn't answer the question of where temporary data should be stored in the first place, but I don't care about that as long as nobody has the audacity to suggest that maybe /tmp might be a reasonable place for transient temporary data." Can you see why this might be treated with incredulity? Maybe it's worth going back to the topic at hand rather ranting about something irrelevant. -- 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/cahb+spbpom8oz5hvespjqtkaglr-+hbh-uk46-ovu79bwd3...@mail.gmail.com
Re: so long, and thanks for all the fish
On 4 April 2013 18:28, wrote: > There is apparently no mode of argument, or "style of > communications", which is capable of penetrating the Debian > bureaucracy. It is impervious, even to patches which have been > previously solicited. Silly me, for taking that seriously. > You need to remember that the Debian project is essentially masturbation. Nobody likes to be told they're doing it wrong.
