=== Sargun_ is now known as Sargun [01:12] sarnold: No always. === a16g_ is now known as a16g === Ursinha is now known as Ursinha-zzz [03:38] stgraber: hey, could you please commit your changes from casper 1.332? (Since there's a documented Vcs-Bzr field, and the importer is balking) [03:43] slangasek: hmm, I don't have those commits around anymore. Anyway, I just updated the packaging branch with a manual import of 1.332 so the content and the tags should be fine now. [03:43] stgraber: ok, thanks [04:46] Good morning [04:52] morning pitti [06:03] smoser: ah, today's cloud images work again (ssh) === tkamppeter_ is now known as tkamppeter === catbus is now known as Guest41706 === racedo` is now known as racedo [07:30] good morning === Adri2000_ is now known as Adri2000 [08:01] LTS desktop packages are supposedly supported for 3y, and server packages for 5y. But that doesn't match what `apt-cache show package | grep Supported` says: [08:01] dpkg -l | awk '/^ii/ { print $2 }' | xargs apt-cache show | grep ^Supported | sort -u [08:01] Supported: 18m [08:01] Supported: 5y [08:01] ==> no "3y" anywhere there, although many packages don't have a "Supported" line in their control file. How can I see for how long a package is supported? [08:07] alkisg: That changed with Precise, everything is 5y [08:07] Thank you StevenK, and I assume the packages that are supported for 18m is just minor bugs... [08:08] I'm not certain of the rules [08:08] I just know that desktop stopped being 3 years and started being 5. [08:09] Thanks, it answers my concerns, the 18m packages are too few to bother with anyway :) [08:10] Maybe they are part of flavors that were not LTS, e.g. lubuntu maintained packages etc [08:14] who's maintaining the vuds scheduling? [08:16] tjaalton, nobody [08:16] tjaalton, track leads and some others have edit access [08:16] tjaalton, but I don't think there is one person responsive for the schedule [08:17] tjaalton, would be easier it you asked what you really want to know ;-) [08:20] tjaalton: for changes, poke one of the track leads [08:24] seb128: the hybrid session got dropped from the schedule since it was mistakenly marked as superseded [08:24] pitti: thanks, who is the track lead? [08:24] tjaalton, I can schedule things [08:25] seb128: oh, cool. well could we have the first slot tomorrow? [08:25] it was originally today at 1800UTC but it was bad for me & tseliot [08:26] no [08:26] http://summit.ubuntu.com/uds-1305/2013-05-15/display [08:26] there is no slot left at this time [08:26] would thursday 15utc in client 2 works for you? [08:27] nope :/ [08:28] oh well, put it back where it was, today 1805-1900 [08:28] tkamppeter, hey, would it be ok if the oprint dialog design session is moved from tomorrow 2pm to thursday 3pm? [08:28] is it ok to lead the session without video? :) [08:29] tjaalton, ^ if that works for Till I can put yours there, otherwise let's do today 18h [08:29] tjaalton, yeah, audio is fine [08:30] seb128: yeah that would be fine [08:30] no, great [08:30] jibel: FTR, run-adt-test -sl works again for saucy, so it really was the openssh issue === ckpringle_ is now known as ckpringle === tkamppeter_ is now known as tkamppeter [08:50] seb128, no problem. [08:50] tkamppeter, thanks [08:51] tjaalton, hybrid is on schedule for tomorrow 2pm utc [08:59] tkamppeter, seb128: woohoo, thanks :) [09:02] yw ;-) === Sp4rKy_ is now known as Sp4rKy === mmrazik is now known as mmrazik|afk [09:47] stgraber: I now added a NM test for hotplugging ethernet (with veth), still works fine [09:48] stgraber: but that's using "ip link add name ethXX type veth peer name vethXX", not your two-command approach [09:48] stgraber: I guess that eliminates the race [10:36] dholbach: ping [10:44] Quintasan, pong [10:46] dholbach: Do you happen to know who can I ask about jobs at Canonical? I'd like to know on what I might actually work on. [10:50] Quintasan, is it about a specific job? [10:51] dholbach: Yeah, software engineer job id 622 [10:51] Quintasan, can you give me a link please? [10:55] uhhh [10:55] dholbach: https://ch.tbe.taleo.net/CH03/ats/careers/requisition.jsp?org=CANONICAL&cws=1&rid=622 [10:55] There you go [10:55] thanks [11:02] Quintasan, I'll find out and get back to you [11:02] dholbach: Thanks! [11:18] How come running "backportpackage -b -u ppa:endre-karlson/virtualization -s raring -d precise openvswitch" doesn't put a package at https://launchpad.net/~endre-karlson/+archive/virtualization ? === MacSlow is now known as MacSlow|lunch [11:26] cjwatson: ? :) [11:36] ekarlso-: what *did* it do? [11:55] ekarlso-: 2013-05-14 11:30:46 INFO Failed to parse changes file '/srv/launchpad.net/ppa-queue/incoming/upload-ftp-20130514-112605-003226/~endre-karlson/virtualization/ubuntu/openvswitch_1.9.0-0ubuntu1~ubuntu12.04.1~ppa1_source.changes': Signing key E4B4AA25FA856267A8267A6A [11:55] FDDCC098A811ECB6 not registered in launchpad. [11:56] ekarlso-: https://help.launchpad.net/Packaging/UploadErrors#The_upload_appears_to_work_but_I_don.27t_get_any_email_about_it === _salem is now known as salem_ === MacSlow|lunch is now known as MacSlow === ev_ is now known as ev === Lutin is now known as Guest31310 === bl4de_ is now known as bl4de === wedgwood_away is now known as wedgwood === mmrazik|afk is now known as mmrazik [12:46] cyphermox_, is it possible to tell what kind of Bluetooth 2.1 pairing a device uses (numeric, alphanumeric, numeric comparison, etc) before trying to pair to it? I.e. is the pairing scheme broadcast along with the device name, or is it revealed only when pairing starts? === josepht_ is now known as josepht [12:59] The coffee at this hotel is good, but the service sucks. ★★☆☆☆ === oSoMoN_ is now known as oSoMoN === Guest61231 is now known as mfisch [13:02] Hey folks! question about SRU. I have prepared a SRU bug 1059544, added a task for the affected Ubuntu release, and uploaded a branch with a fix. I have upload rights for the package. Should I just merge and upload this to -proposed, or do I need approval from e.g. release team? [13:02] bug 1059544 in checkbox (Ubuntu Raring) "checkbox alsa_record_playback should use autoaudiosrc instead of alsasrc" [Undecided,New] https://launchpad.net/bugs/1059544 === mfisch is now known as Guest83719 === achiang` is now known as achiang === dbarth__ is now known as dbarth [13:09] mpt: I'll check and let you know. I'm not sure how pairing works precisely tbh [13:18] cjwatson: I have uploaded my fingerprint for the key === sergiuse1s is now known as sergiusens [13:36] suggestions ? [13:37] nvm :p [13:39] ekarlso-: OK. You'll need to retry the upload after doing that [13:40] ok, thanks :) [13:40] ekarlso-: ... looks like you managed it [13:40] yes :) === mardy_ is now known as mardy [13:47] kenvandine: does the latest signon-ui fix the integration tests for you (it does for me)? [13:47] hi,i want to ask sth on ip header declaration....right channel? [13:47] mardy, i'll check === francisco is now known as Guest83986 [13:51] @pilot in === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sconklin__ === barry` is now known as barry [13:51] wow, guys, I'm trying GoLang...is incredible! [13:55] I glanced at it once, seemed kind of nice [13:59] stgraber: hmm, so I scheduled the language pack refresh session for 1905 UTC today, but I just remembered I have a RL conflict this evening (choir practice), so we can't have two parallel foundations sessions in the last two slots today [14:00] stgraber: would it be inconvenient if I moved it to tomorrow, say 1605 UTC? === dpm_ is now known as dpm-uds [14:01] cjwatson: I don't have anything at 16:05 UTC tomorrow, so fine by me [14:02] stgraber: ok, done === Ursinha-zzz is now known as Ursinha === greyback is now known as greyback|food === mahmoh1 is now known as mahmoh [14:12] cjwatson: are you foundation track lead? [14:14] Mirv: can we sync new qtchooser from debian? in 26-3 they finally added auto-fallback to qt4 versions, which is a very nice feature [14:15] bkerensa: with bdmurray, yes [14:16] what's the number on the y axis (and the one that appears when you hover on the graph) on an errors.u.c detailed page? === ckpringle_ is now known as ckpringle [14:34] smoser: am now. what's up? === rsalveti_ is now known as rsalveti === morphis|away is now known as morphis [14:36] xnox, i sent you mail, and opened a bug and subscribed you. [14:36] generally was a really big PITA because you didn't answer me :) [14:37] smoser: i'm so sorry =) off on vacation. [14:37] * xnox is catching up on irc pings first. === Zic_ is now known as Guest47677 === hrww is now known as hrw === nhandler_ is now known as nhandler === greyback|food is now known as greyback === fabo_ is now known as fabo === catbus is now known as Guest17082 === cody-somerville_ is now known as cody-somerville [15:02] pitti: could you have a look at bug 1179979? [15:02] bug 1179979 in apport (Ubuntu) "symlinks create different python tracebacks" [Undecided,New] https://launchpad.net/bugs/1179979 === blitzkrieg3 is now known as jmleddy [15:08] bdmurray: ah, funny; I had thought that the kernel already resolves duplicates in /proc/self/exe [15:09] oh wait, that's python, so we need to look at the second arg [15:09] bdmurray: right, will fix [15:09] pitti: great, thanks! [15:09] bdmurray: I just did an apport upload some 10 mins ago.. [15:10] I needed ev's help to sort out the difference between the buckets since they looked so similar. ;-) === dannf` is now known as dannf === yofel_ is now known as yofel [15:19] bkerensa: chromium non-maintenance was pre-qengho_ time, not relevant anymore :) [15:20] mitya57: wat [15:20] i have no idea what is qengho? === jasoncwarner__ is now known as jasoncwarner [15:21] s/what/who/ (check the changelog entries) :) [15:21] bkerensa, he's the ubuntu chromium maintainer (and on his channel) [15:22] ah [15:22] well thats great news then === james_w` is now known as james_w [15:26] oh, i missed the start of uds? [15:27] chrisccoulson, yes [15:30] yeah, you missed the decision to switch to mosaic as the default browser [15:30] *shrug* [15:30] ;) [15:30] lol [15:31] i was hoping for lynx. never mind [15:32] w3m-img FTW [15:32] hell yeah [15:33] chrisccoulson: GET. [15:33] heh [15:34] Who needs GET when you have nc? [15:34] (uphill, both ways, in the snow) [15:34] telnet. [15:34] I'd take any of those choices. :) [15:35] wetstring.iso === qengho_ is now known as qengho [15:36] I used to work for a high-performance web server company some of whose customers ... well, let's say they were the sort of people who *really* needed very high performance on lots of static files in 2000, and whose web sites you might not actually want to look at in a real web browser [15:36] our support staff were encouraged to use low-level text-only HTTP clients where appropriate [15:37] cjwatson: hehe :P [15:37] ;) [15:37] Ah... The way the web should have remained... :p === jtechidna is now known as JontheEchidna === infinity1 is now known as infinity === Guest83719 is now known as mfisch === kaleo_ is now known as Kaleo [16:11] greyback, dpm, pitti, mhall119, any of you coming to https://blueprints.launchpad.net/ubuntu/+spec/client-1305-printing-stack-with-mobile-in-mind ? [16:11] seb128: no, I'm in the upgrade testing one [16:11] pitti, ok [16:11] seb128: I have no idea why I'm invited to that! [16:14] greyback, no worry, I asked in case ;-) [16:21] seb128: no, I'm in app dev sessions all day [16:21] mhall119, no worry === blitzkrieg3 is now known as jmleddy [16:43] pitti: did I tell you how awesome the nm tests you're adding are? it's really cool stuff === gridcube_ is now known as GridCube [16:44] lool: :) glad that you like them :) === emma_ is now known as em === mdz` is now known as mdz === vibhav is now known as Guest18875 [17:17] stgraber, pitti: can you mark https://code.launchpad.net/~timo-jyrinki/unity-lens-files/precise.sru.hiddenfiles/+merge/162780 as merged? [17:18] done [17:20] thanks === mmrazik is now known as mmrazik|afk === blitzkrieg3 is now known as jmleddy [17:48] mhall119: are you collecting session videos in some kind of central account or anything? [17:49] cjwatson: no, but they will remain linked on summit [17:50] there was no easy way that we could find last time to put them all in the same place on YouTube [17:50] but Summit is searchable and has session descriptions and links to BPs and Etherpad, so it gives us other features too [17:50] mhall119: ok, so I don't need to do anything special? [17:51] having already filled out the broadcast url [17:51] cjwatson: nope, just end the hangout and that's it [17:51] cool [17:54] cjwatson: last time there was a halfway-coordinated effort to use 'standard' tags on the videos so they could be found later [17:55] cjwatson: #uds, #uds-1305 for starters === Sweetsha1k is now known as Sweetshark === Guest18875 is now known as vibhav === deryck is now known as deryck[lunch] === mmrazik|afk is now known as mmrazik [18:45] ev: Do you know if improved whoopsie-daisy experience on server is on a vUDS topic? === robru_ is now known as robru === deryck[lunch] is now known as deryck [18:57] does anyone know why libtool forces link_all_deplibs to "no"? [18:58] or, in other words, libtool in debian is patched to do that, but why.. [18:59] * Don't add the contents of dependency_libs to the link line when [18:59] linking programs. Closes: #191425, #199423, #238681. [18:59] is I believe the relevant changelog entry [18:59] ah, thanks [19:00] there are several problems with overlinking [19:01] one is performance on startup; another (more serious) is that you get screwed unnecessarily if one of your library deps changes the soname of something it links against [19:01] now you are trying to load libfoo1 and libfoo2 into memory at the same time and hilarity ensues [19:02] now, why this isn't upstream I can't help you with [19:02] right, it's been there for nine years now :) [19:03] does our patched libtool DTRT for static linking, and does it work on non-Linux? [19:03] git/beta version of sssd fails to build and the fedora guys noticed the patch, now thinking how to fix the issue for sssd [19:03] I indeed assume that there are some portability problems [19:03] right, anything that fails to link on Ubuntu as a result of that libtool patch is itself buggy [19:04] they created internally shared libs that various bits link to, they used to be statically linked [19:04] https://lists.fedorahosted.org/pipermail/sssd-devel/2013-May/015053.html [19:05] slangasek: I've got five positive (and zero negative) pieces of feedback for the new udev in my PPA now; is there a chance you could test it on your LVM setup, too? === kentb-out is now known as kentb [19:06] pitti: ah, that reminds me I need to comment about the new network device name [19:06] pitti: hmmm... which one? i can test my non-trivial lvm here as well. [19:06] stgraber: yeah, I guess I'll forward port the old rules generator for the time being, to separate that question from the general update [19:06] xnox: that'd be great -- https://lists.ubuntu.com/archives/ubuntu-devel/2013-May/037084.html [19:06] pitti: not immediately; but as you can see there are lots of others around with LVM in use who should be able to help make sure this is tested before upload :) [19:07] slangasek: hehe [19:08] xnox: there's nothing known-broken there with LVM, but we have a patch which was nontrivial to port, so I'd rather make double sure it's still right [19:13] pitti: even with that patch, I don't think we were watching and using DM_COOKIEs correctly though. As nested LVMs sometimes did not come up for me before. I just check to make sure, my normal servers reboot with the upgrade ;-) [19:14] xnox: yeah, I think we should not kill the udev in the initramfs and start a new one [19:14] it should be possible to start it once in initramfs and just keep it running, as both /dev and /run are already move-mounted into the real system anyway [19:15] if we don't mind the memory penalty of running a process out of the initramfs indefinitely instead of backed by the filesystem [19:16] what is the argument for needing to keep it running from the initramfs? [19:16] I always wondered whether there could be a udevadm control command to tell it to pivot [19:18] slangasek: it seems a bit pointless to stop and restart it, but more importantly, it seems we had some problems with our lvm package that expects some events to never get lost, but shutting down and restarting udev would lose some events [19:19] at least that's how I understood the purpose of that dm-cookies patch [19:26] correct. and one ideally wants the cookies to check which VGs were scanned or not, thus not to "find" the wrong one by accident (in case of nested LVMs, fake-raids etc) [19:30] pitti: yes; and I think the right solution is to get that upstreamed, not to carry a shared library penalty on every system due to processes running from the initramfs [19:30] sure; at this point it's only thinking aloud anyway [19:31] * pitti waves good night === bradm_ is now known as bradm [19:37] barry: sorry! I missed the UDS session [19:37] stgraber: ^ [19:37] was in a meeting :( === pim is now known as ZifZaf [19:40] lifeless: darn. maybe we can set up a time for us to chat [19:41] cjwatson, just saw your scribus merge, is it right to build-depends on a virtual package (libtiff-dev)? some other packages do "libtiff5-dev | libtiff-dev" ... is there one more correct than the other one? [19:41] seb128: Build-depending on virtuals is fine. [19:42] seb128: in ubuntu we transitioned to newer tiff ahead of debian. any should be fine, as long as you choose the better one =) [19:42] xnox, what's the preferred way? [19:42] any = is in real or virtual. [19:42] seb128: yes, it's fine [19:42] seb128: Binary deps are meant to declare a "real" preference, but build-deps have no such policy. === iulian_ is now known as iulian [19:42] seb128: 5 i think. [19:42] seb128: there's only one provider of libtiff-dev at any one time so the distinction is immaterial [19:42] seb128: (And, in Debian, build-deps on virtuals are preferred, as it makes binNMUs easier for transitions, since Debian's buildds don't respect alternate deps, intentionally) [19:43] xnox: no [19:43] I guess we rely on one version only having the provide? [19:43] ok, cjwatson already said that :p [19:43] * xnox is confused. [19:43] xnox: Evidently. ;) [19:44] xnox: Virtual build-deps are the preferred method, so transitions aren't a painful mess. [19:44] I went through quite a few libtiff-dev r-build-deps a couple of releases ago; this ended up being the natural pattern for most of them, but I didn't bother pushing against the flow in cases where the Debian maintainer had decided to be specific [19:44] i see. [19:44] xnox: And alternate build-deps only work in Ubuntu because we hacked sbuild to make it work so we could do the main/universe split, they're explicitly not followed in Debian. [19:44] infinity: that. thanks. === Guest31310 is now known as Lutin [19:45] infinity, what happens if several package provide the virtual? do we get a random version picked on build depending of the position of the moon? [19:45] Though libtiff5-dev | libtiff-dev works in both, as long as you don't mind it never picking other versions in Debian. [19:45] (ie: on a Debian buildd, "libtiff4-dev | libtiff-dev" == "libtiff4-dev") [19:45] infinity: limitation or intention? [19:45] (in debian) [19:45] seb128: You shouldn't use this in cases where several packages provide the virtual, indeed. [19:45] xnox: It's intentional in Debian. [19:45] But I knew what was happening with libtiff-dev. [19:46] sbuild's resolver actually does try to intelligently select in the case of multiple providers, it's not random. [19:46] cjwatson, right, I was wondering because infinity said it's the preferred way for transitions [19:46] In the case of transitions which follow the only-one-package-provides-preferred-virtual pattern. [19:46] seb128: The Debian release team prefers things they can binNMU. Individual library/stack maintainer may know better in specific cases. [19:46] I'd be more cautious about it for others. [19:46] barry: yeah that would be good [19:46] ok, makes sense [19:46] cjwatson, infinity, xnox: thanks ;-) [19:46] stgraber: ^^ [19:47] btw do you know if debian plans to start the libtiff transition soon? [19:47] barry: yep, we can do that [19:47] I suspect it'll start sometime after people are done being grumpy about doko and I doing toolchain transitions. *cough* [19:47] lol [19:49] Debian tends to try to avoid overlapping transitions [19:49] I think there's a decent queue :) [19:49] http://lists.debian.org/debian-release/2013/05/msg00127.html [19:50] seb128: there are 27 planned transitions filed, a few uncoordinated transitions started (even before wheezy release). Oh tiff3 is not out of the debian, ouch. [19:51] well, it's not like the delta was hard to maintain... ;-) === racarr is now known as racarr|lunch === mrpouit is now known as mr_pouit === racarr|lunch is now known as racarr === JanC_test_ is now known as JanC_test [21:02] ugh forgot to include changelog entries from debian with a merge upload. :S easy to do when working with git buildpackage. [21:04] oh, a git user! [21:10] Yes, since Debian uses git to maintain the packaging for the package I was working on, and I maintain the Ubuntu delta in the same repo. [21:10] c === wedgwood is now known as wedgwood_away === francisco is now known as Guest23862 [21:45] stgraber: ive got both bug 859600 and 1094319 in shape for a sponsorship if youve got time [21:45] bug 859600 in gnome-keyring (Ubuntu Precise) "Please convert gnome-keyring to multiarch" [High,In progress] https://launchpad.net/bugs/859600 [21:45] bug 1094319 in gnome-keyring (Ubuntu) "p11-kit: couldn't load module: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: cannot open shared object file: No such file or directory" [Undecided,Fix released] https://launchpad.net/bugs/1094319 [21:48] barry: still about I'm curious about python tracebacks ending in 'ValueError: bad marshal data' [21:52] bdmurray: yeah [21:52] https://errors.ubuntu.com/problem/5b56cf70bb8fe037f020c4a2536d214092cb9823 [21:52] there is an example [21:54] I gather this is due to corrupt .pyc files? [21:54] bdmurray: yeah, gotta be [21:55] I wonder if apport should help out here [21:57] bdmurray: maybe we need a post-installation .pyc checker, but this one is happening in threading which comes with the stdlib. i really should bring this up on debian-python ml [21:57] barry: if you look at http://people.canonical.com/~brian/tmp/phased-updates.html [21:58] every duplicity error for version 0.6.18-0ubuntu3.1 ends in bad marshal data === salem_ is now known as _salem [22:02] bdmurray: looks like they're all in "import threading" too. that's pretty curious [22:02] barry: ? import time, types, re, calendar [22:02] ValueError: bad marshal data (string ref out of range) [22:02] from https://errors.ubuntu.com/problem/550cc32bf32c9dfe4901e6010c000ad39b69d5f4 [22:03] okay, not that one ;) [22:06] actually there are a lot of EOFError's about duplicity too [22:06] https://errors.ubuntu.com/?release=Ubuntu%2012.04&package=duplicity&period=year [22:09] bdmurray: my best guess is that this is a systematic problem with the writing of .pyc files during package installation. even though there's no atomic writes of pycs until python 3.3, i still can't think of a scenario that could cause this to happen. can you do me a favor? can you compile a list of public bugs of this type and send me an email? i'll try to formulate something for debian-python, and perhaps upstream [22:11] barry: public launchpad bugs with ValueError ... bad marshal data and /or EOFError: EOF read where ... [22:11] barry: note that pyc files are handled specially by ubiquity, although I can't imagine how it'd matter [22:11] bdmurray: yes [22:11] barry: okay both it is! [22:11] But just in case these are all during installation [22:11] bdmurray: thanks! [22:12] cjwatson: interesting. what does ubiquity do specially? [22:12] We exclude .pyc files from the live filesystem to save space; ubiquity goes through and calls pycompile and friends a bunch of times to recreate them after installation [22:12] i guess there's no way to know whether the pyc was created at system installation time or via subsequent package installation [22:13] Not easily, though anything that's on the live image and that hasn't been upgraded since installation from a live image would fall into that category [22:13] https://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/scripts/plugininstall.py#L334 [22:13] (configure_python) [22:14] cjwatson: is there any way more than call to configure_python() could run at the same time? [22:15] No, that's all single-threaded/single-process [22:16] * barry wonders how hard it would be to "backport" atomic pyc writing to python 2.7 - can't be backport-no-quotes because it's C in 2.7 and python (importlib) in 3.3 [22:16] Indeed it's only ever called once period [22:16] And it should be strictly after all files from the live image have been copied to disk [22:16] yeah. i can't think of how this could happen in single-threaded/process [22:17] bdmurray: have you ever run across this bug in python3 code? [22:17] (this or any similar?) [22:17] Just worth mentioning in case you wind up down some confusing blind alley and it turns out to be the fault of this code. It may be unrelated === kentb is now known as kentb-out [22:17] cjwatson: thanks [22:18] the big problem of course is that i have no idea how to reproduce this, but i could certainly try a few fresh installs to see if i can trigger the problem [22:18] cjwatson: so ubiquity is possibly a good clue === robru is now known as robru_ === robru_ is now known as robru [22:23] barry: I haven't looked closely but will keep an eye out [22:25] bdmurray: cool. my working hypothesis is that we have a race condition in writing .pyc files under some conditions. py3.3 writes them atomically and so should be immune, but py2.7 does not. if we see this problem with py3.3 then i really have nfc ;) [22:27] barry: I suppose it is possible that ubiquity runs something else as root in parallel with that which might cause python to write the .pyc files on its own [22:27] cjwatson: that could do it [22:28] There *shouldn't* be, and I can't think of an obvious place to start looking [22:28] The only thing being run in the chroot at that point is py_compile.py (etc.) itself [22:28] I think [22:29] But it's perhaps worth some detailed strace investigation at around the point plugininstall.py kicks off (just after "Copying files" finishes) [22:29] @pilot out === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [22:30] cjwatson: actually, i'm looking at the code now. i need to investigate in more detail when dinner isn't ready , but i actually think that 2.7 may open the pyc file O_EXCL|O_CREAT|O_WRONLY|O_TRUNC [22:31] barry: Couldn't this happen pretty much any time you're updating a python module via dpkg and also running some root-owned python process in parallel? [22:31] barry: (Like, I dunno, python-apt) [22:33] barry: Or, as the many errors point to, duplicity, since it's probably cronned as root, and can sometimes trip at just the wrong time (during a package update when the pyc files are briefly missing or being recreated). [22:33] infinity: it could. 3.3's behavior is a bit different than 2.7 here, since it writes the pyc to a pseudo-random file and then atomically renames it into place after successful write. py2.7 doesn't do the atomic rename [22:34] barry: That should be vaguely trivial to knock up a fix for. [22:34] infinity: yes, i think so too [22:35] (slightly less trivial in 2.7 since the import machinery is in C there, but not really that bad i suspect) [22:36] barry: mkstemp(3)? [22:37] a lot of these are upgrades rather than fresh installs [22:37] i'm fairly sure python 2 isn't *hilariously* vulnerable to pyc-writing races [22:37] barry: I'm not inclined to believe this is a harder problem to solve in C than in Python. :) [22:37] infinity: for posix perhaps :) the question is whether we want to try to get a cross platform fix upstream or just hack it into debuntu's version. i'll probably try to chat with a few of the other upstream import machinery experts so we can come to some consensus on the problem and proper fix [22:39] infinity: it's probably not, although the specific algorithm would be different a bit [22:39] barry: A google for "mkstemp win32" gets me http://gitorious.org/git-win32/mainline/blobs/8cfc8e4414bbb568075a948562ebb357cb84b6c3/win32/mkstemp.c [22:39] Or a much longer one in a random pastebin. Heh. [22:40] mwhudson: yeah, it's *probably* true, but not as hardened as 3.3. e.g. 2.7 opens excl|creat but no atomic rename afaict [22:40] infinity: yeah, but it's not like i'm personally ever gonna test it on windows :) [22:40] barry: sure [22:41] Gah, still no armhf porter box? [22:41] Or http://msdn.microsoft.com/en-us/library/t8ex5e91%28VS.80%29.aspx .. [22:41] cjwatson: Need a panda? [22:41] that'd be nice [22:41] as long as it's remotely :) [22:44] cjwatson: shiva.0c3.net [22:45] infinity: Cool, thanks. No schroot? [22:45] how many packages are in ubuntu? [22:45] or in the repositories i should say [22:45] which version, which architecture, and do you mean binary packages or source packages? [22:45] how many for a given version at a time? [22:45] like 13.04 for example [22:45] different answers depending on which version, which is why I'm asking you. [22:46] cjwatson: See /msg [22:46] all x86 etc.. [22:47] can i get a list of all debs in the ubuntu repositories? [22:47] sure, you can grab the Packages files from archive.ubuntu.com/dists/ [22:47] er /ubuntu/dists/ [22:48] 13.04 has 20477 source packages; as for binary packages, amd64 41005 armhf 39953 i386 41054 powerpc 40161 [22:48] argh [22:48] cjwatson: that was quick how did you get those numbers :D [22:49] anyone got some random tips for figuring out why / is being mounted read only? [22:49] goddard: I grepped the Sources and Packages files [22:50] grep-dctrl is good for advanced tricks, but for this it's sufficient to just count matches for ^Package: [22:51] cjwatson: so the software list is stored locally [22:52] apt fetches Packages files in order to work out what to present to you, if that's what you mean, yes [22:53] Though I ran my grep jobs on a machine with the full archive since that was faster than downloading the indices over my ADSL [22:54] cjwatson: still a little fuzzy to me [22:55] cjwatson: and you have a full archive of 13.04? [22:56] I'm an Ubuntu archive administrator ... [22:56] I have *the* full archive :-P [22:56] :) [22:56] But it's all on archive.ubuntu.com [22:56] (You only need the index files for this sort of thing, not the whole enormous site) [22:57] mwhudson: dmesg may have enlightening info. [22:57] mwhudson: Controllers resetting, write/read errors, etc. [22:58] cjwatson: so that is like a few TB? [22:58] cjwatson: and thats btw [22:58] thanks* [22:59] dists/raring/ is 3.5GB, but that's including all the installer images and such in there [22:59] The Packages and Sources files in there are only 73MB [23:00] The whole thing is pretty enormous, sure; I don't want to trash this machine's buffer cache by running du to find out [23:02] infinity: seems to be a less deep problem actually, running mount / -o remount,rw works fine [23:04] mwhudson: That doesn't imply fineness. It just means you've ignored the kernel's attempts to save you from yourself. [23:04] hmm [23:04] mountall: Plymouth command failed [23:04] mountall: Disconnected from Plymouth [23:04] mountall: Skipping mounting / since Plymouth is not available [23:04] Oh, or maybe it never got mounted rw in the first place. [23:06] is there some way of making that more verbose? [23:06] mountall is voodoo to me. I'd suggest slangasek, but he's supposedly not here. [23:06] yeah, so don't suggest me [23:06] (Though the error message implies that plymouth either isn't there, or isn't running... Did you break it somehow?) [23:07] i don't know how this is supposed to work [23:07] is it in the initramfs or in the rootfs? [23:07] That depends. [23:08] this is a 'linaro engineering build' [23:08] mwhudson: that message only appears if it can't connect to plymouth *and* there's an error mounting the root filesystem [23:08] so this is special++ [23:08] If you have a FRAMEBUFFER=y initramfs config (either explicitly or transitively via something like full disk encryption), then plymouth will be in the initrd. [23:09] s/full disk encryption/installation of the 'cryptsetup' package/ [23:09] slangasek: i just love being special [23:09] Or that. [23:09] i doubt that is involved [23:09] mwhudson: If it's an LEB, all bets are off. It might just be broken. :P [23:10] yeah [23:10] this very same image worked last week though :/ [23:10] and if i run mount / -o remount,rw and reboot ... it works [23:10] A new definition of time-based release wherein the release only works one time? [23:11] i still see [23:11] mountall: Plymouth command failed [23:11] mountall: Disconnected from Plymouth [23:11] but not the skipping / one [23:11] * mwhudson brb [23:34] infinity, slangasek: is there some way i can make plymouth and/or mountall super verbose? [23:34] mwhudson: well, from the error messages I infer that you're managing to crash plymouth, so not really [23:35] (and mountall's verbose output is supposed to go *to plymouth*, so no dice there either) [23:35] mwhudson: you can try to run plymouth post-boot and see what you get? [23:35] yay [23:36] root@localhost:~# plymouth --ping [23:36] root@localhost:~# echo $? [23:36]