| 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:00 |
| ginggs | alternatively, is there a way that the orig*.tar.gz can be copied from my PPA into the archive? | 00:01 |
| === lilstevie_ is now known as lilstevie | ||
| ginggs | nvm, i made a plan (nvidia-cuda-toolkit) | 01:40 |
| pitti | Good morning | 05:49 |
| doko | apw: fyi strace ftbfs on arm64 due to header changes in 3.8 | 07:47 |
| mwhudson | good morning pitti | 07:49 |
| pitti | hey mwhudson, how are you? | 07:50 |
| === 6A4AAAALJ is now known as grumble | ||
| === tlbr is now known as Guest76323 | ||
| === elijah is now known as Guest53930 | ||
| === shadeslayer is now known as Guest75339 | ||
| === Guest75339 is now known as shadeslayer_ | ||
| doko | chrisccoulson: new thunderbird crashed for me 4-5 times today, always when Shift-deleting emails / email threads | 11:21 |
| === hikiko is now known as hikiko|ln | ||
| === _salem is now known as salem_ | ||
| === freyes__ is now known as freyes | ||
| === grumble is now known as brumgle | ||
| === hikiko|ln is now known as hikiko | ||
| === shadeslayer_ is now known as shadeslayer | ||
| === brumgle is now known as grumble | ||
| === infinity changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: closed | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: | ||
| === tvoss is now known as tvoss|dinner | ||
| === pavlushka is now known as Guest52849 | ||
| === pavlushka_ is now known as Guest59271 | ||
| === alan_g is now known as alan_g|eod | ||
| === adam_g` is now known as adam_g | ||
| === tvoss|dinner is now known as tvoss | ||
| nacc | smoser: quick question for you, re: importer | 18:46 |
| smoser | k | 18:47 |
| 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:49 |
| 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:53 |
| 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:54 |
| 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 | 18:57 |
| 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:21 |
| smoser | you could make itconfigurable | 19:22 |
| nacc | yeah, true | 19:22 |
| smoser | usd-import --prefix=importer/ | 19:22 |
| === salem_ is now known as _salem | ||
| 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:19 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| ubottu | bug 1631474 in initramfs-tools (Ubuntu Yakkety) "No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option" [High,Fix committed] https://launchpad.net/bugs/1631474 | 21:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 | |
| 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:32 |
| 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:34 |
| 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:36 |
| chiluk | yeah anyhow I really think this all needs to be re-engineered. | 21:37 |
| chiluk | preferably with some test-cases set up. | 21:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!