[01:20] <quidnunc> Is it possible to have a package as of now that has build-depends on package versions not available in the repositories?
[01:24] <crimsun> meaning "may I upload a source package that build-depends on packages that no longer exist?"  No.
[01:28] <quidnunc> crimsun: No, meaning does it make sense that a package that was uploaded build-depends on a package version that was not?
[01:28] <crimsun> quidnunc: if the source package in question hasn't been rebuilt in quite some time, yes, it's quite possible.
[01:29] <quidnunc> crimsun: THanks
[06:18] <jono> can anyone tell me where lernid is in the build queue?
[06:21] <superm1> jono, it appears to be in the NEW queue: https://edge.launchpad.net/ubuntu/lucid/+queue
[06:21] <superm1> an archive admin needs to release it
[06:22] <jono> superm1, any archive admins around?
[06:22] <jono> ideally we need it available for the kick off of some python sessions tomorrow
[06:27] <pwnguin> by my math its like 5am in the uk
[06:28] <lifeless> pwnguin: fortunately they archive admins aren't UK people
[06:28] <lifeless> pwnguin: only some are.
[06:31] <persia> I didn't think any of today's archive admins were (for various values of "Today")
[06:31] <pwnguin> ive no clue who runs the archive
[06:32] <lifeless> persia: james_w
[06:32] <persia> lifeless: Is it not Thursday?
[06:32] <persia> Well, I suppose it's also Wednesday
[06:33] <persia> But it's *definitely* not Monday anymore.
[06:33] <lifeless> persia: I wasn't aware that they lost access on non rota days
[06:33] <persia> Personally, I think it's Wednesday in TX and Thursday in NSW, if one is hunting an archive admin right now.
[06:34] <persia> lifeless: Well, no, but they tend to make themselves more available on rota days.
[06:36] <jono> there must be a list archive admins somewhere
[06:37] <cody-somerville> ~ubuntu-archive
[06:37] <jussi01> https://edge.launchpad.net/~ubuntu-archive
[06:37] <jussi01> heh
[06:37] <jono> StevenK, around?
[06:38]  * StevenK prods jono
[06:38] <jono> StevenK, :)
[06:38] <jono> Lernid is in NEW - any chance you could move it along?
[06:38] <jono> we need it for opp dev week starting tomorrow
[06:38] <StevenK> Maybe. How much beer is on offer?
[06:38] <jono> StevenK, two pints
[06:39]  * persia prefers https://wiki.ubuntu.com/ArchiveAdministration because it helps ping the right folk on the right days
[06:40] <jono> thanks persia
[06:40] <StevenK> jono: Accepted.
[06:40] <persia> jono: Well, you've already spent the quart, so it doesn't matter so much to you, but maybe for the next person who needs one :)
[06:40] <jono> thanks StevenK!
[06:40] <jono> :)
[06:40] <jono> sounds awesome, good to know, persia :)
[06:41] <lucent> Hi, can someone walk me through the process of submitting a patch that fixes a bug?  I know which lines of code I want to change in the package "lirc" but I don't know how to generate a suitable patch against the package
[06:41] <persia> lucent: Do you use bzr?
[06:41] <lucent> persia: I do not
[06:42] <persia> https://wiki.ubuntu.com/Bugs/HowToFix
[06:42] <lucent> okay I will read
[06:42] <persia> There used to be simpler instructions there :/
[06:43] <persia> https://wiki.ubuntu.com/Bugs/HowToFix?action=recall&rev=16
[06:43] <lucent> persia: I get yelled at when I submit plain diff -uprN patches
[06:44] <lucent> it is kind of bewildering to me but I will try to learn more about this
[06:44] <persia> Who yelled at you?
[06:44] <persia> Which bug?
[06:44] <persia> That should *never* happen.
[06:44] <persia> The process for submitting patches is as follows:
[06:45] <persia> A) If you use bzr, branch the package, change it, commit, push a branch, request a merge
[06:45] <persia> B) If you don't use bzr, attach a perfectly normal patch to the bug, make sure the "this is a patch" checkbox is checked.
[06:45] <persia> That's it.
[06:45] <lucent> oh, before I heard this I thought I was doing something wrong
[06:45] <persia> Anything else is just extra messiness because someone thinks you're trying to learn how to be an Ubuntu Developer.
[06:45] <persia> No, you weren't doing anything wrong.
[06:46] <persia> We specifically have the Ubuntu Reviewers team (which more people should join! ) which reviews the patches.
[06:46] <lucent> thank you :)
[06:46] <persia> Not all of them get uploaded right away.  Sometimes they get pushed upstream first, etc.
[06:46] <persia> Submitting a debdiff with all the correct tweaks to integrate to packaging, etc. makes it *harder* to get it upstream.
[06:47] <lucent> unrelated second question, there's no cdrtools in Ubuntu... is cdrtools a "not done here" for Ubuntu Karmic?
[06:47] <persia> (although it's what we expect from developers who can't upload a given package)
[06:47]  * persia has no idea
[06:48] <lucent> I don't want to step on toes if I branch the existing PPA and fine tune it to work with Karmic
[06:48] <lucent> a little Google research had vague references to Mark Shuttleworth rumored to be saying no... it was all kind of unconfirmed
[06:49] <persia> Nothing you do in a PPA affects Ubuntu.
[06:50] <tumbleweed> lucent: however, debian and ubuntu both use cdrkit, not cdrtools
[06:51] <lucent> I am aware of that, in fact am helping to test code for the libburn and libcdio projects (yet a third iteration of burning software)
[06:51] <lucent> the devels for libburn and libcdio refer to cdrecord as the baseline
[06:52] <tumbleweed> lucent: aah. yes, go wild in your ppa (never heard of libcdio, looks into it...)
[06:52] <lucent> the GNU project supports libcdio "in name only" (I'm sure you will be familiar with that concept?)
[06:53] <lucent> I think there's maybe 5 developers between the two projects libcdio and libburn
[06:53] <lucent> it is GPL license and actively developed
[06:54] <lucent> I guess the rumor was that cdrkit development is stalled
[08:06] <pitti> Good morning
[08:07] <rainct_> Hey
[08:08] <pitti> slangasek: invalid-mta> well, FSVO "reasonable"; this was discussed to death with the LSB folks, and they are not willing to remove the sendmail requirement; so to finally fix pulling in postfix with every LSB package you isntall, this seems like a lesser evil to me; and it won't change a thing if you already have an MTA installed
[08:08] <pitti> there simply is no frigging way we can sensibly install a real MTA without any questions
[08:08] <lamont> pitti: +1
[08:08] <pitti> nor is it sensible to install MTAs on nowaday's desktop boxes in teh first place
[08:09] <pitti> ... (says one who has running a local postfix, but with nicely configured SSL certificates for relaying to his server)
[08:10] <pitti> and ssmtp is even less useful; you don't have an MTA to relay to by default
[08:28] <dholbach> good morning
[08:29] <sladen> ccheney: can you go through the dups for bug #450569 and friends and demerge all the ones you just demerged.  The Pre-Depends: loop is _not_ related to some random process running in the background.  It should be possible to separate them again based on package number.  1:3.1.1-5ubuntu1  is where the Pre-Depends loop is (current), and 1:3.0.1 is where the process hang was (six months ago)
[08:40] <csurbhi> good morning #kernel
[08:41] <dholbach> csurbhi: this is  #ubuntu-devel ! :-)
[08:41] <dholbach> hehe
[08:47] <Noisi> hi there! i try to cross compile with arm-linux-gcc a sqlclient to arm720t and i need lib mysqlclient. Must i compile it from soucre with arm-linux-gcc?  it would give me great pleasure for some tip.
[10:10] <slangasek> pitti: we could have a package which provides m-t-a, and interfaces with UbuntuOne to send all your root mail there or something :P
[10:11] <dholbach> hey slangasek! :)
[10:11]  * dholbach hugs slangasek!
[10:11] <slangasek> dholbach: heyo. :)
[10:13] <persia> Would it be terribly difficult to have an m-t-a that just delivered to /var/spool and had a config widget that let you set up the equivalent of postfix's sasl _passed and sender_relay maps to real smarthosts?
[10:14] <persia> (and by default forward *all* mail to the first configured user on the machine)
[10:14] <slangasek> persia: AIUI one of the concerns with that is that on a modern desktop, the user will never know they even have local mail in that case
[10:16] <persia> slangasek: We could ship the mail clients with a default spool configuration?
[10:16] <slangasek> maybe
[10:16] <persia> Personally, I find lots of stuff I try to do ends up complaining that I don't have mail set up.
[10:16] <slangasek> or we could turn every mail into a notification
[10:16] <slangasek> :-)
[10:16] <persia> As a result, I inevitably set up postfix without much confidence.
[10:16] <persia> But I know I don't need that.
[10:44] <slangasek> mvo: does https://wiki.ubuntu.com/LucidLynx/TechnicalOverview#Issue%20when%20upgrading%20from%20Lucid%20Alpha%202 seem like something you would want update-manager to do for us, and would you have time to implement it for Lucid?
[10:51] <slangasek> TheMuso: do you know if anyone is planning to test UbuntuStudio so it can be included in alpha 3?
[10:56] <sivang> Hi all
[10:56] <sivang> why is libapache2-mod-wsgi in universe and not in main ?
[11:00] <persia> sivang: Nothing in main either Depends or Build-Depends on it.
[11:01] <sivang> persia: this is going to be the next gen web gateway technology
[11:01] <sivang> persia: and is already used int he python web world
[11:01] <sivang> persia: ubuntu being a python in mind distro, should get it into main
[11:01] <sivang> persia: I can take care of it's maintainerhip if that's required
[11:03] <persia> sivang: It's not about maintenance.  It's about dependencies.  If you think it's essential, get something to depend on it.
[11:03] <sivang> persia: what if I wanna use it under an ubuntu machine? do I need to switch to fedora where it is sort of officially supported?
[11:03] <sivang> persia: what's the dependency argument has to do with an emerging web technology
[11:03] <sivang> :)
[11:04] <persia> sivang: How isn't it supported in Ubuntu?  It's present, isn't it?
[11:08] <mvo> slangasek: yes, I can do that
[11:08] <sivang> persia: in univeser
[11:08] <sivang> mvo !!
[11:08] <sivang> mvo: How have you been you family man?
[11:08] <sivang> :)
[11:09] <Daviey> persia: will libapache2-mod-wsgi get 5 years LTS support in universe?
[11:09] <sivang> Daviey++++++
[11:09] <mvo> hey sivang - good, good (les sleep than before)
[11:09] <persia> Daviey: Depends on people being interested, but there's nothing blocking it.
[11:09] <sivang> mvo: a child ?
[11:10] <sivang> persia: people interested == python web community worldwide
[11:10] <sivang> persia: Is that enough? ;)
[11:10] <persia> sivang: Quite likely, as long as they care to keep the version we ship in Lucid in shape, and some people watch the status in Ubuntu.
[11:11] <persia> sivang: But that's completely irrelevant to the universe/main distinction (which we're overdue abolishing anyway).
[11:12] <sivang> persia: whom do I need to talk to or do I need to create a wiki page for the promotion ?
[11:12] <sivang> pitti: ^^^
[11:12] <persia> sivang: What's your goal?  Just having it work and getting regular security updates?
[11:12] <sivang> MainInclusionReport was the last time I checked
[11:12] <sivang> persia: security
[11:12] <sivang> persia: my only concern
[11:13] <persia> sivang: OK.  and are you willing to track the security status of it in Lucid and make sure any required patches are tested and made available in a timely manner?
[11:13] <sivang> persia: "I do." :)
[11:13] <sivang> but I need to get my membership fixed again
[11:13] <Daviey> sivang: Whilt it shouldn't make any difference, there is certainly a difference in love packages in main recieve compared to universe.  If you want to try and get it promoted, I would add it as a ubuntu-server agenda item for the next meeting.  If you get the support of -server, then i think it's more likely.
[11:14] <sivang> Hmmm... red tape.....
[11:14] <sivang> ;
[11:14] <persia> sivang: Great.  So file "security" bugs whenever one is needed with the tested patches and ask folk in #ubuntu-hardened if they aren't getting uploaded in a timely manner.
[11:14] <sivang> ;)
[11:14] <persia> Then you have a supported solution.
[11:14] <persia> Only bother with the MIR if you need it as a dependency or build-dependency of something on the shipping images.
[11:15] <sivang> persia: not yet, that will come, but not yet.
[11:15] <slangasek> Daviey: sure, because any time anyone loves a package in universe they push to have it in main, which isn't exactly scalable. :)
[11:15] <sivang> slangasek: true
[11:15] <sivang> but if I use ot now
[11:15] <sivang> now
[11:15] <sivang> who gurantees it won't screw my server?
[11:15] <persia> Daviey: There really isn't any difference based on component.  I've found *lots* of packages in main that were completely disfunctional and ignored (and tossed them out of main).  The differnence is just that more people tend to care about more of the packages in main.
[11:15] <persia> sivang: You?
[11:16] <persia> sivang: and anyone you recruit to help you (Daviey seems like a good candidate)
[11:16] <Daviey> persia: i entirely agree, but the server team seems to think diffently - based on posts such as http://ubuntumathiaz.wordpress.com/2009/11/30/rfp-packages-to-promote-to-main-and-demote-to-universe-for-lucid-lynx-lts/
[11:17] <persia> There's no warranty for the vast majority of software in Ubuntu (even in main), and most of it has a waiver for fitness for any particular purpose.  That it works is because people care about it and because we trust each other, rather than because of any contractual arrangement.
[11:17] <persia> Daviey: Some members of the server team are sadly benighted about the meaning of "support".  Just do it :)
[11:17] <Daviey> heh
[11:18] <sivang> persia: I hope no one of my customers ever hear that when I seel them Ubuntu Servers:)
[11:18] <sivang> sell
[11:18] <sivang> "sell" => offer them to use ubuntu server on their VDS
[11:19] <sivang> when they hear "no warranty" they run out and cry "RHEL, RHEL!!!"
[11:19] <sivang> ;)
[11:19] <sivang> anyway, to go back to a more fruitful discussion and less trolling :)
[11:19] <sivang> so, just file bugs and make sure someone cares aboiut it?
[11:19] <sivang> or cares "enough" about it
[11:19] <sivang> ?
[11:20] <persia> sivang: Go read the licenses of RHEL software.  It's the same software under the same licenses and comes with the same specific disclaimer of usefulness.
[11:21] <persia> That doesn't mean it isn't useful, just that nobody guarantees it.  If you, completely separately, decide to enter into a contract with a customer to provide support or warranty for some return, that's between you and your customer.
[11:21] <sivang> persia: sure, I try to explain that to them, however, you say that even if a [pacakge in main that's not gurantee for security, I don't think this is the right statement
[11:21] <sivang> one of the first tasks
[11:21] <sladen> charge them $10,000 and provide the guarantee yourself
[11:21] <sivang> I got from pitti as a mentor, was to do security review for warty
[11:22] <sivang> for everything we importedfrom debian
[11:22] <persia> OK.  Packages in main only get security support if someone either identifies the problem in a clear way to Ubuntu or if a CVE is published.
[11:22] <sivang> persia: that's what I want, is it so hard to achive ?
[11:22] <persia> That's nice, but it's certainly not anything like a guarantee.
[11:22] <sivang> persia: it is *something*
[11:22] <sivang> better than *nothing* inuniverse
[11:22] <sivang> ahh I need a real latpo
[11:22] <sivang> aptop
[11:23] <sivang> right, I rest my case:)
[11:23] <sivang> this kbd is the worst ever
[11:23] <persia> sivang: Like I said before, just do it, and provide the guarantee.  You're effectively asking someone else to do something so that you can get paid.  I'm unsure why they would want to do that.
[11:23] <sivang> no, I'm asking this so I could promote Ubuntu as a wsgi hosting platform
[11:23] <sivang> irrelavant to my pay
[11:23] <sivang> seriously
[11:23] <sivang> I've done so much for ubuntu without seeing a dime, so I don't think this request is out of place.
[11:24] <sivang> I am promoting ubuntu regardless of my commercial itnerest in it.
[11:24] <sivang> oh, and I've contributed with will :-)
[11:24] <persia> sivang: I think you miss my essential point.  If you want it to be supported, support it.  That's all it takes.
[11:25] <persia> If you want someone else to support it, then find some way to incentivise them.
[11:25] <sivang> so I don't feel like ubuntu is owning me something, to make straight
[11:25] <sivang> persia: okay, noted.
[11:25] <sivang> persia: I'll start with it and then find someone else to care for it.
[11:25] <sladen> sivang: your contribution _to_ Ubuntu would be _the support_ of $package
[11:25] <sivang> sladen: right, what's the comitte these days to get main upload right for a specific package?
[11:25] <persia> sivang: I'd love to see the package well maintained.  I think you're perfectly capable of doing it.  I know that the universe/main distinction is meaningless and that we've been working to abolish it for the last two years.
[11:26] <sladen> sivang: either provided directly by yourself, or through pursuading somebody else to take on that support
[11:26] <sivang> sladen: you have main upload rights?
[11:26] <sivang> sladen: would you sponsor me?
[11:26] <sladen> sivang: I'd sponsor a sane-looking patch to a package that was already there
[11:27] <persia> sivang: The security team would *love* to sponsor all your security updates.  They are constantly looking for new people to submit tested patches.
[11:27] <sivang> okay cool
[11:27] <sladen> sivang: but I wouldn't _gaurantee_ to do so ('gaurantee' is a very strong word)
[11:27] <sivang> I'll start playing with mod-wsgi
[11:27] <sivang> sladen: I know, but you still have main upload rights yes?
[11:27] <sladen> sivang: last time I checked, yes
[11:27] <sivang> sladen: so once it's tested and working, we're good to go?
[11:28] <sladen> sivang: whether I use them as much as I should, is another question
[11:28] <sivang> sladen: good, cause I Have no interest in going throught the red tape for main right
[11:28] <sivang> sladen: :-)
[11:28] <Daviey> sladen: I'm not entirely sure gaurantee is a word :)
[11:28] <sivang> Daviey: haha
[11:28] <sivang> in Israel surely it is not.
[11:28] <sivang> NOTHING is guranteed here.
[11:28] <sivang> ;)
[11:29] <sivang> what's the right omitte to file a universe upload rigths again?
[11:29] <Daviey> sivang: If you care about the package as passionately as you seem to.. Just unoffically taking on burden of checking for security and bugs, submitting patches (either plain or debdiff), is enough to allow someone else to sponsor the package
[11:30] <Daviey> sivang: This means that you can personally guarantee support, and everyone wins
[11:30] <persia> And there's only a few people who can push to -security anyway (not everyone with main upload rights can do this).
[11:46] <ogra> lool, do you happen to have a working qemu lucid atm ? i cant get iso-codes to unpack here running rootstock, i wonder if you can in an interactive setup
[11:47] <lool> ogra: You mean apt-get install iso-codes?
[11:47] <ogra> yeah
[11:47] <ogra> rootstok hangs forever in
[11:47] <ogra> Selecting previously deselected package iso-codes.
[11:47] <ogra> Unpacking iso-codes (from .../iso-codes_3.12.1-1_all.deb) ...
[11:48] <ogra> and i wonder if it has to do with the bz2 tarball or the 3.0 source format, though i would expect more packages to be in that format if i install the ubuntu-netbook task
[11:49] <cjwatson> neither the source tarball compression method nor the 3.0 source format can possibly have anything to do with whether the binary package installs successfully
[11:49] <lool> ogra: it works in qemu-system-arm for me
[11:49] <persia> Neither the source tarball nor the source format should have any impact on binary installation.
[11:50] <cjwatson> snap
[11:50] <persia> Indeed.
[11:50] <ogra> lool, hmm, k, then it must be my VM setup i guess :/
[11:50] <lool> Schnipschnapschnappy das kleine Krokodil
[11:50] <ogra> LOL
[11:50] <lool> ogra: it's you again and your bad karma
[11:50] <ogra> yeah, apparently :/
[11:51] <lool> I'll try in qemu-arm-static too
[11:51]  * ogra needs to do something about that karma thing
[11:51] <lool> works with syscall emulation as well
[11:52] <ogra> cjwatson, well, repackaging in 3.0 was the only significant difference i found to the karmic package (which unpacks fine) ... apart from several new upstream releases
[11:53] <ogra> but i think lool has just proven it must be my VM ... and since we use the same kernel i suspect it can only be my setup ... either i'm missing something in the rootfs or in the qemu call
[11:54] <persia> ogra: The key is that nothing in how the source package is packed or unpacked *can* affect the binary package, which is always constructed in accordance with debian/rules.
[11:54] <ogra> lool, do you use MALLOC_CHECK_=0 in yours ?
[11:55] <ogra> persia, indeed ... but as i said, it was the only significant changelog entry i found
[11:57] <lool> ogra: no
[11:57] <ogra> aha
[11:57] <ogra> i should probably try without then
[11:57]  * ogra does that ... we'll see in 1h :)
[11:57] <lool> But MALLOC_CHECK_=0 when the source package is built is not going to affect the binary packages!
[11:58] <ogra> i'm not building anything :)
[11:58] <ogra> i'm getting stuck installing a binary
[11:58] <lool> I know, but I'm hungry, my jokes get worse every minute
[11:59] <ogra> ah, french humor :) get some lunch !
[11:59] <lool> If the chicken isn't ready in 10 minutes it's going to be awful
[12:16] <persia> Can anyone suggest a better fragment than `while [ ! -f /var/lib/partman/persia ]; do sleep 5; done; tail -f /var/lib/partman/persia` to start viewing a low-volume file once it appears?  I'm sure there's some cool fsnotify thing.
[12:19] <lifeless> is there a timeout in the new lvm, for drive probing?
[12:20] <persia> I haven't noticed one (and needed to press 'C' once to get the boot to finish when swap didn't want to come up)
[12:20] <ion> persia: tail -F /var/lib/partman/persia
[12:21] <lifeless> persia: hmm, I would quite like it to stop and drop me into busybox ;)
[12:21] <persia> ion: Nifty.  Is that smart, or does it poll like my snippet?
[12:21] <ion> It probably just polls.
[12:21] <ion> Yeah, it has an open-sleep loop, just straced it.
[12:22] <persia> lifeless: What letters show up while it's waiting?  Press them one at a time to see if you get a useful result.  I *think* C is Cancel, but I'm kinda guessing (there's no docs I've found)
[12:22] <soren> slangasek: I have a user who says that since upstart 0.6.3-11 landed, his ssh and apache servers don't start on boot. Does this sound familiar?
[12:22] <lifeless> persia: letters?
[12:22] <persia> ion: I'll probably use that next time because it's less typing, but it ought be done the smart way.
[12:22] <ion> Yeah
[12:22] <lifeless> persia: I'm talking about 'probing all drives, please pe patient this may take a while\n'
[12:22] <Keybuk> persia: C is cancel fsck
[12:23] <persia> lifeless: So, you should have something like "Waiting for foo [CSM]" and that seems to mean you can press 'C' , 'S', or 'M' for different (undocumetned) effects.
[12:23] <slangasek> soren: yes, his /etc/network/interfaces is broken and he should help verify the SRU for bug #497299
[12:23] <Keybuk> persia: only [SM] for that one ;-)
[12:23] <ion> lifeless: mountall just stopping at that request instead of continuing until device appears or user hits a key is a known bug and will be fixed.
[12:23] <Keybuk> S = Skip this filesystem (pretend it's marked nowait in fstab)
[12:23] <Keybuk> M = Give me maintenance shell
[12:24] <lifeless> persia: no prompt at all
[12:24] <lifeless> ion: thanks
[12:24] <Keybuk> I = Ignore fsck errors (and try to mount anyway)
[12:24] <lifeless> Keybuk: what needs to be installed to get that prompt?
[12:24] <Keybuk> F = Run fsck -y (after an fsck failure)
[12:24] <Keybuk> lifeless: nothing
[12:25] <Keybuk> lifeless: just mountall and plymouth
[12:25] <lifeless> hmm,  I suspect plymouth is missing.
[12:25] <ogra> you should get a message about that on boot
[12:25] <lifeless> libplymouth is installed
[12:25] <ion> A couple of small functions just need to be added to plymouth to make it integrate to other main loop than its own, and then mountall needs to be changed to be asynchronous with the boredom timeout query.
[12:25] <ogra> mountall will complain it cant connect to plymouth
[12:26] <persia> Keybuk: Thanks for the summary of options.  Is this already in /usr/share/doc/ somewhere, or would it be useful for me to put it in a text file and add it somewhere (and to which package?)
[12:26] <Keybuk> persia: no, and no
[12:26] <Keybuk> the fact you just see letters is very temporary
[12:26] <Keybuk> the idea is that the new theme will have a much nicer message
[12:26] <Keybuk> e.g. say "Press C to cancel" etc.
[12:26] <persia> Ah, cool.  Nevermind then.
[12:26] <slangasek> Keybuk: aren't those strings verbatim from mountall?  You intend the theme to fix them up?
[12:26] <lifeless> I don't think anything in the kernel|initramfs dependency set drags in plythmouth itself
[12:27] <Keybuk> slangasek: the new theme will require changing the messages, yeah
[12:27] <slangasek> lifeless: ubuntu-standard :P
[12:27] <lifeless> slangasek: perhaps,  but you really don't want to know what I'm up to :P
[12:27] <slangasek> Keybuk: a little unnerving that this is considered tied to a theme
[12:28] <slangasek> (and yes, I've been in the plymouth theme code)
[12:29] <soren> slangasek: Great, thanks for the hint. I'll point him to that.
[12:29] <Keybuk> slangasek: we need the ability to put messages in different places on the screen
[12:29] <Keybuk> and also resolve the issues where the "Fsck in progress" messages are built into the theme, instead of from mountall
[12:29] <Keybuk> etc.
[12:29] <slangasek> ah
[12:33] <Keybuk> and as ion says, mountall instead of just going into a "reading from plymouth" loop for each key press needs to work asynchronously
[12:33] <Keybuk> so if the volume arrives while waiting, it cancels the prompt and carries on with its work
[12:35] <persia> Keybuk: Is there a way that one can provide hints to say "don't wait on this"?  I never want to wait on swap for boot (although I'd like it mounted at some point).
[12:36] <Keybuk> persia: nobootwait in fstab is the hint
[12:36] <persia> Nifty.  I thought I'd get pointed at some code that needed fixing.  Thanks!
[12:40] <lifeless> slangasek: so, the new lvm doesn't want to find stuff at boot
[12:40] <lifeless> slangasek: any pointers before I start climbing through hoops?
[12:40] <slangasek> lifeless: WFM, worked for kees
[12:40] <slangasek> I disavow all knowledge beyond that :-)
[12:40] <lifeless> hah
[12:50] <cjwatson> dpm: re bug 518718, bug 527052 implies that it should be just "Ubuntu Netbook", not "... Edition"?  that's what current cdimage code says too
[12:50] <lifeless> slangasek: FYI - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488332
[12:51] <lifeless> appears to be it; I haven't dug deep enough to know if there is more under the hood, but I can get pvscan happy with the sysfs setting
[12:51] <slangasek> lifeless: ummm, I definitely don't have CONFIG_SYSFS_DEPRECATED_V2 set here (stock Lucid kernel), and WFM
[12:51] <lifeless> slangasek: this is stock lucid kernel too
[12:51] <cjwatson> dpm: shall I just change the netbook strings in the obvious way here?
[12:53] <cjwatson> dpm: since it involves removing a word, I can probably just update all the translations myself
[12:53] <cjwatson> or most of them anyway
[12:57] <slangasek> cjwatson: assuming you know the correct genitive->nominative conversion? :)
[12:57] <lifeless> slangasek: should mountall depend on plymouth?
[12:58] <cjwatson> slangasek: oh, I can leave those fuzzy
[12:58] <slangasek> lifeless: I defer to Keybuk; mountall /works/ without plymouth, it just doesn't /talk/ to you
[13:00] <tjaalton> how is it supposet to work on a serial terminal?
[13:00] <tjaalton> -sed
[13:00] <Keybuk> lifeless: udev doesn't work with deprecated sysfs layout anymore
[13:00] <tjaalton> I find it strange that a server install pulls plymouth..
[13:00] <Keybuk> so you can't have it ;)
[13:00] <lifeless> Keybuk: Oh, I don't want it.
[13:01] <Keybuk> tjaalton: why?  we still need something to arbitrate password prompts and suchlike during boot
[13:01] <seb128> cjwatson, is debug-ubiquity supposed to send you in install only mode rather than livecd desktop?
[13:01] <lifeless> I suspect that lvm in the initramfs is old, but I don't know why yet.
[13:01] <cjwatson> seb128: debug-ubiquity is orthogonal to the try/install mode
[13:01] <lifeless> Keybuk: I'm not quite back into the system to fiddle; root is mounted but I suspect upstart is in lala land
[13:01] <tjaalton> Keybuk: no way to do that without plymouth?
[13:01] <cjwatson> oh, heh, maybe it isn't
[13:01] <Keybuk> tjaalton: plymouth works fine for doing that - there's no reason to invent a different way
[13:01] <seb128> cjwatson, weird, I picked livecd desktop and got installer only
[13:02] <seb128> cjwatson, I was wondering if that's due to me addign debug-ubiquity to the option, will try without
[13:02] <cjwatson> seb128: yeah, bug I think, fixing now
[13:02] <seb128> cjwatson, thanks
[13:02] <cjwatson> well, that said
[13:02] <tjaalton> Keybuk: ok then. as long as it works on a serial terminal as well ;)
[13:02] <cjwatson> seb128: I think actually maybe it does make sense - the thing is that if you don't use install-only mode, then debug-ubiquity is a no-op
[13:03] <cjwatson> the way you get debug mode in "try ubuntu" mode is to run 'ubiquity -d' in a terminal
[13:03] <seb128> cjwatson, would it make sense to have debug-ubiquity in the f6 menu for unstable versions?
[13:03] <cjwatson> so I think I'll leave it as it is and retroactively declare that it's meant to be that way ;)
[13:03] <Keybuk> tjaalton: it does
[13:03] <seb128> cjwatson, ok, makes sense
[13:03] <cjwatson> seb128: hmm, the problem with debug-ubiquity is that it exposes your password in the logs
[13:04] <cjwatson> admittedly it does tell you that it's doing so, but still, I'd prefer it to just be when we ask for it
[13:04] <seb128> ok
[13:04] <cjwatson> unfortunately the only way to fix that is by some really messy hacking in debconf that made both joeyh and I feel ill
[13:05] <seb128> cjwatson, I don't get the crash in glib with today image btw, will make harder to report a bug about it, I delayed to have a version where the partition setup was working and now it's working all the way...
[13:05] <cjwatson> how annoying
[13:05] <seb128> yes
[13:05] <cjwatson> let's hope (?) it recurs
[13:05] <seb128> I will try again with yesterday's image later
[13:06] <seb128> it was not an image recording issue, I did write the key several times to clean hacks I did on the stick
[13:12] <cjwatson> seb128: yeah, I doubted it was
[13:13] <ogra> lool, ha ! seems qemu doesnt like the use of a swapfile
[13:14] <ogra> lool, running rootstock with --noswap makes iso-codes install
[13:14] <ogra> (that wasnt an issue in karmic though)
[13:21] <ogra> Riddell, in qt4-x11 4:4.6.0-1ubuntu2 you set -arch armv6, do you remember the reason for that ?
[13:25] <Riddell> I did?
[13:25] <Riddell> where?
[13:26] <cjwatson> ogra: I do, it was because there was a specific armv6 implementation of some bits
[13:26] <cjwatson> the default was arm, and wasn't good for armv7
[13:26] <ogra> do you remember if it was assembler ?
[13:27] <cjwatson> the armv6 code doesn't handle multicore, but is otherwise much better than what was there before
[13:27] <cjwatson> yes
[13:27] <ogra> ah, k, thanks a lot
[13:27] <seb128> bah
[13:27] <seb128> I almost success to install a3 now
[13:27] <seb128> it's not moving from the "detecting other systems" now
[13:27] <seb128> ie grub install
[13:28]  * seb128 wonders if I should just power down the box
[13:29] <seb128> cjwatson, anything useful I can get from an installer only install blocking on grub os detection?
[13:29] <seb128> cjwatson, it's at 93% looking for other os for a while now
[13:29] <cjwatson> syslog, ps axf maybe
[13:30] <cjwatson> strace of whatever process it is that's looping
[13:34] <seb128> cjwatson, there is a "blkid -o value -s TYPE /dev/sda2" running for some 8 minutes now
[13:34] <cjwatson> can you strace it to see what it's doing?
[13:34] <lifeless> Keybuk: 'mounted-dev main process (435) terminated with status 1
[13:34] <lifeless> Keybuk: would that throw upstart off?
[13:35] <Keybuk> wouldn't think so
[13:35] <seb128> cjwatson, nothing apparently, strace -p <pid> stays there
[13:35] <Keybuk> though it does mean something's wrong with your /dev ;-)
[13:35] <Keybuk> if you don't have anything in there - then you'd have bigger problems
[13:35] <lifeless> eh
[13:35] <cjwatson> seb128: sounds like it's looping in internal logic then ...
[13:35] <lifeless> root is mounted
[13:35] <lifeless> lvm is happy
[13:35] <cjwatson> seb128: kill the blkid process and see if it proceeds :)
[13:36] <lifeless> I can see hundreds of nodes if I break=premount and look
[13:36] <cjwatson> seb128: what is /dev/sda2?
[13:36] <seb128> cjwatson, gdb says blkid_do_probe()
[13:36] <seb128> blkid_verify()
[13:36] <seb128> blkid_get_dev()
[13:36] <lifeless> Keybuk: 177 to be precise
[13:37] <seb128> cjwatson, it's an extended partitin
[13:37] <seb128> +o
[13:38] <Keybuk> lifeless: break=premount is a long way before the root fs
[13:38] <seb128> cjwatson, which has sda5 and sda6
[13:38] <lifeless> Keybuk: break=bottom has the root mounted
[13:38] <seb128> which are the / and swap for the install
[13:38] <lifeless> Keybuk: I've just checked
[13:38] <Keybuk> lifeless: does mounted-dev fail consistently for you?
[13:39] <lifeless> Keybuk: I see that error, yes
[13:39] <Keybuk> lifeless: add "console output" to the job, then "set -x" in the script
[13:39] <lifeless> the symptom I have is that the machine is stopped just after showing the root fs as clean
[13:39] <slangasek> lifeless: 'break=premount' is while in the initramfs, though, so who knows what's going on in between that and chrooting?
[13:39] <slangasek> s/going on/going wrong/
[13:39] <lifeless> ctrl-alt-delete makes it reboot, and it kills the hw-clock only.
[13:39] <lifeless> Keybuk: doing, thanks
[13:42] <seb128> cjwatson, grub-install blocked on the same command, after killing it again it's downloading langpacks now
[13:42] <seb128> cjwatson, thanks
[13:49] <cjwatson> seb128: I'm not seeing that with the extended partition here - it would be good if you could manage to debug it independently?
[13:50] <seb128> cjwatson, it's almost done installing langpacks let's see if that does it on the installed system
[13:54] <seb128> oh plymouth joy
[13:54] <seb128> "xorg crashes on enter"
[13:54]  * seb128 uninstall
[13:54] <seb128> at least the mini install worked ;-)
[14:06] <Keybuk> bryceh: radeon should work with KMS right?
[14:07] <Ixan> is there some complete documentation for preseed somewhere with all available settings for every subpart like partman somewhere? pretty please be so..
[14:07] <persia> Yes.
[14:07] <Keybuk> tjaalton: ^ ?
[14:07]  * persia tries to remember the URL
[14:08] <seb128> cjwatson, I don't get the blkid hang on the installed system
[14:08] <seb128> cjwatson, I will try an another install and see how it goes
[14:08] <persia> https://help.ubuntu.com/${release_number}/installation-guide/${arch}/index.html
[14:11] <Ixan> yeah, seen that before. perhaps i was just secretly praying there were more paramteres i could configure
[14:12] <cjwatson> there are a number of undocumented templates, but mostly they aren't useful for setting manually, and there's no comprehensive list - the guide is meant to be a list of all the ones that are actually useful
[14:12] <cjwatson> what in particular are you missing?
[14:12] <Ixan> using the crypto template for partman and setting a default password for luks
[14:13] <Ixan> so users can change it themselves upon receiving it
[14:15] <cjwatson> hmm, the current code explicitly disallows preseeding that I'm afraid
[14:15] <cjwatson> which may or may not be an error - feel free to file a bug on partman-crypto
[14:15] <Ixan> hirr, curses!
[14:17] <tjaalton> Keybuk: yes
[14:18] <Keybuk> tjaalton: all I get is a blank screen and a hang on boot
[14:18] <Keybuk> seems to be about the point the driver would be loaded
[14:18] <tjaalton> Keybuk: then try the mainline build
[14:18] <Keybuk> tjaalton: -v
[14:19] <tjaalton> .33 I mean
[14:19] <Keybuk> tjaalton: newer kernel you mean?
[14:20] <tjaalton> Keybuk: yes, 2.6.33 mainline build
[14:20] <tjaalton> if you like deb's ;)
[14:20] <Keybuk> I'd like a .iso ;P
[14:20] <tjaalton> bah :)
[14:20] <Keybuk> what driver would it be trying to use
[14:21] <Keybuk> if I can blacklist it, I can see if I can install
[14:21] <slangasek> Keybuk: you  linux-backports-modules-nouveau-lucid-generic
[14:21] <slangasek> meh
[14:21] <tjaalton> ah, well in that case you can disable kms
[14:21] <slangasek> Keybuk: linux-backports-modules-nouveau-lucid-generic is present, right?
[14:21] <cjwatson> slangasek: that's a good insult
[14:21] <Keybuk> slangasek: how could I tell?
[14:21] <tjaalton> but it was radeon, no?
[14:21] <cjwatson> you linux-backports-modules-nouveau-lucid-generic, you.  (furthermore, your mother was a radeon.)
[14:21] <slangasek> oh, radeon
[14:21] <Keybuk> tjaalton: Radeon Xpress 1250 I think
[14:21] <tjaalton> Keybuk: radeon.modeset=0
[14:22] <Keybuk> (looking up the pci id)
[14:22] <Keybuk> but
[14:22] <Keybuk> saying
[14:22] <Keybuk> that
[14:22] <Keybuk> the NVIDIA based laptop doesn't work either
[14:22] <Keybuk> just a nice greeish/cyanish/blueish screen
[14:22] <slangasek> must be a plymouth bug
[14:22] <slangasek> :-)
[14:22] <Keybuk> slangasek: this is before I get to plymouth ;)
[14:22] <pfr> sorry guys for asking this here, but the chance that some of you know what i need is the highest on this channel:  does Canonical have somebody like Jono Bacon who lives in Germany?
[14:22] <Keybuk> pfr: there is nobody like Jono Bacon in Germany, Jono Bacon is illegal there
[14:22] <sebner> pfr: dholbach
[14:22] <pfr> or at least some community guy who speaks german?
[14:22] <slangasek> Jono Bacon is unique in the world
[14:22] <pfr> Keybuk: heh
[14:22] <sebner> lol
[14:23] <sebner> pfr: Ich spreche auch Deutsch aber du willst den dholbach ;)
[14:23] <pfr> dholbach: yes, i think i want you :P
[14:23] <sebner> heh
[14:23] <Ixan> i learned all my german from special german movies from the 70s. best not uttered in public
[14:24] <Keybuk> tjaalton: modeset=0 worked
[14:24] <Keybuk> see, can't be a plymouth bug
[14:25] <Keybuk> I now have a blue bar
[14:25] <Keybuk> (I must patch that to be brown at some point <g>)
[14:25] <sebner> Keybuk: please don't! :P
[14:25] <tjaalton> Keybuk: try the newer kernel once you've installed, to see if it works with drm from .33
[14:25] <Keybuk> tjaalton: ok
[14:26] <Keybuk> awwh, the touch screen doesn't work in the installer's X session
[14:27] <tjaalton> which device? serial wacoms don't work yet, but soon after a3
[14:27] <Keybuk> tjaalton: it's a Dell XT
[14:27] <Keybuk> the touchscreen did work in the live environment a while back, both in capacitive and resistive modes
[14:27] <tjaalton> the old one or XT2?
[14:27] <Keybuk> the old one
[14:28] <tjaalton> what does "a while back" mean?
[14:28] <tjaalton> looks like it's a wacom
[14:28] <Keybuk> about the point that we dropped HAL
[14:28] <Keybuk> it never worked properly before that
[14:28] <Keybuk> then we dropped HAL
[14:28] <tjaalton> sounds about right
[14:28] <Keybuk> and it magically worked in both modes
[14:28] <tjaalton> oh
[14:28] <Keybuk> when HAL was around, it'd only work in resistive mode
[14:31] <tjaalton> yeah sounds like the wacom isn't getting initialized, which is known. there's a patch waiting in git which doesn't make it filter the list of devices udevdb has. then the devices with subsys tty will work
[14:31] <tjaalton> fixes vbox as well
[14:31] <Keybuk> ah yeah, I think I saw that one go past on #udev
[14:32] <tjaalton> then wacom needs an updated udev rules file and things should work. I have a thinkpad X61 tablet with the same issue
[14:32] <Keybuk> I guess this is a case of "everything worked fine until somebody tried to make it work properly"
[14:33] <tjaalton> something like that yes :)
[14:33] <ion> There are recent tablet PCs that have a wacom connected to a *serial port*? Seriously? :-)
[14:33] <Keybuk> it was probably the wrong resolution, and uncalibrated, and all those things that engineers hate
[14:33] <Keybuk> but I COULD PRETEND TO BE JACK BAUER!
[14:34] <tjaalton> ion: sure
[14:44] <cjohnston> rickspencer3: could you please join #ubuntu-classroom-backstage when you get a chance
[14:44] <Keybuk> cjwatson: silly question
[14:44] <Keybuk> if I put radeon.modeset=0 on the kernel command-line when I install
[14:45] <Keybuk> does that get copied to the kernel command-line of the installed system?
[14:45] <ogra> i think it depends where you put it
[14:46] <ogra> the -- has a meaning here
[14:46] <Keybuk> ogra: as do many things in life
[14:46] <cjwatson> Keybuk: if it goes after --, yes
[14:46] <ogra> but i forgot if it has to be in front or behind
[14:46] <ogra> ah
[14:46] <Keybuk> cjwatson: yeah, it did copy it
[14:53] <Keybuk> wow, I'm so used to everything Just Working on intel
[14:54] <lifeless> Keybuk: it was haning because ifupdown hadn't been upgraded
[14:54] <lifeless> Keybuk: and that meant lo wasn't being started
[14:55] <lifeless> Keybuk: which meant rc-sysvconf never kicked in
[14:55] <Keybuk> you don't need rc scripts anyway ;)
[14:55] <lifeless> sorry, rc-sysinit.conf I think
[14:56] <lifeless> no, but being able to login is nice.
[14:57] <slangasek> lifeless: "because ifupdown hadn't been upgraded" - that upgrade is a workaround for a broken /etc/network/interfaces, why was yours broken?
[14:58] <lifeless> slangasek: it wasn't broken: I din't have a network-interface.conf file
[14:58] <slangasek> er, oh
[14:58] <lifeless> slangasek: because I had hardy's.
[14:58] <lifeless> slangasek: there is a missing versioned dep here, I think.
[14:58] <lifeless> either breaks or depends, dunno which is appropriate.
[14:58] <slangasek> breaks isn't appropriate
[14:58] <lifeless> of course, this doesn't matter if the upgrade completes properly :>
[14:59] <slangasek> it's upstart's rc-sysinit.conf that depends on the new ifupdown functionality, so if there's to be a dep, that's where it needs to go
[14:59] <lifeless> yes
[15:00] <lifeless> All I was saying about breaks was I didn't know which way around the relation needed to be expressed
[15:00] <Keybuk> slangasek: probably a Breaks on the older version is better?
[15:00] <Keybuk> actually I guess it needs a Dep now because of the fact the .conf file depends on the event
[15:00] <Keybuk> which is likely to cause yet more buildd failures
[15:00] <lifeless> breaks on older stops it being a hard dep
[15:00] <lifeless> depends will bring it in if it has to be there
[15:00] <slangasek> that's overloading the meaning of breaks though
[15:00] <lifeless> slangasek: orly?
[15:01] <lifeless> anyhow
[15:01] <lifeless> bugs incoming.
[15:01] <slangasek> lifeless: upstart doesn't break the old ifupdown, the absence of new ifupdown breaks new upstart :)
[15:01] <Keybuk> in practice, if an Upstart job refers to an event generated by a job outside of its package, then it must depend on that package
[15:01] <Keybuk> so Upstart should have a Depends: ifupdown
[15:01] <Keybuk> and, since Upstart is supposed to work unconfigured, that has to be a Pre-Depends
[15:03] <lifeless> bug 527829 is the mounted-dev issue
[15:03] <lifeless> its trivial
[15:03] <Keybuk> ah, I didn't know it needed one
[15:05] <lifeless> bug 527830 is the lo issue
[15:05] <lifeless> I filed another bug earlier tonight, there is a predepends loop
[15:05] <lifeless> udev -> upstart -predep->mountall -> udev
[15:06] <Keybuk> lifeless: can't be helped
[15:06] <lifeless> so you can't actually install those three by hand without silly-buggery
[15:06] <lifeless> Keybuk: I'm just reporting it
[15:07] <Keybuk> mountall depends on udev (it copies out of /lib/udev/devices - which is created by udev's postinst)
[15:07] <tseliot> Keybuk: do you mind if I modify the way mountall interacts with plymouth?
[15:07] <Keybuk> udev should not depend on Upstart though?
[15:07] <Keybuk> tseliot: be my guest
[15:07] <tseliot> :-)
[15:08] <Keybuk> lifeless: I can't see a udev->upstart dep here
[15:08] <lifeless> Keybuk: technically it depends on upstart-job
[15:08] <lifeless> right after libusb, before module-init-tools
[15:08] <Keybuk> ah right, from misc:Depends
[15:08] <lifeless> but as thats provided by upstart. ..
[15:08] <Keybuk> right, again, it has to ;-)
[15:09] <Keybuk> upstart has to depend on mountall because it uses "on filesystem"
[15:09] <Keybuk> so there you go
[15:09] <Keybuk> all those are correct
[15:09] <lifeless> why does udev depend on upstart?
[15:10] <Keybuk> lifeless: it ships an upstart job
[15:10] <Keybuk> that's pretty much the definition of "depends on" :p
[15:10] <Keybuk> the real problem is that upstart is using pre-depends I guess
[15:10] <Keybuk> it doesn't *have* to
[15:10] <lifeless> I think thats a pretty key driver for it, yes.
[15:11] <lifeless> but its 2am, and I don't think I'm a good sounding board right now.
[15:11] <Keybuk> we never made Upstart "Essential"
[15:11] <lifeless> so I'm happy, my server is running lucidish now
[15:11] <lifeless> I'm going to make email flow and go halt()
[15:11] <Keybuk> coreutils 7.1 apparentlyt
[15:11] <ttx> pitti: will the beta1 burndown charts reset their start date at the beginning of beta1 subcycle ?
[15:11] <lifeless> Keybuk: which we never shipped ;>
[15:12] <Keybuk> lifeless: that's ok, >= 7.1 will dtrt
[15:12] <pitti> ttx: I just sent a mail to -platform about this, with a proposal
[15:12] <ttx> pitti: ah, will read and comment if needed :)
[15:17] <Keybuk> message:
[15:17] <Keybuk>   merge Scott's fix for 524484
[15:17] <Keybuk> ohhh, t'other Scott
[15:17] <Keybuk> slangasek: OOI, wouldn't james_w's importer automatically have committed that upload?
[15:17] <slangasek> yes, but without the full branch history, so
[15:18] <Keybuk> slangasek: why without the full branch history?
[15:18] <Keybuk> my understanding is that it would have checked out the lp:ubuntu/upstart branch
[15:18] <slangasek> because it wouldn't know it was a merge of smoser's branch?
[15:18] <Keybuk> slangasek: ah, smoser had a branch?
[15:18] <slangasek> yes
[15:18] <Keybuk> oh, of course, he must have done - you merged it
[15:18] <slangasek> :-)
[15:18] <Keybuk> did you overwrite the importer's own? ooi
[15:19] <slangasek> shouldn't have clobbered anything the importer cares about
[15:19] <lifeless> slangasek: ><
[15:19] <lifeless> the right thing is
[15:20] <slangasek> the importer is supposed to recognize that I've tagged the upload, and consider it equivalent to the archive
[15:20] <lifeless> debcommit -r - that should tag it
[15:20] <Keybuk> slangasek: indeed not, just curious - I overwrite the importer all the time ;)
[15:20] <tseliot> Keybuk: does "Cc" stand for Ctrl-c ?
[15:20] <slangasek> lifeless: I'm familiar :)
[15:20] <Keybuk> tseliot: no, just C in upper or lower case - I don't really trust plymouth ;)
[15:20] <lifeless> then when you push your upload is compared by the importer
[15:20] <lifeless> if different, it will win
[15:21] <slangasek> where by "win" you mean "everyone loses", right? :)
[15:21] <Keybuk> lifeless: not if the importer has already done the import
[15:21] <Keybuk> then you have to overwrite what it did with something better
[15:21] <tseliot> Keybuk: ok. I guess we can't catch "Esc" as that's already in use, right?
[15:21] <lifeless> Keybuk: thats why you push before dput, after building
[15:21] <Keybuk> tseliot: right
[15:22] <Keybuk> lifeless: as we've just followed - smoser couldn't push to the lp branch
[15:22] <lifeless> Keybuk: why not?
[15:22] <Keybuk> I was wondering whether steve had to "fix" the history after the upload or not
[15:22] <Keybuk> lifeless: he's not a member of core-dev ?
[15:22] <lifeless> Keybuk: if he can upload the package, he can push to the branch
[15:22] <lifeless> Keybuk: doesn't matter; its all about 'can he upload'
[15:22] <Keybuk> only via a sponsor I guess
[15:22] <lifeless> which sounds like what slangasek did
[15:23] <lifeless> 'sponsor' => merge + dput
[15:23] <slangasek> Keybuk: no, I committed first, uploaded after
[15:23] <Keybuk> right, so we've achieved the answer to my question :p
[15:23] <Keybuk> I was just curious :)
[15:23] <lifeless> \o/ working code, 6 years in :>
[15:23]  * slangasek grins
[15:24] <Keybuk> not that there's anything implicitly wrong with overwriting the importer
[15:24] <lifeless> zomg, why is tla-load-dirs still in the archive.
[15:24] <lifeless> Keybuk: well, there is on upstream changes.
[15:25] <lifeless> Keybuk: unless you capture the pristine data precisely as the importer sees it
[15:25] <slangasek> lifeless: how else are you going to run tla-buildpackage? :-P
[15:25] <lifeless> slangasek: aieee
[15:26] <Keybuk> lifeless: in Upstart's case, the branch is based off the upstream trunk - and I use merge-upstream to make releases ;)
[15:27] <Keybuk> lifeless: do you know the bug# for your pre-depends loop report?
[15:28] <lifeless> no, check my filed bug rss feed
[15:28] <Keybuk> "bend over, I need to check your RSS"
[15:28] <lifeless> bug 527722
[15:30] <Keybuk> thx
[15:30] <lifeless> de nada
[15:30] <Keybuk> all three bugs have fixes committed
[15:30] <lifeless> thanks
[15:30] <lifeless> I realise they are kindof corner case
[15:31] <lifeless> at least for all our karmic->lucid upgrades
[15:32] <Keybuk> we care about hardy→lucid upgrades this cycle though too, no?
[15:32] <lifeless> yes
[15:32] <lifeless> but even they would presumably typically be ok
[15:32] <Keybuk> probably, always worth getting the ordering right
[15:32] <lifeless> its because I ended up with an interrupted upgrade that this blew up
[15:32] <Keybuk> they're obviously not critical for α3, but would be good to have for β1 since more people will test then
[15:33] <lifeless> and yeah, +1 on trying to get it right, otherwise I wouldn't have diagnosed and reported ;)
[15:37] <slangasek> Keybuk: bug #527605 looks like a dupe of the dep cycle report?
[15:38] <Keybuk> yeah could be
[15:56] <Caesar> Sigh. Does nobody use NFS any more?
[15:56] <Keybuk> I use NFS
[15:56] <ogra> for what ? sshfs is so much nicer :)
[15:57] <Caesar> The number of things in Lucid that complain because $PWD is unreadable by root makes me sad
[15:57] <Caesar> ogra: sshfs doesn't scale
[15:57] <Keybuk> Caesar: so don't squash root ;)
[15:57] <ogra> yeha
[15:57] <Caesar> Keybuk: err, no
[15:58] <Caesar> Keybuk: can I ask you the upstart questions I emailed you about?
[15:58] <Caesar> or can you answer them now or something?
[15:58] <Keybuk> Caesar: I am busy at the moment, I'll reply to your mail in due time
[15:58] <Caesar> ok
[15:59] <Keybuk> (probably today)
[15:59] <Caesar> Thank you
[15:59] <james_w> nigelb: hi, why do you keep proposing the merge for the apport hook in rhythmbox?
[15:59] <nigelb> james_w: sorry for the spam.
[15:59] <nigelb> I made plenty of mistakes
[15:59] <nigelb> each time someone pointed something out, I had to keep correcting it
[16:00] <nigelb> james_w: I think its perfect now though :)
[16:00] <james_w> nigelb: you don't have to do those steps every time
[16:00] <james_w> nigelb: you can just push to your branch and it will update
[16:01] <nigelb> james_w: but my branch would diverge with every change and it would throw up an error
[16:01] <james_w> nigelb: hmm
[16:01] <james_w> what were you doing to make a change?
[16:02] <nigelb> I was deleting the branch, uncomitting, making the changes, and pushing again, and requesting merge
[16:02] <james_w> just make the changes and commit!
[16:02] <james_w> you are using a version control system ;-)
[16:02] <nigelb> james_w: I'm learning that now
[16:03] <nigelb> james_w: I thought the commits and changelog should be matching
[16:03] <nigelb> now I realized it doesnt have to be
[16:03] <james_w> nah
[16:03] <james_w> good :-)
[16:04] <nigelb> james_w: sorry again for all that spam
[16:04] <james_w> no problem
[16:04] <james_w> just wanted to make sure you were finding the system pleasant to use, and it looked like you were doing more than you had to
[16:05] <nigelb> yeah, I learned that now
[16:22] <slynux_> can anyone suggest a good makefile tutorial
[16:22] <slynux_> ?
[16:31] <chrisccoulson> slynux_: i don't know any good tutorials, but i find that a good way of learning is to look at other packages as examples
[16:31] <slynux_> ok
[16:31] <chrisccoulson> you can generally learn a lot by doing that ;)
[16:35] <Chipzz> I would disagree
[16:35] <Chipzz> most Makefile's you'll see today are autogenerated by automake
[16:35] <smoser> hi, i'm looking to make sure that bug 525003 gets fixed in lucid.  I'm not exactly sure how what i need to do.  i've linked a branch and proposed merging, i hope thats enough?
[16:35] <Chipzz> and those contain so much cruft...
[16:36] <mdz> ara, do you know where to find the script used to mark a bug (with duplicates) as a duplicate of another bug, moving all the duplicates across?
[16:36] <nigelb> smoser: you could ping pitti :)
[16:37] <nigelb> mdz: lp-set-dup?
[16:37] <mdz> nigelb, that sounds promising
[16:37] <ara> mdz, I am afraid not, bdmurray maybe knows better
[16:38] <smoser> nigelb, yeah, i wanted to avoid bothering him if the above was sufficient and thought someone might know.
[16:38] <micahg> mdz: ubuntu-dev-tools
[16:40] <mdz> nigelb, thanks
[16:40] <mdz> ara, lp-set-dup is it
[16:40] <nigelb> mdz: happy to help :)
[16:40] <pitti> smoser: can you please assign it to me? I only look at new bugs ever other week or so, if you subscribe or assign me I get it to know much faster
[16:40] <ara> mdz, thanks
[16:41] <smoser> pitti, ok. i just didn't want to explicitly pester you if it otherwise was fine.
[16:41] <smoser> thanks.
[16:41]  * mdz cleans up that batch of duplicates of bug 520824
[16:49] <cjwatson> kirkland: bug 455746 - I notice that postfix is in the eucalyptus-cloud task, but not eucalyptus-cluster.  I think I was told that this should go in the cluster controller bit, but am I right in thinking we actually only need it on the cloud controller?
[16:49] <cjwatson> if that's right, then it's a trivial fix
[16:50] <lamont> what controls writing to /etc/mailcap? (as in, how do I tell it about a diff handler ofr something?)
[16:50] <cjwatson> update-mime(8) describes it
[16:50] <ion> lamont: sed -nre '5p' /etc/mailcap
[16:51] <lamont> doh
[16:55] <kirkland> cjwatson: yes, as far as I can tell, it's only the front end of eucalyptus that sends mail (welcome mails to new users, etc)
[17:01] <kirkland> cjwatson: there's two other things i wanted to get your input on
[17:02] <kirkland> cjwatson: one is that we've run into some unfortunate timing issues on preseed installs of separated components
[17:03] <kirkland> cjwatson: i think there's a bit of time where the, say CLC or CC is up, and broadcasting it's avahi message
[17:03] <kirkland> cjwatson: and the installation of the next machine picks that up
[17:04] <kirkland> cjwatson: but the webserver providing the preseed file is not quite up and ready
[17:05] <lucas> how often are sync requests being processed?
[17:08] <james_w> lucas: they probably haven't for a couple of days due to the milestone freeze
[17:09] <james_w> should be ~every weekday apart from that
[17:10] <lucas> ah ok, perfect
[17:10] <lucas> I thought it was only once a week or something
[17:11] <lucas> and started getting worried about the ruby mess ;)
[17:11] <manjo> cjwatson , ping
[17:13] <manjo> cjwatson, I am trying to install a EEEpc 1201N, the installer is stuck at 93% (looking for other operating system) and I am unable to chvt to another terminal to look at the logs...
[17:14] <manjo> cjwatson, I got this image yesterday...
[17:16] <kees> lifeless: have you gotten anywhere with your lvm issues?  I can try to help debug it.
[17:20] <manjo> cjwatson, looks like its an issue with the nvidia graphics card
[17:21] <manjo> that I am not able to see the VT1/2etc
[17:21] <manjo> but if I chvt to 2 and do reboot it actually reboots
[17:23] <Keybuk> tjaalton: still around?
[17:23] <Keybuk> tried 2.6.33 and still no love for radeon
[17:24] <tseliot> slangasek: do you think I need to implement the support for ask-questions in the boot theme?
[17:29] <matti> Hello folks.
[17:30] <matti> Is keyserver.ubuntu.com down?
[17:32] <tjaalton> Keybuk: ah, too bad
[17:32] <tjaalton> needs a bugreport then
[17:33] <tseliot> wouldn't that require a new user space drm too?
[17:33] <tseliot> (just asking)
[17:33] <tjaalton> we already have 2.4.18 which is the latest release
[17:33] <tjaalton> and that was made for nouveau
[17:34] <tjaalton> though our version has the abi change reverted
[17:34] <Keybuk> tjaalton: how would you like the bug report filed?
[17:34] <cjwatson> kirkland: ok, fixed cloud preseed thing
[17:34] <tjaalton> Keybuk: upstream :)
[17:34] <cjwatson> kirkland: the design of the upstart jobs was meant to prevent that; as far as I'm concerned if we're seeing that that means that the job implementation is faulty ...
[17:34] <kirkland> cjwatson: cheers, thanks.
[17:35] <Keybuk> tjaalton: I don't have the no-how to talk to them, but would appreciate it if you could for me
[17:35] <tjaalton> Keybuk: or if you feel like it you could poke airlied on #dri-devel
[17:35] <cjwatson> manjo: sorry, without logs I'm as clueless as you - however it could be the blkid hang seb128 ran into earlier, don't know for sure
[17:35] <kirkland> cjwatson: right, so I agree that publication should only occur after the bits are up and serving the preseed file
[17:35] <kirkland> cjwatson: i need to check with ttx on that one, though, as he said that it shouldn't be that way
[17:35] <tjaalton> Keybuk: ok, well just file it against -ati, it'll include what we need
[17:35] <Keybuk> tjaalton: I'll do the poke
[17:35] <kirkland> cjwatson: i'll dig deeper
[17:36] <cjwatson> kirkland: I didn't really do much of the upstart stuff
[17:36] <kirkland> cjwatson: no, i did most of it, i know it inside and out
[17:36] <kirkland> cjwatson: one last question, ecryptfs related
[17:36] <manjo> cjwatson, thought I will run it by you incase you had prior experience with this hang... I rebooted and started a reinstall and it seems to go past the 93% mark.. ie on 2nd install does not hang at 93%
[17:36] <kirkland> cjwatson: actually, nevermind.  it's a hard one.  i'll think more on it.
[17:38] <manjo> cjwatson, but do you think filing bug against ubiquity will be of any use at this point ?
[17:38] <manjo> coz we lost data wrt to previous install attempt right ?
[17:39] <cjwatson> manjo: not without logs
[18:02] <Keybuk> slangasek: as well as the ENTER Kills My X Server issue
[18:02] <Keybuk> people have reported a problem where typing corrupts the top of the screen
[18:02] <Keybuk> right?
[18:27] <slangasek> tseliot: ask-questions> I have no opinion, I didn't report that bug I just triaged it :)
[18:28] <slangasek> Keybuk: yes
[18:29] <Keybuk> slangasek: cool, I can replicate that one on the radeon machine
[18:29] <slangasek> \o/
[18:30] <tseliot> slangasek: ok
[19:00] <chrisccoulson> cjwatson - somebody just reported a duplicate of bug 209410 against gnome-screensaver. i notice in that bug you mention that ubiquity already tries to inhibit the screensaver
[19:00] <chrisccoulson> out of interest, how do you do this?
[19:04] <chrisccoulson> ah, never mind. i found it now (gnome-screensaver-command --poke)
[19:04] <chrisccoulson> i know why that doesn't work
[19:48] <mathiaz> james_w: hi!
[19:49] <mathiaz> james_w: what are we supposed to do with these kind of branches:
[19:49] <mathiaz> james_w: https://code.launchpad.net/~ubuntu-branches/ubuntu/lucid/vsftpd/lucid-201002122353/+merge/19228
[20:37] <soren> cjwatson: Björn seems happy with my latest stab at bug 246558. How about you?
[20:40] <jibel> mvo_, Hi, I've found the problem (and solution) for the xapian search with an hyphen (hence searching for a package name)
[20:40] <mvo_> jibel: ohhh - nice!
[20:40] <mvo_> jibel: how?
[20:41] <jibel> mvo_, the indexer uses it's own term generator instead of xapian TermGenerator and it does it the wrong way
[20:41] <jibel> s/it's/its/
[20:41] <mvo_> jibel: aha, good that I have you here, one thing that occured to me was that we problably want to only reapply the sort mode in xapian when its not in the default sort mode. because one nice feature of the xapian sort is sort by relevance
[20:41] <mvo_> jibel: apt-xapian-index?
[20:41] <jibel> yes apt-xapian-index
[20:42] <mvo_> jibel: cool, if you give me the details I can fix that
[20:42] <jibel> we sort by relevance but relevance is not shown anywhere, from a user point it's confusing
[20:42] <mvo_> hm, right
[20:42]  * mvo_ scratches head
[20:43] <jibel> we have report where the users searches for pitivi and enters 'pit'
[20:43] <jibel> but the qualitycutoff is so high that it's not displayed in the list
[20:44] <mvo_> could we display relevant with little stars or something maybe?
[20:44] <mvo_> utf-8 ftw ;)
[20:44] <jibel> yes, it's a percentage
[20:46] <jibel> mvo_, I'll push a fix for apt-xapian-index and synaptic, it won't be hard to port it software-center.
[20:48] <jibel> but I'd like to know why enrico did it this way.
[20:54] <mvo_> jibel: #xapian has been very responsive about questions like this in the past
[20:54] <mvo_> jibel: I imagine that it might be because when he wrote it something in the xapian buildin was missing
[20:55] <cjwatson> soren: I'll think about it.  I'm worried about doing lots of work at boot time.
[20:55] <cjwatson> soren: but I will think about it.
[20:59] <jibel> mvo_, indeed, I talked to ojwb yesterday about the pb with the phrase generator,he was very helpful
[20:59] <jibel> mvo_, the patch for apt-xapian-index is at http://pastebin.com/3QYx9u5K
[21:00] <jibel> the stemming part can be removed since it indexes only package names.
[21:01] <mvo_> jibel: sweet, that is all?
[21:02] <mvo_> jibel: *thanks* very much
[21:03] <jibel> no that's not all.  This patch will generate correct index with terms at the right position
[21:04] <jibel> e.g xserver-xorg-video-ivtv will be indexed xserver 1 xorg 2 video 3 ivtv 4
[21:05] <jibel> the hyphen is the phrase generator so when you search for  xserver-xorg it search for an exact match for the term AND the position
[21:05] <mvo_> jibel: aha, ok
[21:06] <jibel> mvo_, with the current version of apt-xapian-search the key contains the hyphen and can't be searched
[21:07] <jibel> mvo_, we also need to change the query string to replace the '-' by '%-'
[21:08] <jibel> mvo_, this makes xapian expand the last term of the query and replacing the operator PHRASE by AND
[21:08] <jibel> mvo_, you can then search for 'name:(xserver-com)'
[21:09]  * mvo_ nods
[21:10] <jibel> mvo_, and it will returns all package with a name containing xserver and com*
[21:10] <jibel> I'll send you a piece of code it's easier.
[21:10] <mvo_> ok
[21:11] <mvo_> I need to leave for bed now, I will check it out tomorrow morning :)
[21:11]  * mvo_ waves
[21:11] <jibel> have a good night
[21:12] <soren> cjwatson: Thanks. If you have other ideas about how to handle this for shared VM images, I'm all ears, though. This was just my initial reaction.
[21:18] <mathiaz> bdmurray: hi - how often are the json search refreshed?
[21:18] <mathiaz> bdmurray: for example: http://qa.ubuntu.com/reports/team-subscribed/server-team-subscribed-with-date.json
[21:19] <TheMuso> slangasek: I thought a new testing group had been started to do just that, and since I'm not invovled with that, I don't know. GOing by the tracker, obviously not.
[21:19] <Daviey> mathiaz: it's not like you could claim it's not regular enough!  "created": "2007-11-26T14:40:26.815940+00:00"
[21:19] <bdmurray> mathiaz: I thought I'd mentioned in the e-mail that'd I run that once but could make it a cron job if it met your requirements.
[21:19] <TheMuso> hrm ok amd64 still needs 3 more tests done.
[21:20] <bdmurray> Daviey: that's likely a bug tasks' creation date
[21:20] <Daviey> bdmurray: it is
[21:20] <mathiaz> bdmurray: right - so I've loaded that in bughugger and it's a good start
[21:20] <mathiaz> bdmurray: doing the query on the date is a bit awkward
[21:20] <mathiaz> bdmurray: as what I'd like to express is: created <= yesterday UTC
[21:20] <Daviey> looks like it was last updated Wed, 24 Feb 2010 00:30:02 UTC
[21:21] <bdmurray> mathiaz: okay, I'll look at getting that to work in bughugger then
[21:22] <mathiaz> bdmurray: the problem I'm trying to solve is that the dailynewbugs lists (http://qa.ubuntu.com/reports/ubuntu-server-team/dailynewbugs.ubuntu-server.thu.html) are quickly out-dated
[21:23] <mathiaz> bdmurray: does bughugger check the *current* status of a bug when it works from a json search?
[21:23] <bdmurray> mathiaz: no
[21:24] <mathiaz> bdmurray: hm - fundamentally that's what I'd like to do
[21:26] <mathiaz> bdmurray: I'll think about it a bit more
[21:26] <mathiaz> bdmurray: server-team-subscribed-with-date.json may be a good starting point though
[21:27] <mathiaz> bdmurray: are these reports generated using launchpad API or directly from the DB?
[21:27] <bdmurray> mathiaz: the api
[21:33] <james_w> mathiaz: currently they are probably bugs if the diff doesn't show something useful
[21:40] <TheMuso> slangasek: ah ok alpha 3 released, missed the topic. Don't mind me
[21:49] <Caesar> Is the only difference between the Ubuntu Server CD and the non-Server CD the installer?
[21:49] <Caesar> or is there more to it?
[21:57] <lifeless> kees: thanks for offering, yes all fixed.
[21:57] <lifeless> kees: bugs filed; system happy
[21:57] <kees> lifeless: cool; if you have them handy, what are the bug#s?
[22:01] <lifeless> not handy sorry
[22:01] <lifeless> uhm, I think one is invalid, and I might need to file one other, on consideration
[22:02] <kirkland> lool: when you come around tyhicks has a few questions for you about https://bugs.launchpad.net/ubuntu/+source/linux/+bug/524919; you can find him in #ecryptfs on irc.oftc.net
[22:02] <lifeless> however, I was up to 3:30 or so doing the recovery, and its 9 now: I'm a little shattered
[22:02] <lifeless> kees: gimme 15 to try and get my head together, and I can tell you what happened
[22:02] <lifeless> kees: its all about sysfs scanning
[22:03] <kees> lifeless: interesting, okay, no worries, get some sleep.  :)
[22:06] <MattJ> As an upstream developer with a (new) package going into lucid... the version it is based on has known issues, is there a way we could get it updated?
[22:07] <MattJ> I'm not sure which is best, since we weren't planning another bugfix release in that development branch (but could make one if necessary)
[22:07] <MattJ> or you can tell me it's a lost cause and I'll just try not to think about it :)
[22:08] <dupondje> is it fixed in debian ? or isn't it in debian ? :)
[22:08] <james_w> MattJ: no, impossible, we love shipping with bugs ;-)
[22:08] <MattJ> It's in debian, but also the same upstream version
[22:09] <MattJ> Bugs are great, but not when their mine :)
[22:09] <MattJ> *they're
[22:09] <MattJ> See?
[22:09] <james_w> heh
[22:09] <james_w> MattJ: no problem
[22:09] <james_w> you can either provide a patch fixing all the bugs, or make a new bugfix release from that branch upstream
[22:10] <james_w> once you have either one wave it around here and find someone to help
[22:10] <MattJ> Ok, great
[22:11] <MattJ> I'll figure out what needs backporting and get that done ASAP, thanks :)
[22:17] <jcastro> MattJ: I have been putting docs together for upstreams such as yourself to make it easy to find out this kind of info, any feedback on it would be appreciated! https://wiki.ubuntu.com/Upstream
[22:18] <MattJ> Oh very nice, thanks :)
[22:23] <lifeless> kees: ok, slighty fed etc
[22:23] <lifeless> kees: uhm, hers the issue
[22:23] <lifeless> here is the issue
[22:23] <lifeless> if you say 'iz bug' I will file it a little bit later
[22:24] <lifeless> I had an upgrade from hardy go queer, which wasn't a bug
[22:24] <lifeless> however, I ended up with new kernel, old userspace
[22:24] <lifeless> amongst the various problems I had, the old lvm2 needs sysfs to be in a now deprecated layout
[22:24] <lifeless> or sysfs_scan=1 leads to actual block devices being skipped
[22:25] <lifeless> upstart OTOH needs the newer layout, so the newer kernel is needed
[22:25] <lifeless> so, I'm thinking kernels with the new sysfs layout should Breaks: lvm << version-that-added-the-new-layout
[22:39] <lifeless> kees: let me know whether I should file that bug or not ;)
[22:42] <kees> lifeless: would a Breaks: have actually helped that situation?
[22:42] <lifeless> kees: yes
[22:42] <kees> lifeless: I would say yes, then, open a bug for that.
[22:43] <lifeless> kees: the new kernel would have required lvm to be in the same install set
[22:43] <lifeless> and anyone doing surgery would have had dpkg whinging at them how the breaks was present
[22:43] <lifeless> ok, I'll open a bug. Thanks
[22:58] <shtylman_> what is the purpose of the linux-preempt kernel?
[22:58] <shtylman_> does the generic kernel not have preempting ?
[22:59] <jdong> the generic kernel does not CONFIG_PREEMPT, no.
[22:59] <crimsun> shtylman_: lower latency with faster tick
[22:59] <shtylman_> jdong: crimsun: thanks :)
[23:23] <baffle> slangasek: Hi, I was just talking to Kirkland about libvirt-bin and the new upstart script he made for it. A quick question; Is /etc/default/ deprecated with upstart? Are configuration parameters supposed to be put directly into /etc/init/<deamon>.conf
[23:24] <persia> Caesar: The difference between "server" and other alternate CDs is the contents of the pool on the CD and the selection of available preseed files.  The difference between "live" and "alternate" CDs is the installer.  That there doesn't happen to be a live CD for "server" is a coincidence (although an intentional one)
[23:24] <baffle> slangasek: .. instead? I see that /etc/default/libvirt-bin is marked as "obsolete" in the package "Conffiles:" too.
[23:26] <baffle> persia: Another difference between server installation CD and live CD is the exclusion of various network card modules; I noticed that "bnx2" is missing. "bnx2" is commonly used on servers.. I had to patch the liveCD to get networking to work on a server.. (I PXE boot the image)
[23:28] <persia> baffle: comparing server alternate to Desktop live shows all sorts of differences.  Comparing server alternate to desktop alternate will show you how the contents differ (some stuff on desktop live is only in the pool).
[23:29] <persia> baffle: If Desktop alternate doesn't work (or doesn't contain the packages you need) it may be worth filing a bug.  No promises it gets fixed (space considerations vs. number of users served, etc.).  If desktop alternate works and desktop live doesn't, *definitely* file a bug: that's likely just a documentation issue.
[23:32] <baffle> persia: I'm not sure if it can be qualified as a *bug*. It is just that the live CD seems to be missing support for "server grade" network cards, and I had to patch them from the correct kernel-module udeb myself.
[23:32] <cjwatson> bnx2 got fixed, I think
[23:32] <baffle> cjwatson: Oh.
[23:32] <baffle> cjwatson: Then it wasn't intentional. :)
[23:32] <cjwatson> hang on, missing in the *live* CD?
[23:32] <cjwatson> that's the other way round from the normal problem :)
[23:32] <baffle> cjwatson: Yes.
[23:32] <cjwatson> but it's certainly a bug either way
[23:32] <cjwatson> bnx2 is complicated because it requires firmware
[23:32] <baffle> cjwatson: But, nevermind, I was basing this on Karmic, I haven't checked out live on lucid.
[23:33]  * persia would expect it to be in the pool for the liveCD but not in the squashfs if it's in desktop alternate, and if it's not in desktop alternate, believes it deserves a bug for tracking of the decision to include/not-include it
[23:33] <cjwatson> please see if you can reproduce it in lucid if you can, and absolutely file a bug if it doesn't work
[23:33] <cjwatson> ah yes
[23:33] <cjwatson> initramfs-tools (0.92bubuntu34) karmic; urgency=low
[23:33] <cjwatson>   * Remove bnx2 from the initramfs; it needs firmware, and at this stage we
[23:33] <cjwatson>     only support network modules that don't need firmware loading (LP:
[23:33] <cjwatson>     #394783).
[23:33] <cjwatson>  -- Colin Watson <cjwatson@ubuntu.com>  Tue, 07 Jul 2009 11:45:58 +0100
[23:33] <cjwatson> so see bug 394783 for context
[23:34] <cjwatson> since that's closed, please do open another bug if you actually need it, since that information is useful to us
[23:35] <baffle> cjwatson: Well, *need* is maybe not the correct term. I found it practical to have the ability to get a full desktop system booted from PXE on some servers..
[23:36] <baffle> cjwatson: I.e. if you need to do some hacking to fix broken RedHat/CentOS servers. :-)
[23:36] <baffle> cjwatson: So it isn't really a typical use case.
[23:36] <cjwatson> ok, well, you have the audit trail now...
[23:37] <baffle> cjwatson: Thank you for your help. You wouldn't happen to know anything about upstart? Ref. my question to slangasek above..
[23:38] <baffle> I just doesn't like posting bugs on packages if it is intended behaviour. Not others fault that I do weird stuff..
[23:38] <baffle> s/doesn't/don't/
[23:47] <cjwatson> baffle: my understanding from talking to the upstart author is that on the whole he prefers upstart jobs to be written in a way that's simple enough that you no longer really need a separate /etc/default/ file to make merging of customisations easier
[23:47] <cjwatson> baffle: but there's no written-down standard as yet, so there's almost certainly some variance
[23:51] <cjwatson> part of the historical reason why /etc/default/ exists was that it was pretty hard for admins to edit /etc/init.d/ scripts and then keep their changes merged across versions - it wasn't an original part of sysvinit, it evolved
[23:56] <Chipzz> cjwatson: that's an interesting angle on /etc/default :)
[23:57] <Chipzz> I always thougt of it slightly different