[00:00] <ginggs> would someone with universe upload rights and fast internet, please 'dget https://launchpad.net/~ginggs/+archive/ubuntu/testing/+files/nvidia-cuda-toolkit_8.0.44-0ubuntu1~ppa3.dsc' , remove '~ppa3' from the changelog and upload?
[00:00] <ginggs> warning: 2.5GB of source tarballs
[00:01] <ginggs> alternatively, is there a way that the orig*.tar.gz can be copied from my PPA into the archive?
[01:40] <ginggs> nvm, i made a plan (nvidia-cuda-toolkit)
[05:49] <pitti> Good morning
[07:47] <doko> apw: fyi strace ftbfs on arm64 due to header changes in 3.8
[07:49] <mwhudson> good morning pitti
[07:50] <pitti> hey mwhudson, how are you?
[11:21] <doko> chrisccoulson: new thunderbird crashed for me 4-5 times today, always when Shift-deleting emails / email threads
[18:46] <nacc> smoser: quick question for you, re: importer
[18:47] <smoser> k
[18:49] <nacc> smoser: we're considering moving the importer's actions (when using an existing repository or not) into a importer/ namespace -- so that i don't need to worry about branch collisions between the 'upstream' git tree and locally. I'm wondering if you think it's better to leave that remote configuration in the repository locally or if it's better to just delete it out of the repository configuration,
[18:49] <nacc> since it's only valid to use with the importer itself
[18:53] <smoser> i'm not sure i follow. 'remote configuration' and how would you colide with upstreams ? if someone did : git remote add upstream git-rul-here
[18:54] <nacc> 'upstream' here being ~ubuntu-server-dev eventually
[18:54] <nacc> currently ~usd-import-team
[18:54] <nacc> 'importer upstream'
[18:54] <nacc> aka usd-clone 'origin'
[18:57] <nacc> you can ignore the details, i think
[18:57] <nacc> smoser: just which, in your opinion is better, if you use usd-import on an existing directory -- i'm starting to think we don't want to 'leak' the importer's namespace
[19:21] <smoser> oh. i see.
[19:21] <smoser> if you ran import on an existing directory, it'd start tagging ubuntu/ stuff. and that could collide.
[19:21] <nacc> smoser: that way the user can do whatever they want (or not) in that git tree, and the importer just reuse existing objects if possible
[19:21] <nacc> smoser: yeah
[19:21] <smoser> i think dont do that.
[19:21] <nacc> smoser: yep, me too
[19:22] <smoser> you could make itconfigurable
[19:22] <nacc> yeah, true
[19:22] <smoser> usd-import --prefix=importer/
[21:19] <chiluk> cyphermox can you explain to me how we got so far diverged from debian initramfs-tools?
[21:19] <chiluk> there are tons of changes?
[21:21] <cyphermox> because we need ipv6 support in initramfs-tools.
[21:21] <chiluk> cyphermox it seems to me that a lot of the changes seem like valid features that I'd expect debian to want.
[21:21]  * cyphermox shrugs
[21:21] <chiluk> cyphermox is debian not willing to accept ipv6  support?
[21:21] <cyphermox> any other things predate me, I think
[21:21] <chiluk> has anyone tried to push this back up there?
[21:21] <cyphermox> I don't know
[21:21] <slangasek> it's been several years since we've done any work on this
[21:21] <chiluk> cyphermox ... recent changes not-withstanding.. not talking about all that..
[21:22] <cyphermox> it's a complicated thing, and I haven 't exactly reviewed all of initramfs-tools aside from the little changes I made
[21:22] <slangasek> it's a lot of work, given that Debian never integrated udev into their initramfs the way we did
[21:22] <chiluk> slangasek how is it that you monitor all channels at all times?
[21:22] <slangasek> magic
[21:22] <slangasek> or technology?
[21:23] <chiluk> do you have a highlight set for cyphermox or initramfs-tools?
[21:23] <slangasek> chiluk: just happened to be in the right window at the right time
[21:23] <chiluk> ok fine..
[21:23] <cyphermox> hehe
[21:23] <slangasek> and you can't prove otherwise
[21:23] <cyphermox> chiluk: slangasek is watching to see where I screw up
[21:23] <cyphermox> ;)
[21:24] <tsimonq2> and I'm watching to see when you guys screw up so I can learn :P ;)
[21:24] <tsimonq2> or when you guys succeed, either one ;)
[21:24] <chiluk> don't give us so much hope tsimonq2
[21:24] <cyphermox> chiluk: fwiw, I'm preparing a revert of all the recent changes in initramfs-tools for xenial
[21:25] <cyphermox> and I'll get back to my dark little corner to 1) cry myself to sleep, and 2) fix it a different way that won't be as dangerous.
[21:25] <chiluk> cyphermox: pulling ipv6 from xenial ip options?
[21:25] <cyphermox> essentially, yes
[21:26] <chiluk> I'd be ok with simply removing that one liner.  I like the rest of the changes.
[21:26] <cyphermox> reverting what regresses.
[21:26] <cyphermox> what one liner?
[21:26] <chiluk> cyphermox: do you have a bug open about this?
[21:26] <cyphermox> I'll be using bug 1631474
[21:26] <chiluk> I feel a strange ownership in all this initramfs stuffs now.
[21:27] <cyphermox> chiluk: I'm not throwing it all out, we'll just integrate it slightly differently.
[21:27] <chiluk> so you want to revert back to 8.2 essentially right?
[21:27] <cyphermox> it's going to be a good opportunity to not have to deal with the cruft from ipconfig
[21:27] <cyphermox> to 8.1
[21:28] <cyphermox> 8.2 is where I started to put things in.
[21:28] <chiluk> I'll review 8.1->8.4 but I think you fixed a lot of stuffs in that timeframe.
[21:28] <chiluk> it would be nice if we actually suppored static assignment with ip= variable.
[21:28] <chiluk> i'm pretty sure that still fails.
[21:29] <chiluk> going forward that is.
[21:29] <cyphermox> I think it would be a very misguided thing to use tbh
[21:29] <cyphermox> so my personally opinion is that it needs to die in the flames of hell.
[21:29] <cyphermox> (static assignment via ip= magic)
[21:30] <chiluk> well I'm fairly certain it will fail unless it's going down some weird path I did not code inspect.
[21:30] <cyphermox> it just calls ipconfig with the right parameters, and that is supposed to work.
[21:31] <cyphermox> not that I tried it, but we haven't changed it -- setting ip=1.2.3.4:1.2.3.5:something:something:yadda:yadda would just do ipconfig -t $sometimeout  $IP
[21:31]  * cyphermox realizes this is kind of hand-wavy
[21:32] <cyphermox> not setting ip= at all (ie. you don't write anything) should do straight DHCP, via ipconfig, again as ipconfig -t timeout $device
[21:34] <chiluk> cyphermox as with static assignment as it stands now it would call ipconfig -t ${ROUNDTTT} -d $IP    which should fail since -d would have the full $IP and not simply the interface
[21:34] <chiluk> cyphermox: oh nm.. I see that ipconfig understand the IP=:::: awesome-sauce
[21:36] <cyphermox> device being whatever BOOTIF= set, or "" in which case ipconfig will try the bring up all devices (using logic in C similar to what I did in all_netbootable_devices()
[21:36] <cyphermox> chiluk: yes
[21:36] <cyphermox> AFAIK none of that ip= stuff is touched by the kernel at all, it's only meant for ipconfig
[21:37] <chiluk> yeah anyhow I really think this all needs to be re-engineered.
[21:37] <chiluk> preferably with some test-cases set up.