=== slank is now known as slank_away
=== k-s is now known as k-s[AWAY]
EagleScreenhello, we have *again* bluetooth obex broken in gvfs in quantal and raring, please fix it00:16
TheMusoEagleScreen: Please file a bug.00:18
EagleScreenTheMuso: there are two bugs filled00:18
TheMusoOk then thats fine.00:19
EagleScreenTheMuso: quantal was released with this bug, and I do not see activity to fux it before raring, I think having a working bluetooth is an important feature nowadays00:22
sladenEagleScreen: what are the bug numbers?00:25
EagleScreenBug #1103253 and Bug #89985800:26
ubottuError: Launchpad bug 1103253 could not be found00:26
ubottubug 899858 in gvfs "regression in gvfs to connect/browse using obex" [Medium,Confirmed] https://launchpad.net/bugs/89985800:26
sarnoldEagleScreen: probably 1103253 is dead because your packages were out-of-date and the retracer only supports tracing on current.. I doubt there will be any movement there. You should update the old packages, re-create the crash, and file a new bug as the robot asks...00:31
EagleScreensarnold: I amon it00:31
EagleScreenI have reported it again in Bug #110377000:41
ubottuError: Launchpad bug 1103770 could not be found00:41
sarnoldwoot. now just wait for the retracer...00:42
wjtaylor_Is touch fully supported in 12.04. I started using it and my cursor jumps all over now. Didn't want to fill out a bug report, if it's not supported.01:26
sladenwjtaylor_: if it doesn't work, it's a bug.  Please file it.  The most important bit is which /exact/ hardware you're using and which programme(s)01:28
wjtaylor_yeah, np.  Dell XT2 and  whatever the stock Document Viewer (pdf view) in 12.0401:30
=== cpg is now known as cpg|away
Snow-Manpitti: around..?02:25
Snow-Manpitti: was hoping to chat w/ you about possibly having a per-cluster directory under /var/run for sockets and then modifying pg_lsclusters (and friends) to add and support listen_addresses which might not overlap.02:26
Snow-Manpitti: in an ideal world, I'd like to be able to run 2 clusters on the same physical box, both using the default port of 5432 but with different IPs02:27
Snow-Manpitti: and still have psql --cluster x.y/whatever and friends work.02:27
Snow-Manand not error out when there are conflicting ports for two clusters, when they have different IPs.02:27
TheMusoSnow-Man: pitti is not likely to be on for another few hours.02:43
Snow-ManI expect he reads scrollback. :)02:43
=== cpg|away is now known as cpg
lifelessare dates for UDS Q available yet ?02:48
lifelesseven approx ?02:48
lifelessgrr, I mean 'S'02:50
sladenwjtaylor_: Evince is the PDF viewer.  please could you file a bug with exactly what actions (gestures)02:52
infinitylifeless: Approximately a week after release, if history is anything to go by, but nothing officially announced yet.03:11
lifelessinfinity: thanks03:12
infinitylifeless: Well, a week and a half, since release is a Thursday.  But you know what I meant, I assume.03:12
lifelessindeed :)03:13
=== cpg is now known as cpg|away
=== cpg|away is now known as cpg
pittiGood morning04:43
infinitypitti: Yo.04:44
infinitypitti: When do we plan on doing langpacks for precise.2 (or do you at all)?04:45
pittiSnow-Man: hm, that requires psql to iterate through the server configs and map IP/port ranges to find out which one it really wants to talk to?04:45
infinitypitti: And, if you do, shall we escalate that "upgrade the chroot, pleeeease" ticket first?04:45
pittiSnow-Man: with unix ports that's easier of course, but that pretty much is guaranteed to break client apps which are not using p-common (i. e. pretty much all of them), as they can't find the socket any more04:45
pittiinfinity: ah, for that I'm pretty much in "poke me when you need it" mode04:46
pittiinfinity: yeah, I guess we should do some escalation there04:46
pittiinfinity: when is precise.2 due?04:46
infinitypitti: Kay.  I'll apply some pressure from a few angles.04:46
infinitypitti: Freeze was meant to be (and nominally still is) today, though we're delaying the release by two weeks, so we have some wiggle room on the freezy bit too.04:47
pittiinfinity: ah, ok; I requested a full langpack export from Launchpad now04:47
infinitypitti: Alright, but we'll hold off on magically turning that into source packages while we escalate the ticket?04:48
pittiinfinity: the next regular one will arrive on Jan 28, so that we could build/upload the packs on Jan 29; is that enough, or do we need to poke webops to do a manual export?04:48
infinitypitti: (I assume this could be done in any chroot, is there a reason it's on that specific host?)04:48
pittiinfinity: it's not very host specific, it just needs some space to run this stuff04:49
pittiinfinity: but as this will be a fresh -base rebuild, I don't even need the previous packages04:49
infinitypitti: The 29th still gives us ~2w before freeze, so that would be fine.04:49
infinityErr, before release.04:49
pittiinfinity: so in theory I could even build them at a porter box04:49
infinityBrain no workie tonight.  Too much glibc.04:49
infinitypitti: Yeah, that's what I was thinking, given that porter boxes have lucid/precise/raring chroots (whatever you want to use, precise probably makes mose sense), and a reasonable chunk of space and bandwidth.04:50
pittiglibc? eek, that suppurates out of your brain only very slowly04:50
pittiinfinity: macquarie just has all the "langpack group ACL"/"space for permanently storing the files" etc. set up, that's all04:51
infinityWell, we can and should escalate the ticket too.04:51
infinitySo, if I can get that done before the 29th, you're golden.04:51
* pitti adds the 29th to his calendar04:52
infinityLog for successful build of eglibc_2.17-0experimental0 on i38604:52
infinityWell, this is promising.04:52
infinityIf only I hadn't thought of three more things to fix while it was building.04:52
pittiinfinity: OOI, does that already include the magic patch which makes gstreamer apps not be sad and hang most of the time?04:56
pitti(no, I never watch videos during lunch break, this is is totally not an egoistic question)04:57
infinitypitti: Yes, you can upgrade from my PPA right now and tell me if it solves that bug for you.04:59
pittihttps://launchpad.net/~adconrad/+archive/ppa/+packages ?05:00
pittiah, that very05:00
infinityThere are a few small multiarch-related bugs in that, but nothing that affects x86.05:00
infinityJust fixing up some armhf/armel stuff right now, and nailing down something that affects cross-machine multiarch while I'm in there.05:00
pittiinfinity: that seems to work beautifully!05:05
infinitypitti: Oh wow.  The bug is THAT reproducible that you can tell it's fixed that quickly?05:05
infinitypitti: I don't think the severity of it was quite made clear to me, then.05:05
pittiinfinity: I usually had to open a video two or three times before totem would stop hanging and star playing05:06
infinitypitti: Anyhow, one or two more fixes, and mulling over if I want to rewrite a patch from doko or save that for later, and I'll be uploading to experimental and raring tonight/tomorrow.05:06
pittiinfinity: I could usually search within music or a video once, but it would again hang when doing it multiple times05:06
infinitypitti: Ouch.  That's pretty rough.05:07
infinitypitti: Glad to hear it's all gooder with those packages, then.05:07
dholbachgood morning07:17
ritzHi, How do I instruct debuild to use "-j3" for build process07:21
ritzfor build on smp system07:21
slangasekritz: DEB_BUILD_OPTIONS=parallel=307:22
slangasekhowever, the majority of packages don't honor this07:22
pittiyou can actually call "debuild -j3"07:22
pittithat will additionally parallelize dh_builddeb and perhaps some others07:23
slangasekah, hmm07:23
ritzslangasek++ pitti++ thanks07:23
pittithat sets above D_B_O option plus MAKEFLAGS=-j307:24
pittiactually, D_B_O will already parallelize dh_builddeb, sorry07:24
SpamapShallyn: FYI, had to reject your qemu-kvm upload to quantal-proposed. No bug reference, and the version has been superseded by security.07:37
SpamapStkamppeter_: FYI, had to reject cups upload to quantal-proposed because it has no bug reference.07:39
tkamppeter_SpamapS, the cups upload is also not rlevant any more. I have proposed a better approach and I am waiting for user feedback, if no user reacts there will be no SRU att all.07:52
SpamapStkamppeter_: great, thanks for the clarification.07:55
=== smb` is now known as smb
=== yofel_ is now known as yofel
Sweetsha1kslangasek: yes, heard that from seb128. I uploaded a new package on http://people.canonical.com/~bjoern/precise/ and a ppaified version was build in https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-oneirictest-20110718?field.series_filter=precise. I have to smoketest that one and then it should be good for review. the changes are minimal and described in bug 1037111 and should address all concerns.08:56
ubottubug 1037111 in libreoffice (Ubuntu Precise) "[SRU] LibreOffice 3.5.7 for precise" [High,In progress] https://launchpad.net/bugs/103711108:56
=== Sweetsha1k is now known as Sweetshark
psivaabdmurray: there is no single script to do the set up for the auto -upgrade testing. I have now given the automation set-up information in the bug description.09:43
=== Ivanka_ is now known as Ivanka
=== henrix_ is now known as henrix
=== cpg is now known as cpg|away
rbasakgrab-merge is giving me a conflict in debian/patches/series. This I understand. But the working directory it gives me to resolve this conflict seems to have patches applied but no .pc directory. Is this expected? I can fix this up by hand but don't understand the expected workflow here. What am I missing, and how does everyone else deal with this?11:12
toabctlsomeone familiar with pulseaudio? see #110394811:13
=== _salem is now known as salem_
seb128bug #110394811:13
ubottubug 1103948 in pulseaudio (Ubuntu) "Rhythmbox hangs in pa_threaded_mainloop_wait () from /usr/lib/x86_64-linux-gnu/libpulse.so.0" [Undecided,New] https://launchpad.net/bugs/110394811:13
seb128TheMuso, ^11:14
toabctlseb128, thx11:14
seb128toabctl, yw11:14
Laneyseb128: toabctl: that's bug #1085342 in eglibc11:16
ubottubug 1085342 in totem (Ubuntu) "Pulseaudio applications hang (Totem, GNOME Shell etc.)" [Undecided,Confirmed] https://launchpad.net/bugs/108534211:16
seb128Laney, thanks11:16
Laneypthread_cond_wait at the top of the trace is the clue for that one11:17
* Laney dupes a few11:18
toabctlLaney, thx!11:18
jemaduxi have dual boot ubuntu lts and ubuntu daily .. i am using chroot to update the 13.04 but now i cant .. .any way to do that?12:18
=== salem_ is now known as _salem
=== MacSlow is now known as MacSlow|lunch
=== tkamppeter_ is now known as tkamppeter
=== _salem is now known as salem_
=== k-s[AWAY] is now known as k-s
ogra_@pilot in13:50
=== udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ogra_
k-s /wc13:51
=== MacSlow|lunch is now known as MacSlow
OdyXtkamppeter: can you hint me about Debian #697970 and LP #872483 ? A proper fix would be a quirk in backend/libusb*, right ?14:07
ubottuDebian bug 697970 in cups "cups: printing gets wrong after some pages on Epson Stylus Photo 750" [Important,Open] http://bugs.debian.org/69797014:07
ubottuLaunchpad bug 872483 in cups (Ubuntu Oneiric) "laser printer only prints first job correct" [Medium,Fix committed] https://launchpad.net/bugs/87248314:07
=== Ursinha-afk is now known as Ursinha
tkamppeterOdyX, yes, the printers need quirk rules in th usb backend.14:25
tkamppeterOdyX, the user needs to supply the USB VID/PID from libusb and also the usb backend option which solves the problem for him.14:26
=== slank_away is now known as slank
OdyXtkamppeter: that's in the Debian bugreport14:28
tkamppeterOdyX, with this info it is easy to add the new rule to the backend.14:29
hallynSpamapS: i have no idea waht that was about, will have to look at the diff in the rejected queue, thanks14:43
hallynoh, that one14:47
ogra_hmm, do we have a versioning policy for package SRUs where the debian version didnt change over several releases but SRUs have to be uploaded to multiple of them ?14:53
ogra_s/multiple of them/multiple releases/14:54
cjwatsonogra_: https://wiki.ubuntu.com/StableReleaseUpdates links to https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging for that14:54
ogra_cjwatson, heh, that doesnt really solve my issue14:55
Laney2.0-2ubuntu1 in two releases  2.0-2ubuntu1.11.10.1 and 2.0-2ubuntu1.12.04.114:55
cjwatsonogra_: it doesn't?14:56
cjwatson"2.0-2 in two releases         2.0-2ubuntu0.11.10.1 and 2.0-2ubuntu0.12.04.1"14:56
ogra_cjwatson, release 1+2 have $package_0.1-0ubuntu1.debian.tar.gz ... the dev release has ubuntu2 ... now an SRU to release 1+2 having exactly the same content as ubuntu2 cant be named ubuntu2 for the SRUs14:56
cjwatson(and following one for if it already has ubuntuN)14:56
ogra_simply because the ubuntu1.debian.tar.gz differs in the changelog entry14:57
ogra_err ubuntu2, sorry14:57
ogra_oh, i see14:57
cjwatsonum, so then it should be ubuntu1.12.04.1 and ubuntu1.12.10.1 if ubuntu2 is in raring - I don't see the problem here14:57
ogra_yeah, sorry, missed the bottom line of the table14:58
barrymitya57: i'm going to look at your mp again today.  thanks for updating it15:09
mitya57barry: thank you!15:13
* mitya57 will probably also announce pybuild to ubuntu-devel15:14
dholbachstgraber, highvoltage: I just found out that the hangout we planned will conflict with UDW :-/15:14
dholbachstgraber, highvoltage: would it be OK if we move a week later?15:14
barrymitya57: +1!15:16
stgraberdholbach: A week later is fine for me, assuming we keep it on the same day and time15:18
dholbachstgraber, yep15:18
dholbachthanks a bunch!15:18
ogra_jtaylor, looks like merge 141288 was long merged, could you cancel the request (or target it to the -updates branch, i guess that would auto close it)15:23
ogra_it still shows up in the sponsoring queue15:23
xnoxwhat was the name of a package with useful little utilities, like `runone`?15:40
xnoxbikeshed, watershed or something....?!15:40
xnoxmicahg: thanks.15:42
xnoxalthough there also is watershed...15:42
micahgxnox: it's actually its own source, run-one15:43
xnoxmicahg: now i wonder the difference between run-one and watershed packages....15:44
micahgxnox: NIH syndrome?15:45
xnoxmicahg: =Dunno15:45
xnoxNIH vs :Dustin15:45
ogra_urgh, do we have the basics of merging a new upstream releases written down somewhere ?16:17
* ogra_ glares at a 19MB debdiff that patches 3 new upstream releases on top of orig.tar.gz16:18
Laneydoesn't look like the packaging guide has that for non-UDD16:19
psusidebian packaging guide?16:19
roaksoaxbdmurray: howdy! DO you mind taking care of bug #1049177 (Precise SRU). It'16:23
ubottubug 1049177 in maas (Ubuntu Precise) "isc-dhcp-server apparmor profile should have include ".d" " [Undecided,New] https://launchpad.net/bugs/104917716:24
roaksoaxbdmurray: howdy! DO you mind taking care of bug #1049177 (Precise SRU). It's been sitting in the queue for a loooooooong time!!. Thank you :)16:24
=== chiluk is now known as chiluk_away
=== ricotz_ is now known as ricotz
Snow-Manpitti: I was thinking some kind of 'default' value for the socket location which would point to the 'primary' instance on the system16:34
Snow-Manpitti: but p-common using apps could override that with --cluster16:34
highvoltagedholbach: regarding the postponement, +116:38
dholbachhighvoltage, gracias!16:38
=== pcarrier_ is now known as pcarrier
mptev, https://wiki.ubuntu.com/ErrorTracker#extra-info17:05
=== chiluk_away is now known as chiluk
evthanks mpt!17:06
ogra_@pilot out17:10
=== udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
=== ximion is now known as ximion-afk
* dholbach hugs ogra_17:27
dholbachcan somebody please moderate my u-d-a mail?17:27
* ogra_ hugs dholbach back17:28
=== ximion-afk is now known as ximion
cjwatsondholbach: done17:31
Sweetsharkslangasek: bug refs cleaned on http://people.canonical.com/~bjoern/precise/17:31
dholbachthanks cjwatson17:31
cjwatsonMost of the half of the world you're looking at is pandabox relocation.17:32
=== henrix is now known as henrix_
* mlankhorst tries to guess context, fails18:01
=== henrix_ is now known as henrix
jtaylormterry: pycurl, https://github.com/facebook/tornado/issues/671#issuecomment-1263514718:15
mterryjtaylor, oh nice18:17
slangasekgema: ping18:36
gemaslangasek: pong18:36
slangasekgema: hey - so stgraber and xnox are telling me that on the boot speed profiling box that's having install problems, there's an intermittent X hang, unrelated to the installer itself18:38
slangasekgema: have you (QA) talked to the desktop team about this at all yet?18:38
slangasekI think we need to bring their expertise to bear18:38
gemaslangasek: they told us we had to get some logs and reproduce the problem for them to be able to fix18:38
gemacan they fix this hang, it may be what's killing the machines18:38
xnoxthere was full syslog in the bug with x hang in it....18:39
xnoxi'm not sure if xerrors or other interesting things got into it as well or not.18:39
gemaxnox: can you fix the hang?18:39
slangasekgema: we need someone on bryce's team to look at the hang18:40
dokobryce, tjaalton: are you planning a xserver upload? want to make xvfb m-a foreign18:40
tjaaltondoko: got a diff?18:41
gemabryce: could you have an engineer look at a hang we have on one of the testing machines that may be killing bootspeed and other HW testing?18:41
dokotjaalton, well, it's a one liner18:41
tjaaltondoko: ah, I can add it18:42
dokotjaalton, estimated upload?18:42
tjaaltongema: what kind of a hang? I suspect there is an issue with lightdm and the way it interacts with plymouth..18:42
tjaaltondoko: in a hurry?18:42
dokono, but next week would be nice18:43
gematjaalton: it hangs a ubiquity install as far as we can tell, not sure if we even get to lightdm18:43
stgrabertjaalton: the screen completely stops refreshing after a few minutes (which usually ends up being the middle of an install)18:44
gematjaalton: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/109694318:44
ubottuUbuntu bug 1096943 in ubiquity (Ubuntu) "Ubiquity freezes during nfs-based desktop install from recent live destkop images on physical hardware" [High,Confirmed]18:44
stgrabertjaalton: none of the two heads show any change even though the machine is still responsive and clearly doing things18:44
stgrabertjaalton: attaching with x11vnc to X shows me the same stuck video output, so X isn't completely dead either18:44
tjaaltongema: ah, so it's not a boot issue..18:44
gematjaalton: it could be if we managed to get the system installed, but it is not yet18:45
slangasekgema: so this causes install failures /consistently/?  I understood it was intermittent18:45
gemaslangasek: we have all sorts of intermittent issues, this is one hitting bootspeed hardware and PS HW18:46
gemaslangasek: clearing this would help us make some progress18:46
slangasekgema: yes - but you said "if we managed to get the system installed", which I thought was possible18:46
slangasekjust not reliable18:46
gemaslangasek: it was at some point18:46
gemaslangasek: one install out of 7 or 8 will succeed18:47
slangasekthose are not quite the ratios I was led to understand18:47
gemaslangasek: some other jobs fail when it reboots randomly18:47
gemawhich can also be due to this bug18:47
gemaslangasek: 5th boot, 17th boot, 18th boot18:47
gemait depends18:47
gemaslangasek: I hadn't considered before now that it could be X hanging those times also18:48
gemaslangasek: so we were exploring HW overheating and/or fsck getting on the way18:48
* slangasek nods18:49
gemaslangasek: https://bugs.launchpad.net/utah/+bug/109951918:51
ubottuUbuntu bug 1099519 in UTAH "Bootspeed completes 16-17 runs and then fails to connect to machine" [High,Fix released]18:51
gemait's not really fixed, we put togehter a workaround that cannot verify without reliable installs18:52
* slangasek nods18:52
=== chiluk is now known as chiluk_away
tjaaltongema, stgraber: ok.. can't really look into it now, I'll check it out tomorrow18:56
gematjaalton: ack, thanks18:56
mterry@pilot in19:20
=== udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry
roadmrinfinity: hello! I finished verifying the bugs for checkbox 0.13.9 (remember?) but the SRU is only 5 days old. Should we wait until it reaches 7 days in -proposed?19:23
infinityroadmr: What about http://pad.lv/1061198 ?19:27
ubottuLaunchpad bug 1061198 in checkbox (Ubuntu) "Candidate revision checkbox_0.13.8" [Undecided,New]19:27
infinityroadmr: Oh, which I guess is just a meta-bug, now that I look at it.  Still should have a v-done. :P19:27
roadmrinfinity: yep, metabug, 0.13.8 failed verification for one of the bugs :/19:28
roadmrinfinity: which is why we superseded it with 0.13.919:28
infinityroadmr: Yeahp, I remember.  I'm not THAT old.  Yet.19:29
infinityroadmr: Anyhow, releasing it now.  Thanks.19:29
roadmrinfinity: on the contrary, thank you for helping!19:29
stgraberkees: had any luck with that seccomp testsuite failure?19:56
keesstgraber: yeah, already fixed and sent upstream20:12
keesstgraber: http://sourceforge.net/mailarchive/forum.php?thread_name=20130123221333.GN26411%40outflux.net&forum_name=libseccomp-discuss20:13
keesstgraber: http://sourceforge.net/mailarchive/forum.php?thread_name=20130123225538.GP26411%40outflux.net&forum_name=libseccomp-discuss20:13
stgraberkees: nice!20:13
hallynslangasek: adam_g and jamespage have both noticed /dev/kvm perms not being updated...  and it is seeming to me like i need to do 'restart udev' before the udevadm trigger --action-change in qemu-kvm.postinst.  Do i understand right that inotify should be causing udev to see the new config file without a 'restart udev'?20:25
infinityhallyn: Are they running the most recent SRU kernels for precise or raring, by any chance?20:27
stgraberkees: doing a quick test build with your patches applied here. If that succeeds on both i386 and amd64, I'll push that to Ubuntu and sync from Debian once you have those there too.20:27
keesstgraber: if you want to wait a few hours, -2 should be in Debian unstable once my build finishes.20:27
stgraberkees: that'd work too :)20:27
stgraberI can certainly wait a few more hours20:28
keescool :)20:28
slangasekhallyn: I'm not certain if it's inotify or not, but it's certainly always been the case before that udev picks up new rules automatically.  You should absolutely /not/ be calling 'restart udev'20:28
infinityhallyn: (I only ask because inotify's kinda slightly busted right now, and there's a new SRU coming to fix that)20:28
slangasek(restarting udev considered harmful)20:28
stgraber"restart udev" is clearly wrong, "udevadm control --reload-rules" will do what you want if inotify fails20:29
hallyninfinity: ok, *i* am seeing it on very latest raring kernel, yes20:31
hallynjamespage: was on quantal, maybe quantal-proposed20:32
hallynslangasek: stgraber: ok then i won't add that :)20:32
=== slank is now known as slank_away
Snow-Manpitti: so, yea, using a symlink for the current 'primary' cluster per-port would work fine, imv.20:33
=== slank_away is now known as slank
=== henrix is now known as henrix_
=== chiluk_away is now known as chiluk
stgrabercjwatson, hallyn: I just got that one when upgrading a desktop from 12.10 to 13.04 in LXC. Isn't that the one the grub upload was supposed to fix? http://paste.ubuntu.com/1567189/20:56
hallynstgraber: i don't think so20:57
hallynoh.   yes :)20:57
stgraberwell, doesn't look like it's completely fixed :)20:58
hallyni bet you broke it.  on purpose.20:59
hallynstgraber: d'oh,20:59
hallynit looks like the latest merge from debian may have dropped the fix20:59
hallynno, there it is, in postinst.in21:01
infinitystgraber: Is this a container issue, or...?21:07
infinity/usr/sbin/grub-probe: error: failed to get canonical path of /dev/mapper/castiana-home21:07
hallyninfinity: yes, grub is not supposed to try to install in a continer (not safe)21:08
infinity^-- Surely, that shouldn't happen.21:08
hallynand yes, /dev/mapper isn't set up in the containers :)21:08
hallynbut even if it resovled to /dev/dm*, it would still fail update-grub21:08
infinityhallyn: Okay, then whatever logic was added to postinst.in needs to be elsewhere, since zz-update-grub doesn't use that. :P21:08
hallyninfinity: doh! :)21:08
hallynwhat is zz-update-grub21:09
stgraberyeah, I think we cover it for the case where we just install grub-pc but not for when upgrading kernels which is what I was doing here (12.10 -> 13.04 dist-upgrade)21:09
infinityhallyn: /etc/kernel/postinst.d/zz-update-grub21:09
hallynyeah under debian/kernel.  pshaw21:09
stgraberso it sounds like we'll need another round of SRUs to get rid of the problem for good21:10
hallynwell, is zz-update-grub a new thing in raring?21:10
=== salem_ is now known as _salem
infinityhallyn: No.21:10
hallynS i g h21:11
hallynstgraber: have you filed the bug?21:11
stgraberhallyn: not yet, but I can do that now21:11
hallynstgraber: was this an ubuntu-cloud-based container?21:11
hallynjust twondering why you had a kernel image installed otherwise21:11
stgraberhallyn: I was working on the auto-dist-upgrader which does Ubuntu Desktop dist-upgrade testing (and so has a kernel and grub installed)21:12
hallynstgraber: it looks like taking a full ubuntu desktop iso install and upgrading it might oughta be a regular lxc test21:12
stgraberhallyn: well, once I have the dist-uprader running again with LXC, it'll be doing a dozen of those a day on my box, so we'll catch any regression for sure ;)21:12
infinitystgraber: The problem here is that if we skip update-grub altogether, your grub config will be wrong.21:13
hallynstgraber: cool :)21:13
infinitystgraber: So, if you use a container to do your upgrade, then reboot that into a VM or bare metal, it... Won't.21:13
hallynwell we could try to get fancy and (a) (as discusssed before) set up /dev/mapper entries inthe container at startup and (b) let apparmor/userns be the one to stop update-grub from writing to the host's /21:14
infinityIn the update-grub case, it's not actually trying to write anything to boot records, just probe values to update the config.21:15
stgraberhallyn: I don't know why, but I'm not fond of the idea of having /dev/mapper in my container, even if apparmor is supposed to prevent me from accessing it :)21:15
hallynbut that has the problem,21:15
hallynstgraber: right, and we'd be accomodating a veyr rare special case while making update-grub fail and break upgrades in the common case21:16
hallyn(common case being /var/lib/lxc/r1/rootfs is jsut a directory on host's /)21:16
stgraberinfinity: In my case I don't expect the container to ever be bootable in a VM without re-running update-grub anyway as the container is just a directory on my laptop and so doesn't have a partition which means no real UUID21:17
stgraberinfinity: so as far as I'm concerned, it's fine skipping update-grub entirely in this case and the weird case of people booting a VM image in a container, then dist-upgrading in the container and finally booting in the VM, well, they'll just get the old kernel, that should still be bootable21:18
infinitystgraber: Well, we could make update-grub exit 0 at the top for containers, I'm just trying to determine if that's a good or a bad thing for all usecases.  As a non-container-user, I have no idea.21:18
hallyninfinity: i think cjwatson had in the past rejected that, but i could be wrong or, if i'm not, don't recall why21:19
stgraberone fix would be to check if the backing device exists and is writable. If it's, then go ahead, if it's not, then skip it. That should work fine with any container and non-container paths and if someone really wants grub to read/write to the partitions and MBR, then they just have to create those entries, update apparmor and update the device cgroup settings.21:22
infinitystgraber: That's kinda broken for grub-probe's obviously useful failure mode of "your system is actually broken, doofus".21:24
infinitystgraber: (eg: a desktop system with a broken /dev, or other such possibilities)21:24
infinitystgraber: Papering over the failure because some systems are broken by design feels wrong.21:25
stgraberhmm, indeed. Though if that specific check was done only for containers, it'd be half-decent I guess21:25
hallynempowered by design21:25
infinitystgraber: Well, that goes back to the "if it's a container, just exit" thing. :P21:26
infinitystgraber: But yeah, I guess probe itself could learn about containers and... I don't know what.  Return bogus info?21:26
hallyni think 'if it's a container, just exit' is ok until we have device namespaces (or something like it)21:26
hallynafter all, once we have device ns, we can run udev in the container and /dev/mapper will be there21:27
infinityI assume flask-kernel in ARM containers suffers similar pain.21:28
infinityObviously, I need a drink.21:28
mterry@pilot out21:28
=== udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
hallynminor slip :)21:29
stgraberbug 110446321:29
ubottubug 1104463 in grub2 (Ubuntu) "/etc/kernel/postinst.d/zz-update-grub triggers a grub update in lxc containers" [Undecided,New] https://launchpad.net/bugs/110446321:29
infinitystgraber: Alright, expanded on your summary of the discussion a bit.21:34
stgraberinfinity: thanks21:34
bdmurraybryce: do you have an opinion on removing xserver-xorg-video-intel from oneiric -proposed?21:44
brycebdmurray, huh, that's the old libreoffice start screen fix, jeez that's ancient21:48
brycebdmurray, that was an easy fix, and quite safe, and very straightforward to reproduce/verify, but it's just a minor cosmetic problem.  If no one is complaining about it, it probably doesn't matter.  It's hard to care much about oneiric issues at this point.21:51
brycebdmurray, sort of a shame to toss the sru after all the work that went into it though.21:51
bryceit annoys me we lose so many X SRUs because people don't verify them.  :-(21:52
infinitybryce: If it's easy to reproduce/verify, someone should have done so.21:52
sarnoldit feels like I see an SRU expiry every day or two. tat feels like an astonishing amonut of work to lose..21:53
infinityI might have to actually document this somewhere other than the heads of me, cjwatson, and wgrant, but we can actually rescue deleted SRUs (binaries and all).21:53
infinitySo, if someone suddenly feels the urge to verify something, we don't need to redo the work.21:53
infinityWe can just copy it back in over itself.21:54
infinityBut having stuff sitting in proposed for a year isn't doing anyone any favours.21:54
bryceinfinity, yes someone should have; that was a trivially easy one to reproduce.  I did the verification myself for precise IIRC.21:54
sarnoldinfinity: nice to know it isn't immediately fatal :) but still... *sniff*21:55
infinitybryce: I tend to try to verify most of my own uploads these days, just to avoid the frustration of others not doing so.21:55
bryceinfinity, I'm tempted to install an oneiric build just to do the same here, but not a great use of a couple hours...21:55
infinity(I realize as I say this that I currently have an unverified SRU in precise that I need to do something about...)21:55
bryceinfinity, yeah me too where I can.  With X, so many problems are HW-specific though21:55
bdmurrayI guess with X bugs its harder to verify them yourself21:55
hallyninfinity: though i thought technically the rules, uh, 'encouraged' the bug fixer not doing the verifications?21:56
infinityYeah, X and kernel are both problematic that way.21:56
hallynstill i try to give it a week and then go and verify21:56
infinityhallyn: I have zero issues with the fixer actually verifying.  I have issues with the fixer rubber-stamping it without actually testing the binaries.21:56
hallyninfinity: that's good to know21:57
infinityhallyn: The latter case is the reason I *prefer* the submitter verifying, only because he has a vested interest in actually testing it instead of lying.21:57
bryceinfinity, also in solving the bugs we often identify some work around for the user to test, and often the user is just fine sticking with that workaround, so we lose them for testing the "real" fix.21:57
infinityhallyn: But it comes down to trust, to a certain degree.  And I trust some uploaders not to lie to me or cut corners. :P21:57
hallyninfinity: haha, given the embarassment of the fix not fixing it, i do feel like as fixer i ahve a vested interest :)  but i understand21:57
infinityhallyn: It's generally a combination of laziness and hubris.  If you're *sure* your change was correct, you'll feel like you can totally fudge the paperwork and no one will notice.21:58
infinityhallyn: And then when you're wrong, well.  Grr.21:58
infinityhallyn: So, just don't do that (which I'm pretty sure *you* don't), and it's all good.21:58
infinitybryce: Yeah, the workaround thing can be doubly problematic, if you get them to mangle a conffile or something, and they forever are unable to correctly test the upgraded package against an unmodified setup due to a subsequent communication failure.22:00
infinitybryce: But, such is life.  Oh how I wish we had a massive community QA team who could independently repro/verify half these bugs.22:01
infinity(On the other hand, I'd also like to see fewer SRUs, so...)22:02
infinityI do think the knee-jerk of "I fixed a bug in release X, and I must not backport it to A, B, and C is just not scaleable at all.22:02
infinityI don't have issues with us adding a ton of polish to LTS releases, but we could do with a lot fewer SRUs to interim releases for non-critical bugs, IMO.22:03
infinitys/must not/must now/ up there.  Man, I can't type today.22:03
hallyninfinity: actually openstack and juju are making that worse i think - everyone wants the fixes backproted to precise so it'll work in juju.  Which is understandable, but more work.22:04
=== cr3_ is now known as cr3
infinityhallyn: Well, like I said, I don't mind the precise SRUs, per se.  But we have a ton of quantal ones, and even a fair few oneirics still, and the reason is because uploaders say "well, this patch applies cleanly to all three releases, it's almost zero effort for me to SRU them all".22:05
=== cr3 is now known as Guest95022
infinityhallyn: And that's true.  But they're not thinking of the burden of post-upload verification and release for what is, 99% of the time, not a critical bug.22:06
infinityIMO, for non-LTS releases, if it install, boots, doesn't blow up your hardware, and gets security fixes, we're more or less done.22:06
infinity(Yes, there are ciritcal bugs that don't fit in that broad scope, but you get the idea)22:06
hallyninfinity: yeah22:08
infinityhallyn: Now, we don't want to cause massive regressions when upgrading through releases, of course, but "this image is a bit less pretty than I think it should be" or "there's a typo in this thing over here" or whatever isn't really much of a regression.  And the answer is always "well, upgrade to the next release, then, it's fixed there, because all SRUs have to be fixed in our current devel release".22:09
infinityAll of this is probably just me accidentally arguing for getting rid of interim releases altogether and only doing LTSes, but let's pretend I didn't say that out loud, cause we're not even ready to discuss that sort of thing yet, and I'm also not sure which side of that fence I'm personally on. :P22:11
slangasekor better yet: "hey, you know we have a constantly-usable trunk in our devel release now"22:11
infinityslangasek: Jinx.  Ish.22:11
infinityA curious side-effect of ditching interim releases (if we were to do so) is that LTSes might get better support from the usual SRU overachievers.22:12
infinityCause the people who currently feel they need to SRU to quantal/precise/oneiric would instead look into backporting to precise/lucid/hardy.22:13
dobey2 years is a very long time; some of the differences are just not reconcilable with simple SRUs22:14
infinitydobey: Sure, and that's almost a positive.  Cause many bugs aren't worth SRUing back to old LTSes when the answer should be "sorry, upgrade to precise if you want that fixed".22:15
dobeyshipping unity on lucid would be fun though22:15
infinitydobey: But there are also a lot of bugs that probably SHOULD be fixed in older LTSes that get ignored in favour of people fixing things in oneiric for very little benefit.22:15
infinitydobey: So, meh.  It's hard to debate how it would actually turn out.  But I suspect less focus on interim releases would both reduce the SRU workload and accidentally produce a few more fixes for old LTSes in the process.22:16
dobeybut i wouldn't say that is entirely becuase interim releases exist22:16
infinitydobey: No.  There are any number of reasons people don't fix bugs in older releases.  Sometimes, it's too hard, sometimes it's easy but they just don't personally see the value, etc, etc.22:17
infinityBut hey, I don't see the value in fixing anything but hardware-exploding critical bugs in oneiric either, and people do it.22:17
dobeythere'd probably be a few more fixes making it back, but i wouldn't guess that it would be a significantly useful increase22:17
infinityIf those same people had oneiric taken away from them, they'd need an outlet, right? :)22:17
infinitydobey: Anyhow, all just random stream of consciousness faff.  It's not like we're planning to announce the end of the 6 month release cycle any time soon.22:18
dobeyyeah i know22:18
infinity(Though, I suspect you'll hear more discussion about it off and on leading up to 14.04)22:18
dobeyhave heard plenty of faffing about it over the past several cycles already as well :)22:19
bryceinfinity, I'm coming to be of the same opinion vis a vis SRUs for interim releases, although usually once you've sorted out the backport for A (stable) and C (LTS), the fix for B is almost for free anyway.22:19
slangasekbryce: the uploading is almost for free, the verification is a huge cost22:21
dobeyalthough i'd also presume that if we do kill off interim releases and only do LTS, that we'll end up just doing LTS every 12 or 6 months, and have similar problems with getting more fixes backported; especially with LTS being 5 years across the board now22:21
slangasek"LTS every 12 or 6 months" - certainly not :)22:22
hallynlts every 6 months?22:22
bryceslangasek, exactly - the verification cost is why I'm coming to this opinion.22:22
dobey18-24 month releases are nice for having more development time, but also a huge drain. spending a year doing a bunch of work and then having all your requirements change for the release, is not fun :)22:24
=== cr3_ is now known as cr3
=== ximion1 is now known as ximion-afk
=== ximion-afk is now known as ximion1
=== zequence_ is now known as zequence
=== zequence_ is now known as zequence
=== cpg|away is now known as cpg
bdmurrayroaksoax: isc-dhcp has been sitting in precise-proposed for a long time because bug 974284 and bug 727837 are unverified23:18
ubottubug 974284 in isc-dhcp (Ubuntu Precise) "invoking dhclient3 with -1 causes issue if no dhcp server available" [High,Fix committed] https://launchpad.net/bugs/97428423:18
ubottubug 727837 in dhcp3 (Ubuntu Hardy) "dhcp3-server fails to drop privileges properly" [Undecided,Confirmed] https://launchpad.net/bugs/72783723:18
cjwatsonstgraber,hallyn,infinity: this is all already fixed in Debian/experimental/bzr and precise-proposed, just not yet in raring23:19
Kanohi, who works on secure boot? just got a board with it but kubuntu did not boot but fedora did23:21
stgraberbdmurray: I guess I can confirm those two if you want. But I'm the author for both patches and the uploader, so not ideal :)23:23
bdmurraystgraber: I thought infinity was just saying that was fine23:24
stgraberbdmurray: yeah, I tend to self-verify my SRUs when nobody else does it and I actually care about the fixes, those two I really don't care about so didn't bother verifying :)23:25
stgraberbdmurray: marked both verification-done23:26
infinitycjwatson: Ahh, I think stgraber's assumption was that raring and precise-proposed had the same behaviour, if that's not true, yay.23:27
stgraberinfinity: that was my assumption based on the, upload to dev before sruing habit, I didn't actually diff the scripts to check :)23:28
cjwatsonRight, I make sure it's committed *somewhere* so it doesn't get lost, but I consider "repository that will definitely end up in raring at some point before release" as acceptable23:29
cjwatsonI'm doing an experimental build now anyway23:29
=== chiluk is now known as chiluk_away

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