[01:02] Mirv: It should not go back in. That was the agreement. [02:19] stgraber: hi, I've been told you could maybe give me a hand, grub2 isn't booting W7 it boots kubuntu fine then I installed Ubuntu and still no lucky, the boot-repair tool from what I can tell installed grub1 which then managed to boot Windows but not ubuntu.. the error message is around the web but nobody did have a real fix other than I reinstalled everything and now it works:/ [02:19] and the error is that it says Invalid EFI path when windows is choosen [02:55] so a nice evening random question for anyone who might be about :-) If I want a stupid simple key-value store, is there any reason to look beyond berkeleydb? [03:02] Depends on how much you care about Oracle being the steward of the open source project you're going to depend on. [03:04] dantti, sounds like an existing bug report about grub2 not generating the correct chainloader path on efi systems... i.e. it still tries to do chainloader +1 [03:04] ScottK, indeed.. is there an alternative? [03:04] psusi: yes, that's right it is +1 [03:04] I hadn't really thought much about it. [03:05] I'd just suggest that as a reason to perhaps look beyond it. [03:05] psusi: I tried to change this to sth like boot/efi/microsoft... but didn work (tho I dunno if the path was correct) [03:05] dantti, yea, there's a bug report for that [03:06] ScottK, :-) thanks [03:06] psusi: do you know if there is a workaround? like putting the right path? [03:06] dantti, yea, put the right path ;) [03:09] psusi: ok, I'll try some variants of the path here :) thanks [03:26] ScottK: I'm not deeply concerned about Orable messing up BDB, to be fair. [03:26] ScottK: Or Oracle. :P [03:26] I think so far they haven't, but looking at the trends in mysql and java, I'm not sure how much one should assume that will continue. [03:27] In other news, I figured out why sip4 didn't migrate and fixed it. [03:27] ScottK: Wildly different projects. MySQL already had the dual-license model, Java already had completely closed IP, BDB is, on the other hand, one of the freest of the free. [03:28] ScottK: If they try to mess up BDB in any meaningful fashion we'll all just fork and they can eff off, but it wouldn't be painful like the MySQL/Maria business. [03:28] Right. [03:29] Is LP running slow on updating from Debian? There's a package that was accepted in Debian over 24 hours ago that I still can't sync via LP. [03:30] ScottK: I believe zumbi broke our imports. [03:30] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709118 [03:30] Debian bug 709118 in src:gdb "gdb: truncated Maintainer field" [Serious,Fixed] [03:31] Though, I think wgrant was going to blacklist that gdb version and make it all go again. [03:31] Yes, getting there :) [03:31] mipsel of -2 failed to build [03:31] Nice. [03:31] So did mips. [03:31] So -1 is going to stick around blocking gina for a while [03:32] infinity: mips failed on -1 too [03:32] OK, now I don't feel guilty for manually syncing pyqwt5 so sip4 could migrate. [03:32] It's only mipsel that's regressed from -1 to -2 [03:33] The other package I'm waiting for though is no rush. [03:33] It'll hopefully be working again tonight [03:33] Tonight where? [03:33] Here :) [03:33] So next <12 hours [03:34] "Lunchtime" [03:40] Good morning === mnepton is now known as mneptok === Logan_ is now known as log [05:43] slangasek: ping? [05:44] GunnarHj: hi [05:45] slangasek: Hi, Steve! What about the other tasks at bug 1155327? Are they possibly invalid now? [05:45] bug 1155327 in nvidia-graphics-drivers-304 (Ubuntu Raring) "skype crashed with SIGSEGV in malloc@plt()" [High,Confirmed] https://launchpad.net/bugs/1155327 [05:45] GunnarHj: oh... probably [05:45] (closed them out now) [05:46] or rather, would have if LP hadn't timed out [05:46] slangasek: Ok, you are fast today. :) [05:50] slangasek: I removed the GLib upstream task as well, so now the whole bug report is history. [05:53] ev: FYI, I just fixed apport (-retrace) to actually be able to map files for the target release; before, it was always using Contents.gz for the host release, which led to bad retraces [05:53] ev: so it would be good if you could update apport to current trunk, and apply http://bazaar.launchpad.net/~ubuntu-archive/apport/lp-retracer-config/revision/7 to your retracer config [06:27] good morning === Tonio_ is now known as Tonio_aw [06:35] slangasek: ping? [07:12] cyphermox: hi! Could you please have a look at this whenever you got a spare minute? https://code.launchpad.net/~mardy/qmenumodel/root-index/+merge/164705 [07:19] I need an advocate for the debian NM process.. volunteers? :) (I'm a DM already) [07:22] could someone look at http://launchpad.net/bugs/1172015 . i'm starting to think someone hates sydney [07:22] Launchpad bug 1172015 in ubiquity (Ubuntu) "Sydney timezone is in the wrong location" [Undecided,Confirmed] [07:28] ScottK: I know (appmenu). There's a dispute, not sure how it could be resolved. I quoted the FFe bug text, but I was asked to push it anyhow. For my part I'm neutral, I understand the agreement and also understand the wish to not have regressions (but then why have an agreement in the first place). The QPA plugin is still under work, and there's now a blueprint for it https://blueprints.launchpad.net/appmenu-qt/+spec/qt5-qpa-appmenu [07:29] hopefully it will get completed soon and the patch dropped for good [07:31] the patch does not do other harm but potentially give a wrong impression of a problem solved, while it's not yet [07:37] ScottK, Mirv: I don't have the backlog but I discussed it with didrocks and it doesn't make sense to us to break Ubuntu "just to drop a patch that's not creating any issue", knowing that a proper solution is being worked and that we will drop the patch this cycle anyway [07:37] didrocks, ping [07:38] seb128: +1 [07:38] tvoss: pong [07:41] seb128: yes. it should have been rised during the FFe approval discussion to disagree with the saucy plan. that's the only problem. [07:41] ok [07:41] so not optimal, but here we are [07:41] right [07:42] I also though we would have the QPA by now, but as said, as long as that's happening there is no reason to drop the patch in that upload and break Ubuntu [07:43] yeah, Qt5 is not really used in saucy, and the patch doesn't break anything, so as long as the replacement isn't ready, I don't see why we will break saucy for the sake of breaking it [07:43] then, once touch is in saucy, we can resume the QPA work [07:43] and have something clean [07:43] (help from the kubuntu team is welcomed of course) [07:44] doko: have you seen bug 1182613? [07:44] bug 1182613 in puppet (Ubuntu) "puppet completely broken on saucy" [Undecided,New] https://launchpad.net/bugs/1182613 [07:58] rbasak: oops. [07:59] dep8 tests FTW [07:59] rbasak: rolling distros are hard, when you only test 1% of your functionality ;)* [07:59] * rbasak is waiting on review for a facter merge which adds one for the same issue [08:00] it's much easier for upstreams than for distros. [08:08] rbasak, does puppet support ruby 1.9 at all? [08:10] jamespage: http://docs.puppetlabs.com/guides/platforms.html#ruby-versions [08:10] jamespage: for 3.x, looks like 1.8.7 and 1.9.3 only [08:11] "To the best of our knowledge, these issues were fixed in the second public release of Ruby 1.9.3 (p125), and we are positive they are resolved in p392 (which ships with Fedora 18). Unfortunately, Ubuntu Precise ships with p0 for some reason, and there’s not a lot we can do about it. If you’re using Precise, we recommend using Puppet Enterprise or installing a third-party Ruby package." [08:41] xnox: did you "escalate for someone to poke those builds harder" or should I do that? [08:42] mitya57: well, the second rebuild failed as well. I've been recommended by myself to poke it harder myself on my pandaboard. [08:42] mitya57: briefly discussed on #ubuntu-release last night. [08:42] * mitya57 reads the log [08:44] that was a very brief discussion :) [08:44] I don [08:44] I don't have a pandaboard, but if someone gives an armhf-enabled ppa to me, I could try to debug this [08:52] mitya57: https://dev.launchpad.net/CommunityARMBuilds [09:05] rsalveti: hey Ricardo! Can you please forward http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/udev/saucy/revision/237 to upstream? (bugzilla or systemd-devel@lists.freedesktop.org) [09:09] apw: I'm about to do a systemd upload; should I still wait a bit to include the fix for bug 1100386, or do you reckon that this will take longer? [09:09] bug 1100386 in udev (Ubuntu Raring) "Server installations on VMs fail to reboot after the installations" [High,In progress] https://launchpad.net/bugs/1100386 [09:28] ScottK: $ syncpackage --force cmake ;-)))))) [09:29] pitti, yeah i have that here ... give me 5m, i am struggling with unity, it has lost half my windows [09:30] apw: stop using Windows =) [09:30] xnox, heh ... even restarting it is not sorting its head out, dammit [09:31] Hey all [09:31] anybody here ? apw , cjwatson , infinity ? === ckpringle_ is now known as ckpringle [09:40] How to overcome this error ? => https://launchpadlibrarian.net/140439152/buildlog_ubuntu-raring-i386.linux_3.8.0-21.32ubuntu1~nikth2_FAILEDTOBUILD.txt.gz [09:46] pitti, ok ... finally got unity sorted (logout time) and I have attached the diff to the bug: bug #1100386 (for systemd) [09:46] bug 1100386 in udev (Ubuntu Raring) "Server installations on VMs fail to reboot after the installations" [High,In progress] https://launchpad.net/bugs/1100386 [09:47] NikTh, you are better off coming over to #ubuntu-kernel for these kernel related build issues [09:47] apw: Thanks [09:47] NikTh, ping me when you get there [10:05] apw: great, thanks! (and no hurry, if you need more time then take it) [10:09] pitti, that one should be good to go, tested and the like, though i did mod the changelog to get the bug number right :) [10:10] apw: ack, thanks; uploading now [10:10] pitti, ta === mbiebl_ is now known as mbiebl === ritz_ is now known as ritz|away === pete-woods is now known as pete-woods-lunch === MacSlow is now known as MacSlow|lunch [11:11] geser: Qt takes more than 4 hours to build on armhf (i.e. the 4:4.8.4+dfsg-0ubuntu9 build took 13 hours, 28 minutes, 34.2 seconds) [11:11] (sorry for not noticing your message earlier, I was not online) === dholbach_ is now known as dholbach === gusch is now known as gusch|away [11:47] hello, not sure if this is the correct channel to ask but i packaged an app for raring, i have packaged a new version of it and uploaded to my ppa, i'm not sure what i need to do now [11:55] @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: mdeslaur [11:57] xnox: No. There's one Ubuntu change left. [12:01] yolanda: did you see the postfix autopkgtest failure on i386? that looks curious, is that a bug in python itself? [12:01] seb128: I approved an FFe based on an agreement. If people didn't want to follow the agreement, then that was the time to discuss it. I can't stop anyone from uploading whatever they want, but I can learn the lesson to never, ever agree to such an FFe again. What's the date when the patch can be dropped? [12:01] pitti, no, i didn't see it, can you point me at it? [12:01] ScottK, "when the qpa is ready" [12:02] ScottK, it doesn't make sense to advocate for runtime regressions for users just for the sake of dropping a patch which is creating no issue... [12:02] i.e. maybe never and who cares what we agreed. [12:02] yolanda: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-postfix/1/ARCH=i386,label=adt/ [12:02] ScottK, well, I do care about fixing it properly, but I don't see the point to break users for the sake of making a point [12:02] OK. That's why I asked for when. [12:03] I didn't say I'd try to stop you adding it back. [12:03] good, sorry that the qpa thing is not ready yet [12:04] pitti, let me test them locally again [12:04] ScottK: hm?! [12:04] I think keeping our patches in Qt5 to a minimum and not having them devolve into a unmaintainable mess is an important goal and it has to start now. [12:04] i haven't seen that error before === greyback is now known as greyback|lunch [12:05] ScottK, agreed [12:05] ScottK: after last merge by Riddell, there were two patches left, both are in Debian and filed upstream. [12:05] RAOF: do you plan to package colord 1.0 soon? if so, any chance you can import upstream commit 4c6792 to drop the g_type_init() calls, and add a valgrind test dependency? that's the two issues I see on https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-colord/ [12:05] seb128: I do, however, consider this going back on an agreement and I'll of course consider that when reviewing FFes in the future. [12:06] xnox: OK. I knew about one being in Debian. I didn't check the other. [12:07] ScottK, hum, that's fair enough, I don't think the request made by then was appropriate (e.g "let's accept it but add a clause that we will regress it early next cycle for no good reason if the new work is not ready yet") but that one is done so no point to discuss it now [12:07] Then was the time to discuss it, not now. [12:08] I would be less grumpy about the situation if there was a date beyond "when ready" for dropping this Qt4 forward port. [12:09] well, the guys are working on the QPA support but that's not the only thing they have to work on, and I've no idea how much work that is [12:09] I just know it's being tracked but it's not trivial enough to say "it will be squeezed in an afternoon next week" [12:10] e.g it's going to take some extra time [12:10] Could you ask for an estimate? [12:10] * cjwatson curses at build systems that don't fail immediately === MacSlow|lunch is now known as MacSlow [12:10] pitti, i tested with saucy - amd64 and works locally, let me test with i386 [12:11] yolanda: yes, it succeeds on amd64 in jenkins, too [12:11] ScottK, ok, I will try to get one [12:11] xnox: no, there is also disable_overlay_scrollbars.diff which is not in Debian/upstream [12:13] it is of course an ubuntu-specific hack, and I don't know if there is another way to fix the issue (see i.e. bug 1170384) [12:14] bug 1170384 in qtbase-opensource-src (Ubuntu) "[sna] Xorg crashed with SIGABRT in memcpy_blt() -

