ScottKMirv: It should not go back in.  That was the agreement.01:02
danttistgraber: 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
danttiand the error is that it says Invalid EFI path when windows is choosen02:19
balloonsso 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?02:55
ScottKDepends on how much you care about Oracle being the steward of the open source project you're going to depend on.03:02
psusidantti, 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 +103:04
balloonsScottK, indeed.. is there an alternative?03:04
danttipsusi: yes, that's right it is +103:04
ScottKI hadn't really thought much about it.03:04
ScottKI'd just suggest that as a reason to perhaps look beyond it.03:05
danttipsusi: I tried to change this to sth like boot/efi/microsoft... but didn work (tho I dunno if the path was correct)03:05
psusidantti, yea, there's a bug report for that03:05
balloonsScottK, :-) thanks03:06
danttipsusi: do you know if there is a workaround? like putting the right path?03:06
psusidantti, yea, put the right path ;)03:06
danttipsusi: ok, I'll try some variants of the path here :) thanks03:09
infinityScottK: I'm not deeply concerned about Orable messing up BDB, to be fair.03:26
infinityScottK: Or Oracle. :P03:26
ScottKI 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:26
ScottKIn other news, I figured out why sip4 didn't migrate and fixed it.03:27
infinityScottK: 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:27
infinityScottK: 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
ScottKIs 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:29
infinityScottK: I believe zumbi broke our imports.03:30
ubottuDebian bug 709118 in src:gdb "gdb: truncated Maintainer field" [Serious,Fixed]03:30
infinityThough, I think wgrant was going to blacklist that gdb version and make it all go again.03:31
wgrantYes, getting there :)03:31
wgrantmipsel of -2 failed to build03:31
infinitySo did mips.03:31
wgrantSo -1 is going to stick around blocking gina for a while03:31
wgrantinfinity: mips failed on -1 too03:32
ScottKOK, now I don't feel guilty for manually syncing pyqwt5 so sip4 could migrate.03:32
wgrantIt's only mipsel that's regressed from -1 to -203:32
ScottKThe other package I'm waiting for though is no rush.03:33
wgrantIt'll hopefully be working again tonight03:33
ScottKTonight where?03:33
wgrantHere :)03:33
wgrantSo next <12 hours03:33
pittiGood morning03:40
=== mnepton is now known as mneptok
=== Logan_ is now known as log
GunnarHjslangasek: ping?05:43
slangasekGunnarHj: hi05:44
GunnarHjslangasek: Hi, Steve! What about the other tasks at bug 1155327? Are they possibly invalid now?05:45
ubottubug 1155327 in nvidia-graphics-drivers-304 (Ubuntu Raring) "skype crashed with SIGSEGV in malloc@plt()" [High,Confirmed] https://launchpad.net/bugs/115532705:45
slangasekGunnarHj: oh... probably05:45
slangasek(closed them out now)05:45
slangasekor rather, would have if LP hadn't timed out05:46
GunnarHjslangasek: Ok, you are fast today. :)05:46
GunnarHjslangasek: I removed the GLib upstream task as well, so now the whole bug report is history.05:50
pittiev: 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 retraces05:53
pittiev: 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 config05:53
dholbachgood morning06:27
=== Tonio_ is now known as Tonio_aw
mlankhorstslangasek: ping?06:35
mardycyphermox: hi! Could you please have a look at this whenever you got a spare minute? https://code.launchpad.net/~mardy/qmenumodel/root-index/+merge/16470507:12
tjaaltonI need an advocate for the debian NM process.. volunteers? :) (I'm a DM already)07:19
Noskcajcould someone look at http://launchpad.net/bugs/1172015 . i'm starting to think someone hates sydney07:22
ubottuLaunchpad bug 1172015 in ubiquity (Ubuntu) "Sydney timezone is in the wrong location" [Undecided,Confirmed]07:22
MirvScottK: 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-appmenu07:28
Mirvhopefully it will get completed soon and the patch dropped for good07:29
Mirvthe patch does not do other harm but potentially give a wrong impression of a problem solved, while it's not yet07:31
seb128ScottK, 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 anyway07:37
tvossdidrocks, ping07:37
didrocksseb128: +107:38
didrockstvoss: pong07:38
Mirvseb128: yes. it should have been rised during the FFe approval discussion to disagree with the saucy plan. that's the only problem.07:41
Mirvso not optimal, but here we are07:41
seb128I 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 Ubuntu07:42
didrocksyeah, 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 it07:43
didrocksthen, once touch is in saucy, we can resume the QPA work07:43
didrocksand have something clean07:43
didrocks(help from the kubuntu team is welcomed of course)07:43
rbasakdoko: have you seen bug 1182613?07:44
ubottubug 1182613 in puppet (Ubuntu) "puppet completely broken on saucy" [Undecided,New] https://launchpad.net/bugs/118261307:44
ttxrbasak: oops.07:58
rbasakdep8 tests FTW07:59
ttxrbasak: 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 issue07:59
ttxit's much easier for upstreams than for distros.08:00
jamespagerbasak, does puppet support ruby 1.9 at all?08:08
rbasakjamespage: http://docs.puppetlabs.com/guides/platforms.html#ruby-versions08:10
rbasakjamespage: for 3.x, looks like 1.8.7 and 1.9.3 only08:10
rbasak"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:11
mitya57xnox: did you "escalate for someone to poke those builds harder" or should I do that?08:41
xnoxmitya57: well, the second rebuild failed as well. I've been recommended by myself to poke it harder myself on my pandaboard.08:42
xnoxmitya57: briefly discussed on #ubuntu-release last night.08:42
* mitya57 reads the log08:42
mitya57that was a very brief discussion :)08:44
mitya57I don08:44
mitya57I don't have a pandaboard, but if someone gives an armhf-enabled ppa to me, I could try to debug this08:44
gesermitya57: https://dev.launchpad.net/CommunityARMBuilds08:52
pittirsalveti: 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:05
pittiapw: 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
ubottubug 1100386 in udev (Ubuntu Raring) "Server installations on VMs fail to reboot after the installations" [High,In progress] https://launchpad.net/bugs/110038609:09
xnoxScottK: $ syncpackage --force cmake ;-))))))09:28
apwpitti, yeah i have that here ... give me 5m, i am struggling with unity, it has lost half my windows09:29
xnoxapw: stop using Windows =)09:30
apwxnox, heh ... even restarting it is not sorting its head out, dammit09:30
NikThHey all09:31
NikThanybody here ? apw , cjwatson  , infinity  ?09:31
=== ckpringle_ is now known as ckpringle
NikThHow to overcome this error ? => https://launchpadlibrarian.net/140439152/buildlog_ubuntu-raring-i386.linux_3.8.0-21.32ubuntu1~nikth2_FAILEDTOBUILD.txt.gz09:40
apwpitti, ok ... finally got unity sorted (logout time) and I have attached the diff to the bug: bug #1100386 (for systemd)09:46
ubottubug 1100386 in udev (Ubuntu Raring) "Server installations on VMs fail to reboot after the installations" [High,In progress] https://launchpad.net/bugs/110038609:46
apwNikTh, you are better off coming over to #ubuntu-kernel for these kernel related build issues09:47
NikThapw: Thanks09:47
apwNikTh, ping me when you get there09:47
pittiapw: great, thanks! (and no hurry, if you need more time then take it)10:05
apwpitti, that one should be good to go, tested and the like, though i did mod the changelog to get the bug number right :)10:09
pittiapw: ack, thanks; uploading now10:10
apwpitti, ta10:10
=== 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
mitya57geser: 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
mitya57(sorry for not noticing your message earlier, I was not online)11:11
=== dholbach_ is now known as dholbach
=== gusch is now known as gusch|away
vassiehello, 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 now11:47
mdeslaur@pilot in11:55
=== 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
ScottKxnox: No.  There's one Ubuntu change left.11:57
pittiyolanda: did you see the postfix autopkgtest failure on i386? that looks curious, is that a bug in python itself?12:01
ScottKseb128: 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
yolandapitti, no, i didn't see it, can you point me at it?12:01
seb128ScottK, "when the qpa is ready"12:01
seb128ScottK, 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
ScottKi.e. maybe never  and who cares what we agreed.12:02
pittiyolanda: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-postfix/1/ARCH=i386,label=adt/12:02
seb128ScottK, well, I do care about fixing it properly, but I don't see the point to break users for the sake of making a point12:02
ScottKOK.  That's why I asked for when.12:02
ScottKI didn't say I'd try to stop you adding it back.12:03
seb128good, sorry that the qpa thing is not ready yet12:03
yolandapitti, let me test them locally again12:04
xnoxScottK: hm?!12:04
ScottKI 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
yolandai haven't seen that error before12:04
=== greyback is now known as greyback|lunch
seb128ScottK, agreed12:05
xnoxScottK: after last merge by Riddell, there were two patches left, both are in Debian and filed upstream.12:05
pittiRAOF: 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
ScottKseb128: I do, however, consider this going back on an agreement and I'll of course consider that when reviewing FFes in the future.12:05
ScottKxnox: OK.  I knew about one being in Debian.  I didn't check the other.12:06
seb128ScottK, 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 now12:07
ScottKThen was the time to discuss it, not now.12:07
ScottKI would be less grumpy about the situation if there was a date beyond "when ready" for dropping this Qt4 forward port.12:08
seb128well, 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 is12:09
seb128I just know it's being tracked but it's not trivial enough to say "it will be squeezed in an afternoon next week"12:09
seb128e.g it's going to take some extra time12:10
ScottKCould you ask for an estimate?12:10
* cjwatson curses at build systems that don't fail immediately12:10
=== MacSlow|lunch is now known as MacSlow
yolandapitti, i tested with saucy - amd64 and works locally, let me test with i38612:10
pittiyolanda: yes, it succeeds on amd64 in jenkins, too12:11
seb128ScottK, ok, I will try to get one12:11
mitya57xnox: no, there is also disable_overlay_scrollbars.diff which is not in Debian/upstream12:11
mitya57it 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:13
ubottubug 1170384 in qtbase-opensource-src (Ubuntu) "[sna] Xorg crashed with SIGABRT in memcpy_blt() - <Address 0xb8070f48 out of bounds> when using ReText with Qt5" [High,In progress] https://launchpad.net/bugs/117038412:14
xnoxmitya57: are we talking about the same thing? I was discussing cmake package with scottk.12:14
xnoxmitya57: btw. I could give you ssh access to a panda board if you want to poke qt4-x11.12:14
xnoxpm if you are interested.12:15
mitya57xnox: I was talking about:12:15
mitya57<ScottK> 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
mitya57xnox: not today (I hope it's not urgent)12:15
xnoxScottK: ^, not me then =) I'm not involved in Qt5 packaging much.12:15
xnoxmitya57: nah. I'll get around to it eventually.12:16
mitya57xnox: btw, do you have any plans to package pyqt5 or do you want me to do that? :))12:17
=== pete-woods-lunch is now known as pete-woods
xnoxmitya57: i haven't tried it since before they published qt5 preview snapshot.12:18
xnoxi think i did push my latest trial somewhere to launchpad.12:18
mitya57xnox: ok, I'll look at it next week and let you know if I get any success12:19
mitya57pitti: fyi, I have dep-8 fixes for docutils and pandas in the sponsoring queue12:20
pittimitya57: ah, splendid, thanks12:21
=== _salem is now known as salem_
mitya57(pandas is not yet failing on jenkins, but it doesn't work with the latest nose)12:21
seb128there is a good stack of tests work in the sponsoring queue12:22
seb128we need a patch pilot round from somebody from qa :p12:22
seb128there are like 10 of those waiting12:22
yolandapitti, fails for me locally on i386 also12:23
pittimitya57: ah, you fixed it in Debian and merged? awesome12:23
pittiseb128: 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 two12:23
seb128pitti, you are piloting next monday I see ;-)12:23
mitya57pitti: if you speak about nose, then I broke it, not fixed :)12:23
pittimitya57: I meant docutils12:24
mitya57pitti: jwilk fixed that12:24
pitti+XS-Testsuite: autopkgtest12:25
pittimitya57: ^ FYI, this is perfectly fine for Debian12:25
pittiit's part of the DEP8 spec12:26
pittimitya57: and dropping pysupport in Debian will certainly get you applauds from doko, too :)12:26
pittimitya57: what is debian/x-rst.xml? (that's not mentioned in the remaining delta)12:26
mitya57pitti: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=16;bug=68550912:27
yolandapitti, it fails in that regular expression, but looks good to me? child.expect(r'.*[pP]assword', timeout=5)12:27
pittiyolanda: yeah, hence my suspicion of "bug in python"12:27
pittiit said "internal error in regex machine" or so12:27
mitya57pitti: oops, x-rst.xml is an old version of docutils.xml, will now remove it12:27
yolandaoh yes: RuntimeError: internal error in regular expression engine12:27
yolandaall the failures are the same12:28
pittimitya57: no worries, I can just remove it in the merge12:33
mitya57pitti: already removed it, and fixed the version number12:34
* pitti pulls again12:34
pittimitya57: forgot to push?12:34
mitya57pitti: no, pushed12:34
mitya57pitti: looks like mdeslaur just uploaded pandas fix12:36
pittiheh, me too12:37
pittiso I guess mdeslaur's will win :)12:37
mdeslauroops :)12:37
pittimitya57: anyway, thank you! (also uploaded docutils)12:37
pittimdeslaur: sorry12:37
mitya57pitti: thanks12:37
yolandapitti, so what we do with that isuse?12:40
cjwatsonRiddell: Was kdegames-data going away intentional?  Looks like that needs some transition work in saucy-proposed.12:40
pittiyolanda: 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 RE12:41
cjwatson  ** gcc version 4.8 found, expected gcc 3.x with x>1 or gcc 4.x with 0<x<8!12:43
cjwatsonseriously, virtualbox?12:43
cjwatsondebfx: ^- you might like to have a look at that12:43
=== 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
Riddellcjwatson: mm not sure, will look into it thanks12:54
cjwatsoninfinity: 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:11
Mirvcjwatson: 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 tomorrow13:26
cjwatsonMirv: please see the discussion in this channel yesterday13:27
Mirvcjwatson: ok, scrolling back13:27
cjwatsonBut 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
cjwatsons/is false/are false/.13:28
* cjwatson peers at the sweep package. So much ugliness that could just be dh_autoreconf13:30
Mirvcjwatson: thanks, read the discussion13:33
seb128Mirv, I opened https://bugs.launchpad.net/cupstream2distro/+bug/1182570 on the daily landing tools13:34
ubottuLaunchpad bug 1182570 in Canonical Upstream To Distro "Should force publishing if archs-which-were-never-available are depwaiting" [Undecided,New]13:34
seb128Mirv, didrocks said he would work on it next week I think13:34
mardykenvandine: hi! Did you see my "categories" branch for the SystemSettings?13:36
mardy(the branch name doesn't match the content very closely, actually :-) )13:36
kenvandinemardy, yes... did you see my comment on it?13:36
mardykenvandine: obviously not :-)13:36
kenvandineLooks like you forgot to add SystemSettings.pc.in13:36
kenvandinemardy, i also pushed a fix for my branch you reviewed13:37
mardykenvandine: just approved13:37
kenvandinei'll just merge these to trunk until we get the merger setup for it13:38
kenvandinemardy, i'm going to add a settings stack for daily release today13:38
kenvandineand get that configured for the merger, etc13:38
kenvandineand CI13:38
mardykenvandine: looking forward to it!13:40
mardycyphermox: hi, thanks for your review. Do you have some names to suggest?13:41
cyphermoxmardy: not really. people who've done Qt and helped you with QMenuModel before?13:42
NikTh waiting13:42
cyphermoxmardy: perhaps timo, but he doesn't seem to be around13:42
cyphermoxNikTh: ask in #ubuntu-kernel, but I think your config file for the kernel you're building is incorrect or not found13:44
NikThcyphermox: I'm sorry, I just tested some commands on IRC .. to another channel , but the message appeared here too. Sorry. :-)13:45
NikThcyphermox: Actually I'm waiting but not for an answer here. I'm waiting for building results.. :-)13:46
kenvandinemardy, merge conflict now :)13:46
cyphermoxNikTh: ok13:47
mardykenvandine: updated :-)13:48
kenvandinemardy, can you make me an admin of ~system-settings-touch13:49
kenvandinei want to setup a PPA for CI builds13:49
rsalvetipitti: I didn't forward that patch upstream as it's only relevant when you're booting in an android kernel13:50
mardykenvandine: done13:50
rsalvetiwhich is what happens only with touch13:50
kenvandinemardy, thx13:51
rsalvetibut I can give it a try13:51
=== wedgwood_away is now known as wedgwood
pittirsalveti: yeah, I don't think it hurts to have that working in udev upstream; thanks!13:51
mardyseb128: about this blueprint: https://blueprints.launchpad.net/ubuntu/+spec/client-s-touch-system-settings13:52
mardyseb128: you added one item "[mardy] write the "base shell" app: TODO"13:53
mardyseb128: isn't that the same as the first item?13:53
kenvandinemardy, not part of this merge, but i just noticed some copy and paste noise, like a reference to signon-ui.pot in src.pro14:00
mardykenvandine: oh, that might be. I'll check14:02
kenvandinemardy, i've merged this branch, just clean that up in your next branch14:02
mardykenvandine: OK14:03
stgraberpitti: 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
stgraber(physical sound card)14:27
=== ckpringle_ is now known as ckpringle
cjwatsonpitti: 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:35
cjwatsonpitti: Specifically, started during debootstrap14:36
=== francisco is now known as Guest25788
cjwatsonpitti: I notice we no longer have the udevadm.upgrade stuff; might that be relevant?14:39
cjwatsonpitti: This appears to be the same as bug 118254014:42
ubottubug 1182540 in lxc (Ubuntu) "lxc smoke test, test_lxc_apparmor appears to hang on saucy VM" [High,Confirmed] https://launchpad.net/bugs/118254014:42
seb128mardy, yes, seems so, sorry I just dumped the session notes in there and didn't check for duplicates14:53
slangasekmlankhorst: pong15:03
pitticjwatson: ah, I didn't really see why disabling udevadm is related to starting/stopping the daemon15:04
cjwatsonI suspect something else calls udevadm which starts udevd15:04
pitticjwatson: so I'll put it back; it's almost certainly due to dropping these bits, yes15:05
cjwatsonI have an strace but it's gigantic15:05
pittiI'll use above bug for that15:05
pittishouldn't be too hard to reproduce15:05
cjwatsonjust debootstrap and you'll find an extra udevd --daemon process hanging around when you're done15:05
=== dpm-laptop is now known as dpm
mlankhorstslangasek: can you accept all the new packages in precise?15:07
pittistgraber: does that only affect /dev/snd/*, or other devices as well15:07
cjwatsonHm, it actually looks as though it's being started directly15:07
cjwatson11398 write(1, " * Starting the hotplug events dispatcher udevd\n", 48) = 4815:07
cjwatsonWhy is that touching /etc/init.d/udev ...15:08
slangasekmlankhorst: I don't think I'll have a chance to look at it this morning; maybe SpamapS has some time?15:08
pittihm, where does that string come from; doesn't look like /etc/init/udev.conf15:08
mlankhorstslangasek: friday's fine too, it's been lingering for ages in NEW15:08
SpamapSslangasek: definitely not. I'm wrangling contractors today15:09
cjwatsonVia invoke-rc.d, WTF15:09
stgraberpitti: 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:09
pitticjwatson: hm, I assume we have a policy-rc.d somewhere?15:10
cjwatsonThis might be a debootstrap bug15:10
cjwatsonIt has a fake initctl which doesn't respond to initctl version15:10
cjwatsonWhich invoke-rc.d now cares about15:10
pittioh, I remember slangasek's mail about that15:10
cjwatsonSo I could make it pass through version and see if that helps15:11
cjwatsonSomething like http://paste.ubuntu.com/5690668/15:12
pittidouble quoting?15:13
pittiah, I guess it's a script that writes a script15:13
pittiright, nevermind me15:13
slangasekcjwatson: hah, doh15:14
cjwatsonWonder what else might have a similar bug15:15
pittistgraber: do you still have a running session? ("loginctl show-session")15:16
=== mmrazik is now known as mmrazik|afk
cjwatsondebian-installer-utils and ubiquity at least15:17
cjwatsonWith any luck that's the limit of the clone-and-hack15:17
slangasekwhy is this not done via policy-rc.d?15:17
cjwatsonIt installs a policy-rc.d as well15:18
cjwatsonI believe this is insurance against policy-violating packages15:18
cjwatsonOf which there were many more earlier on15:18
cjwatsonI mean, even openssh was at best skating on very thin policy until this morning15:19
stgraberpitti: http://paste.ubuntu.com/5690694/15:19
stgraberpitti: loginctl also says "c2     201105 stgraber         seat0" so the session is definitely registered15:20
cjwatsonYep, that debootstrap change appears to fix it - just testing a bit more and I'll upload15:20
pitticjwatson: thanks15:20
cjwatsonWonder if gina's unstuck yet15:20
pittistgraber: can you check if the devices have TAGS=:uaccess in "udevadm info --export-db|less"?15:21
stgraberpitti: E: TAGS=:seat:uaccess:15:21
stgraber(looking at /dev/dri/card0 in this case)15:21
pittistgraber: do the ACLs come back if you switch to VT1 and back?15:21
pittistgraber: you can also try "sudo udevadm trigger --sysname-match=card0 --verbose"15:22
stgraberpitti: hmm, well, interstingly enough I can't switch vt... ctrl+alt+FX won't work and chvt won't either15:23
pittistgraber: try the udev trigger?15:23
stgraberpitti: the udevadm trigger didn't help, still no ACL for my user on the device15:24
stgraberpitti: 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/015:25
stgraberoh, actually that's wrong, tty0 doesn't give the ENOTTY15:26
stgraberbut it doesn't quite work either15:26
pittistgraber: otherwise, the output of this might give some insight:15:26
pittisudo strace -fvvs1024 udevadm test-builtin uaccess /devices/pci0000:00/0000:00:02.0/drm/card015:26
pittistgraber: the sysfs path probably doesn't match for you, you can look it up in udevadm info --export-db15:26
pittistgraber: hm, wait -- I remember that I've seen something like this in otto15:27
pittistgraber: i. e. with ACLs in a container15:27
pittistgraber: you run your whole desktop in LXC, right?15:27
stgraberpitti: strace => http://paste.ubuntu.com/5690719/15:27
cjwatsonslangasek: 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 debootstrap15:28
stgraberpitti: nope, that's a fairly standard desktop machine, I have a container running though but it doesn't have tty access15:28
cjwatsonSo I think I should fix both15:28
pitticjwatson: so disabling udevadm during package upgrade wouldn't help at all here, right? (as the daemon is not normally started through udevadm)15:29
slangasekpitti: udevadm needs to be disabled during package upgrade anyway; was that change dropped?15:29
pittistgraber: ok, comparing mine to your's, I have getxattr() == 44, then setxattr() == 0, and the writev("unload module index"), your's is missing the setxattr15:29
stgraberright, that confirms it's not even trying to set the ACL, doesn't really tell us why15:30
pittislangasek: it wasn't ported over, yes; what's wrong with running udevadm during package upgrade?15:30
cjwatsonpitti: 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 was15:30
cjwatsonLet me dig up Scott's post about it15:30
pittiyeah, I'm curious why that is15:30
stgraberthough I wonder if my messed up VTs could somehow break the code that detects whether I'm at the console or not15:30
pittiat least info works just fine without udevd15:31
pittiit just reads /run/udev, it doesn't query the daemon15:31
slangasekpitti: I think that's the wrong question; why would you drop any part of the packaging before knowing why it was there?15:31
cjwatson  * It is not permitted to call udevadm trigger or settle during an upgrade15:31
cjwatson    without depending on udev.  Attempting this will fail.15:32
cjwatsonwas the specific one15:32
pittiwell, that's not much of an explanation15:32
slangasekthere were lots of upgrade failures because of this15:32
cjwatsonAnd info is a complete red herring, because udevadm.upgrade *passed through info calls*!15:32
pittiand both trigger and settle work fine without udevd15:32
pittiso that seemed obsolete to me15:32
pittiI can add it back, but it seems like unnecessary complexity to me15:33
slangasekhow can 'trigger' work without udevd?15:33
cjwatsonThis was associated with https://lists.ubuntu.com/archives/ubuntu-devel/2009-January/027260.html15:33
cjwatsonAlthough that doesn't really explain it very well either15:33
pittislangasek: the trigger operation works fine, but of course rules wouldn't be processed15:33
stgraberslangasek: IIRC trigger just uses /sys/..../uevent to re-emit the uevent15:34
=== wedgwood is now known as wedgwood_away
pittibut that's just the same net result as diverting udevadm trigger and saying that it won't work15:34
cjwatsonSo I think Scott was concerned precisely that rules wouldn't be processed, and was trying to force packages to get this right15:34
cjwatsonEven if udevadm "works" (i.e. exits 0)15:34
pittiah, so that's not for *preventing* package installation failures, but for *causing* them to expose problems15:35
slangasekcjwatson: but if 'udevadm trigger' now passes with no effect, how does that enable the caller to retry later?15:35
pittiso in that regard we could put it back, but if anything that should cause more install failures, not less15:35
cjwatsonslangasek: indeed I'm arguing that we should put the previous implementation back because it's better to fail than to do the wrong thing15:36
slangasekthe previous implementation failed?15:36
cjwatsonespecially given that this has been intentionally failing for four years, so it's not a hidden source of problems15:36
slangasekoh, right15:36
cjwatsonif [ "${0##*/}" = "udevtrigger" ] || [ "$1" = "trigger" ]; then15:37
cjwatson    echo "udevadm trigger is not permitted while udev is unconfigured." 1>&215:37
slangasekyes, now I have the right end of the stick15:37
cjwatson    exit 115:37
slangasekyes, so udevadm would be called but we would lose the trigger15:37
=== Quintasan_ is now known as Quintasan
=== gusc is now known as gusch
tvossseb128, ping15:37
seb128tvoss, hey15:37
pittiso I guess what that really wants to say is that udevadm trigger should fail if udevd isn't running15:37
pitti(udevadm settle, info, monitor, hwdb, test, etc. are all fine)15:38
cjwatsonpitti: 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 udevadm15:38
cjwatsonThe previous implementation explicitly excluded settle as well15:38
cjwatsonAnd doesn't settle also essentially require rules to be in place?15:38
pittitrigger does (as that will cause re-processing the rules)15:39
pittisettle just waits for udevd to finish with this, but if there's no udevd, there's nothing to wait for15:39
cjwatsonMm, I suppose ...15:39
pittianyway, I'll put it back15:40
slangasekright, furthermore I heard 'settle' no longer works upstream15:40
pittisorry for the misunderstanding15:40
cjwatsonif udevd isn't running> provided, basically, that udevd works as if it were Essential and can operate even when the package is unconfigured15:40
cjwatsonpitti: It's not this critical bug affecting lxc and livefs builds, anyway, so you can take a little more time about it if you like15:40
pitticjwatson: yeah, I won't get to that today any more anyway15:41
cjwatsonI've stolen that bug and will sort it out15:41
pittifiled as bug 118294815:44
ubottubug 1182948 in systemd (Ubuntu) "disable udevadm trigger during package upgrade" [Medium,In progress] https://launchpad.net/bugs/118294815:44
pittislangasek: why doesn't "settle" work any more? there's even a systemd unit for it15:45
slangasekpitti: I don't know; it's just something I heard, perhaps I heard wrong15:49
=== ritz_ is now known as ritz|here
ionmvo: Any thoughts about this? https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/118293215:51
ubottuLaunchpad bug 1182932 in software-properties (Ubuntu) "Add PPA keys to /etc/apt/trusted.gpg.d/{owner}-{ppa}.gpg" [Undecided,New]15:51
mvoion: I think that is a good idea15:52
mvothanks for working on this!15:52
ionNo problem, it was little effort.15:53
mvoion: any preferences what I should put in the changelog?15:54
ion“[Johan Kiviniemi]”, “* Add PPA keys to /etc/apt/trusted.gpg.d/{owner}-{ppa}.gpg” perhaps? Feel free to write anything you like.15:55
mdeslaur@pilot out15:55
=== 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:
=== wedgwood_away is now known as wedgwood
ionmvo: Hmm, i suppose apt-key should be patched to create keyring files using a more permissive mode than 0600.15:58
mvoion: hm, 0644 should be ok15:59
davmor2mvo: how do chap, how's life?15:59
mvoion: commited, thanks, I will upload in a bit16:00
mvodavmor2: hey! nice to see you. I'm good, how are you?16:00
davmor2mvo: I'm well thanks, busy as hell, but that is good too :)16:01
mvodavmor2: haha, indeed! nice to see all the progress on the touch front, its very exciting to watch16:02
ionmvo: I fail to see a gpg parameter to set the mode. Perhaps a chmod in apt-key after running gpg when --keyring was given? For every invocation or only when we detect a new keyring file was created?16:03
mvoion: I think its ok to keep 0644, /etc/apt/trusted.gpg is also 064416:05
=== gusch is now known as gusch|brb
mlankhorst666 ofc16:18
mlankhorsttrust goes both ways right?16:19
=== salem_ is now known as _salem
=== gusch|brb is now known as gusch
tvossslangasek, ping16:45
slangasektvoss: hi16:45
debfxcjwatson: re virtualbox: is it urgent to fix that? otherwise I'd fix it through Debian once it has migrated to testing.17:03
tvossgema, ping17:14
tvossslangasek, is there a wiki page around somewhere that captures any resource measurement things17:15
=== mnepton is now known as mneptok
slangasektvoss: I believe there is...at least there's one that lool created17:17
slangasekbut I don't remember the page and don't see it linked from https://wiki.ubuntu.com/Touch/17:18
slangasektvoss: ah, https://wiki.ubuntu.com/Nexus7/MeasuringMemoryUsage - should maybe be converted to live under Touch/17:19
gematvoss: pong17:23
=== _salem is now known as salem_
tvossslangasek, thanks17:54
tvossgema, did you start summarizing the memory measurement work, yet?17:54
gematvoss: we are looking into the stacked graphing you showed me17:56
gematvoss: doanac is leading this work and can give you previews as we make progress17:57
gemadoanac: ^17:57
tvossgema, cool. but I'm looking for a wiki page documenting the current work17:58
gematvoss: if you are referring to the memory performance indicator (the summary page) we haven't started that one yet17:58
gematvoss: this is where the work is being tracked: https://blueprints.launchpad.net/ubuntu/+spec/qa-s-dashboard17:58
pmcgowancjohnston, hey can ask you some questions on how topics and blueprints work18:06
doanactvoss: documenting the plan to improve the view or a document about the existing view?18:20
tvossdoanac, documenting the measurement approach :) not necessarily the UI18:21
doanactvoss: ah - okay. will do and get back to you on it18:22
tvossdoanac, perhaps you can take it from here https://wiki.ubuntu.com/Nexus7/MeasuringMemoryUsage and move it to Touch. Would you mind keeping me and jasoncwarner in the loop?18:23
doanactvoss: okay. also an idea: instead of doing this in the wiki. would it make more sense to put these explanations in the views themselves?18:24
tvossdoanac, for step two: yes, having a wiki page would help on a short timescale18:25
doanactvoss: okay. will do and will keep jason in the loop as well18:26
tvossdoanac, awesome, thank you18:26
ionmvo: Does this look okay? https://github.com/ion1/apt/commits/debian/sid18:27
cjohnstonpmcgowan: you can18:39
=== deryck is now known as deryck[lunch]
pmcgowancjohnston, if I want to define new topics and associate blueprints to them, is that all done via bp dependencies?18:43
pmcgowanwhat makes a topic show up18:43
pmcgowanfor ubuntu-s status tracking that is18:43
cjohnstonpmcgowan: IIRC lool made a doc on it last cycle. trying to find it18:47
ScottKwgrant: Still not picked up.  How's it going?19:07
roaksoaxhowdy! Has something change in saucy that symlinks (in /etc/init.d) are no longer being create for upstart jobs19:12
infinityroaksoax: https://lists.ubuntu.com/archives/ubuntu-devel/2013-May/037150.html19:13
roaksoaxinfinity: thanks!!19:13
evpitti: ooh, thanks! Will do!19:16
roaksoaxinfinity: what about for packages that do not exist in debian and have no init script, any ideas what's needed to get to work correctly?19:20
=== francisco is now known as Guest82484
rbasakroaksoax: just the upstart job, surely? Why do you need init.d symlinks?19:24
rbasakForget I said that. I'm being stupid.19:25
roaksoaxrbasak: I don,t but dh_installinit is add a check of "if [ -x "/etc/init.d/XYZ" ]; then", which means that invoke-rc.d will never be called, hence the server will never start on postinst19:26
roaksoaxis adding*19:26
=== deryck[lunch] is now known as deryck
barrybdmurray: lp: #117370419:31
ubottuLaunchpad bug 1173704 in python-imaging (Ubuntu Saucy) "PILcompat needs to add PngImagePlugin" [High,In progress] https://launchpad.net/bugs/117370419:31
=== dduffey_afk is now known as dduffey
=== _salem is now known as salem_
=== Tonio_aw is now known as Tonio_
ScottKbarry: You should ask doko to push your python-imaging change to Debian (if you didn't) and phatch is PAPT maintained.19:49
stgraberlifeless, barry: so where do we meet? hangout?19:58
lifelesssounds good, let me see19:58
lifelessstgraber: barry; sent you a hangout invite, no response :P20:00
roaksoaxinfinity: --upstart-only doesn't seem to make an effect20:05
barrylifeless, stgraber sorry i was a bit late, looking for the invite now20:06
=== racarr is now known as racarr|curry
=== racarr|curry is now known as racarr
=== francisco is now known as Guest56727
=== sarnold_ is now known as sarnold
cjwatsondebfx: as long as it's in the next couple of weeks, I guess that's fine20:51
Logan_Has anyone been noticing that new Debian versions aren't being picked up by LP, according to syncpackage?21:02
stgraberLogan_: is the source package name > gdb? :)21:05
stgraberso yeah, known issue21:05
Logan_Bug link?21:06
stgrabergood question, I just saw that mentioned a couple of times on IRC, there's probably a bug against Launchpad/the package importer21:06
Logan_Not seeing any. :/21:07
stgraberLogan_: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=70911821:08
ubottuDebian bug 709118 in src:gdb "gdb: truncated Maintainer field" [Serious,Fixed]21:08
cjwatsonYeah, it's being fixed21:08
cjwatsonwgrant is applying a workaround in LP at some point21:08
Logan_Ooh, awesome.21:09
Logan_Thanks guys!21:09
cjwatsonIdeally we'd be able to work out why that got accepted in Debian in the first place, as the code says it shouldn't have done21:09
cjwatsonAnsgar's best guess observes that the lintian command in question is run through sudo and that maybe sudo fell over21:10
cjwatsonBut without dak privileges on ftp-master.d.o I can't really check21:10
ScottKDktrKranz: ^^^ maybe you could ...21:14
Laneycjwatson: Couldn't it be because dak checked the _amd64.changes which doesn't seem to be invalid: http://packages.qa.debian.org/g/gdb/news/20130520T194802Z.html21:14
Laney(didn't check what that lintian check actually does, mind)21:15
cjwatsonLaney: It's the .dsc that's invalid, and lintian does fail on the _amd64.changes (which is sourceful) when run manually21:15
cjwatsonEven when run manually on franck, I'm told (I've only tried on ries myself)21:16
Laneyho hum21:17
cjwatsonFurthermore, 'dak process-upload' rejects it when run by hand21:19
cjwatsonAll a bit mysterious really21:19
=== salem_ is now known as _salem
cjwatsonLogan_: It's annoying me though so don't fear it'll get forgotten.  Also I will notice when it gets fixed in the form of a gigantic mail from auto-sync, I expect ...21:23
=== mbarnett` is now known as mbarnett
cjwatsondebfx: Ah, I see you fixed it anyway - thanks21:29
Noskcajkirkland, can you merge some of the changes into testdrive? Andres has been rather slow to respond21:31
cjwatsonRiddell: I've uploaded rebuilds of the stuff that was still depending on libkdegamesprivate1, which should be enough to get it past proposed-migration21:42
cjwatsonDidn't test-build them all but the result of test-building kapman looked plausible21:42
dokorbasak, so what about rebuilding all the facter stuff?21:55
cjwatsonRiddell: Oh, except kmahjongg apparently needs adjustment because libkmahjongg took over one of its binary packages?  Not going to worry about that now - bedtime.21:58
rbasakdoko: I've fixed facter in bug 1173265 - infinity said he'd review and sponsor soon21:59
ubottubug 1173265 in facter (Ubuntu) "facter fails to run from rebuilt source package" [High,Triaged] https://launchpad.net/bugs/117326521:59
rbasakdoko: is the puppet failure due to facter?21:59
=== Tonio_ is now known as Tonio_aw
=== Tonio_aw is now known as Tonio_
=== kentb is now known as kentb-out
=== wedgwood is now known as wedgwood_away
=== ssweeny` is now known as ssweeny
NikThHere I am again. You will never get rid of me :P New build error. As I guess I must add something in debian/rules, but what ? Error here: https://launchpadlibrarian.net/140487585/buildlog_ubuntu-raring-amd64.linux_3.8.0-21.32ubuntu1~bfsbfq0_FAILEDTOBUILD.txt.gz23:29
=== _salem is now known as salem_
wgrantcjwatson, ScottK: Working on getting the fix deployed... a bit difficult atm.23:46

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!