| britt__ | hey guys | 00:08 |
|---|---|---|
| StFS | Hi. I'm wondering if somebody can help me figure out whether a fix to a bug will be made available on quantal or whether it's just going to be released for raring | 00:57 |
| StFS | this is the bug: https://bugs.launchpad.net/ubuntu/+source/libav/+bug/1038781 | 00:58 |
| ubottu | Ubuntu bug 1038781 in libav (Ubuntu) "-dev packages are missing alternate depends on -extra packages" [Low,Fix released] | 00:58 |
| infinity | siretart: ^ | 01:01 |
| infinity | StFS: As it stands, the bug isn't targetted for an SRU, no. | 01:02 |
| StFS | infinity: thanks... how would I have seen this myself? just for the future... and what is the process, I mean, who takes these SRU decisions? | 01:05 |
| StFS | can I request somewhere that it is? | 01:06 |
| infinity | If it had a quantal task, that would be a pretty good indication. | 01:06 |
| StFS | ok | 01:06 |
| infinity | The part where this also appears to be a problem in precise as well leads me to think it should, perhaps, be nominated. But I'm not about to create work for others, either. | 01:08 |
| infinity | siretart: You have any objections about backporting that fix to Q and P? | 01:08 |
| StFS | infinity: well... thanks for your help, I hope siretart notices this at some point and takes it under consideration. | 01:13 |
| StFS | afk | 01:13 |
| === bryceh is now known as bryce | ||
| pitti | Good morning | 05:24 |
| TheMuso | pitti: GOod morning. | 05:36 |
| TheMuso | Damn capslock. | 05:37 |
| pitti | TheMuso: nah; it makes a fine escape key :) | 05:37 |
| TheMuso | lol | 05:38 |
| TheMuso | Well with my setup, it doubles as my KVM control key, and sometimes the KVM sticks capslock on. | 05:39 |
| pitti | TheMuso: I have swapped Esc and Caps Lock ages ago; vim is so much nicer with that | 05:39 |
| TheMuso | Sounds fair. | 05:40 |
| siretart | infinity: I have no problems with that, if you feel that this does qualify as an SRU | 06:18 |
| === Amaranthus is now known as Amaranth | ||
| dholbach | good morning | 07:55 |
| pitti | dholbach: guten Morgen | 07:56 |
| dholbach | hey pitti | 07:56 |
| tkamppeter | pitti, hi | 08:06 |
| pitti | hello tkamppeter, how are you? | 08:12 |
| mlankhorst | any sru admins on that can accept nvidia-graphics-drivers-experimental-310, nvidia-graphics-drivers-173-updates, jockey, and xorg ? | 08:31 |
| tkamppeter | pitti, you have assigned bug 808829 to me. What do I have to do with it now? | 08:57 |
| ubottu | Launchpad bug 808829 in cups-pk-helper (Ubuntu) "[MIR] cups-pk-helper" [Low,In progress] https://launchpad.net/bugs/808829 | 08:57 |
| pitti | tkamppeter: jdstrand had some additional requirements for acking the MIR | 08:58 |
| tkamppeter | pitti, you need that someone has to test it for Oneiric and Precise? | 08:58 |
| * pitti doesn't understand | 08:59 | |
| pitti | tkamppeter: that's for raring only | 08:59 |
| tkamppeter | pitti, you mean that it is built with PIE and BIND_NOW and that the test suite gets running on every build? | 09:00 |
| tkamppeter | pitti, comment #21. | 09:00 |
| pitti | right | 09:00 |
| === henrix_` is now known as henrix | ||
| === doko_ is now known as doko | ||
| freedomrun | gsettings set org.gnome.nautilus.window-state start-with-status-bar true is impossible in 13.04 ??! | 09:53 |
| === Zic_ is now known as Guest38238 | ||
| === mcclurmc_away is now known as mcclurmc | ||
| pitti | seb128, ev, ogra_, slangasek: bug 1088428 *grin* | 10:51 |
| ubottu | Launchpad bug 1088428 in d-conf (Ubuntu) "[Apport test bug armhf] dconf-service crashed with SIGSEGV in __libc_do_syscall()" [Medium,New] https://launchpad.net/bugs/1088428 | 10:51 |
| seb128 | pitti, nice! | 10:51 |
| pitti | seb128: FYI, I updated the configuration on osageorange accordingly | 10:51 |
| seb128 | k | 10:52 |
| === Nigel_ is now known as G | ||
| pitti | seb128: crashdb.conf now has ubuntu-{i386,amd64,armhf} databases, and the cronjobs use --crash-db to select which arch they run for | 10:52 |
| ogra_ | pitti, neat ! | 10:52 |
| seb128 | great | 10:52 |
| pitti | seb128: and added config/Ubuntu*/armhf/sources.list for getting the packages from ports.u.c. for armhf | 10:52 |
| === mcclurmc is now known as mcclurmc_away | ||
| pitti | seb128: FYI, LP retracer config is now in lp:~ubuntu-archive/apport/lp-retracer-config (also rolled out to porter box) | 11:04 |
| pitti | tseliot: do you think you'll have time for bug 1054458 today? it has been breaking _all_ nvidia installations since quantal for everyone | 11:07 |
| ubottu | Launchpad bug 1054458 in ubuntu-drivers-common (Ubuntu Quantal) "nvidia-detector crashed with ValueError in __get_value_from_name(): invalid literal for int() with base 10: 'experimental-304'" [High,Triaged] https://launchpad.net/bugs/1054458 | 11:07 |
| === sraue_ is now known as sraue | ||
| tseliot | pitti: isn't it fixed in raring? https://code.launchpad.net/~ted/ubuntu/raring/ubuntu-drivers-common/nvidia-experimental-number/+merge/137754 | 11:41 |
| tseliot | pitti: in 1:0.2.71.1 ? | 11:41 |
| rbasak | Does anyone know if ogra_ is around today? | 11:42 |
| pitti | tseliot: ah, the MP is still open and the bug for raring as well | 11:43 |
| pitti | tseliot: so I guess we mostly need the fix for nvidia-common for quantal | 11:43 |
| pitti | tseliot: also, current git still doesn't have that particular fix; it might not be strictly necessary due to ignoring 'experimental', though | 11:44 |
| tseliot | pitti: let me check... | 11:45 |
| tseliot | pitti: commit ee6fb0234e1fbc21d8e8092022d631b5e7a8fb2b in u-d-c should do it | 11:50 |
| tseliot | pitti: without the patch in the merge request | 11:50 |
| pitti | tseliot: ah, thanks | 11:50 |
| tseliot | pitti: let me check nvidia-common in precise | 11:51 |
| tseliot | pitti: my upload in precise-proposed was rejected. Let me reupload... | 11:54 |
| === _salem is now known as salem_ | ||
| === mcclurmc_away is now known as mcclurmc | ||
| pitti | seb128: I guess it is time to re-enable LP crashes for raring, if we still want to do it; WDYT? | 12:02 |
| tseliot | pitti: so my fix is in precise-updates too. It shouldn't really be an issue any more | 12:13 |
| pitti | tseliot: great, thanks for checking! | 12:14 |
| tseliot | np | 12:14 |
| === _jmp__ is now known as _jmp_ | ||
| tsdgeos | everytime i update my raring VM compiz crashes | 12:28 |
| tsdgeos | are you guys aware of that? | 12:28 |
| pitti | tseliot: so I wonder why this is still the top crasher in https://errors.ubuntu.com/ | 12:34 |
| pitti | tseliot: (which link to bug 825350) | 12:35 |
| ubottu | Launchpad bug 825350 in nvidia-common (Ubuntu Oneiric) "nvidia-detector crashed with ValueError in __get_value_from_name(): invalid literal for int() with base 10: '173-updates'" [Medium,Confirmed] https://launchpad.net/bugs/825350 | 12:35 |
| pitti | tseliot: oh, that's -experimental vs. -updates | 12:35 |
| pitti | tsdgeos: i. e. we got ~ 740 reports for this yesterday alone | 12:36 |
| tsdgeos | i see | 12:36 |
| === cpg is now known as cpg|away | ||
| pitti | tsdgeos: sorry, tab error; that was meant for tseliot | 12:43 |
| tsdgeos | pitti: oh, i unsee then :D | 12:44 |
| seb128 | pitti, @raring: not sure how much use we will have of those reports during end of year break time | 12:56 |
| seb128 | pitti, early next year my avoiding collecting launchpad noise while we are not there | 12:56 |
| === Guest38238 is now known as Zic | ||
| pitti | seb128: WFM | 13:06 |
| === amitk is now known as amitk-afk | ||
| smoser | slangasek, the reason bug 978127 would not be fixed by running is that that would require an ntp service on the network (and some configuration of the ephemeral image to use it) or access to ntp.ubuntu.com. we want/need maas to run "completely offline". | 14:04 |
| ubottu | Launchpad bug 978127 in cloud-init (Ubuntu Precise) "incorrect time on node causes failed oauth" [High,Triaged] https://launchpad.net/bugs/978127 | 14:04 |
| === amitk-afk is now known as amitk | ||
| ScottK | jamespage: We're one FTBFS away from getting opencv and friends out of raring-proposed. I gave you a ping about sivp/armhf late on Friday, but just in case you missed it ... It looks like another Java'ish thing and it'd be nice if you could have a look at it. | 14:10 |
| xnox | smoser: if you are running "completely offline" you'd still want all nodes to agree on common time. So in your "mini-offline" world you'd still want to have a local ntp. (sure it will be incorrect, but at least time should be the same for all parties involved). | 14:13 |
| tseliot | pitti: right but errors.ubuntu.com mention jockey and there's no way to know if they are using the latest nvidia-common | 14:14 |
| xnox | smoser: the proposed change seems to use oauth authentication reject messages as a "faked" ntp server. | 14:14 |
| xnox | smoser: can the maas server start and advertise ntp on the network? | 14:15 |
| === Tonio__ is now known as Tonio_aw | ||
| === Tonio_aw is now known as Tonio__ | ||
| smoser | xnox, you are correct in your assesment. | 14:20 |
| xnox | smoser: but I take it you still want SRU instead of starting ntp server?! =) | 14:21 |
| smoser | in order to insert ntp, we'd have to do one of 2 things: have the local maas mount and modify the ephemeral amage (it does not do that at this point). pass the ntp image into the image someway, kernel cmdline could be used. | 14:21 |
| smoser | xnox, yes. | 14:21 |
| smoser | the code in question will not be negatively affected if the system has a reasonable clock. | 14:22 |
| xnox | smoser: /me thought that dhcp advertises ntp and all well-behaved ubuntu's should pick that up on boot with no special changes. | 14:22 |
| smoser | how is it advertised? avahi? i'm not sure. | 14:22 |
| xnox | smoser: good point. /me goes to check my facts. | 14:22 |
| smoser | personally, when i went looking at that path, it seemed to me that ntp on ifup seems problematic. | 14:23 |
| smoser | as there are things possibly running at that point that get pissed off by jump forward or back of system clock. | 14:23 |
| smoser | one such thing is other dhcp/ifup events. | 14:23 |
| smoser | especially in the jump backwards case, it seems that this scenario is a problem: | 14:24 |
| smoser | * system up with eth0 and eth1 devices | 14:24 |
| smoser | * eth1 and eth2 come up and start dhcp | 14:24 |
| smoser | sed s,eth1,eth0, s,eth2,eth1, | 14:25 |
| smoser | * eth0 comes up, calls ntp, sets clock backwards 3 hours | 14:25 |
| smoser | * eth1's dhcp never gets a dhcp response, but sits waiting 3 hours + its expected wait of 120 seconds. | 14:26 |
| pitti | tseliot: oh, there is, the individual reports have dependency versions | 14:26 |
| smoser | * this blocks 'static-networking-up' | 14:26 |
| smoser | well, the cae of static-netw0rking-up is probalby incorrect, as you shouldn't have had eth1 configured for dhcp if it asn't going to get an address. but it seems like a broken path to me. | 14:27 |
| smoser | and other things are actually running when ntpdate is run. | 14:27 |
| smoser | xnox, have i evaluated that incorrectly (its entirely possible) | 14:27 |
| tseliot | pitti: is it just me who can't see nvidia-common here? https://errors.ubuntu.com/oops/00023a60-24c9-11e2-b817-e4115b0f8a4a | 14:28 |
| xnox | smoser: =/ yeah. Internets tell me that in your dhcp server it should be possible to specify the ip of the ntp-server that clients subsequently should use. | 14:28 |
| xnox | smoser: not sure which dhcp server you are using though. | 14:28 |
| smoser | xnox, we could add a kernel cmdline parameter for this. and have ntp* just respect it. | 14:29 |
| pitti | tseliot: hm, it seems nvidia-common isn't a dependency of jockey-common | 14:29 |
| xnox | smoser: so my proposed "advertising" method is via dhcp, which worked good enough for my network setup (synchronising dmz modems with internal network) | 14:29 |
| smoser | but again, the work around we have actually works, requires no additional services, and still plays well with others. | 14:29 |
| xnox | smoser: well, with dhcp advertising you shouldn't need a kernel cmdline option & it should already be supported out of the box. | 14:29 |
| smoser | i'm confused. | 14:30 |
| xnox | smoser: sure. i think SRU is a good quick fix for this. But there will be other services wanting synchronised clock across nodes. | 14:30 |
| xnox | smoser: ok, maybe I am confused how MAAS works. | 14:30 |
| smoser | xnox, this is only a problem in "ephemeral" environment. its used for "boot and enlist" or "commission" of a node. | 14:31 |
| smoser | its iscsi read-only root. | 14:31 |
| xnox | smoser: you have an offline node boot -> get dhcp ip address -> talk to maas server <-> enlist with each other. | 14:31 |
| smoser | when the system is actually installed, the installer sets the correct clock to hardware and can install ntp properly then. | 14:31 |
| xnox | ah. | 14:31 |
| smoser | enlist with maas server. | 14:31 |
| xnox | use any hacks you want at that time then =))))) | 14:31 |
| smoser | xnox, and i'm pretty sure there is no auto-discovery of ntpdate setting on ifup | 14:32 |
| xnox | since it literary does not matter =) | 14:32 |
| smoser | i'm looking at /etc/network/if-up.d/ntpdate | 14:32 |
| xnox | smoser: ok. I'll go and test ntpdate update. Cause i was certain it used to work.... | 14:32 |
| smoser | xnox, it may work for ntpd, but i'm talking about ntpdate | 14:33 |
| smoser | and generally, i do think that lots of things are going to fall apart on an ifup that sets the clock backwards. | 14:33 |
| smoser | (separate issue entirely) | 14:33 |
| xnox | ack. | 14:34 |
| === slank_away is now known as slank | ||
| smoser | xnox, but thank you for looking at my SRU | 14:35 |
| smoser | and spending enough time to understand the problem on it. | 14:35 |
| xnox | smoser: it seems like something is suppose to autogenerate /var/lib/ntp/ntp.conf.dhcp (which should probably live in /run) to pick up & try ntp servers from local network..... lp suggests there are bugs about this. | 14:36 |
| smoser | right. | 14:37 |
| smoser | that was my suspicion also. | 14:37 |
| xnox | *sad times* =/ | 14:37 |
| smoser | but it seems racy | 14:37 |
| smoser | ie, how long do you wait? | 14:37 |
| smoser | for the finding of the advertised thing. | 14:38 |
| xnox | well, ofcourse it's racy since we are changing the time reference :P | 14:38 |
| smoser | waiting longer time blocks this ntpdate till later in the boot when it is more detrimental | 14:38 |
| smoser | waiting shorter means you may miss it. | 14:38 |
| smoser | in addition to possibly setting the clock backwards :) | 14:38 |
| xnox | =/ while 1; do ntupdate && try-enlist-maas && break; done; loz | 14:39 |
| xnox | lolz =) | 14:39 |
| tseliot | pitti: would it be ok if I wrote a small test for nvidia-common where I only faked an nvidia card which requires nvidia-experimental-304 and look for that ValueError exception? I can't think of any other way to prove that my code works other than running it myself | 14:57 |
| pitti | tseliot: oh, sure; /usr/share/ubuntu-drivers-common/fake-devices-wrapper already does something like that, feel free to add/modify that one | 14:58 |
| tseliot | pitti but isn't the problem in precise? | 14:58 |
| pitti | tseliot: that script ought to work in precise | 14:59 |
| pitti | tseliot: I've also seen plenty of reports from oneiric and quantal | 14:59 |
| pitti | I guess it was triggered by the new driver packages, we just didn't expect the new schema back then | 14:59 |
| tseliot | pitti: I can add a test in both nvidia-common and ubuntu-drivers-common if you want. I only have to do something like this: http://paste.ubuntu.com/1423312/ | 15:01 |
| pitti | tseliot: I guess a faked /sys is more elegant, as otherwise you'd overwrite the very class you are testing | 15:03 |
| pitti | tseliot: but anyway, if it was fixed very recently, it's probably okay; but I wondered why they were still so frequent | 15:03 |
| mhall119 | didrocks: I'll ask in here, for the Ubuntu Accomplishments daemon, it's currently using a cron script and PID file to keep itself alive. Rafal was trying to get it to start on demand as a dbus service, but is having problems getting that working. Would it be an issue submitting it to Universe using the cron method? | 15:05 |
| didrocks | mhall119: it's a system-wide service? | 15:05 |
| mhall119 | no, user-session | 15:05 |
| didrocks | should be just a dbus job with a .service file rather then :/ | 15:06 |
| mhall119 | I know, but he's not been able to get it working that way yet | 15:06 |
| didrocks | needing some help to look at what's wrong? | 15:06 |
| tseliot | pitti: honestly I have no idea. I'll explore the fakesysfs way as it could be useful to add more tests in the future for both packages | 15:06 |
| mhall119 | didrocks: if you could, that would be fantastic | 15:06 |
| didrocks | (I don't commit right now, but I would prefer we do it right ;)) | 15:06 |
| didrocks | yep | 15:06 |
| didrocks | ping me EOW about it | 15:07 |
| didrocks | I'll give it a look | 15:07 |
| mhall119 | didrocks: thanks, I suspect it's just an issue of not being familiar with dbus | 15:07 |
| pitti | tseliot: so e. g. in quantal/raring you can run /usr/share/ubuntu-drivers-common/fake-devices-wrapper software-properties-gtk, or f-d-w ubuntu-drivers debug, etc. | 15:07 |
| didrocks | mhall119: probably :) | 15:07 |
| mhall119 | it's very easy to not be familiar with dbus :) | 15:07 |
| didrocks | heh | 15:07 |
| tseliot | pitti: right but that's not something I can include in u-d-c's tests directory, is it? | 15:08 |
| pitti | tseliot: it's shipped by u-d-c | 15:12 |
| pitti | tseliot: tests/ubuntu_drivers.py also uses fakesys.py (the same module) | 15:12 |
| pitti | tseliot: same for the autopkgtest in debian/tests/system | 15:13 |
| tseliot | pitti: right, I'll use fakesys.py in u-d-c and include fakesys.py in n-c | 15:15 |
| === barry` is now known as barry_ | ||
| === barry_ is now known as barry | ||
| pitti | ScottK: hey, how are you? | 15:32 |
| ScottK | Hey pitti. Not bad. | 15:32 |
| pitti | ScottK: would you want to review the new round of psql microreleases? (just standard MRE) | 15:32 |
| ScottK | Possibly later today. | 15:32 |
| pitti | ScottK: thanks | 15:33 |
| pitti | (it seems we need to ping around for SRUs these days) | 15:33 |
| ScottK | Yeah. | 15:33 |
| jamespage | ScottK, promise to look at that problem in the next 30 mins | 15:40 |
| ScottK | jamespage: Great. Thanks. | 15:40 |
| === bdmurray_ is now known as bdmurray | ||
| === dholbach_ is now known as dholbach | ||
| bdmurray | ev: your whoopsie-daisy ppa does not have pycassa for quantal | 16:00 |
| ev | bdmurray: I'm moving everything over to daisy-pluckers' PPA | 16:01 |
| ev | which has the latest and greatest pycassa | 16:01 |
| bdmurray | okay, great | 16:01 |
| ev | let me know if you have issues with it - I want to get that deployed on production very soon | 16:01 |
| pitti | hey ev, how are you | 16:01 |
| ev | hi pitti! | 16:01 |
| ev | I'm good, how's you? | 16:01 |
| pitti | I'm great, thanks | 16:02 |
| pitti | ev: quite happy that apport likes arm now :) | 16:02 |
| ev | yay | 16:03 |
| pitti | ev: I'll soon work on getting that into daisy, too | 16:04 |
| ev | pitti: excellent! Thank you | 16:04 |
| pitti | ev: but that needs a newer apport version; I believe you have packages for that instead of running from trunk, right? | 16:04 |
| ev | yes | 16:04 |
| pitti | ev: OOI, do the packages carry anything that isn't in trunk which we'd need? | 16:05 |
| ev | there's one in my whoopsie-daisy ppa, but I'm trying to move all that stuff over to daisy-pluckers/daisy-seeds | 16:05 |
| ev | I'll have a quick look | 16:05 |
| ev | one moment | 16:05 |
| pitti | (like the generic hooks from the ubuntu branch, but they sholdn't be necessary for retracing) | 16:05 |
| pitti | ev: i. e. could we potentially move this from using the packages to checking out the latest tagged release from bzr? | 16:06 |
| ev | pitti: probably, yes. The code change would need to be made in the daisy-retracer charm and in lp:canonical-memento modules/whoopsiedaisy | 16:06 |
| ev | pitti: no, the version in my ppa doesn't carry anything special | 16:09 |
| pitti | ev: ok; I haven't looked at the memento bits yet, but I'll test all this in Juju first | 16:10 |
| ev | okay | 16:11 |
| ev | thanks | 16:11 |
| jamespage | ScottK, it looks like it ran out of heap space - have you already tried rebuilding? | 16:11 |
| ScottK | jamespage: Yes. | 16:11 |
| ScottK | It built before though. | 16:11 |
| jamespage | ScottK, OK _ I'm just creating a raring schroot to test this in | 16:11 |
| ScottK | Thanks. | 16:11 |
| ev | the U1 guys pointed me at how to mock out SSO auth, so I'm trying to get that landed while I fix 1087361 | 16:11 |
| bdmurray | ev: on the tube you mentioned watching database load when querying it... | 16:13 |
| ev | oh yes | 16:14 |
| ev | nodetool tpstats | 16:14 |
| ev | bdmurray: hit ctrl-R on jumbee and type nodetool | 16:14 |
| ev | also watch top | 16:14 |
| ev | bdmurray, pitti: fwiw, I'm working on formalising our discussions in https://wiki.ubuntu.com/ErrorTracker/ServerSideHooks and https://wiki.ubuntu.com/ErrorTracker/PhasedUpdates | 16:22 |
| === tlyu_ is now known as tlyu | ||
| bdrung | dholbach: is there a timeframe for the hackfest? | 16:34 |
| ev | bdmurray, pitti: I think cleaning up the stack traces is going to be as simple as: http://paste.ubuntu.com/1423516/ . Results in: http://paste.ubuntu.com/1423521/ | 16:56 |
| === deryck is now known as deryck[lunch] | ||
| slangasek | pitti: 1088428> very nice :) | 17:07 |
| slangasek | smoser: "completely offline"> yeah, I suspected that might have been the case. I'm not altogether comfortable with piggy-backing on oauth for clock syncing, but that's no reason for me to block it | 17:08 |
| smoser | slangasek, well, in this case, the clock that *matters* is the oauth clock | 17:08 |
| slangasek | yes, I understand | 17:09 |
| smoser | ie, if there were ntp and the client was good but the server was off, then this fixes that case too :) | 17:09 |
| smoser | but yes, "have good clocks" makes more sense. | 17:09 |
| === asac` is now known as asac | ||
| === ssweeny is now known as AndroUser | ||
| jamespage | ScottK, not getting very far I'm afraid - the error is coming from somewhere in the depths of scilab | 17:39 |
| ScottK | Ohh. Fun. | 17:40 |
| jtaylor | I think fftw3 needs to be kicked into raring | 17:42 |
| jtaylor | excuses look fine but it doesn't migrate :( | 17:42 |
| cjwatson | excuses is just the first stage | 17:44 |
| cjwatson | * i386: libaudiomask-dev, libaudiomask1, mffm-fftw-dev, mffm-fftw1 | 17:45 |
| cjwatson | ^- new uninstallables when attempting to promote fftw3 | 17:45 |
| cjwatson | that's from update_output | 17:46 |
| jtaylor | arg | 17:47 |
| jtaylor | why does apt-cache rdepends not work on provides ._. | 17:47 |
| cjwatson | Looks like libfftw3-3 dropped its Provides: fftw3 | 17:48 |
| jtaylor | ayes I though nobody needs it | 17:48 |
| cjwatson | grep-dctrl and friends are more reliable | 17:49 |
| jtaylor | good that we have this proposed now | 17:51 |
| jtaylor | very useful | 17:51 |
| achiang | infinity: hi, you about? just wanted to followup re: valgrind | 17:56 |
| infinity | achiang: I haven't poked valgrind yet. | 17:56 |
| achiang | infinity: is it something i might take a shot at, both to learn and also to offload you? | 17:57 |
| achiang | or is it best left to wizards as yourself? :) | 17:57 |
| === deryck[lunch] is now known as deryck | ||
| infinity | achiang: If all you want is your patches in, that could be trivially done. It was the new upstream merge I was going to poke at, which could be a bit more effort, but if you want to, I won't stop you. :P | 17:58 |
| infinity | achiang: I just didn't find "spare hacking time" on the weekend to care much. | 17:58 |
| achiang | infinity: re: upstream merge, that would be grabbing valgrind out of unstable, seeing what ubuntu patches need either merging or dropping, then ... a debdiff? | 17:59 |
| infinity | achiang: s/unstable/experimental/ but, yes. Minus the debdiff part. It'll be huge and unwieldly. A full source package is saner. | 18:00 |
| achiang | where can i upload that for review as a member of the ubuntu peon group? (aka not motu or coredev or anyone with upload rights to anywhere, really...) | 18:01 |
| infinity | achiang: Officially, there's revu. | 18:02 |
| infinity | achiang: Unofficially, you could just put it $somewhere, and point someone (like me) at it for review. | 18:02 |
| achiang | infinity: ok, wfm. not sure if i can find spare hours today but i'll try | 18:03 |
| === mcclurmc is now known as mcclurmc_away | ||
| === AndroUser is now known as ssweeny | ||
| freedomrun | hello. where is status bar on the bottom of nautilus in 13.04??! | 18:07 |
| xnox | freedomrun: this is development channel. Support is at -> #ubuntu | 18:17 |
| Laney | J | 18:18 |
| xnox | ? | 18:18 |
| Laney | typo | 18:18 |
| xnox | ack | 18:18 |
| Laney | 13.04 -> #ubuntu+1 | 18:18 |
| xnox | meh, nautilus did not change between the two =) | 18:18 |
| freedomrun | xnox, yeah I know that was exactly why I asked here | 18:19 |
| Laney | suuuure, not at all | 18:19 |
| freedomrun | if someone know devs shurely does | 18:19 |
| freedomrun | Laney, xnox thnx | 18:20 |
| slangasek | smoser: I'm uncomfortable with the fix for bug #974509. You're picking a random, 32-character alphanum string; looking it up *with* the DNS search path; and if it's resolvable, adding that address to the blacklist. While the odds of this ever actually biting you due to a collision with a real hostname that resolves to a real IP that you care about, AFAICS this is a wrong change | 18:43 |
| ubottu | Launchpad bug 974509 in cloud-init (Ubuntu Precise) "cloud-init selects wrong mirror with dns server redirection" [Medium,Triaged] https://launchpad.net/bugs/974509 | 18:43 |
| smoser | slangasek, looking | 18:45 |
| slangasek | ok | 18:45 |
| slangasek | er, also insert an "are quite small" in there somewhere | 18:45 |
| slangasek | smoser: anyway, the risk here is so very small that I won't insist on the SRU being reuploaded; but I think this should be fixed right in the long term (and on trunk) | 18:46 |
| smoser | slangasek, well, in addition to that 32 char random string being resolvable | 18:46 |
| smoser | it also has to resolve to the same thing that the lookup was doing | 18:47 |
| === Ursinha is now known as Ursinha-afk | ||
| slangasek | smoser: yes. so the chance of a collision with a real name that happens to point to the same IP is small, but real | 18:47 |
| smoser | the users of 'is_resolvable' is really limited in this case (mostly to looking for mirrors) | 18:47 |
| slangasek | smoser: is there a plausible scenario where $random resolves to a dns redirector, but neither does-not-exist.example.com. nor example.invalid. does? | 18:48 |
| smoser | i played with a few different (publically available) dns servers. | 18:49 |
| smoser | many dns servers that do this are not available unless you're on their network. | 18:49 |
| smoser | but i think that i decided for the 32 char randomness to work around one that i actually found. | 18:49 |
| === henrix is now known as henrix_ | ||
| smoser | slangasek, so i dont have a really good answer to "why specifically search for random". | 18:52 |
| slangasek | smoser: ok. so I predict that at some point in the future, someone somewhere is going to have an inexplicable provisioning failure because of this. :) | 18:52 |
| slangasek | smoser: cloud scaling + murphy's law | 18:53 |
| slangasek | smoser: but if you don't know why it was added, I guess it's hard to argue that it can be safely removed | 18:53 |
| === henrix_ is now known as henrix | ||
| === Ursinha-afk is now known as Ursinha | ||
| smoser | slangasek, http://paste.ubuntu.com/1423782/ | 18:57 |
| smoser | hm.. so i guess that isn't complet info. | 18:57 |
| slangasek | that looks like a server that would not require the $random | 18:58 |
| smoser | right. | 18:58 |
| smoser | so that earthlink dns server redirects those 2. | 18:59 |
| smoser | opendns (at least when i wrote this) did not redirect example.invalid | 18:59 |
| slangasek | sure, but as long as it redirects *either* of them, that gives you the info you need | 19:00 |
| slangasek | smoser: anyway, this isn't a critical issue... I could file a bug report about it if you want, and leave it at that? | 19:01 |
| smoser | right. so i dont have a definitive example, but i assume that i guessed that if some hosts give 404 for .invalid, then other scould give for both .invalid and .example.com. | 19:01 |
| smoser | but clearly none of this is definitive as anyone can change their implementation server side at any point. | 19:02 |
| smoser | please file a bug if you're ok with that, and i'll at least try to justify better why it is as it is. | 19:02 |
| slangasek | smoser: will do, thanks | 19:07 |
| slangasek | smoser: bug #1088611 | 19:18 |
| ubottu | Launchpad bug 1088611 in cloud-init (Ubuntu) "using random hostnames to detect dns proxies allows for false positives" [Undecided,New] https://launchpad.net/bugs/1088611 | 19:18 |
| ricotz | infinity, hi, are you "responsible" for the armhf ppa chroots? there is a problem while setting up libgtk2.0-0:armhf/libgtk-3-0:armhf as you can see here https://launchpad.net/~ajf/+archive/trg/+build/4053496 | 19:21 |
| gladk | Hi all, will the packages be automatically synced from Debian for Raring, or not? | 19:23 |
| infinity | ricotz: That has nothing to do with the chroot. | 19:27 |
| infinity | ricotz: Anyhow, bouncing the build to see if it happens again. If it does, what you have there is a qemu bug, and not much I can do about it. | 19:28 |
| infinity | ricotz: Nope, looks like the same issue. | 19:36 |
| infinity | slangasek: qemu sucks, it's all your fault somehow: https://launchpad.net/~ajf/+archive/trg/+build/4053496 | 19:36 |
| tumbleweed | gladk: they are, unless Ubuntu has modified them. Why do you ask? | 19:39 |
| mterry | zul, hello! I see your steveador mir. You just uploaded a version that uses tests but doesn't fail on them? | 19:46 |
| zul | mterry: yeah still working on them | 19:47 |
| mterry | zul, OK. I'll leave that MIR alone for now | 19:47 |
| mterry | thanks | 19:47 |
| ricotz | infinity, ok, it works locally here with the raring qemu version | 19:48 |
| ricotz | infinity, so maybe there is a way to update it since as the error messages says qemu is a bit older there | 19:49 |
| ricotz | meaning the actual server which those builders run on | 19:50 |
| slangasek | infinity: are we sure that the setting to make qemu be happy with address spacing didn't come unstuck? | 19:50 |
| infinity | slangasek: I have no idea. I've had zero involvement with the qemu PPAs, except for reviewing Spads' patches to lp-buildd long ago. | 19:51 |
| slangasek | ok, let's blame Spads then :) | 19:52 |
| infinity | slangasek: I'd concur that perhaps backporting raring's qemu to precise-cat might be an awful plan, though. I've seen a lot fewer random and weird crashes with it. | 19:52 |
| infinity | elmo: Any opinions on a qemu backport to precise-cat for the "virtual" ARM buildds? | 19:53 |
| slangasek | ricotz, infinity: fwiw I can confirm that this isn't reproducible with the raring qemu, but is with the precise version | 19:56 |
| slangasek | (slightly different output, I get a segfault rather than the shown error message; but same issue) | 19:57 |
| infinity | I figured as much. | 19:57 |
| infinity | I think I'll go kill that build to free up the buildd now. | 19:58 |
| elmo | infinity: precise; funny guy | 19:58 |
| infinity | elmo: Well, the version it's reporting appears to be the precise one. | 19:58 |
| infinity | elmo: Is that already a backport of precise's qemu to hardy? :P | 19:58 |
| elmo | yes | 19:59 |
| infinity | Check. | 19:59 |
| infinity | Then more backporting seems simple enough. :) | 19:59 |
| ricotz | infinity, this "lock up" is/will get pretty common now with more ppas using armhf | 19:59 |
| ricotz | if it is easy to backport that would be great | 20:00 |
| infinity | ricotz: Yeah, I know. | 20:00 |
| elmo | infinity: hmm | 20:00 |
| elmo | lamont: ^-- sanity check? | 20:00 |
| infinity | Those three words are slightly odd together on that line. | 20:00 |
| lamont | looking | 20:00 |
| slangasek | infinity: only the punctuation is odd | 20:00 |
| infinity | slangasek: Zing. | 20:01 |
| slangasek | a "lamont sanity check" sounds like something that probably has its own medical billing code | 20:01 |
| lamont | our current version is 1.0.50-2012.03-0ubuntu1~ppa10.04.1~0.IS.8.04.0 | 20:02 |
| elmo | (because I don't see a modern qemu in hardy-cat, but the xen guests are definitely hardy (not sure why, they could be anything) | 20:02 |
| lamont | if that sheds any light | 20:02 |
| infinity | elmo: Would be qemu-linaro. | 20:02 |
| xnox | slangasek: smoser: the way we do this with ubiquity is wget http://start.ubuntu.com/connectivity-check.html and check that checksum matches. | 20:02 |
| elmo | infinity: aha, that's why | 20:02 |
| lamont | elmo: hardy-cat-buildd | 20:02 |
| gladk | tumbleweed: geant321 was uploaded to Debian, which fixes also bug in Ubuntu | 20:02 |
| xnox | slangasek: smoser: this way we detect dhcp redirection, but still can resolve & find out if we can reach internetz. | 20:02 |
| infinity | lamont: Right, so, backporting the quantal version would be ideal. (The raring version is identical, but won't build). | 20:03 |
| infinity | lamont: Well, identical, but won't build, and enables some useless x86 feature you don't care about. | 20:03 |
| xnox | slangasek: smoser: similar approach is done by Windows with it's "limited connectivity check", they go one step further and allow to specify alternative servers/IPs to check against. | 20:03 |
| tumbleweed | gladk: looks like it already synced | 20:03 |
| infinity | elmo: Speaking of "the guests could be anything"... How many cookies do I need to mail to whom to make the Xen guests be precisey? | 20:05 |
| lamont | slangasek: I'm still trying to parse that to decide whether to thank, or lob. :-p | 20:06 |
| infinity | elmo: (Not really related to this qemu thing, where we'd still want the backport, but I'm still on the "I'd like a 3.2 kernel baseline on all buildds" warpath) | 20:06 |
| ricotz | infinity, even an update to lucid would be a nice step ;) | 20:08 |
| infinity | ricotz: Would be a pointless endeavor. | 20:08 |
| ricotz | there are quite some issues with those old hardy kernels building glib | 20:08 |
| slangasek | lamont: ;) | 20:08 |
| ricotz | infinity, ok, just thinking if this greate bump would be too risky | 20:09 |
| infinity | ricotz: All the distro buildds are precise, no risk in making the PPAs match. | 20:09 |
| infinity | (Well, all but adare...) | 20:09 |
| ricotz | infinity, ah, if that is so then this should really be done | 20:10 |
| lamont | infinity: care to propose the backport via a ppa-by-reference? | 20:10 |
| elmo | infinity: I don't think it's a big deal, most of them are airlocked, and those that aren't, it's only a ppa-create change - feel free to RT it | 20:10 |
| elmo | infinity: speaking of which | 20:10 |
| infinity | lamont: As in, you want me to do the backport and give it to you? Can do. | 20:10 |
| infinity | elmo: If the ppa-xen stuff is in a repo I can get at, I'll even write the code. :P | 20:11 |
| ricotz | infinity, btw, is the filesystem-size of the ppa builders adjustable? | 20:13 |
| infinity | ricotz: No. | 20:13 |
| infinity | ricotz: That'll be solved when the PPAs eventuall move to something more cloudy, but for now, you're stuck with what you get. | 20:14 |
| ricotz | so it is not possible to increase them in that process :\ | 20:14 |
| infinity | ricotz: It's a physical limitation on a lot of the hosts. | 20:14 |
| ricotz | i see | 20:14 |
| elmo | infinity: if it's not on LP, I'm happy that we fix that for you | 20:14 |
| infinity | elmo: I would have imagined it was cleverly hidden on adelie or some such, but happy to be proven wrong. I haven't looked at that code since I worked for you. | 20:15 |
| elmo | infinity: most of our new stuff is on LP, albeit under canonical-$(grep -v "'" /usr/share/dict/words | shuf -n1) type names | 20:16 |
| hrw | is upload to ppa broken at the moment? | 20:16 |
| infinity | hrw: Shouldn't be. | 20:17 |
| hrw | Uploading chromium-mali-opengles_0.0+20121110-0ubuntu3.dsc: 550 Requested action not taken: internal server error | 20:17 |
| hrw | next try: Directory to upload to does not exist. | 20:17 |
| hrw | and all next attempts just got stuck at "Uploading to ppa (via ftp to ppa.launchpad.net):" | 20:18 |
| infinity | hrw: Oh, fun. | 20:19 |
| infinity | elmo: RT filed, feel free to bounce it back to me with a "here's the source, hippie, fix it yourself and let us know". | 20:19 |
| infinity | elmo: #57971 | 20:20 |
| === kees_ is now known as kees | ||
| infinity | hrw: thedac is looking into your upload woes. | 20:24 |
| hrw | infinity: thanks a lot | 20:24 |
| hrw | Successfully uploaded packages. | 20:24 |
| hrw | ;) | 20:25 |
| infinity | hrw: \o/ | 20:25 |
| hrw | and armhf build started | 20:26 |
| ricotz | infinity, i hope i didnt distract you from the glibc issue i mentioned ;) | 20:28 |
| infinity | ricotz: What's the urgency on the glibc issue? I'm going to rev to 2.17 over the holidays (which includes the fix), do you desperately need a fixed 2.16 before that?> | 20:28 |
| infinity | ricotz: If so, I'll whip something up this afternoovening. | 20:28 |
| ricotz | infinity, actually i really need | 20:29 |
| infinity | ricotz: Alright. I already had a local branch for a new 2.16 upload, just need to put it through some testing. | 20:29 |
| ricotz | infinity, so if you get to it this would be great | 20:29 |
| ricotz | infinity, thanks! | 20:29 |
| hrw | infinity: it here any announced eta for 2.17? | 20:30 |
| infinity | hrw: Should land before New Year, if nothing goes horribly wrong. | 20:30 |
| hrw | cool | 20:30 |
| infinity | hrw: davidm froze it on Nov 28 (a week earlier than I expected), so release in December seems pretty likely. | 20:31 |
| infinity | hrw: And by davidm, I mean davem. Silly tab completion. | 20:32 |
| hrw | cool | 20:32 |
| hrw | hm. build in ppa failed. but 'debuild -B -aarmhf' locally works. have to reinstall chromebook and check there | 20:34 |
| gladk1 | tumbleweed: yes, really synced. | 20:34 |
| pitti | ev: very nice! as a special case, could we write if a pointer is NULL or not? that should already help in a lot of cases | 20:34 |
| slangasek | xnox: so the problem with using the start.ubuntu.com connectivity check is that in this context we want the "local mirror" handling to work even when there isn't a connection to the public Internet | 20:35 |
| === glebihan__ is now known as glebihan | ||
| xnox | slangasek: I see. In that case, I don't understand what the dns check is for. If there mirror is in place and good (e.g. Release.gpg verifies) use it, if not -> don't use it. | 20:40 |
| * xnox goes to re-read bug & code | 20:40 | |
| === Tonio__ is now known as Tonio_aw | ||
| slangasek | xnox: yeah, good question :) | 20:45 |
| xnox | slangasek: as far as I can see cloud-init is after a usable mirror, and not the game of spot the broken dhcp server. | 20:47 |
| === mwhudson_ is now known as mwhudson | ||
| xnox | slangasek: of course verifying release.gpg is apt-hash-mismatch racy. | 21:05 |
| slangasek | smoser: 1066115> what are the chances that someone has a "generic" cloud config that they're passing around, and they're expecting it to be a no-op for landscape when used with an image that doesn't include landscape-client/ | 21:05 |
| slangasek | xnox: InRelease | 21:05 |
| xnox | slangasek: ack ;-) | 21:07 |
| smoser | slangasek, i woudl say it is pro bably very slim. i suspect not many people are actually using the landscape config stuff. | 21:07 |
| smoser | especially since it was competely broken in 12.04 until the previous SRU | 21:07 |
| smoser | (ie, broken in lts unknown for months.) | 21:08 |
| === roaksoax_ is now known as roaksoax | ||
| cjwatson | slangasek: which reminds me, we could probably actually do InRelease now, for quantal and newer | 21:11 |
| cjwatson | it was blocked on the new key | 21:12 |
| smoser | whoowhoo for InRelease! | 21:13 |
| cjwatson | and it might not even be all that complicated since it should all be in ubuntu-archive-publishing now, not LP ... though I'll need to verify that | 21:13 |
| === robbiew is now known as robbiew-afk | ||
| slangasek | smoser: do you agree however that this is a possible regression for users when applying this SRU? | 21:26 |
| rbasak | cjwatson: \o/ | 21:27 |
| rbasak | cjwatson: I'm hoping to finish the by-hash stuff this cycle too | 21:27 |
| smoser | you're saying in the case where they had were using a cloud-config that had landscape content in it, and they expected it not to install the landscape package. | 21:27 |
| smoser | is that right? | 21:27 |
| rbasak | Not sure how much of it we will be able to get live though, but at least it'll be possible to run a race-free mirror without resigning with InRelease in place | 21:27 |
| smoser | slangasek, ^ | 21:30 |
| slangasek | smoser: yeah | 21:30 |
| slangasek | smoser: such that the user assumes the landscape config will be a no-op on images that don't include landscape, and might be surprised if it suddenly causes landscape to be installed | 21:30 |
| smoser | slangasek, i will agree that it would change behavior in that case. | 21:31 |
| === salem_ is now known as _salem | ||
| === cpg|away is now known as cpg | ||
| ajmitch | stgraber: bother, I missed the TB meeting due to work stuff, did the TB comment on the new ARB voting at some point? I saw it mentioned in a previous meeting that it'd be discussed on the list | 21:48 |
| stgraber | ajmitch: nope, it wasn't brought up, can you maybe send a reminder to our mailing-list? | 21:49 |
| ajmitch | sure | 21:49 |
| ajmitch | followed up in the thread about it from last month | 21:53 |
| stgraber | thanks | 21:53 |
| arges | stgraber, hi. I believe bug 991360 is causing regressions in quantal. What's the best way to file a bug to get this fixed? Should i create a new bug or re-open the old one? | 22:11 |
| ubottu | Launchpad bug 991360 in isc-dhcp (Ubuntu) "isc-dhcp-client does not send hostnames in DHCPv6 by default" [Low,Fix released] https://launchpad.net/bugs/991360 | 22:11 |
| stgraber | arges: new one | 22:12 |
| === sraue_ is now known as sraue | ||
| arges | stgraber, ok | 22:13 |
| micahg | tkamppeter: are you test building before you upload? (a few of your upload with problems today could've been caught with a test build in a clean env) | 22:15 |
| === chiluk is now known as chiluk_away | ||
| === robbiew-afk is now known as robbiew | ||
| tkamppeter | micahg, I did test build cups-pk-helper but without pbuilder, and it needed two new build deps. | 23:05 |
| tkamppeter | micahg, now there is a version which has built. | 23:05 |
| micahg | tkamppeter: right, so pbuilder helps for that stuff, should be the same for the missing python with xbmc | 23:06 |
| tkamppeter | micahg, strange is that the previous version of xbmc built and that xbmc built on the Nexus 7 running Raring. | 23:07 |
| micahg | tkamppeter: sure, the question is will it build in a clean env | 23:08 |
| tkamppeter | micahg, the change is small and has nothing to do with Python, it cannot have introduced a dependency on Python. | 23:08 |
| micahg | tkamppeter: raring changed to require a certain python build dependency that wasn't needed before for some packages (idr specifics) | 23:09 |
| slangasek | tkamppeter: the difference may be that python is no longer part of the minimal package set in raring | 23:09 |
| slangasek | (instead, python3 is) | 23:09 |
| slangasek | so it's possible you've hit a pre-existing build failure | 23:09 |
| achiang | infinity: ouch. last time we appear to have sync'ed valgrind from debian was july 2011 :-/ | 23:09 |
| infinity | achiang: Meh. It doesn't look like a monumental task. | 23:10 |
| infinity | achiang: Just needs a round tuit. | 23:10 |
| achiang | infinity: yeah, i'm still looking for one of those :) | 23:10 |
| cjwatson | slangasek: Even python3 is not Build-Essential nowadays | 23:10 |
| infinity | tkamppeter: I removed python from the chroots where it was (mistakenly) installed, despite not being build-essential. | 23:10 |
| slangasek | cjwatson: ah - good :) | 23:10 |
| cjwatson | Hmm, although python3-minimal is Priority: required for some reason still | 23:11 |
| cjwatson | Anyway, dishwasher more urgent than priority-fettling | 23:11 |
| infinity | cjwatson: Required != Build-Essential, though, unless it gets transitively yanked into the set. | 23:11 |
| cjwatson | Depends whom you ask. debootstrap includes required in all its sets. | 23:12 |
| * slangasek nods | 23:12 | |
| infinity | Yes, but debootstrap's demonstrably not policy compliant. :/ | 23:12 |
| cjwatson | (and has forever) | 23:12 |
| infinity | I'd really like to fix that. | 23:12 |
| cjwatson | Sure, but we could make it closer by dropping python3-minimal from required, since it isn't. | 23:12 |
| infinity | But it'll take some debian-devel bikeshedding probably. | 23:12 |
| infinity | Though, Debian's variant=buildd is lighter than ours anyway. | 23:13 |
| cjwatson | (It won't change any real Ubuntu installation, since python3 is in minimal) | 23:13 |
| infinity | So theirs is slightly closer to compliant. | 23:13 |
| slangasek | infinity: "not policy compliant" - as in, you're asserting that packages should still be required to declare build-dependencies on packages of priority: required that are not pulled in by build-essential? | 23:14 |
| slangasek | I think it'd be better to fix policy, in that case | 23:15 |
| infinity | slangasek: Policy says anything that isn't either Essential or Build-Essential isn't build-essential. | 23:15 |
| slangasek | rather than making maintainers chase bugs that are in no way reproducible outside of an artificially-constructed build environment | 23:15 |
| infinity | slangasek: To be fair, most packages follow this quite well. | 23:15 |
| infinity | slangasek: And if debootstrap --variant=buildd were policy compliant, then it wouldn't be any more artificially constructed than the environment we ask them to test in today. | 23:16 |
| slangasek | I'm just saying that if there are things of Prio: required that we think *should* be at that priority, and build-essential doesn't pull them in, we should fix it so that build-essential *does* pull them in | 23:16 |
| infinity | (Most of required ends up being pulled in transitively by Essential or Build-Essential anyway) | 23:16 |
| slangasek | instead of fixating on making hyper-minimal chroots that make it harder for maintainers to get it right | 23:17 |
| slangasek | (but python, which will almost certainly never be Prio: required in Debian, would be good to have out of that set) | 23:17 |
| infinity | slangasek: The canonical example of this is locales. It exists in some Debian chroots, but not all, and it's definitely a bug to not build-depend on it. I pulled it out of our chroots to catch those bugs. | 23:17 |
| slangasek | sure | 23:18 |
| infinity | slangasek: And it's not so much a fixation for me. I dunno. The BE set isn't ridiculous, by any stretch. It's unfortunate that debootstrap's gotten it wrong for so long, but I don't see why that shouldn't just be fixed. | 23:18 |
| ScottK | FWIW, python*-minimal is not Required in Debian, so no d-devel fettling required to get rid of that. | 23:18 |
| infinity | slangasek: (And, as I said, ours is more bloated than Debian's, so cutting ours back would be a good first step) | 23:18 |
| infinity | ScottK: Yes, we've well established that. :) | 23:19 |
| slangasek | How about getting rid of the python*-minimal packages altogether? That'd be nice | 23:19 |
| ScottK | OK. | 23:19 |
| * ScottK is in favor. | 23:19 | |
| infinity | I'm all for it. Upstream hates them anyway. | 23:19 |
| ScottK | Send doko on vacation for a week ... | 23:19 |
| ScottK | I don't see the point of them anymore. | 23:20 |
| slangasek | I've gotten the impression that doko is attached to them, but I don't understand why... their raison d'être never came to pass | 23:20 |
| ScottK | He is. I don't understand it either. | 23:21 |
| infinity | Honestly, "We never did anything with them" and "upstream can't stand the split and refuses to even acknowlegde it's 'python' until you install the full package" seem like good enough reasons. | 23:21 |
| slangasek | right, my recollection of the compromise included "we promise to never install python-minimal without python, this split is just there so we have something that meets the early-configuration requirements for Essential" | 23:22 |
| ScottK | Which is now OBE. | 23:23 |
| ScottK | (AIUI) | 23:23 |
| slangasek | which means no one can depend on python-minimal without us being in violation of that promise; and it's not essential; so it's a meaningless split | 23:23 |
| === henrix is now known as henrix_ | ||
| infinity | Well, it's one seed change to punt it out of required. All in favor? :P | 23:29 |
| achiang | is python-minimal something that can actually run interesting python programs? | 23:41 |
| jtaylor | define interesting | 23:42 |
| achiang | dunno, how about ubiquity? | 23:43 |
| jtaylor | probably not, but you have most of the stdlib | 23:44 |
| jtaylor | at least the important parts | 23:44 |
| achiang | i mean... if you could get away with just python-minimal for the installation process, then i could see it making sense (just talking what's possible, ignoring the promise for now) | 23:45 |
| infinity | ubiquity wouldn't come close to running with just -minimal. | 23:46 |
| achiang | my team regularly moans about trying to trim 3MB here and there, but we've never tested -minimal to see if we could actually use it for anything | 23:50 |
| === jasoncwarner_ is now known as jasoncwarner | ||
| lifeless | achiang: -minimal isn't useful for anyting :) | 23:51 |
| achiang | yeah, the seed comments always talk about how you can't use it by itself, so that's one we've never really understood. :) | 23:52 |
| lifeless | there was an idea | 23:55 |
| lifeless | back in 2005 | 23:55 |
| lifeless | to use python in early boot | 23:55 |
| lifeless | -minimal was that, just enough python to be able to write python syntax code and have it execute | 23:55 |
| slangasek | lifeless: my understanding was that it was for Essential, not for early boot | 23:59 |
| slangasek | lifeless: if it was for early boot, then that was *completely* the wrong way to do it ;P | 23:59 |
| lifeless | slangasek: it was a long time ago, with anthony baxter in the room in the first UDS in spain. | 23:59 |
| lifeless | I don't think anyone has ever taken advantage of it. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!