when using ReText with Qt5" [High,In progress] https://launchpad.net/bugs/1170384 [12:14] mitya57: are we talking about the same thing? I was discussing cmake package with scottk. [12:14] mitya57: btw. I could give you ssh access to a panda board if you want to poke qt4-x11. [12:15] pm if you are interested. [12:15] xnox: I was talking about: [12:15] I think keeping our patches in Qt5 to a minimum and not having them devolve into a unmaintainable mess is an important goal and it has to start now. [12:15] xnox: not today (I hope it's not urgent) [12:15] ScottK: ^, not me then =) I'm not involved in Qt5 packaging much. [12:16] mitya57: nah. I'll get around to it eventually. [12:17] xnox: btw, do you have any plans to package pyqt5 or do you want me to do that? :)) === pete-woods-lunch is now known as pete-woods [12:18] mitya57: i haven't tried it since before they published qt5 preview snapshot. [12:18] i think i did push my latest trial somewhere to launchpad. [12:19] xnox: ok, I'll look at it next week and let you know if I get any success [12:20] pitti: fyi, I have dep-8 fixes for docutils and pandas in the sponsoring queue [12:21] mitya57: ah, splendid, thanks === _salem is now known as salem_ [12:21] (pandas is not yet failing on jenkins, but it doesn't work with the latest nose) [12:22] there is a good stack of tests work in the sponsoring queue [12:22] we need a patch pilot round from somebody from qa :p [12:22] there are like 10 of those waiting [12:23] pitti, fails for me locally on i386 also [12:23] mitya57: ah, you fixed it in Debian and merged? awesome [12:23] seb128: yeah, I sponsor quite a lot of them (but mostly just if someone pokes me outside of my patch pilot days) [12:23] * pitti looks at these two [12:23] pitti, you are piloting next monday I see ;-) [12:23] pitti: if you speak about nose, then I broke it, not fixed :) [12:24] mitya57: I meant docutils [12:24] pitti: jwilk fixed that [12:25] +XS-Testsuite: autopkgtest [12:25] mitya57: ^ FYI, this is perfectly fine for Debian [12:26] it's part of the DEP8 spec [12:26] mitya57: and dropping pysupport in Debian will certainly get you applauds from doko, too :) [12:26] mitya57: what is debian/x-rst.xml? (that's not mentioned in the remaining delta) [12:27] pitti: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=16;bug=685509 [12:27] pitti, it fails in that regular expression, but looks good to me? child.expect(r'.*[pP]assword', timeout=5) [12:27] yolanda: yeah, hence my suspicion of "bug in python" [12:27] it said "internal error in regex machine" or so [12:27] pitti: oops, x-rst.xml is an old version of docutils.xml, will now remove it [12:27] oh yes: RuntimeError: internal error in regular expression engine [12:28] all the failures are the same [12:33] mitya57: no worries, I can just remove it in the merge [12:34] pitti: already removed it, and fixed the version number [12:34] * pitti pulls again [12:34] mitya57: forgot to push? [12:34] pitti: no, pushed [12:36] pitti: looks like mdeslaur just uploaded pandas fix [12:37] heh, me too [12:37] (thanks!) [12:37] so I guess mdeslaur's will win :) [12:37] oops :) [12:37] mitya57: anyway, thank you! (also uploaded docutils) [12:37] mdeslaur: sorry [12:37] pitti: thanks [12:40] pitti, so what we do with that isuse? [12:40] Riddell: Was kdegames-data going away intentional? Looks like that needs some transition work in saucy-proposed. [12:41] yolanda: I suppose as a first step you should report a bug against python3.3; then, maybe you can find a workaround by slightly altering the RE [12:43] ** gcc version 4.8 found, expected gcc 3.x with x>1 or gcc 4.x with 0 seriously, virtualbox? [12:43] debfx: ^- you might like to have a look at that === greyback|lunch is now known as greyback === dpm_ is now known as dpm-uow === dpm is now known as dpm-laptop === dpm-uow is now known as dpm === gusch|away is now known as gusc [12:54] cjwatson: mm not sure, will look into it thanks [13:11] infinity: I synced libnss-db, although you're touched-it-last; I'm pretty sure that Julien's and my QA uploads cover everything we need between them, but feel free to double-check. [13:26] cjwatson: can you comment on keeping or ditching Architecture line delta to Debian related to powerpc builds? you were mentioned here: http://pastebin.ubuntu.com/5690298/ - we're planning to do uploads/syncs tomorrow [13:27] Mirv: please see the discussion in this channel yesterday [13:27] cjwatson: ok, scrolling back [13:28] But I'll address one thing to make sure it sticks: the assertions that proposed-migration prevents migration of packages with FTBFSes is false. It prevents migration of packages with regressions in the set of builds that worked. [13:28] s/is false/are false/. [13:30] * cjwatson peers at the sweep package. So much ugliness that could just be dh_autoreconf [13:33] cjwatson: thanks, read the discussion [13:34] Mirv, I opened https://bugs.launchpad.net/cupstream2distro/+bug/1182570 on the daily landing tools [13:34] Launchpad bug 1182570 in Canonical Upstream To Distro "Should force publishing if archs-which-were-never-available are depwaiting" [Undecided,New] [13:34] Mirv, didrocks said he would work on it next week I think [13:34] yep [13:36] kenvandine: hi! Did you see my "categories" branch for the SystemSettings? [13:36] (the branch name doesn't match the content very closely, actually :-) ) [13:36] mardy, yes... did you see my comment on it? [13:36] kenvandine: obviously not :-) [13:36] Looks like you forgot to add SystemSettings.pc.in [13:36] :-D [13:37] ops [13:37] mardy, i also pushed a fix for my branch you reviewed [13:37] kenvandine: just approved [13:37] thx [13:38] i'll just merge these to trunk until we get the merger setup for it [13:38] mardy, i'm going to add a settings stack for daily release today [13:38] and get that configured for the merger, etc [13:38] and CI [13:40] kenvandine: looking forward to it! [13:41] cyphermox: hi, thanks for your review. Do you have some names to suggest? [13:42] mardy: not really. people who've done Qt and helped you with QMenuModel before? [13:42] waiting [13:42] mardy: perhaps timo, but he doesn't seem to be around [13:44] NikTh: ask in #ubuntu-kernel, but I think your config file for the kernel you're building is incorrect or not found [13:45] cyphermox: I'm sorry, I just tested some commands on IRC .. to another channel , but the message appeared here too. Sorry. :-) [13:46] cyphermox: Actually I'm waiting but not for an answer here. I'm waiting for building results.. :-) [13:46] mardy, merge conflict now :) [13:47] NikTh: ok [13:48] kenvandine: updated :-) [13:48] thx [13:49] mardy, can you make me an admin of ~system-settings-touch [13:49] i want to setup a PPA for CI builds [13:50] pitti: I didn't forward that patch upstream as it's only relevant when you're booting in an android kernel [13:50] kenvandine: done [13:50] which is what happens only with touch [13:51] mardy, thx [13:51] but I can give it a try === wedgwood_away is now known as wedgwood [13:51] rsalveti: yeah, I don't think it hurts to have that working in udev upstream; thanks! [13:52] seb128: about this blueprint: https://blueprints.launchpad.net/ubuntu/+spec/client-s-touch-system-settings [13:53] seb128: you added one item "[mardy] write the "base shell" app: TODO" [13:53] seb128: isn't that the same as the first item? [14:00] mardy, not part of this merge, but i just noticed some copy and paste noise, like a reference to signon-ui.pot in src.pro [14:02] kenvandine: oh, that might be. I'll check [14:02] mardy, i've merged this branch, just clean that up in your next branch [14:03] kenvandine: OK [14:27] pitti: hey, so I'm definitely loosing ACLs on /dev/snd/* every so often, it's not directly related to suspend/resume but it does happen every few days or so (may be related to some package updates) [14:27] (physical sound card) === ckpringle_ is now known as ckpringle [14:35] pitti: I'm trying to figure out why all our livefs builds are hanging, and it turns out that there's a stray 'udevd --daemon' process running, started a rather suspicious 40 seconds after the start of the build. Do you know what might have regressed here? [14:36] pitti: Specifically, started during debootstrap === francisco is now known as Guest25788 [14:39] pitti: I notice we no longer have the udevadm.upgrade stuff; might that be relevant? [14:42] pitti: This appears to be the same as bug 1182540 [14:42] bug 1182540 in lxc (Ubuntu) "lxc smoke test, test_lxc_apparmor appears to hang on saucy VM" [High,Confirmed] https://launchpad.net/bugs/1182540 [14:53] mardy, yes, seems so, sorry I just dumped the session notes in there and didn't check for duplicates [15:03] mlankhorst: pong [15:04] re [15:04] cjwatson: ah, I didn't really see why disabling udevadm is related to starting/stopping the daemon [15:04] I suspect something else calls udevadm which starts udevd [15:05] cjwatson: so I'll put it back; it's almost certainly due to dropping these bits, yes [15:05] I have an strace but it's gigantic [15:05] I'll use above bug for that [15:05] shouldn't be too hard to reproduce [15:05] just debootstrap and you'll find an extra udevd --daemon process hanging around when you're done [15:06] *nod* === dpm-laptop is now known as dpm [15:07] slangasek: can you accept all the new packages in precise? [15:07] stgraber: does that only affect /dev/snd/*, or other devices as well [15:07] Hm, it actually looks as though it's being started directly [15:07] 11398 write(1, " * Starting the hotplug events dispatcher udevd\n", 48) = 48 [15:08] Why is that touching /etc/init.d/udev ... [15:08] mlankhorst: I don't think I'll have a chance to look at it this morning; maybe SpamapS has some time? [15:08] hm, where does that string come from; doesn't look like /etc/init/udev.conf [15:08] /etc/init.d/udev [15:08] slangasek: friday's fine too, it's been lingering for ages in NEW [15:09] slangasek: definitely not. I'm wrangling contractors today [15:09] Via invoke-rc.d, WTF [15:09] pitti: assuming I should have an ACL on /dev/dri/card0, it affects all devices, though I think sound devices are more visible as pulseaudio appears to close them and reopen rather frequently (whereas the dri devices are kept open) [15:10] cjwatson: hm, I assume we have a policy-rc.d somewhere? [15:10] Ah [15:10] This might be a debootstrap bug [15:10] It has a fake initctl which doesn't respond to initctl version [15:10] Which invoke-rc.d now cares about [15:10] oh, I remember slangasek's mail about that [15:11] So I could make it pass through version and see if that helps [15:12] Something like http://paste.ubuntu.com/5690668/ [15:13] double quoting? [15:13] ah, I guess it's a script that writes a script [15:13] right, nevermind me [15:14] cjwatson: hah, doh [15:15] Wonder what else might have a similar bug [15:16] stgraber: do you still have a running session? ("loginctl show-session") === mmrazik is now known as mmrazik|afk [15:17] debian-installer-utils and ubiquity at least [15:17] With any luck that's the limit of the clone-and-hack [15:17] why is this not done via policy-rc.d? [15:18] It installs a policy-rc.d as well [15:18] I believe this is insurance against policy-violating packages [15:18] Of which there were many more earlier on [15:19] I mean, even openssh was at best skating on very thin policy until this morning [15:19] pitti: http://paste.ubuntu.com/5690694/ [15:20] pitti: loginctl also says "c2 201105 stgraber seat0" so the session is definitely registered [15:20] Yep, that debootstrap change appears to fix it - just testing a bit more and I'll upload [15:20] cjwatson: thanks [15:20] Wonder if gina's unstuck yet [15:21] stgraber: can you check if the devices have TAGS=:uaccess in "udevadm info --export-db|less"? [15:21] pitti: E: TAGS=:seat:uaccess: [15:21] ok [15:21] (looking at /dev/dri/card0 in this case) [15:21] stgraber: do the ACLs come back if you switch to VT1 and back? [15:22] stgraber: you can also try "sudo udevadm trigger --sysname-match=card0 --verbose" [15:23] pitti: hmm, well, interstingly enough I can't switch vt... ctrl+alt+FX won't work and chvt won't either [15:23] stgraber: try the udev trigger? [15:24] pitti: the udevadm trigger didn't help, still no ACL for my user on the device [15:25] pitti: starting to wonder if I somehow hit a kernel bug... stracing chvt I'm seeing "ioctl(3, KDGKBTYPE, 0x7fffbecbf14f) = -1 ENOTTY (Inappropriate ioctl for device)" when trying to do the ioctl against any of /dev/tty, /dev/tty0 or /proc/self/fd/0 [15:26] oh, actually that's wrong, tty0 doesn't give the ENOTTY [15:26] but it doesn't quite work either [15:26] stgraber: otherwise, the output of this might give some insight: [15:26] sudo strace -fvvs1024 udevadm test-builtin uaccess /devices/pci0000:00/0000:00:02.0/drm/card0 [15:26] http://paste.ubuntu.com/5690716/ [15:26] stgraber: the sysfs path probably doesn't match for you, you can look it up in udevadm info --export-db [15:27] stgraber: hm, wait -- I remember that I've seen something like this in otto [15:27] stgraber: i. e. with ACLs in a container [15:27] stgraber: you run your whole desktop in LXC, right? [15:27] pitti: strace => http://paste.ubuntu.com/5690719/ [15:28] slangasek: Ah, though it's true that if we had a policy-rc.d that would have acted as a stopgap. We have that in other stop-daemons-running code but *not* in debootstrap [15:28] pitti: nope, that's a fairly standard desktop machine, I have a container running though but it doesn't have tty access [15:28] So I think I should fix both [15:29] cjwatson: so disabling udevadm during package upgrade wouldn't help at all here, right? (as the daemon is not normally started through udevadm) [15:29] pitti: udevadm needs to be disabled during package upgrade anyway; was that change dropped? [15:29] stgraber: ok, comparing mine to your's, I have getxattr() == 44, then setxattr() == 0, and the writev("unload module index"), your's is missing the setxattr [15:30] right, that confirms it's not even trying to set the ACL, doesn't really tell us why [15:30] slangasek: it wasn't ported over, yes; what's wrong with running udevadm during package upgrade? [15:30] pitti: It's unrelated, but as slangasek says, I believe it's important for packages not to be able to call udevadm during udev package upgrade for the same reason it always was [15:30] Let me dig up Scott's post about it [15:30] yeah, I'm curious why that is [15:30] though I wonder if my messed up VTs could somehow break the code that detects whether I'm at the console or not [15:31] at least info works just fine without udevd [15:31] it just reads /run/udev, it doesn't query the daemon [15:31] pitti: I think that's the wrong question; why would you drop any part of the packaging before knowing why it was there? [15:31] * It is not permitted to call udevadm trigger or settle during an upgrade [15:32] without depending on udev. Attempting this will fail. [15:32] was the specific one [15:32] yes [15:32] well, that's not much of an explanation [15:32] there were lots of upgrade failures because of this [15:32] And info is a complete red herring, because udevadm.upgrade *passed through info calls*! [15:32] and both trigger and settle work fine without udevd [15:32] so that seemed obsolete to me [15:33] I can add it back, but it seems like unnecessary complexity to me [15:33] how can 'trigger' work without udevd? [15:33] This was associated with https://lists.ubuntu.com/archives/ubuntu-devel/2009-January/027260.html [15:33] Although that doesn't really explain it very well either [15:33] slangasek: the trigger operation works fine, but of course rules wouldn't be processed [15:34] slangasek: IIRC trigger just uses /sys/..../uevent to re-emit the uevent === wedgwood is now known as wedgwood_away [15:34] but that's just the same net result as diverting udevadm trigger and saying that it won't work [15:34] So I think Scott was concerned precisely that rules wouldn't be processed, and was trying to force packages to get this right [15:34] Even if udevadm "works" (i.e. exits 0) [15:35] ah, so that's not for *preventing* package installation failures, but for *causing* them to expose problems [15:35] cjwatson: but if 'udevadm trigger' now passes with no effect, how does that enable the caller to retry later? [15:35] so in that regard we could put it back, but if anything that should cause more install failures, not less [15:36] slangasek: indeed I'm arguing that we should put the previous implementation back because it's better to fail than to do the wrong thing [15:36] ah [15:36] the previous implementation failed? [15:36] especially given that this has been intentionally failing for four years, so it's not a hidden source of problems [15:36] oh, right [15:37] if [ "${0##*/}" = "udevtrigger" ] || [ "$1" = "trigger" ]; then [15:37] echo "udevadm trigger is not permitted while udev is unconfigured." 1>&2 [15:37] yes, now I have the right end of the stick [15:37] exit 1 [15:37] fi [15:37] etc. [15:37] yes, so udevadm would be called but we would lose the trigger [15:37] (potentially) === Quintasan_ is now known as Quintasan === gusc is now known as gusch [15:37] seb128, ping [15:37] tvoss, hey [15:37] so I guess what that really wants to say is that udevadm trigger should fail if udevd isn't running [15:38] (udevadm settle, info, monitor, hwdb, test, etc. are all fine) [15:38] pitti: If it causes install failures, we've been seeing those for four years, so they aren't new - it's basically an assertion about the correct design of other packages using udevadm [15:38] The previous implementation explicitly excluded settle as well [15:38] ok [15:38] And doesn't settle also essentially require rules to be in place? [15:39] trigger does (as that will cause re-processing the rules) [15:39] settle just waits for udevd to finish with this, but if there's no udevd, there's nothing to wait for [15:39] Mm, I suppose ... [15:40] anyway, I'll put it back [15:40] right, furthermore I heard 'settle' no longer works upstream [15:40] sorry for the misunderstanding [15:40] if udevd isn't running> provided, basically, that udevd works as if it were Essential and can operate even when the package is unconfigured [15:40]