[00:18] <malkauns_> why do flash video's on 12.04 sometimes play fast?
[00:31] <wgrant> stgraber: Well done.[6~
[00:32] <stgraber> thanks wgrant :)
[00:33] <wgrant> Aw
[00:33] <highvoltage> http://jonathancarter.org/2012/05/16/launchpad-net-bug-1-000-000/ ;)
[00:33] <wgrant> sinzui closed it.
[00:33] <ajmitch> how mean
[00:34] <highvoltage> yes!
[00:34] <highvoltage> (unless he fixed it)
[00:34] <ajmitch> but good timing at getting that bug, stgraber ;)
[00:39] <TheMuso> Awesome work, that woudl have had to be very tight timing to get that number.
[00:46] <lifeless> they used a conspiracy
[00:46] <lifeless> myself, I'd have used an API script.
[00:49] <highvoltage> lifeless: yeah that would be clever. why didn't we think of that!? ;)
[00:49] <stgraber> ;)
[03:34] <micahg> ScottK: any reason why a boost-mpi-source upload never happened with the boost1.49 upload?
[03:36] <micahg> ScottK: ah, I see, it's all in boost-defaults now...meh, this needs more digging
[03:38] <micahg> ScottK: no, I think my question is still valid :)
[04:15] <ScottK> micahg: Because I couldn't get it to build at the time and then I forgot about it.
[04:16] <micahg> ScottK: ok, I was just looking at the boost transition list, libboost-all-dev is uninstallable due to a missing boost parallel package
[04:21] <superm1> siretart: curious, what's the fix you ended up coming up with for the FTBFS you talked about in http://goo.gl/KDK9o ?  mythtv is hitting the same thing in precise after it's most recent ffmpeg resync: http://goo.gl/v7dc6
[05:06] <kInOzAwA> lol ScottK  from webchat?
[05:30] <siretart> superm1: well, that irclog explains it at about 20:00
[05:32] <siretart> superm1: btw, is there someone investing some efford to avoid the internal ffmpeg copy in the mythtv package?
[05:59] <ScottK> micahg: I'll try to pick up work on it, but it'll be a few days.
[06:00] <micahg> ScottK: sure, no rush :), plenty to do
[06:23] <pitti> Good morning
[06:24] <pitti> bdmurray: more precisely, line numbers will appear in frames which would otherwise just be <module>, i. e. not in any function or method
[06:24] <pitti> bdmurray: this mostly happens for ImportErrors, but can also happen in global initialization code
[06:28] <pitti> slangasek: I heard some rumours that we'll switch from ConsoleKit to logind; wouldn't that solve foundations-q-xdg-runtime-dir along?
[06:44] <TheMuso> I heard same rumours.
[07:21] <xnox> stgraber: congrats on bug 1kk!
[07:49] <xnox> bug 1000000
[08:43] <pitti> ogasawara, apw: FYI, binNEWed -2.5
[08:44] <apw> pitti, thanks
[08:45] <pitti> apw: remember the other day when we talked about the kernel team uploading copying kernels themselves?
[08:45] <pitti> err, s/uploading copying/copyring proposed/
[08:46] <pitti> typing is hard! I should replace my ubuflu with a tea perhaps
[08:46] <pitti> apw: there is an opportunity to try now, if you want to
[08:52] <apw> pitti, didn't we decide you would have to handle the component missmatches anyhow?  though of course i will try it to check it works :)
[08:53] <pitti> apw: yes, archive admins still need to accept the uploads from unapproved and also fix the overrides
[08:53] <pitti> but it's one step
[08:53]  * apw will have a look now
[08:53] <pitti> it doesn't help much still, but I'm mostly curious whether you need ~u-archive power to run that script or upload privs for that package
[08:54] <pitti> apw: i. e. I mostly want to figure out this ^, it won't help much to reduce teh SRU workload
[08:54] <pitti> phone, bbl
[08:56] <pitti> apw: so, if you could do bzr checkout lp:ubuntu-archive-tools ?
[08:59] <apw> pitti, np doing now
[08:59] <apw> pitti, ok have that
[09:00] <pitti> apw: can you please run copy-proposed-kernel.py natty linux-ti-omap4
[09:01] <apw> pitti, i read the output as positive in general
[09:02] <apw> pitti, chinstrap:~apw/typescript for the transcript
[09:03] <apw> pitti, appears to be at the unapproved queue indicated in the output
[09:03] <pitti> ah, so that worked? nice
[09:04] <apw> pitti, i think so from what i can see, indeed
[09:04] <pitti> apw: yes, archive admins still need to accept the uploads from unapproved and also fix the overrides
[09:04] <pitti> WTF?
[09:04] <pitti> that's not at all what I typed
[09:04] <pitti> apw: there it is: https://launchpad.net/ubuntu/natty/+queue?queue_state=1
[09:05] <pitti> ah, clicking middle button to paste the URL somehow seems to have triggered some cursor up event or so
[09:05] <apw> nice :/
[09:05] <apw> pitti, so does it make sense to get our people to do this phase of the push
[09:05] <dupondje> could somebody look @ https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/937522 please? Would like to get it closed :)
[09:05] <pitti> apw: can you also try the -updates/-security moving?
[09:05] <pitti> apw: sru-release -s natty linux-ti-omap4
[09:06] <apw> pitti, now ?
[09:06] <pitti> apw: as I said, I was mostly curious about permissions here; if you want, you or even the bot are welcome to run that
[09:06] <pitti> apw: er, sorry
[09:06] <pitti> apw: sru-release -s oneiric linux-ti-omap4
[09:06] <pitti> bug 985999 is ready for releasing
[09:07] <pitti> apw: it would just fail with natty, as there is no -proposed ti-omap anyway
[09:07] <apw> pitti, looks to have worked: https://launchpad.net/ubuntu/oneiric/+queue?queue_state=1
[09:08] <pitti> great
[09:08] <pitti> so the copying actually uses upload privs, not ~ubuntu-archive; that's only required for actually accepting the copies
[09:08] <pitti> apw: thanks for trying
[09:08] <apw> pitti, no problem.  i quite like at least us copying into -proposed as that indicated someone with upload privs asked for it
[09:10] <pitti> apw: so in theory you could do bug 990103 as well
[09:10] <pitti> apw: actually, that one is more interesting; perhaps that's something the bot could do for us
[09:11] <pitti> apw: it takes some time for me to figure out the set of packages (including lbm, the various metas for the different releases, etc.) and whether or not to copy to security as well
[09:11] <pitti> and determining the set of packages seems automatable
[09:11] <pitti> (if that is an actual word, anyway)
[09:12] <apw> pitti, yeah for sure the bot knows which are in the package set for that release, as it asks us to make lbm etc when appropriate
[09:12] <pitti> apw: so in this case it's just "linux", but with API breaks it's more
[09:12] <apw> pitti, so you'd like it to simply copy them when its ready and let the approved queue be your 'queue'
[09:12] <pitti> ports-meta for lucid, linux-ubuntu-modules for hardy, etc.
[09:12] <pitti> apw: yes, that'd be nice
[09:13] <pitti> apw: the copying is fast, and by itself does not change anything
[09:13] <pitti> they can easily be rejected, re-done, etc.
[09:13] <apw> pitti, i can get brad to think about that no problem.  that sounds appropriate then i think
[09:14] <pitti> apw: in some time we'll have a launchpadlib API to do queue accepting, and will hopefully have bug 993120 fixed
[09:14] <pitti> then the bot could do the whole process for copying into -proposed and fixing the overrides
[09:14] <pitti> -> less monkey button pressing from our side, and faster turnaround
[09:15] <pitti> -> more time for beer!
[09:15] <apw> pitti, yeah, and presumably more AAs would be comfortable doing kernels as it would be easier
[09:15] <pitti> yes, cocoplum access is a severe limitation
[09:16] <apw> pitti, ok will get brad to think about the right way to get that doing the right thing.  it should at least generate the commands and put them in the bug :)
[09:16] <pitti> apw: it could just use them; the gut of copy-proposed-kernel is essentially one copyPackage() launchpadlib call
[09:16] <pitti> apw: the rest is setup which the bot presumably already has anyway
[09:17] <pitti> ubuntu.getArchive(name='primary').copyPackage(from_archive=kernel_ppa,
[09:17] <pitti>         include_binaries=True, source_name=pkg, to_series=release,
[09:17] <pitti>         to_pocket='proposed', version=version)
[09:17] <apw> pitti, yeah i am sure it could do it assuming its joined to LP with creds of someone with upload rights, but we may want to make it happen with deliberate action from an uploader so we have accountability
[09:18] <pitti> apw: wouldn't you still have accountability from the person who flipped the "copy to proposed" task to confirmed? that's in the activity log
[09:18]  * apw wonders who will get named on the email when the copy completes now
[09:19] <pitti> and even if that gets done accidentally, we can just reject the queue copies
[09:19] <pitti> the accepts for -updates/-security should always be manual I think
[09:19] <pitti> but -proposed cries for automating
[09:20] <apw> pitti, yeah we'd know who for sure, but likely anyone in the world can flick that so we might not want it to happen without thought, but thats a separate issue
[09:20] <pitti> ah, true that
[09:20] <apw> pitti, yeah for sure ... anything we can do to make it easier.  i would cirtainy agree that whatever happens it should be telling the poor sucker who does it exactly what characters to type so you don't have to work out the package sets etc.  thats just makework
[09:21] <pitti> apw: right, http://people.canonical.com/~ubuntu-archive/pending-sru.html (at the bottom) gives us copy-paste commands for -proposed
[09:21] <apw> pitti, and the logical first step is that, getting it to dump the two commands you showed me stylee with the appropriate packages into the bug and getting the stable people to run them
[09:21] <pitti> but not for -updates/-security, it's not clever enough for that; but the kernel bug bot is
[09:22] <pitti> apw: I agree
[09:22] <apw> yeah, and we definatly can do that, and most likely can make one of those pages with all the pending ones in one place too
[09:22] <apw> brad loves scripting web pages :)
[09:23] <pitti> dear LP; please stop timing out when I try to set that task to "fix released" the tenth time
[09:24] <apw> pitti, the most annoying feature
[09:27] <pitti> apw: oh, look! -changes@ now has your name for the kernels, not mine
[09:28] <pitti> so far it seemed that I was responsible for doing all these uploads :)
[09:32] <pitti> apw: presumably I can remove the linux-backports-modules-3.2.0 source and binaries?
[09:32] <pitti> apw: (from quantal)
[09:35] <xnox> is there a consensus on replacing Vcs-* fields with XS-Debian-Vcs-* ?
[09:38] <apw> pitti, yes lbm makes no sense for the old version
[09:48] <cjwatson> apw,pitti: you could even check whether it's an uploader who set things to Confirmed and then use archive.copyPackage(sponsored=that_uploader)
[09:48] <cjwatson> which is a reasonable on-behalf-of kind of interface
[09:48] <apw> yeah that makes sense
[09:49] <cjwatson> (or whatever way you want to trigger that)
[09:54] <pitti> cjwatson: for sorting out http://people.canonical.com/~ubuntu-archive/component-mismatches.svg and generally reducing the packages in main I'd need to make some adjustments to the DVD seed
[09:54] <pitti> cjwatson: but I wondered, given that we'll drop the DVD/USB image anyway and just have one image, should I perhaps remove it altogether?
[09:54] <seb128> what is setting the /tmp permissions? bug #999526 is an user who has tmp permissions which are wrongly set (and they keep being wrongly set at every reboot), not sure where to direct him
[09:54] <pitti> cjwatson: AFAIK we are only using the "usb" seed now, and "dvd" is dead already
[09:58] <cjwatson> pitti: I think so, but just hard-dropping it would probably cause stuff to fall out of main that shouldn't
[09:58] <cjwatson> (at a guess; haven't looked much)
[09:59] <pitti> cjwatson: we'll see in c-m and could then re-seed some bits that seem important
[10:00] <pitti> I don't think it makes much sense to file some 20 MIRs for texlive packages which we don't really actively maintain anyway
[10:02] <pitti> cjwatson: http://paste.ubuntu.com/990399/ -> DVD removal (keeping the "usb" one for now)
[10:03] <cjwatson> The texlive-* stuff isn't in build-dep chains anyway?
[10:03] <pitti> some binaries are
[10:03] <pitti> but e. g. not texlive-fonts-extra
[10:03] <pitti> texlive-lang-{german,cyrillic} have one reverse build dep each
[10:03] <cjwatson> looks fine as far as it goes, but I think it would be worth an A/B germinate run first
[10:03] <pitti> and texlive-extra has a few
[10:06] <pitti> cjwatson: okay, I'll do that
[11:58] <mdeslaur> @pilot in
[12:08] <hrw> hmm. I do not like dpkg-cross more and more
[12:09] <jdstrand> SpamapS: I'll take a look
[12:20] <HFSPLUS> Katy perry baby, i know your hurting right now after that prick russel brand broke your heart, now all i ask is to give me a chance to prove that i love you. Honey i am nothing like russel brand, and i love you and i will never break your heart katy
[12:25] <HFSPLUS> !ops
[12:25] <HFSPLUS> Katy perry baby, i know your hurting right now after that prick russel brand broke your heart, now all i ask is to give me a chance to prove that i love you. Honey i am nothing like russel brand, and i love you and i will never break your heart katy
[13:10] <melodie> hi,
[13:13] <melodie> I have seen at this page : http://www.ubuntu.com/community/report-problem that it is not so obvious for me to find where I should put a wish. I use "mozilla-sunbird" currently and I would like to ask for it to be packaged and made available in Ubuntu. https://ftp.mozilla.org/pub/mozilla.org/calendar/sunbird/releases/1.0b1/ this version, and the locales for it too. It is not available at Debian either for now, only the plugin for opensync is t
[13:13] <melodie> here :
[13:13] <melodie> http://packages.debian.org/sid/opensync-plugin-sunbird
[13:13] <melodie> my question is where should I go to bring it as a wish ?
[13:15] <geser> melodie: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages, 2nd paragraph of "Requesting a new package for Ubuntu"
[13:16] <cjwatson> you can file wishlist bugs on just Ubuntu (without a package) with the needs-packaging tag to ask for new packages; however, note that sunbird used to be in Ubuntu and was removed
[13:16] <cjwatson> bug 571134
[13:16] <cjwatson> and https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/FirefoxNewSupportModel
[13:17] <melodie> geser, cjwatson I look at your links
[13:17] <cjwatson> so making it actually work with new thunderbird versions would be a fairly important piece, and ensuring that it has good maintenance going forward - Mozilla extensions aren't something that can be just dropped into the archive and largely forgotten about, AIUI
[13:17] <cjwatson> (note I don't actually know anything about sunbird directly)
[13:18] <pitti> cjwatson: got back to this now; so I have germinate output for "with-dvd" and "without-dvd", but diffing the dirs is rather useless as I get tons of random diffs like http://paste.ubuntu.com/990622/
[13:18] <melodie> cjwatson, I don't use thunderbird. I use sunbird as standalone application. I cannot switch to Ubuntu without my usual tools. :/
[13:19] <pitti> cjwatson: do you have a tool to better compare those, or should I post-process the files to only show the package names?
[13:19] <melodie> I have had my appointments and todo notes in it for years
[13:19] <elky> melodie, as i understand it, sunbird can be run standalone as a portable app
[13:19] <elky> http://portableapps.com/apps/office/sunbird_portable
[13:20] <melodie> elky, a portable app ? and why not have the standalone version in the distribution ? In another distribution I use it works fine
[13:20] <cjwatson> melodie: I don't know anything more about this, so no good explaining to me why you need it :)
[13:20] <cjwatson> pitti: I usually run it through cut -d' ' -f1 or similar
[13:20] <melodie> cjwatson, ok thank you
[13:21] <pitti> cjwatson: ok
[13:21] <cjwatson> pitti: actually, tail -n +3 | head -n -2 | cut -d' ' -f1
[13:21] <cjwatson> one of these days I should do a more machine-readable output mode
[13:22] <melodie> elky, portable sunbird is for windows. I don't use windows. brrr !
[13:22] <melodie> :)
[13:23] <elky> melodie, i believe they work fine on wine. they did the last time I played with them
[13:23] <elky> where they = portable apps
[13:25] <pitti> cjwatson: http://people.canonical.com/~pitti/tmp/diff/ are the nonempty diffs between the germinate outputs with (-) and without (+) the dvd seeds
[13:25] <pitti> cjwatson: I guess all.sources.diff is the interesting one?
[13:25] <melodie> elky, I might have found a better turn around. at debian-mentors someone just told me in Debian (sid and other versions) there is "iceowl" which does that. http://packages.debian.org/sid/iceowl so I will go to package request as for it...
[13:26] <melodie> elky, wine is something I prefer not to use. I have tried a few times and it was disapointing with "one time it works, the other it claims a dll is missing.. " and such.
[13:27] <elky> melodie, well when you make the wishlist bug like cjwatson suggested, you can mention that :)
[13:27] <elky> mention iceowl, I mean.
[13:27] <cjwatson> pitti: yep, or http://people.canonical.com/~pitti/tmp/diff/all+extra.diff if you want a list by binaries
[13:27] <cjwatson> elky,melodie: iceowl is explicitly sync-blacklisted in Ubuntu - we prefer the Mozilla names
[13:27] <melodie> elky, I'll have to try it to see if I can use it with my db
[13:27] <pitti> cjwatson: so we'll certainly want to seed the nvidia/fglrx drivers and a few -doc packages, but can happily drop some of the libs
[13:28] <cjwatson> pitti: IIRC bittornado is used in the DC to operate torrent.ubuntu.com
[13:28] <melodie> cjwatson, then what wish could I post ?
[13:28] <pitti> and keep diveintopython and virt-manager/virtinst, too
[13:29] <pitti> and xchat-gnome
[13:29] <pitti> cjwatson: so I'll add those to the "supported" seeds in exchange
[13:29] <elky> cjwatson, i wasn't suggesting it be syncd, rather as a datapoint
[13:29] <pitti> cjwatson: or supported-desktop-extra for xchat-gnome and similar desktopish packages
[13:30] <cjwatson> pitti: right, I'd just come to similar conclusions on the list to keep
[13:30] <elky> but it's past pumpkin o clock so I'm going to head off. good luck melodie
[13:30] <cjwatson> melodie: the wishlist should be for sunbird (though I'd be surprised if there isn't one filed already; I'm not sure), not for a straight copy of iceowl
[13:31] <pitti> cjwatson: I'd add stuff like autoconf-doc to the platform seed "supported-development-common" instead to desktop; sounds ok?
[13:31] <pitti> it already has autoconf, autotools-dev and the like
[13:31] <cjwatson> pitti: yep
[13:31] <cjwatson> it's only needed that way when the documentation is in a separate source package
[13:32] <melodie> cjwatson, I am looking at the pages you pointed me to, then I will seek the page for wish lists at Ubuntu and ask for a standalone sunbird package. I still have to find where they put the locales
[13:33] <geser> would it be possible/allowed that the nvidia source package also build library packages like the Debian package?
[13:42] <pitti> cjwatson: all, committed; thanks for your help!
[13:42] <pitti> s/,//
[13:50] <geser> pitti, cjwatson: do you know if it's allowed that a source package from restricted builds lib-packages in multiverse/restricted (not sure which component would be the correct one for them)?
[13:50] <pitti> geser: I dont see why not
[13:52] <geser> I wasn't sure if there are any restrictions for source packages in restricted what they can build
[13:52] <cjwatson> geser: yes, that's permitted; the rule is basically that source packages must be at least as far out as their binaries
[13:53] <cjwatson> where  main < restricted < multiverse  and  main < universe < multiverse
[13:53] <cjwatson> well, though a source package in main building binaries in restricted/multiverse would be kind of odd, although I think we might have had a reason for that once ...
[13:53] <cjwatson> some kind of dependency closure problem I guess
[13:58] <geser> tseliot: Hi, would it be possible to build the same set of library packages from nvidia-graphics-drivers like in Debian? There are some package in multiverse depwaiting on them, so we either build those library packages too or remove those source packages as it's impossible to build them in Ubuntu
[13:58] <tseliot> geser: what library packages?
[14:01] <geser> tseliot: libcuda1, libopencl1 (provided by nvidia-libopencl1 in Debian).
[14:02] <cjwatson> There's also a new nvidia-support source package showing up for auto-sync, which I've been holding off on ...
[14:02] <geser> nvidia-cuda-toolkit depwaits on libcuda1 and viennacl depwaits on libopencl1, not sure if there are more needed, didn't check in detail yet
[14:03] <tseliot> geser: I think there were a few problems with the packaging of nvidia-cuda-toolkit anyway. I'll have another look at it though
[14:03] <tseliot> cjwatson: I'm wondering what nvidia-support is and whether we really need it
[14:03] <cjwatson> Dunno, I haven't looked.  The autosyncer just shows me everything, I try not to care too deeply about it all :)
[14:04] <cjwatson> But it's often better to sync up to avoid later dependency trouble
[14:04] <cjwatson> (in general)
[14:04] <HFSPLUS> Katy perry baby, i know your hurting right now after that prick russel brand broke your heart, now all i ask is to give me a chance to prove that i love you. Honey i am nothing like russel brand, and i love you and i will never break your heart katy
[14:04] <pitti> !ops
[14:04] <xnox> cjwatson: are you triggering sync from debian manually, or are they done continiously?
[14:05] <pitti> well, emergency is a bit much
[14:05] <pitti> thanks cjwatson
[14:05] <mlankhorst> thank you
[14:05] <pitti> but this guy keeps saying that
[14:05] <pitti> argh, now he's privmsging
[14:05] <mlankhorst> get a network admin and get him glined from freenode..
[14:05] <cjwatson> probably a case for freenode staff, yeah
[14:05] <mlankhorst> for harassment
[14:06] <pitti> nice, http://people.canonical.com/~ubuntu-archive/component-mismatches.svg looks a little less crazy now
[14:06] <cjwatson> xnox: I plan to get at least some of it fully automated this cycle by way of a bot account; for now it's a script I run daily
[14:06] <xnox> cjwatson: ok. thanks.
[14:07] <tseliot> cjwatson: I'll have a look at that package too then, just in case..
[14:07] <cjwatson> last cycle we got it from a script that ran daily and routinely broke part-way through and had to be re-run from the start, to a script that runs straight through and has rather more sensible feedback
[14:07] <cjwatson> so still improvement :)
[14:09] <melodie> cjwatson, I will have to give up, mozilla has announced it as being the last release : https://www.mozilla.org/projects/calendar/sunbird . I feel so sorry, such a good program ! :-(
[14:10] <cjwatson> melodie: well, at least xul-ext-lightning is in the archive (although I know you said you don't use thunderbird)
[14:11] <cjwatson> but perhaps better than nothing
[14:11] <melodie> /o\
[14:11] <xnox> melodie: i use xul-ext-lightning.... seems ok.
[14:11] <melodie> xnox, with thunderbird : right ?
[14:12] <melodie> it's not standalone ?
[14:12] <xnox> yes.
[14:12] <xnox> but you do not need any email accounts in thunderbird, if you just want calendars.
[14:12] <melodie> I think it is very sad. I love standalone apps particularly when it leaves choice and freedom to use any other component.
[14:13] <melodie> xnox, no you just need  the megabytes just for calendar, which sunbird does so well.
[14:13] <melodie> I find it incredible that no one has been interested to continue it
[14:14] <cjwatson> broder,Laney: http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/revision/430
[14:20] <mneptok> melodie: https://en.wikipedia.org/wiki/Mozilla_sunbird
[14:21] <mneptok> melodie: especially this pertinent bit: "Development of Sunbird was ended with release 1.0 beta 1 to focus on development of Mozilla Lightning."
[14:21] <mneptok> melodie: IOW, Sunbird is abandonware. at least by Mozilla.
[14:21] <melodie> it is still free software
[14:22] <melodie> and a good one
[14:22] <melodie> mneptok, do you know a program having for name "animal" ?
[14:22] <tseliot> cjwatson: as I thought, we don't need nvidia-support, however there's a file I can definitely reuse for a work item I was assigned. Thanks!
[14:23] <mneptok> melodie: no. and really, that's a bit outside the scope of development of Ubuntu. probably better asked in another channel.
[14:23] <melodie> mneptok, I don't talk of "animal" by hazard : it is a very very old console game, which is in Ubuntu. In fact I think Ubuntu might be the only place where I can still find it.
[14:23] <melodie> really fun !
[14:24] <melodie> I am filling a bug to ask a package for the last sunbird available. :)
[14:25] <mneptok> melodie: this channel is for development issues only. please stay on topic so that busy devs can maximize mental bandwidth.
[14:25] <melodie> mneptok, ok, thanks for your answers.
[14:25]  * mneptok bows
[14:29] <herton> @pilot in
[14:36] <slangasek> pitti: well, foundations-q-xdg-runtime-dir was to discuss if we had requirements that differ from those in the Fedora implementation; and switching to logind is certainly just a rumor, jodh will be investigating whether logind is a suitable solution as-is or how many changes it needs to integrate with upstart
[14:39] <pitti> slangasek: ah, thanks
[14:43] <Sweetshark> Who takes care about the mysql C++ connectors? Will we have a 1.0.6 or higher api of that in quantal (for whatever that means?)
[14:50] <micahg> Sweetshark: we already have 1.1.0
[14:51] <micahg> (and have since oneiric)
[14:51] <Sweetshark> micahg: interesting, my configure script says different (on precise still)
[14:52] <micahg> Sweetshark: and since you have the only reverse dependency, that's you who cares about it I guess :)
[14:53] <melodie> bye
[14:54] <micahg> looks properly reflected in the soname as well
[15:21] <pitti> micahg: you TIL gimp; do you plan to merge it, or want to leave that to desktop team?
[15:36] <SpamapS> jdstrand: also I think apparmor FTBFS on quantal right now
[15:40] <jdstrand> yeah, need to look into that
[15:40] <arges> congratulations! https://bugs.launchpad.net/launchpad/+bug/100000 : )
[15:42] <mvo> cjwatson: are you ok with me uploading https://code.launchpad.net/~glatzor/software-properties/python3/+merge/105755 ? its a 2to3 based approach to port software-properties but it would unblock a aptdaemon py3 build
[15:42] <micahg> pitti: orly?  yeah, I can do it, was waiting for gegl which I thought was in NEW
[15:43] <micahg> pitti: unless the desktop team wants to do it or it needs to be done before the weekend that is
[15:43] <cjwatson> mvo: For now, yes, though I'd rather revert that and avoid relying on 2to3 long-term
[15:43] <cjwatson> (once we're unblocked)
[15:44] <mvo> cjwatson: agreed
[15:56] <seb128> cjwatson, hey, with the one image discussion is there any plan to drop alternates,udeb over time?
[15:57] <cjwatson> seb128: alternates yes, udebs not currently; netboot installation is still valuable to many of our users
[15:58] <seb128> cjwatson, ok, does netboot use gtk (I get I will not get away with that but looking if,how I could drop multibuilds from gtk)
[15:58] <cjwatson> seb128: we do currently build a netboot GTK image, though there is also a text one
[15:58] <cjwatson> seb128: most of that's synced from Debian on the GTK side AFAIK though
[15:58] <seb128> cjwatson, I'm trying to get gtk build time down, the multiple build is costing a lot on buildd time and local build time for those who want to work on gtk
[15:59] <cjwatson> Does it actually require multiple passes?  Different configure flags / dependencies / something?
[15:59] <seb128> cjwatson, different configure flags yes
[16:00] <cjwatson> Perhaps it might be more economic to figure out how to do it in a single pass
[16:00] <seb128> cjwatson, in fact the udeb build is mostly disabling x11 options, I wonder if that's still needed
[16:00] <seb128> 			--disable-xcomposite \
[16:00] <seb128> 			--disable-xdamage \
[16:00] <seb128> 			--disable-xfixes \
[16:00] <seb128> 			--disable-xrandr
[16:00] <cjwatson> It might just be a matter of building udebs for xcomposite/xdamage/xfixes/xrandr
[16:00] <seb128> ok, thanks
[16:00] <cjwatson> Which ought to be fairly trivial given current X packaging
[16:01] <seb128> I will try to check with mbiebl what he thinks
[16:01] <cjwatson> Not sure whether introspection would require anything extra
[16:01] <seb128> that's the other one yes, though those don't impact the lib so I'm not sure the flag is needed
[16:01] <seb128> like those are extra files but we could just not install them in the udeb
[16:01] <cjwatson> Yeah, I wondered about that
[16:02] <seb128> cjwatson, thanks, I will check on the Debian side if we could get udeb for the x libs and merge shared and udeb in one build for gtk
[16:02] <cjwatson> libxfixes already has a udeb; the others don't
[16:08] <mdeslaur> @pilot out
[16:13] <seb128> is anyone here having an opinion on static builds? Debian dropped the GTK static build recently (which is great, I was just thinking about going forward and do that for Ubuntu) and I was wondering if that's the sort of change that should be discussed on -devel or announced
[16:14] <seb128> or if we can consider it's fine and we will get bug reports anyway if some users still rely on it
[16:33] <infinity> seb128: In theory, static builds are a convenience to our users who want to link their own binaries statically for some reason or other.  In practice, most people who do static linking of complex stacks seem to build their own in-house anyway, so they have tighter control over versions.
[16:34] <infinity> seb128: Still, seems odd that Debian's dropped it...
[16:34] <seb128> infinity, ok, in practice also the cost in build time,dev time - benefit is not good also
[16:34] <seb128> infinity, why?
[16:35] <infinity> seb128: Well, cause we've traditionally provided static copies of most libraries, that's all.  Is there sometihng that makes GTK special in this regard?
[16:35] <seb128> infinity, the new generation of maintainers are less conservative about keeping stuff that almost nobody use and that cost us work it seems, which is good ;-)
[16:36] <seb128> infinity, out of the gtk maintainers who have enough to spend time waiting for gtk to build and fixing the static build because upstream doesn't care about it, not really
[16:36] <seb128> infinity, it just seems it costs over what it brings back
[16:37] <infinity> seb128: I have no real opinion either way.  As you say, you'll get bug reports if users care.
[16:37] <infinity> seb128: But, if it turns out they do, I'd push to turn it back in in Debian, rather than carrying the burden entirely in Ubuntu.
[16:38] <seb128> infinity, right
[16:38] <seb128> well I take that as a "let's try it in q"
[16:38] <infinity> seb128: *nod*
[16:38] <seb128> I guess Debian will hit unhappy users before us in any case if that happens
[16:38] <infinity> seb128: "Upstream doesn't care about the static build" sounds like a pretty valid argument.
[16:39] <seb128> I'm not even sure you can correctly use static built gtk nowadays with the dynamic image loaders and im methods
[16:39] <seb128> infinity, thanks, you convinced me it was ok to drop it ;-)
[16:40] <infinity> seb128: Hey, don't pin this on me. ;)
[16:40] <seb128> infinity, too late for that ;-)
[16:40] <seb128> the changelog already has your name
[16:40] <infinity> ...
[16:41] <seb128> ;-)
[16:41] <infinity> I knew there was a reason I didn't trust the French.
[16:45] <lamont> infinity: isn't canadian like french?
[16:46] <infinity> lamont: Only when I'm eating poutine.
[16:46] <lamont> heh
[16:52] <Sweetshark> lamont, infinity: were do you guys live by the way? I need a rather exact location ....
[16:52]  * infinity raises his eyebrow.
[16:53] <Sweetshark> I have this work item to get more fs-space on the libreoffice-ppa build, and having an exact location makes threading you with ICBM-strikes more believable!
[16:54] <infinity> Sweetshark: For the build itself, or the PPA?
[16:54] <Sweetshark> the filesystem on which we are building
[16:54] <infinity> Sweetshark: If the build is eating the disk on the virtual builders, there's not a lot we can do about that, short of upgrading all the virtual builders physically.
[16:56] <infinity> Sweet mother of... 28G to build libreoffice?
[16:56] <infinity> That's insane.
[16:56] <Sweetshark> infinity: right -- I know its quite a bit of work, but thats what we need. Who do I escalate that too?
[16:57] <Sweetshark> infinity: well, we could get rid of l10n or the stacktraces or running the tests to make it a bit smaller.
[16:57] <infinity> Sweetshark: RT ticket.  It means upgrading all the enablement/ppa shared hadrware, which could be a bit of an uphill battle.  If the only people uploading to that PPA are Canonical employees (and if you don't upload frequently), the path of least resistance might be making it devirt, so it builds on the distro buildds.
[16:57] <Sweetshark> infinity: our you get me the ressources to make libreoffice understand gettext directly ...
[16:59] <cjwatson> Devirt does mean there's contention between you and release-team and the like around release times, though.
[16:59] <infinity> ^
[16:59] <cjwatson> Or even if there's a lot of other distro upload activity.
[17:00] <cjwatson> Is 28G really particularly difficult in terms of FS space?  I'd have thought it'd be more a matter of raising a threshold somewhere.
[17:00] <Sweetshark> infinity: that was another option I was considering: building in proposed and copying over to the ppa -- that doesnt work on backports though.
[17:00] <infinity> If he goes devirt, but x86-only, it probably ends up better as far as resource contention.
[17:01] <infinity> cjwatson: Most of the PPA buildds have 72G disks, laid out in a pretty specific way.  AFAIR, it's a question of physical upgrades to make this problem go away.
[17:01] <cjwatson> Grumble.  My phone has very nearly that much free.
[17:02] <infinity> (Plus, that 28G is sbuild's estimate, which can be low, if it peaks earlier and then deletes things)
[17:02] <infinity> Sweetshark: Building in proposed and copying to a PPA?  That sounds rather backward. :P
[17:03] <Sweetshark> infinity: well ...
[17:03] <infinity> Sweetshark: But if these PPA uploads are actually meant to land in a release (ie: they're not just "test builds"), then I'd be sold on the devirt option.  All arches on, ddebs on, and have AAs copy things around.
[17:04] <infinity> (Not saying IS shouldn't solve the PPA disk space issues some day too, but if you're the only user this really impacts, I'm guessing it'll be pretty low on their priority list, and we should look for clever interim solutions)
[17:05] <Sweetshark> infinity: by now the ppa should have only rather stable stuff. If im doing real "test builds" I do them on personal ppa *cough* now ...
[17:06] <infinity> Sweetshark: So, the PPA in question is staging for distro uploads?  Much like the kernel-sru PPA?
[17:07] <Sweetshark> infinity: yes, pretty much.
[17:07] <infinity> Sweetshark: Okay.  And who has upload rights to it?
[17:08] <Sweetshark> infinity: ricotz, doko, me and penalvch. penalvch will never upload there.
[17:13] <hyperair> oh hey we have 7-digit bug numbers now
[17:33] <xnox> infinity: Sweetshark: didn't like desktop track wanted to run daily libreoffice builds & run the full test-suite, just for the sake or running the full testsuite?
[17:33]  * xnox is pretty sure he heard that during roundup @ UDS.
[17:34] <xnox> if it actually is daily libreoffice builds hitting the ppa, across all stable releases (like chromium ppa's) then potentially it will be a bigger FS resource problem.
[17:38] <infinity> xnox: Ick.
[17:39] <infinity> xnox: I recall something about libreoffice CI, I'm hoping it's not an all stable releases, nor daily.
[17:41]  * infinity doesn't like his odds of backporting x32 support in glibc, when he realises that H.J. Lu is still committing to master, as recently as 5 minutes ago...
[17:41] <infinity> Guess I can backburner that work item until a liiiiitle bit later in the cycle.
[17:41] <infinity> cjwatson: ^-- FYI
[18:55] <Sweetshark> jasoncwarner_: just a headsup, thursday is a bank holiday in germany, so if there is something to 1:1 about drop me a line
[19:09]  * micahg doesn't like the idea of an all arch devirt PPA for libreoffice, most of these builds probably won't be pushed into a release anyways (latest stable libreoffice for older stable Ubuntu releases)
[19:10] <rbasak> Do we know if either d-i or mkfs runs an ssd trim at partition format time? I'll file a wishlist bug unless someone tells me it does.
[19:10] <rbasak> NCommander: ^^
[19:20] <infinity> micahg: Yeah, the backport ones should probably be in a virtualised PPA, I agree.  Solving that problem for them is a bit more effort, though.
[19:39] <pitti> micahg: gegl should be current now, I binNEWed pretty much everything today
[19:41] <micahg> pitti: thanks, will take a look over the weekend, still catching up on a bit of a backlog
[19:43] <micahg> pitti: can you promote the new gegl binaries to main (library and dev package, libgegl-0.2-0, libgegl-dev)?
[19:45]  * micahg guesses libgegl-doc should be in main as well
[20:08] <cjwatson> infinity: heh, makes sense, it was hardly the most urgent on your list anyway
[20:09] <cjwatson> rbasak: d-i doesn't, but I would be inclined to say that that shouldn't be d-i's problem.  mkfs or kernel.
[20:10] <rbasak> ok, thanks. does d-i call mkfs or mkfs.$type? It would be nice to have it in mkfs rather than each backend
[20:12] <cjwatson> IIRC mkfs.$type, and in some cases parted (but that needs to go away anyway)
[20:13] <rbasak> so if I file a bug against each mkfs.$type, I'll get told that it should be in mkfs, right? :)
[20:14] <bryceh> bdmurray, looking at bugs filed against python-support...  it looks like that package recompiles all installed .py scripts to .pyc as part of its installation.  So if you happen to have a buggy python script installed, it causes a package failure bug to be filed against python-support
[20:14] <bryceh> bdmurray, I think those bugs should be filed against their respective packages instead
[20:14] <bryceh> and possibly python-support itself should not fail in such a case, but just flag the error.
[20:15] <rbasak> next question: what tells debootstrap that it should ?configure base-passwd before base-files? I've got it going the wrong way around at the moment so it breaks. The issue is with my hacked mirror where I've regenerated the Packages and Release files, so I know I'm doing something wrong there, but don't see how my Packages is different.
[20:16] <slangasek> bryceh: we can reduce these bug reports to "please stop using python-support, you should be using dh_python2 instead"
[20:17] <bryceh> slangasek, I notice it got demoted to universe in precise; I take it that it's deprecated?
[20:17] <slangasek> bryceh: with prejudice
[20:17] <bryceh> yep http://wiki.debian.org/Python/TransitionToDHPython2
[20:17] <slangasek> in fact, it should've been in universe before precise
[20:18] <slangasek> huh, apparently it wasn't - well, it is now and good riddance ;)
[20:19] <bryceh> slangasek, ok thanks.  Yeah the package builds in oneiric with python-support, but not precise
[20:32] <cjwatson> rbasak: mkfs - dunno
[20:33] <cjwatson> rbasak: er, not somewhere where I can easily look right now, but I thought the order there was hardcoded
[20:34] <rbasak> cjwatson: if you've got time: http://paste.ubuntu.com/991309/
[20:35] <cjwatson> rbasak: give me an hour or two, dinner here
[20:36] <rbasak> cjwatson: thanks! For later: I've got a partial debmirror (quantal main/restricted only) and that works fine. I'm taking a copy and manipulating some unrelated packages (currently just adding a kernel) and using apt-ftparchive to regenerate/sign Packages and Release, and that breaks
[20:38] <seb128> does anyone knows if build-arch: rules target (source using cdbs) sould work fine in the current version?
[20:45] <cjwatson> seb128: pretty sure build-arch is fine, but you should have a build target depending on build-arch anyway ...
[20:46] <seb128> cjwatson, I'm trying to figure why the current Debian gtk version fails to build on precise
[20:46] <seb128> the rules has
[20:46] <seb128>  build-arch: $(call dh_subst_files,$(DEB_ARCH_PACKAGES))
[20:46] <seb128> dh_subst_files = $(patsubst %.in,%,$(wildcard $(addprefix debian/, $(addsuffix *.in, $(1)))))
[20:46] <seb128> debian/%: debian/%.in
[20:46] <seb128> ...
[20:46] <seb128> basically
[20:47] <seb128> but seems like that rules is never called when doing a build
[20:48] <seb128> there is no build target depending directly on build-arch in the rules (but maybe cdbs or something does it in Debian)
[20:53] <cjwatson> seb128: maybe you should add one; I don't know cdbs.  does it build on quantal?
[20:54] <cjwatson> rbasak: ah, I knew a very faint bell was ringing somewhere; Debian #643659
[20:56] <cjwatson> rbasak: so I think debootstrap should be changed to make that ordering more explicit, although it's interesting that this is I think the first clear report I've heard of this happening with debootstrap
[20:57] <cjwatson> rbasak: I would certainly suggest sorting your Packages file if that works around it
[20:57] <cjwatson> mterry: yes, I'm happy to finish my update-manager pye port - thanks
[20:58] <cjwatson> *py3
[21:01] <mterry> cjwatson, hi!  OK
[21:02] <cjwatson> need to fight with relative imports some more, test with new aptdaemon, figure out what's up with option parsing translation
[21:02] <cjwatson> feels fairly close
[21:03] <JontheEchidna> I've got a weird problem involving apt, gcc 4.7 and c++11, and I'm not sure if it's an apt or gcc bug.
[21:03] <JontheEchidna> Basically, if you compile this: http://paste.ubuntu.com/991354/ with gcc 4.7/c++11 (http://paste.ubuntu.com/991357/) the example prints "error".
[21:03] <JontheEchidna> If you compile with gcc 4.7 without the c++11 cflag, or compile the example with gcc 4.6 with the c++11 flag, everything's fine.
[21:04] <JontheEchidna> The relevant class is in apt-pkg/contrib/error.* relative to apt source's root directory
[21:07] <JontheEchidna> basically, a freshly constructed instance of apt's GlobalError class shouldn't have its member PendingMessage boolean flag set, but for whatever reason it is.
[21:07] <JontheEchidna> but only when an application using the class is compiled with c++11 support in gcc 4.7
[21:33] <herton> @pilot out
[22:10] <YokoZar> hey launchpad passed a million bugs today
[22:11] <Resistance> old news, that happened early this morning (over 18 hours ago)
[22:11] <slangasek> yesterday ;)
[22:11] <Resistance> yep
[22:11] <Resistance> about 00:00 locally at my location thoug h:P
[22:11] <slangasek> YokoZar: hey, had a question for you on ia32-libs dependencies
[22:11] <micahg> well, technically UTC today :)
[22:11] <YokoZar> slangasek: ghosts of the past?
[22:12] <slangasek> YokoZar: yeah ;) ia32-libs-mulitiarch depends on gstreamer0.10-fluendo-mp3 - why was this needed?
[22:12] <YokoZar> slangasek: it was needed for wine codecs long ago (at least that's why I put them in ia32-libs) but wine enumerates its dependencies explicitly now
[22:13] <slangasek> ok.  it causes problems when you try to install a different 64-bit package that implements gstreamer0.10-fluendo-mp3, because apt isn't quite smart enough with the replaces
[22:13] <slangasek> or maybe I mean the conflicts
[22:13] <YokoZar> hmm, interesting
[22:13] <slangasek> so I think we should drop that particular dep
[22:14] <YokoZar> Sure.  Who's using ia32-libs-multiarch these days though?
[22:14] <YokoZar> (wine isn't, proudly)
[22:14] <YokoZar> I mean, you could probably drop more deps
[22:14] <YokoZar> or even the whole package :D
[22:15] <tumbleweed> YokoZar: seems only boinc is (and probably a bunch of 3rd-party stuff)
[22:16] <slangasek> YokoZar: well, it's already there in precise, and it's in precise that it's causing problems
[22:16] <slangasek> so this is looking like an SRU
[22:16] <YokoZar> slangasek: ahh ok, yes, SRU removing that dep for sure then
[22:16] <slangasek> I have already wondered about removing it from quantal
[22:16] <slangasek> but I'm in no hurry
[22:16] <micahg> tumbleweed: a few other things as well :)
[22:17] <tumbleweed> micahg: hrm, reverse-depends is lying to me, then
[22:17] <micahg> tumbleweed: nope, you forgot about the transitional ia32-libs package :)
[22:17] <tumbleweed> aah
[22:18] <infinity> micahg: Yeah, but only boinc seems to use that...
[22:18] <micahg> ah, run time deps, yes
[22:19] <infinity> micahg: Things that build-dep on ia32-libs are just plain broken anyway...
[22:19] <micahg> right
[22:19] <infinity> Someone should have noticed that and fixed/removed them.
[22:19] <YokoZar> slangasek: At the moment you can make an amd64 package depend on 32-bit libraries by just depping on ia32-libs-multiarch, if we remove it then we may hypothetically force a package to make an i386-only subpackage for their 64/32 app just to get the dependencies right
[22:19]  * micahg senses another thing to clean up in quantal
[22:19] <YokoZar> slangasek: (mostly thinking of 3rd party junk here)
[22:19] <micahg> infinity: we ran out of time :)
[22:19] <infinity> micahg: Happens, yeah.
[22:20] <slangasek> YokoZar: well, yes, but we *want* to force those packages to be split that way :)
[22:20] <slangasek> we don't want redundant 32-bit binaries masquerading as amd64 packages
[22:20] <YokoZar> slangasek: even like a 3rd party binary-only package?
[22:21] <micahg> well, if Debian makes their release goal of killing ia32-libs, then upstreams will kinda have to :)
[22:21] <slangasek> YokoZar: yes
[22:21] <YokoZar> slangasek: actually, that's a nice way of forcing them to setup apt repos :D
[22:21] <slangasek> cf. discussions at UDS re "You should be distributing archives, not .debs" :)
[22:21] <slangasek> ;)
[22:21] <YokoZar> All right, I'm all for it then
[22:29] <YokoZar> slangasek: relatedly, any possible movement on ".apt" format or similar, ie how to distribute these archives?
[22:30] <infinity> YokoZar: Like, a signed tarball of an archive, insyead of just hosting the files?
[22:30] <infinity> instead, too..
[22:31] <slangasek> infinity: rather, a standard file for distributing metadata about an apt source to allow it to be auto-configured
[22:31] <YokoZar> infinity: no I mean a standard way of adding a repo by parsing a file (and maybe installing a package)
[22:31] <slangasek> YokoZar: and yes, that was one of the two areas of improvement discussed in the UDS session that we think we'll want to tackle this cycle
[22:31] <infinity> Ahh.
[22:32] <YokoZar> slangasek: it's nice to see my 3rd-party-apt spec get revived from its 6 year old grave when I first proposed it at UDS-Boston :D
[22:32] <slangasek> heh
[22:40] <mbiebl> slangasek: hi
[22:40] <slangasek> mbiebl: heya
[22:40] <mbiebl> slangasek: is there a way to tell mountall to timeout waiting for a device to show up?
[22:40] <slangasek> hmm, not really
[22:41] <slangasek> what would you want it to do after timing out?
[22:41] <mbiebl> my use case is this: I have several amazon  EC2 instances
[22:41] <mbiebl> where /var/log is on a attache EBS volume
[22:41] <mbiebl> if that EBS volume is not attached, the boot hangs at that point
[22:42] <mbiebl> nobootwait doesn't quite work as I want, as then it can happen that services are started before /var/log is mounted
[22:42] <slangasek> right
[22:42] <mbiebl> (when the EBS volume is attached)
[22:42] <slangasek> so you want the boot to continue with or without /var/log if it's not found?
[22:43] <mbiebl> this is on lucid, btw
[22:43] <mbiebl> I want it to continue
[22:43] <bdmurray> that sounds kind of like bug 610869
[22:44] <slangasek> I would do a job like this: http://paste.ubuntu.com/991493/
[22:44] <slangasek> mbiebl: ^^
[22:44] <slangasek> but of course that sets a global timeout which may or may not be what you want
[22:44] <mbiebl> right, I basically just want to say that /var/log is not critical
[22:45] <mbiebl> but still have the correct ordering in the usual case
[22:45] <slangasek> yeah
[22:45] <slangasek> seems like the bug bdmurray points to is related
[22:46] <slangasek> but we really would need to be able to set a per-filesystem timeout option in /etc/fstab to do what you want
[22:47] <mbiebl> that would be ideal, yes
[22:47] <slangasek> or maybe nobootwait semantics should just be changed to include a centrally-configured timeout
[22:47] <slangasek> then you could use nobootwait and get the right behavior
[22:47] <slangasek> hmm
[22:48] <slangasek> mbiebl: I think this warrants a bug report against mountall; could you file one?
[22:48] <slangasek> (unlikely that any fixes will get backported to lucid though, sorry - but we could do something for precise)
[22:48] <mbiebl> sure, np
[22:48] <mbiebl> just waiting for the point release before upgrading
[22:48] <slangasek> ah, then perhaps we should fix it for the point release ;)
[22:49] <mbiebl> will file a bug tomorrow
[22:49] <mbiebl> thanks for you input
[22:49] <slangasek> ok, cheers
[22:49] <slangasek> er, hmm
[22:49] <slangasek> mountall does have a --dev-wait-time option ;)
[22:50] <slangasek> mbiebl: hah, looks like this may already be implemented with a 'timeout' fstab option
[22:51] <slangasek> I think mountall needs a better manpage :P
[22:51] <mbiebl> yeah
[22:51] <mbiebl> I've grepped the man pages for keywords like that
[22:52] <slangasek> or rather this needs to be added to the fstab manpage, which does document all the /other/ mountall extensions
[22:53] <mbiebl> slangasek: I've checked mount, mountall and fstab :-)
[22:53] <mbiebl> the mountall man page is rather *short* :-)
[22:53] <slangasek> so there's a default timeout of 30 seconds; overridable with an argument to mountall; and a 'timeout' fstab option
[22:54] <mbiebl> hm, if the default is 30 seconds, then I wonder why the boot blocks indefinitely
[22:54] <slangasek> the timeout *only* applies to filesystems marked 'timeout'
[22:54] <mbiebl> ah
[22:55] <mbiebl> will try that tomorrow
[22:56] <slangasek> ok - let me know how it turns out :)
[23:26] <mbiebl> slangasek: ok, this seems to require a newer mountall. The lucid version doesn't understand the timeout option yet
[23:26] <slangasek> ah, interesting
[23:26] <slangasek> I didn't realize there were new features added post-lucid
[23:26] <slangasek> but ok