| RAOF | SpamapS: With linux 3.1? | 00:03 |
|---|---|---|
| SpamapS | RAOF: been following this https://help.ubuntu.com/community/MacBookAir4-2 | 00:12 |
| SpamapS | RAOF: not sure which magical thing it did to enable the graphics, but it disabled the touchpad :( | 00:13 |
| SpamapS | ahh | 00:13 |
| SpamapS | it patched bcm5974 for the 4,2 | 00:13 |
| SpamapS | but the 4,1 only seems to work with the regular 3.0.0-12-generic version | 00:14 |
| SpamapS | all is well now | 00:14 |
| * SpamapS does a dance | 00:14 | |
| SpamapS | XRANDR .. [check] | 00:17 |
| SpamapS | ooo suspend/resume even works | 00:18 |
| * SpamapS can actually consider *not* lugging his 15" MBP to UDS now | 00:18 | |
| SpamapS | w00t | 00:19 |
| === dendro-afk is now known as dendrobates | ||
| RAOF | @pilot in | 00:25 |
| === udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: RAOF | ||
| === AaronMT|away is now known as AaronMT | ||
| === dendrobates is now known as dendro-afk | ||
| RAOF | Bah. It's really annoying that I can't change the status on any of these merge proposals. | 01:16 |
| micahg | RAOF: you need a tech board member most likely | 01:20 |
| RAOF | Yeah, I know. | 01:21 |
| broder | it's unfortunate that nobody actively working on udd is on ~ubuntu-branches | 01:21 |
| RAOF | Or to be a member of ubuntu-branches. | 01:21 |
| broder | otherwise i would advocate the "harass them until they fix it" approach | 01:21 |
| RAOF | James Westby's in ~ubuntu-branches :) | 01:22 |
| broder | i thought he was doing linaro stuff these dyas | 01:22 |
| RAOF | Oh, yeah. He is, isn't he. Damn! | 01:22 |
| ajmitch | that would make things a bit awkward | 01:23 |
| ajmitch | maybe the TB should be asked to look at the ownership of those branches | 01:24 |
| === luist_ is now known as luist | ||
| stgraber | RAOF: either poke me with the changes you want or make a list in your e-mail to ubuntu-devel (assuming you'll send one at the end of your shift) | 01:48 |
| RAOF | stgraber: Ta. I'll be sure to list them all in an email then. | 01:50 |
| smoser | how do i force debuild to create a .dsc that references the .orig file ? | 02:06 |
| micahg | smoser: -S -sa | 02:07 |
| smoser | thank you, kind sir. | 02:09 |
| micahg | you're welcome | 02:09 |
| wgrant | RAOF/micahg: Or escalate the bug. | 02:18 |
| RAOF | wgrant: Know what that bug is, offhand? | 02:19 |
| lifeless | broder: james_w is in online services now | 02:19 |
| wgrant | lifeless: Wha? | 02:19 |
| wgrant | When did that happen? | 02:19 |
| lifeless | danilo -> linaro | 02:19 |
| lifeless | james_w -> jml's offsider | 02:19 |
| wgrant | Ah, interesting. | 02:19 |
| wgrant | Makes sense, though :) | 02:20 |
| wgrant | RAOF: Bug #540250 looks relevant, but is meant to be fixed... | 02:20 |
| ubottu | Launchpad bug 540250 in Launchpad itself "Cannot edit merge proposals for packaging branches" [High,Fix released] https://launchpad.net/bugs/540250 | 02:20 |
| === dendro-afk is now known as dendrobates | ||
| wgrant | Ahh. | 02:21 |
| wgrant | Now I remember. | 02:21 |
| wgrant | RAOF: What's an example merge proposal? | 02:21 |
| wgrant | Is it for a stable series? | 02:21 |
| RAOF | wgrant: Yes, I think they are. | 02:22 |
| RAOF | is ahttps://code.launchpad.net/~om26er/ubuntu/natty/libdbusmenu/dbusmenu-fix-618587/+merge/71892n is an example. | 02:22 |
| wgrant | Right. | 02:22 |
| wgrant | That would be the problem. | 02:22 |
| wgrant | MP edit access is delegated to people with edit access on the branch. And upload permissions don't grant branch write access to stable series. | 02:23 |
| wgrant | Because those branches are meant to be frozen. | 02:23 |
| wgrant | I'm not sure if there is a bug for this... | 02:23 |
| RAOF | Aha. | 02:23 |
| micahg | smoser: you also want to use -vOLD_UBUNTU_VERSION when merging from Debian | 02:23 |
| wgrant | Bug #612391 | 02:24 |
| ubottu | Launchpad bug 612391 in Launchpad itself "Cannot change status for merge proposals that target a released series" [High,Triaged] https://launchpad.net/bugs/612391 | 02:24 |
| wgrant | If you can escalate that, it might get done :) | 02:24 |
| smoser | micahg, thanks... too late though. i should have know that. | 02:24 |
| micahg | smoser: I try to remember to check the source.changes file to make sure the other entries are there before uploading | 02:25 |
| RAOF | wgrant: Sweet, thanks for that. | 02:26 |
| slangasek | YokoZar: multiarching -dev packages> that's not relevant, you don't get to build-depend on packages other than those for the current arch... | 02:53 |
| YokoZar | slangasek: Err yeah you're right, multiarch is the solution that works around that problem | 02:53 |
| YokoZar | slangasek: cause we build the 32-bit bits on 32 that have the 32 bit dev packages | 02:54 |
| slangasek | yep - at least, I hope it works around it :) | 02:54 |
| YokoZar | slangasek: do you know the status of OpenCL by chance? | 02:55 |
| RAOF | Just as long as the WoW64 stuff can use the 32bit build :) | 02:55 |
| YokoZar | RAOF: Yup. I may have to do some weird copying in the package build script though, as we (unusually) want some files to be part of multiple packages here | 02:56 |
| YokoZar | RAOF: namely in the 32 bit package as well as the 32 bit foreign package | 02:56 |
| slangasek | the 32-bit package is not a different package than the 32-bit foreign package | 02:56 |
| slangasek | it's one package, built on i386 and installable on either i386 or amd64 | 02:57 |
| YokoZar | slangasek: actually nevermind, that's the proper way to do it, have the 32 bit-only package depend on that too | 02:57 |
| slangasek | yep | 02:57 |
| slangasek | YokoZar: I don't think I know what opencl is | 02:57 |
| YokoZar | slangasek: It's the library for getting the graphics cards to do GPU tasks without actually being 3d rendering, if I remember right | 02:58 |
| slangasek | YokoZar: ok; not my department :) | 02:58 |
| micahg | slangasek: I thought that the amd64 buildds could use 32 bit packages, is that not correct? | 02:58 |
| YokoZar | Current Linux implementations may be driver specific (eg, only in the proprietary NVidia packages...despite the openness) | 02:58 |
| slangasek | micahg: nope | 02:59 |
| YokoZar | micahg: You can depend on a package that only has a 32 bit component, but you can't build-depend on that. | 02:59 |
| slangasek | micahg: there's no way to specify it in build-deps, for starters | 02:59 |
| micahg | slangasek: so how does one build a 64 bit app that has some 32 bit components? | 02:59 |
| YokoZar | micahg: The rationale for this that made the most sense when I was learning it to just imagine that each architecture has to be built separately and independently. So things like cross-arch build-deps don't work, while binary dependencies do (unless your package itself is a reverse depends...) | 03:00 |
| * micahg thought wine was like that | 03:00 | |
| slangasek | micahg: if it requires anything beyond the compiler and libc to build the 32-bit stuff, it should be done as an i386 package and use multiarch to install it | 03:00 |
| micahg | ok | 03:01 |
| YokoZar | micahg: This is why we're discussing Wine, as it needs some unusual splitting to make 64/32 mode work on 64. The executive summary is the 32-bit parts are being built on 32. | 03:01 |
| YokoZar | whereas in oneiric they're built on 64 via ia32-libs | 03:01 |
| RAOF | YokoZar: What are you particularly interested in re: OpenCL? | 03:02 |
| micahg | I guess that makes sense, someone had a question a few weeks ago about pbuilder using the amd64 and i386 sources, I guess I gave the wrong answer (I thought that was normal for oneiric) | 03:02 |
| YokoZar | RAOF: Wine already has an implementation of it so any Windows app that uses it would need it to work | 03:02 |
| YokoZar | RAOF: I'm not sure what Windows apps use OpenCL off the top of my head though | 03:04 |
| RAOF | YokoZar: Ah, ok. Currently there's no real solid open implementation standardised, which means there's no standard way to depend on it. In the P+1 timeframe I'd expect us to have an open implementation, possibly even in precise. | 03:04 |
| YokoZar | RAOF: Well, I hope I can speed things along by being your use case then ;) | 03:04 |
| RAOF | Hm. There doesn't seem to be a Khronos ABI for OpenCL. Fundamentally it's likely that you'll end up wanting to Depend: or Recommend: libcl1 or somesuch. | 03:08 |
| pitti | Good morning | 04:02 |
| pitti | jcastro: right now it says "error updating", but will try later | 04:02 |
| ajmitch | morning pitti | 04:02 |
| pitti | hey ajmitch, how are you? | 04:02 |
| ajmitch | good, how are you? | 04:02 |
| pitti | pretty well, although still a bit tired, thanks! | 04:03 |
| * ajmitch wishes that the long weekend here was a few days longer :) | 04:03 | |
| RAOF | @pilot out | 04:23 |
| === udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| === yofel_ is now known as yofel | ||
| === sraue_ is now known as sraue | ||
| pitti | doko_: FYI, keeping binutils in proposed queue, as the previous SRU hasn't been verified yet | 05:09 |
| pitti | doko_: if you want the second upload in -proposed now, please reupload with -v to include the previous changelog | 05:09 |
| pitti | slangasek: how did you build samba? http://launchpadlibrarian.net/83357418/samba_3.5.11~dfsg-1ubuntu2.1_source.changes doesn't have a Launchpad-Bugs-Fixed: header | 05:13 |
| micahg | pitti: FYI, bug 881250, SRU period might need to be truncated | 06:54 |
| ubottu | Launchpad bug 881250 in tzdata (Ubuntu) "Clocks in Ukraine move back October 30, 2011" [High,Triaged] https://launchpad.net/bugs/881250 | 06:54 |
| pitti | micahg: yes, we generall move them to -updates right after verification, as they often tend to be urgent | 06:54 |
| pitti | there's a tzdata 2011m already | 06:54 |
| micahg | right, already in unstable | 06:55 |
| === tkamppeter__ is now known as tkamppeter | ||
| tkamppeter | pitti, are you not on the Sprint? | 07:07 |
| pitti | tkamppeter: no, I'll arrive on the weekend; only for UDS | 07:07 |
| tkamppeter | pitti, interesting, as technical lead of the desktop team. | 07:07 |
| dholbach | good morning! :) | 07:07 |
| pitti | tkamppeter: it's a DX sprint | 07:08 |
| pitti | tkamppeter: seb128 and didrocks are there | 07:08 |
| tkamppeter | pitti, OK, thought it was an all-Canonical Sprint. | 07:08 |
| tkamppeter | pitti, good to know to know who is in which time zone currently. | 07:09 |
| cjwatson | wgrant: I'm pretty sure it's not just that bug. During the Oneiric release cycle, well after that bug was fixed, developers were unable to reject MPs for Oneiric branches. | 07:46 |
| wgrant | cjwatson: That's worrying. If you can find a current example, I would love to see it. | 07:47 |
| cjwatson | wgrant: Try bug 728012 instead. | 07:47 |
| ubottu | Launchpad bug 728012 in Launchpad itself "ubuntu developers are not able to reject merge proposals on official packaging branches they can upload to" [High,Triaged] https://launchpad.net/bugs/728012 | 07:47 |
| micahg | cjwatson: he later added Bug #612391 | 07:47 |
| ubottu | Launchpad bug 612391 in Launchpad itself "Cannot change status for merge proposals that target a released series" [High,Triaged] https://launchpad.net/bugs/612391 | 07:47 |
| wgrant | Let's see. | 07:47 |
| cjwatson | micahg: Indeed, but AFAIK this still happens for development series. | 07:47 |
| micahg | ah | 07:48 |
| cjwatson | wgrant: Unfortunately I have sufficient privilege that it's hard for me to hunt out an example myself, but I guess anything for precise on the sponsoring list should do it. | 07:48 |
| wgrant | The problem here is probably that upload permissions don't grant review privileges. | 07:49 |
| wgrant | And there's no review team set. | 07:50 |
| wgrant | So only ~ubuntu-branches has those superpowers... hm. | 07:50 |
| micahg | wgrant: here's an example: https://code.launchpad.net/~samuel-taylor/ubuntu/oneiric/pidgin-skype/fix-for-657125/+merge/75701 | 07:50 |
| cjwatson | I think we'd like it to be keyed off upload permissions rather than setting a single team. | 07:51 |
| cjwatson | micahg: that's a released series | 07:51 |
| wgrant | cjwatson: Indeed. | 07:51 |
| micahg | I don't think I could've changed it before eitehr | 07:51 |
| wgrant | It currently checks for membership in one of (branch owner, branch reviewer, LP admin). | 07:51 |
| wgrant | Which made sense until package branches. | 07:51 |
| wgrant | Because branch editing was restricted to the branch owner and LP admins. | 07:51 |
| jamespage | does anyone know if there is a tool already in main that will convert markdown to html? | 07:52 |
| wgrant | So isPersonTrustedReviewer should probably just check if they can edit the branch or are in the review team. | 07:52 |
| micahg | I can change this one: https://code.launchpad.net/~barry/ubuntu/precise/ubuntu-dev-tools/bug-881049/+merge/80253 | 07:52 |
| ubottu | Launchpad bug 80253 in debconf (Ubuntu) "Can't launch ubiquity on 20070117 feisty-desktop-i386.iso" [Undecided,Fix released] | 07:52 |
| wgrant | micahg: To Approved/Rejected? | 07:53 |
| tumbleweed | jamespage: python-docutils | 07:53 |
| micahg | wgrant: no, but I don't think I can ever set those | 07:53 |
| wgrant | Right, that's the bug. | 07:53 |
| cjwatson | micahg: I can; that's the bug. | 07:53 |
| jamespage | tumbleweed: sweet - thanks for the pointer | 07:53 |
| micahg | cjwatson: wgrant: sorry for the noise | 07:54 |
| cjwatson | that's ok | 07:54 |
| cjwatson | man, switching from homegrown scripts to pull-lp-source and pull-debian-source has improved my life surprisingly much | 07:55 |
| pitti | I find them quite nice, saves having tons of deb-src lines | 07:56 |
| pitti | s/saves/avoids/ | 07:56 |
| pitti | jcastro: guidebook seems better now, thanks! | 08:22 |
| jamespage | @pilot in | 08:33 |
| === udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jamespage | ||
| * dholbach hugs jamespage | 08:34 | |
| \sh | doko_, do you mind when I take some of the universe packages (from MoM) with your last uploader name tag? | 09:36 |
| jamespage | why can I 'Reject' some merge proposal but not others? | 09:36 |
| * jamespage scratches his head | 09:36 | |
| lifeless | jamespage: natty / not-natty | 09:46 |
| lifeless | jamespage: there is a bug. | 09:46 |
| doko_ | \sh, not at all | 09:51 |
| === doko_ is now known as doko | ||
| doko | pitti, can we move the first one to -updates first? | 09:51 |
| pitti | doko: that's what happens by default if you don't want to replace the current SRU, yes | 09:56 |
| pitti | (still needs verification, as I said) | 09:56 |
| \sh | doko, thx | 09:59 |
| \sh | btw...are there any hints on how to fix format-security issues? | 09:59 |
| doko | pitti, done the verification | 09:59 |
| pitti | \sh: usually it's from something like printf(variable), i. e. handing a non-constant string to a function which evaluates % format codes | 10:05 |
| pitti | \sh: a common pattern is to prepend a "%s", if you really don't want interpolation | 10:05 |
| \sh | pitti: I just saw this error inside | 10:07 |
| \sh | pitti: I just saw this error inside a function which is using gtk_message_dialog_new | 10:07 |
| \sh | and I'm not sure if gtk_message_dialog_new(...,...,...,...,"%s",message) is enough | 10:08 |
| pitti | \sh: using "%s" for the message will work fine | 10:08 |
| pitti | \sh: as I said, it depends: if message is _supposed_ to have format strings in it, then this will break | 10:08 |
| pitti | but if it's not, then "%s" is fine; then any % characters in message will appear verbatim | 10:09 |
| \sh | pitti, kk :) thx :) | 10:10 |
| Daviey | !regression-alert | 11:48 |
| ubottu | cjwatson, jdong, pitti, skaet, ScottK, kees, Daviey, pgraner: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive | 11:48 |
| Daviey | bug 881361, impact not yet determined. Non-default package. | 11:48 |
| ubottu | Launchpad bug 881361 in puppet (Ubuntu Precise) "puppetmaster-passenger fails to install with puppet 2.6.4-2ubuntu2.5" [High,Confirmed] https://launchpad.net/bugs/881361 | 11:48 |
| Riddell | jasoncwarner_: can you approve the desktop-p-kubuntu specs for uds-p please https://blueprints.launchpad.net/sprints/uds-p?searchtext=kubuntu | 11:57 |
| jamespage | @pilot out | 12:10 |
| === udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| jdstrand | Daviey: mdeslaur is looking into it now | 12:10 |
| Daviey | jdstrand: yep, tracking in #ubuntu-server. Thanks. | 12:17 |
| === kenvandine is now known as kenvandine[flush | ||
| === kenvandine[flush is now known as kenvandine_afk | ||
| mterry | @pilot in | 12:35 |
| === udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry | ||
| === yofel_ is now known as yofel | ||
| sabdfl | hello folks | 13:05 |
| ogra_ | hey sabdfl | 13:06 |
| pitti | hey sabdfl, how are you? | 13:08 |
| sabdfl | great thanks pitti, enjoying orlando already :-) | 13:08 |
| pitti | sabdfl: twisting^Wsprinting by the pool ♪ ♫ ? | 13:09 |
| ogra_ | pitti, grrr, you implanted an earworm ! | 13:09 |
| ogra_ | :) | 13:09 |
| ion | Not to me. | 13:09 |
| * ogra_ guesses thats a matter of age :) | 13:10 | |
| ogra_ | or of musical taste | 13:10 |
| mdeslaur | pitti: it seems linux-ec2, linux-mvl-dove and linux-fsl-imx51 on lucid got binaries demoted to universe...was that intentional, or a script error? | 13:33 |
| mdeslaur | pitti: I got them moved now, but want to make sure it's not a script issue | 13:33 |
| === Quintasan_ is now known as Quintasan | ||
| GunnarHj | pitti: are you there? | 13:39 |
| jamespage | doko: OK if I pickup the jffi merge? its borked at the moment in precise | 13:40 |
| doko | jamespage, sure | 13:42 |
| jamespage | doko: ta | 13:43 |
| === kenvandine_afk is now known as kenvandine | ||
| === zyga is now known as zyga-afk | ||
| psusi | do I have to register for UDS if I'm not staying in the hotel ( I live nearby ), or can I just drop by? | 14:25 |
| ogra_ | psusi, you should register in LP, so people know you are there and can i.e. subscribe you to sessions they want you to attend etc | 14:26 |
| ogra_ | its not about the hotel, but about the automatic scheduler that needs to know you are there | 14:26 |
| psusi | ok | 14:27 |
| ogra_ | 8unless you just want to hang out in corridors indeed :) ) | 14:27 |
| jcastro | psusi: please register in LP, that's how they figure out the food and stuff | 14:27 |
| ogra_ | oh, food, right :) | 14:28 |
| * ogra_ forgot about that unimportant bit | 14:28 | |
| psusi | hehe.... I'm not sure how much time I can get away from work to get over there, but I definately want to do some meet and greet as long as everyone's in town | 14:30 |
| jcastro | that would be awesome | 14:30 |
| RoAkSoAx | is merges.u.c no longer been updated? | 14:37 |
| jbicha | I was surprised at my first UDS that lunch was included for all attendees, free OS and free food? sweet! | 14:37 |
| tumbleweed | RoAkSoAx: it should be. Don't forget we're syncing from testing | 14:39 |
| cjwatson | it's running right now, indeed | 14:39 |
| cjwatson | looks healthy to me | 14:39 |
| RoAkSoAx | tumbleweed: ahh right!! | 14:39 |
| RoAkSoAx | thought we were from unstable | 14:40 |
| tumbleweed | cjwatson: any opinions on bug 881288? you were vaguely around for that conversation... | 14:40 |
| ubottu | Launchpad bug 881288 in ubuntu-sponsoring "Syncs using the LP API are showing up as sponsored uploads" [Undecided,New] https://launchpad.net/bugs/881288 | 14:40 |
| cjwatson | I'm afraid I've been failing to get my head around the details of that thus far | 14:41 |
| cjwatson | it's probably better to bring it up with LP folks | 14:42 |
| tumbleweed | ok, I'll file a bug | 14:42 |
| hallyn | Was trying bzr merge-package again; is there a reason why it doesn't first pop all quilt patches and rm -rf .pc in both trees? | 14:47 |
| slangasek | pitti: samba> oh, sorry, built it in a Debian env by mistake, forgot to watch out for the closure header | 15:09 |
| Daviey | slangasek: Hey! Are you looking at the samba issue? | 15:10 |
| slangasek | Daviey: no | 15:10 |
| slangasek | I was looking at an unrelated samba issue | 15:11 |
| Daviey | slangasek: Would you be able to, please? :) | 15:12 |
| Daviey | over 100 dupes now :( | 15:12 |
| pitti | mdeslaur: no, of course not intentional -- it's the usual "LP picks random components" problem; I thought that would be uncovered during verification | 15:33 |
| mdeslaur | pitti: ok, cool, thanks | 15:34 |
| === zyga-afk is now known as zyga | ||
| dobey | anyone notice any issues with builders? i uploaded something to my PPA 40 minutes ago, and LP is saying "Start 2011-10-26" | 15:54 |
| slangasek | Daviey: I certainly don't hold a maintainer lock on the Ubuntu package, I'm not sure why it waits on me - there seem to be several different proposals for addressing it, someone should just pick one and upload it? | 15:55 |
| Daviey | slangasek: Well, there reason i'm turning to you is because you were vocal in the discussion - and clearly understand the package and issue. | 15:57 |
| slangasek | Riddell: ScottK has a significant number of merges that he's TIL on for https://merges.ubuntu.com/main.html - with him taking a break, are these a concern for the Kubuntu team? | 15:58 |
| slangasek | Daviey: sorry, I probably should have just kept my mouth shut on the bug to begin with ;) I was meaning only to provide a historical perspective of why the code is the way it is | 15:58 |
| rbasak | slangasek: this is also a Debian bug and you're a maintainer :-) | 15:59 |
| slangasek | rbasak: yeah, but the bug hasn't been tripped in Debian yet and I'm likely to be painfully slow about deciding how I want to fix it there | 15:59 |
| slangasek | so you guys should pick whatever fix that you think is appropriate to cover the gap now | 16:00 |
| Daviey | slangasek: Well, the frustrating thing is that we could have had 'a' fix before release, but we held back pending a better solution. | 16:00 |
| rbasak | slangasek: wouldn't it be nice if debian and ubuntu agreed how to fix it so we don't have to carry a delta and/or the delta gets carried upstream? | 16:00 |
| * Daviey launches a *sigh* | 16:00 | |
| rbasak | slangasek: it's just a waste of effort if we fix it one way and then debian chooses to fix it another | 16:01 |
| slangasek | rbasak: it's easy enough to fix it twice and in the meantime it's causing pain for users | 16:01 |
| slangasek | so more effort is being wasted talking / worrying about it than would be wasted by implementing 2 different fixes | 16:01 |
| === beuno is now known as beuno-lunch | ||
| rbasak | Well I did submit a patch and it got rejected on the basis of being unsuitable. So I'm still waiting to hear from somebody what will be suitable. | 16:02 |
| Daviey | cjwatson: Do you have thoughts on this? | 16:03 |
| rbasak | Or should I just keep submitting patches without any feedback in the hope that one will be acceptable? | 16:03 |
| Daviey | It is really, really frustrating that we blocked on this for us to just throw anything into an SRU | 16:03 |
| infinity | rbasak: I don't think your patch would have fixed it anyway, after we investigated what was happening. | 16:04 |
| rbasak | infinity: fine, but that's not my point. | 16:06 |
| slangasek | Daviey, rbasak: frankly, I think the *right* fix is to make update-inetd more robust by not depending on perl-modules; but that's not quick, and won't necessarily help the current round of upgrade breakage | 16:06 |
| infinity | rbasak: Mangling update-inetd to not require perl-modules would certainly help, but it won't necessarily be upgraded before samba, which is irksome. | 16:06 |
| htorque_ | hi all! i sent a mail to -devel which didn't yet come through. anything wrong with it? | 16:07 |
| cjwatson | Daviey: at this point I am not sure that adding another semi-informed opinion is going to help matters; too many cooks and all that | 16:10 |
| cjwatson | my opinion was to move update-inetd to the prerm, but AIUI slangasek had a reason not to do that | 16:11 |
| slangasek | I had a reason why I didn't think update-inetd in the prerm was actually the right thing to do | 16:11 |
| slangasek | doesn't mean it's not an appropriate workaround to fix users' upgrades in this case | 16:11 |
| infinity | Actually, it doesn't solve the upgrade issue. | 16:12 |
| slangasek | also, I'm still not sure update-inetd is guaranteed to be reliable in that case | 16:12 |
| infinity | It's not. | 16:12 |
| slangasek | because unpack perl -> unpack samba -> unpack perl-modules would still break | 16:12 |
| infinity | The real problem is that perl-modules is completely broken when it's half-configured during the 5.10->5.12 transition. | 16:12 |
| infinity | What's curious is that unpacking perl-modules 5.12 on a clean system allows update-inetd to work fine. :/ | 16:13 |
| infinity | It's only the bizarre half-upgraded state that breaks. | 16:13 |
| infinity | Making the release upgrader forcefully re-order perl/perl-modules to upgrade as a unit might work around it, but it's obviously not the solution. | 16:14 |
| cjwatson | well, that's because the modules all move from /usr/lib/perl/5.10 to 5.12 ... | 16:15 |
| cjwatson | (isn't it perl-base/perl-modules that matters?) | 16:15 |
| infinity | Err, that. | 16:15 |
| slangasek | so as I look at the postrm, I'm actually not sure at all why the non-purge case is being handled here instead of in prerm | 16:15 |
| slangasek | and we probably should just move that | 16:16 |
| infinity | slangasek: Oh, I'm still convinced the maintainer scripts are a bit wrong, but either way, changing them won't actually make a difference here. | 16:16 |
| infinity | The synthetic reproduction of the bug isn't actually the bug that's being duped 100 times (the latter is an upgrade thing, not people removing/purging in weird orders) | 16:17 |
| Riddell | slangasek: we'll get them done right enough, although I'm on holiday for the two weeks after UDS so it may not be immediate | 16:17 |
| slangasek | yes | 16:17 |
| slangasek | Riddell: ok - no hurry, just thought I'd check if it's something on your radar | 16:18 |
| elgaton | Hi, I'm fixing a small bug (missing dependency in debian/control) and have a few questions: 1) should I generate the patch against the debian/ directory only (as explained in https://wiki.ubuntu.com/MOTU/Contributing) or a debdiff? 2) Since I need to get a sponsor for my patch and I'm working on the fix, is it right to subscribe ubuntu-sponsors and add the "patch" tag to the LP bug, but to set the bug status to "In Progress" and assign it to myself? | 16:18 |
| elgaton | Thanks. | 16:18 |
| slangasek | infinity: right - I just looked at tkamppeter's report, and see no perl, so perl-modules is already broken by that point | 16:18 |
| cjwatson | however, if it were in the prerm, then you could force things with Depends: perl, couldn't you? | 16:21 |
| slangasek | nope | 16:21 |
| infinity | Depends gives you unpacked, not configured. | 16:21 |
| slangasek | this is the "everything's ok, we're just upgrading and things are currently broken, don't mind our dust" | 16:21 |
| slangasek | infinity: er, no | 16:21 |
| rbasak | yeah I couldn't find a way to simulate what's happening during an upgrade as dpkg doesn't have an --unconfigure that I could find, so I had to do combinations of --purge and --unpack. So I triggered _a_ problem with the same root cause, but not the problem people are seeing | 16:21 |
| cjwatson | if you get the sequence of unpack/configure events, you could issue them by hand starting from a natty chroot | 16:22 |
| slangasek | infinity: depends is meant to give you configured; it's just that there are corner cases where configured doesn't mean usable. ;) | 16:22 |
| Daviey | (sorry for being absent, chairing a meeting) | 16:22 |
| slangasek | (because dpkg doesn't care that a dependency of an already-configured package has been removed) | 16:23 |
| cjwatson | slangasek: update-inetd configured doesn't mean usable in this case, but perl configured should | 16:23 |
| cjwatson | or maybe perl-modules configured | 16:23 |
| infinity | slangasek: Eh? perl-modules is pretty clearly unconfigured in these upgrade logs. | 16:23 |
| slangasek | infinity: can you give me an example log? | 16:24 |
| slangasek | (that shows perl state) | 16:24 |
| Daviey | btw, there are two tracking bugs now | 16:24 |
| infinity | slangasek: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/856309 | 16:25 |
| ubottu | Launchpad bug 862129 in samba (Ubuntu Precise) "duplicate for #856309 samba postrm depends on packages not guaranteed to be configured" [High,Triaged] | 16:25 |
| Daviey | bug 877852 is the second master bug (due to LP bug) | 16:25 |
| ubottu | Launchpad bug 877852 in samba (Ubuntu) "samba failed to install when updating from ubuntu 11.04 to 11.10" [Undecided,Confirmed] https://launchpad.net/bugs/877852 | 16:25 |
| slangasek | infinity: oh, that's interesting; it shows both of perl and perl-modules unpacked at version 5.12 | 16:26 |
| slangasek | and actually, at this stage there's no strong guarantee that the dependencies are even unpacked, let alone configured... only postinst gets that as a hard guarantee | 16:26 |
| slangasek | (but apt tries to DTRT) | 16:27 |
| slangasek | possibly the problem is perl-base not being unpacked yet? | 16:27 |
| infinity | slangasek: perl-base is configured. | 16:27 |
| slangasek | sure | 16:28 |
| slangasek | but not at the new version? | 16:28 |
| infinity | slangasek: Yes. | 16:28 |
| infinity | slangasek: Search through the terminal log. | 16:28 |
| slangasek | oh | 16:28 |
| slangasek | right, found it | 16:28 |
| infinity | slangasek: perl-modules is unpacked, perl-base is unpacked and configured, samba explodes, perl-modules is never configured. | 16:28 |
| slangasek | this is what we get for using unreliable interpreters like perl; let's rewrite update-inetd in python | 16:29 |
| infinity | I'm too sick to detect reliably if that was sarcasm. | 16:30 |
| slangasek | a pity | 16:30 |
| === TheDaniel0108 is now known as Daniel0107 | ||
| === Daniel0107 is now known as Daniel0108 | ||
| rbasak | I'm not sure it'd be that hard to rewrite update-inetd to not depend on perl-modules | 16:34 |
| rbasak | File::Copy: `cp`; File::Temp: `tempfile`. Well, close. | 16:34 |
| slangasek | infinity: right, I can't reproduce the problem by just plucking the relevant perl bits out of that log | 16:36 |
| infinity | slangasek: It's been a couple of weeks now, but ISTR it couldn't be reproduced by just unpacking perl-modules on a clean chroot, but could be reproduced by unpacking perl-modules 5.12 over perl-modules 5.10... Or something like that. | 16:38 |
| slangasek | infinity: I had perl-modules installed | 16:38 |
| infinity | Actually, what's responsible for setting @INC? | 16:40 |
| slangasek | dunno, but something clearly has it set to the old path | 16:41 |
| slangasek | the initial value appears to be embedded in libperl | 16:43 |
| slangasek | (where I would expect) | 16:43 |
| slangasek | so how can perl be 5.10.1 after perl-base 5.12.4 has been unpacked? | 16:43 |
| infinity | Except that libperl is unpacked at 5.12 at that point too. | 16:43 |
| slangasek | yeah, and if it wasn't, you'd get a linker error | 16:44 |
| infinity | Okay, so, perl-modules configuration is a red herring anyway, since perl-modules doesn't have a postinst. | 16:45 |
| infinity | unpacked == configured. | 16:45 |
| barry | jtaylor: ping | 16:49 |
| jtaylor | barry: pong | 16:58 |
| infinity | slangasek: Nevermind, I've gone crosseyed grepping that log. libperl and perl-base are upgraded after samba's unpack failure. | 16:58 |
| infinity | slangasek: Which then leads to wondering why we get perl-modules upgraded so early, if it depends on perl (>= 5.12) | 16:59 |
| barry | jtaylor: hi. i'm looking at merging m2crypto from wheezy and i have a few questions. since you touched the package last i thought i'd ask you. first, i don't want to step on your toes if you've already started working on this | 16:59 |
| infinity | slangasek: (Well, okay, perl gets unpacked early too, but libperl and perl-base don't come until much later -- after samba) | 16:59 |
| === dendrobates is now known as dendro-afk | ||
| jtaylor | barry: with what do you ahve an issue? | 17:01 |
| jtaylor | I had actually hopped it could be synced for precise with the new debian maintainer | 17:01 |
| barry | jtaylor: second question: you removed proxylib.py because it was nonfree, but i don't see any bug report in ubuntu or debian about that. wouldn't it be best to report that in debian and it get managed there? | 17:02 |
| barry | jtaylor: ultimately, that's my goal too | 17:02 |
| jtaylor | barry: yes it turned out to be free after all | 17:02 |
| barry | jtaylor: excellent, we can drop that delta | 17:02 |
| barry | jtaylor: i think we can also drop the dhpy2 and sslv2 deltas | 17:02 |
| jtaylor | I failed to remove it correctly (readded via a patch) but the debian maintainer asked the author who said it was free | 17:02 |
| infinity | slangasek: So, the reproduction steps would be "install perl 5.10 and update-inetd, unpack perl-modules 5.12, watch things (obviously) fail" | 17:03 |
| jtaylor | barry: one of the patches contains two seperate changesets | 17:03 |
| barry | cool. so i just need to double check the d/control and d/rules changes you made and if those are in the debian version, then i think we can sync | 17:03 |
| barry | jtaylor: can you think of any other reason why we can't just sync? (i'm guessing "no" since you suggested it above :) | 17:04 |
| jtaylor | does the debian package enable the tests? | 17:04 |
| barry | ah, maybe fix_kill_signal.patch too | 17:04 |
| barry | jtaylor: that's the d/rules change i need to double check | 17:04 |
| jtaylor | changelog does not mention it :/ | 17:04 |
| jtaylor | bad, because 21.1-1 in debian was broken which would have been caught by the test | 17:05 |
| barry | yep, it doesn't run the tests | 17:05 |
| jtaylor | so no sync, the tests are important | 17:05 |
| barry | jtaylor: okay, i'll merge it and forward all the deltas to debian | 17:05 |
| barry | all *remaining* deltas | 17:05 |
| barry | jtaylor: thanks | 17:05 |
| jtaylor | this splits one patch into two http://bazaar.launchpad.net/~jtaylor/ubuntu/oneiric/m2crypto/cosmetics/revision/25 | 17:06 |
| infinity | And a cable guy is here. Might lose internets intermittently for a while. | 17:06 |
| jtaylor | but I guess that should be in debian already | 17:06 |
| barry | jtaylor: i think so, but thanks for the link; i'll double check it all | 17:08 |
| === deryck is now known as deryck[lunch] | ||
| === beuno-lunch is now known as beuno | ||
| slangasek | infinity: ah, right | 17:14 |
| hallyn | well this is odd. I do a 'bzr merge-package', and it randomly removes some source files (which are all identical in both trees) | 17:23 |
| slangasek | hallyn: curious. what branches? | 17:24 |
| hallyn | slangasek, lxc from precise and sid | 17:24 |
| hallyn | (I first did 'quilt pop -a; bzr remove .pc; bzr ci' in both) | 17:25 |
| hallyn | diff -Nrup src ../lxc-sid/src shows no differences before the merge-package attempt | 17:25 |
| hallyn | after, things like src/lxc/arguments.h go away | 17:25 |
| slangasek | hallyn: hmm, the 'bzr remove .pc' is going to cause problems later, given that you don't actually have access to push that change to the sid branch | 17:27 |
| hallyn | oh i dont want to push that to the sid branch :) i just did 'bzr merge-package ../lxc-sid' | 17:27 |
| hallyn | then i'll quilt push -a; bzr add .pc' | 17:28 |
| hallyn | if i don't do that, then bzr gets all confuddled about the 'conflicts' in .pc | 17:28 |
| slangasek | right, but that means the branch you're merging doesn't match the UDD branch anymore | 17:28 |
| slangasek | so it will cause problems for future merges | 17:28 |
| hallyn | hm, it keeps track kof that? | 17:28 |
| slangasek | yes, the .pc conflicts are a horror, but doing it this way just defers the reckoning | 17:28 |
| hallyn | in the end i was probably going to just sling back a debdiff anyway :) | 17:29 |
| slangasek | ah | 17:29 |
| slangasek | if you're not pushing to *either* branch, then that's fine ;) | 17:29 |
| slangasek | but in that case, maybe MoM would be easier? | 17:29 |
| hallyn | i don't know, in the past bzr-mergepackage has don e agreat job (and now, apart from this glitch, debian/ is all settled for the sync) | 17:30 |
| hallyn | i've not used MoM though. but purely by hand it was a bit hairy. | 17:30 |
| slangasek | bzr merge-package output (w/o munging .pc): The merge resulted in 28 conflicts. Please resolve these and commit the changes with "bzr commit". | 17:31 |
| slangasek | conflicts from MoM's merge: 14 | 17:32 |
| hallyn | how does one run mom? | 17:32 |
| slangasek | 'grab-merge lxc' | 17:32 |
| slangasek | it downloads the pre-staged merge from merges.ubuntu.com | 17:32 |
| slangasek | (from ubuntu-dev-tools package) | 17:32 |
| hallyn | slangasek, ok, thanks - i'll try that for my next merge for practice. For this one i think i'll just build the debdiff now and be done with it :) | 17:33 |
| slangasek | hallyn: and the Contents conflicts in src/lxc/ are because this is a new upstream version, meaning that there are *two* merges happening - first one for the upstream, then one for the packaging | 17:34 |
| hallyn | hm? there shouldn't be a new upstream version | 17:34 |
| slangasek | hmm | 17:34 |
| slangasek | that's how the output reads to me, but I see that you're right | 17:35 |
| slangasek | ok, I don't know what's causing that conflict then | 17:35 |
| stgraber | hallyn: for LXC, the easiest is probably to just take the Debian package, re-apply the few patches we have on top of them (unless dlezcano feels like releasing ;)), re-add the upstart stuff and the cgroup-lite change (as I guess Debian doesn't have cgroup-lite yet), I guess that's pretty much it for LXC | 17:35 |
| slangasek | however, it is probably related to the 'criss-cross merge' warning at the top | 17:35 |
| hallyn | stgraber, yes, that's what it amounts to :) | 17:35 |
| hallyn | stgraber, i'll let you review if you don't mind | 17:35 |
| stgraber | hallyn: I guess we can probably convince Daniel to release a new LXC at the end of next week (assuming we'll push some more stuff to git at UDS), then our changes should be back to a minimal set | 17:36 |
| hallyn | stgraber, that'll be nice | 17:36 |
| stgraber | hallyn: sure, send me the debdiff and I'll review + upload if it looks good | 17:36 |
| hallyn | thx | 17:36 |
| hallyn | slangasek, i'll have to go read up on criss-cross merge later :) | 17:37 |
| slangasek | hallyn: summary: branch A merged into branch B, now you're merging branch B into branch A. In this case, I think it's because the new upstream version was introduced separately on each branch | 17:38 |
| stgraber | hallyn: I also need to look at libnih again with James Hunt, once this one is ported to multiarch (he may have already done it on his laptop ;)), I'll commit support for containers using non-native architecture (using qemu + a multi-arch version of libnih and upstart) | 17:38 |
| slangasek | not an error at all, just means bzr's poor little brain sometimes gets confused about what it should do with such a merge | 17:38 |
| stgraber | hallyn: then we'll be able to use "-a armel" on x86 and get a working container | 17:38 |
| hallyn | cool | 17:39 |
| hallyn | i was meaning to look at libcap2 wrt multiarch. haven't yet though. | 17:39 |
| slangasek | stgraber: yes, jhunt and I have multiarch libnih sorted out, I guess he'll be pushing soon | 17:39 |
| stgraber | slangasek: awesome! I might be able to show a working armel or powerpc container on x86 as a lightning talk on Friday then | 17:40 |
| stgraber | (unless I discover that something else than upstart heavily depends on ptrace() in our boot sequence :)) | 17:40 |
| slangasek | heh | 17:40 |
| * slangasek thinks that over briefly | 17:41 | |
| slangasek | nope, shouldn't be anything else | 17:41 |
| stgraber | well, obviously strace and gdb won't work in that container, but you already get that behaviour using a simple chroot with the qemu-<arch>-static stuff | 17:42 |
| * slangasek nods | 17:44 | |
| slangasek | neither of those should be triggering at boot ;) | 17:44 |
| hallyn | stgraber, is linux-any a valid target in ubuntu debian/control? | 17:55 |
| hallyn | well, debuild doesn't warn me about it... | 17:57 |
| hallyn | vim syntax highlighting just doesn't like it maybe :) | 17:58 |
| geser | hallyn: yes, linux-any is valid and also supported by LP | 18:16 |
| hallyn | thx | 18:17 |
| === negronjl_mobile is now known as negronjl | ||
| === deryck[lunch] is now known as deryck | ||
| === dendro-afk is now known as dendrobates | ||
| mterry | @pilot out | 18:49 |
| === udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| adam_g | if i'm about to propose a merge for an SRU to a package that doesn't have an lp:ubuntu/$release-updates/pkg branch, do i just propose merge into lp:ubuntu/$release/pkg instead? | 18:57 |
| mterry | adam_g, yeah | 18:58 |
| mterry | adam_g, I think that's typical | 18:58 |
| adam_g | mterry: thanks | 18:58 |
| Daviey | adam_g: UDD is messed up for SRU's :/ | 19:05 |
| Daviey | The target should be -proposed, but that would never have a -security upload in there, messing up the stacking. | 19:05 |
| * micahg wonders if one can branch from -updates and propose a merge against -proposed | 19:06 | |
| maco | dont see why not | 19:06 |
| micahg | depends on how the branches are stacked on LP | 19:07 |
| slangasek | micahg: you can branch from -updates and propose a merge against -proposed *if there's already a -proposed branch to target*... | 19:11 |
| slangasek | it'd be really nice to be able to do UDD-driven SRUs - i.e., build-from-branch for all SRUs, so the SRU team just lands the branch to approve the upload | 19:12 |
| slangasek | but that's not high on the priority list, I think :) | 19:12 |
| hallyn | stgraber, our /etc/default/lxc has been storing MIRROR= for lxc-create (along with the RUN= for /etc/init.d/lxc). | 19:33 |
| hallyn | stgraber, with the new debian package, the pre-inst does 'rm /etc/default lxc' if that file has 'RUN=' in it | 19:33 |
| hallyn | stgraber, then it creates a new one in .postinst | 19:34 |
| hallyn | are we ok with that? | 19:34 |
| stgraber | hallyn: is it looking for ^RUN or for RUN? if it's simply looking for RUN, that means destroying a configuration file for everyone on upgrade which I really don't think we should do | 19:35 |
| stgraber | we could instead look at the md5 of the file or some similar approach to only replace it if it's indeed the exact same one that was shipped with the earlier version | 19:35 |
| hallyn | if grep -qs 'RUN=' /etc/default/lxc | 19:36 |
| hallyn | ok, | 19:36 |
| hallyn | so i'm thinking i'll just sed over the file to get rid of RUN ? | 19:36 |
| hallyn | i hate adding more delta from debian, but... | 19:36 |
| stgraber | why did he remove RUN= to start with? | 19:36 |
| hallyn | he switched to having /etc/lxc/local/ store data about autostart | 19:37 |
| hallyn | and now added LXC_AUTO=ture anyway | 19:37 |
| hallyn | true that is | 19:37 |
| hallyn | so really, i don't know | 19:37 |
| stgraber | fun... | 19:37 |
| hallyn | he's in #lxcontainers usually so we could ask him, | 19:38 |
| stgraber | I'm wondering why he's actually messing with it in postinst instead of just shipping the file as conffile and letting dpkg deal with it | 19:38 |
| hallyn | right. dunno | 19:38 |
| hallyn | for that matter i don't know why he's changing the mechanism for choosing autostart containers anyway | 19:39 |
| stgraber | I'd much rather carry and extra delta with Debian than removing a user's configuration file without warning (or even changing it) | 19:39 |
| stgraber | *an | 19:39 |
| hallyn | ok. so get rid of both? | 19:39 |
| hallyn | (pre+postinst)? | 19:40 |
| hallyn | maybe i should just push what i have to you, and let you decide :) | 19:40 |
| hallyn | it's all looking good aside from that bit | 19:40 |
| stgraber | yeah, I think the easiest is to get rid of that change and have the new init script check for RUN=yes instead of LXC_AUTO=true | 19:40 |
| hallyn | you think thta's better than shipping a new lxc.default with LXC_AUTO=true and letting the user decide (with comments inthe file to help)? | 19:41 |
| stgraber | oh, and that means that config files are no longer in /etc/lxc/auto/? what's that new /etc/lxc/local thing? ... | 19:41 |
| hallyn | iirc you symlink containers in there | 19:42 |
| hallyn | that you wnat autostarted | 19:42 |
| hallyn | no, wait | 19:42 |
| stgraber | hmm, in Oneiric I'd simply symlink their config into /etc/lxc/auto and they'll auto-start, that was working fine! | 19:42 |
| hallyn | no, debian/local is just for his own scripts | 19:43 |
| * stgraber starts to think we should just move the init script and all that stuff into the upstream branch and be done with it, no more distro delta ;) | 19:44 | |
| hallyn | worth discussing at uds. especially once we start introducing our own network bridge for default config :) | 19:44 |
| hallyn | stgraber, ok, LXC_AUTO defaults to true. but it's new. so, should I just keep the same lxc.default we've had and avoid debconf questions, or should I add LXC_AUTO to our lxc.default so ppl know about it? | 19:47 |
| hallyn | in either case, I figure I'm nuking .preinst and .postinst | 19:47 |
| hallyn | (defaults to true if it's not in /etc/default/lxc, i mean) | 19:47 |
| hallyn | i'll add it in. | 19:48 |
| rbasak | slangasek: thanks, re: bug 862129 | 19:53 |
| ubottu | Launchpad bug 862129 in update-manager (Ubuntu Precise) "samba postrm depends on packages not guaranteed to be configured" [High,Triaged] https://launchpad.net/bugs/862129 | 19:53 |
| mwhudson | so my x220 completely reliably suspends and resumes | 19:58 |
| mwhudson | once | 19:58 |
| mwhudson | the second resume fails, 100% of the time | 19:58 |
| hallyn | stgraber, http://people.canonical.com/~serge/lxc-sync.debdiff is working for me | 19:58 |
| stgraber | mwhudson: do you have cgroup-bin installed? if so, replace it by cgroup-lite | 20:03 |
| mwhudson | $ dpkg-query -W cgroup-\* | 20:05 |
| mwhudson | No packages found matching cgroup-*. | 20:05 |
| mwhudson | although hm, now things are just being strange | 20:06 |
| mwhudson | i tried to reproduce using pm-suspend and it worked, but i'm on ac power now | 20:06 |
| soren | stgraber: If that were the problem, the second *suspend* would be failing, IIRC. Not the second resume. | 20:07 |
| mwhudson | and then i closed the lid and it didn't seem to suspend properly and when i opened the lid again it went to mirrored displays | 20:08 |
| * mwhudson filed https://bugs.launchpad.net/ubuntu/+source/linux/+bug/881647 | 20:08 | |
| ubottu | Launchpad bug 881647 in linux (Ubuntu) "lenovo x220 fails to resume more than once" [Undecided,Confirmed] | 20:08 |
| stgraber | soren: last I had this bug was a while ago, couldn't remember if it was the second suspend or resume that was hanging because of cgroup-bin :) | 20:08 |
| gord | my x220 suspends/resumes fine 100% of the time no matter how many times i do it =\ | 20:09 |
| mwhudson | gord: oneiric? | 20:09 |
| mwhudson | hm | 20:09 |
| gord | yup | 20:09 |
| mwhudson | hm | 20:09 |
| * mwhudson remembers something else | 20:09 | |
| mwhudson | gord: does shutdown/reboot work properly for you? | 20:09 |
| * hallyn doesn't have a single laptop, of many, that'll suspend/resume right now :( | 20:10 | |
| gord | yeah all works fine | 20:10 |
| gord | saying that though the X220 has quite a few customisations you can make so we might just have different hardware | 20:11 |
| stgraber | hallyn: any reason you kept lxc.template and lxc.config? | 20:11 |
| mwhudson | gord: yeah, likely i guess -- i have i7, ssd, intel wifi | 20:12 |
| hallyn | the .template is just for his default/lxc tweaking script? guess that can go. I thought lxc.config had something to do with the -dbg or -dev package | 20:12 |
| gord | intel wifi here, i3 and hd | 20:12 |
| mwhudson | hm | 20:12 |
| * mwhudson plays around -- will probably drop off :) | 20:12 | |
| hallyn | I see now | 20:13 |
| hallyn | my bad | 20:13 |
| hallyn | yeah both of those can go | 20:13 |
| stgraber | hallyn: lxc.config prompts the user for the debconf keys from lxc.templates, my understanding is that these two were used for the templating of the defaults file done by the scripts you removed | 20:13 |
| stgraber | hallyn: ok, removed and added a comment to the changelog, continuing the review :) | 20:14 |
| hallyn | stgraber: well, do you think we should rather keep the pre/postinst and add saving of MIRROR? | 20:14 |
| hallyn | I don't like all that code for something like that; but ... | 20:14 |
| === dendrobates is now known as dendro-afk | ||
| stgraber | hallyn: any reason not to move lxc-start-ephemeral to that new local directory? | 20:16 |
| hallyn | stgraber, no, and lxc-is-container coudl go there too | 20:16 |
| stgraber | ok, I'll move them | 20:16 |
| hallyn | is that location conventional? | 20:16 |
| stgraber | first time I saw that, I saw some others use debian/scripts/ too, I don't remember reading about a standard location | 20:17 |
| barry | any buildd admins around who can rescore a PPA build for me? | 20:18 |
| stgraber | I'm not too sure what to do with /etc/default/lxc to be honest, moving to debconf may be interesting but we need to make sure we don't end up prompting everyone who'll be upgrading from oneiric or lucid | 20:18 |
| stgraber | barry: link? | 20:18 |
| barry | stgraber: https://launchpad.net/~barry/+archive/python/+build/2877224 | 20:18 |
| barry | stgraber: https://launchpad.net/~barry/+archive/python/+build/2877225 | 20:19 |
| barry | (the first is amd64, second i386) | 20:19 |
| barry | stgraber: thanks! | 20:19 |
| stgraber | barry: there you go for a very small bump ;) | 20:19 |
| barry | stgraber: awesome, very nice! thanks | 20:20 |
| stgraber | hallyn: I'd be tempted to go without debconf for that initial merge, then if we feel the need, merge/extend that bit later in the cycle | 20:20 |
| === dendro-afk is now known as dendrobates | ||
| hallyn | stgraber, if you don't want the user to be prompted, then we should undo the changes i made to lxc.default altogether? | 20:21 |
| stgraber | hallyn: I don't want to have them prompted when they didn't touch the config file. I'm fine with prompting them if they changed something | 20:22 |
| mwhudson | well that was a bit strange, it suspends and resumes fine on ac power | 20:22 |
| mwhudson | and pm-suspend is fine, but if i close the lid on battery power, then pm-suspend it oopses | 20:23 |
| hallyn | ok | 20:23 |
| stgraber | hallyn: any reason " debian/lxc.install - README gets (mis-)installed under --with-rootdir." isn't in Debian? doesn't that affect them too? | 20:24 |
| hallyn | no, bc they don't use --with-rootdir=/usr/lib/lxc/root | 20:25 |
| hallyn | which means, lxc-sshd wont' work for them | 20:25 |
| stgraber | ok | 20:26 |
| stgraber | hallyn: http://paste.ubuntu.com/719149/ | 20:26 |
| hallyn | I assume lxcguest.install and lxc.install got updates reflecting the new locations for lxc-start-ephemeral and lxc-is-contaienr? | 20:28 |
| stgraber | I updated your section a bit and listed the changes I made | 20:28 |
| stgraber | yep, I dropped the lines from these two | 20:28 |
| stgraber | IIRC he simply copies everything from local to usr/bin | 20:28 |
| hallyn | great. looks good, thanks. regarding the README, of course I don't know WHY it ends up in .../root | 20:28 |
| hallyn | stgraber, thanks | 20:29 |
| stgraber | rest of the diff looks sane. I haven't looked at exactly what's changing in the diffs but that's what they have in Debian, so that should work :) | 20:29 |
| stgraber | I'll upload it now and will hopefully test it soon (need to upgrade a VM to precise, only have containers at the moment) | 20:30 |
| lifeless | hallyn: btw did I file a bug about rmmod working in containers ? | 20:30 |
| lifeless | [by default] | 20:30 |
| stgraber | lifeless: I'd be happy to +1 on that bug report ;) it's a major pain when upgrading containers | 20:31 |
| lifeless | stgraber: I have a rmmod iwlagn; modprobe iwlagn thing I run regularly. | 20:31 |
| lifeless | stgraber: my host is 64bit, containers 32bit. | 20:31 |
| lifeless | stgraber: finally I bind mount home into them, so I have a shared bash history... | 20:32 |
| lifeless | stgraber: guess what happened when I didn't check the host portion of my prompt, and my wifi did its 'I'm going to suck' thing. | 20:32 |
| stgraber | err, my eyes don't work today ;) I read mknod instead of rmmod which is a completely different issue though just as annoying :) | 20:32 |
| lifeless | stgraber: heh :) | 20:32 |
| stgraber | lifeless: oh, and what happened to the kernel when you did that? :) | 20:33 |
| lifeless | stgraber: anyhow, iwlagn was removed, then modprobe failed spectacularly | 20:33 |
| lifeless | I can't recall if it tried to insert the 32 bit version or quite what went wrong | 20:33 |
| stgraber | I've noticed something similar with my automated d-i testing in a container, d-i tries to modprobe/insmod quite a bunch of modules into my kernel ;) | 20:34 |
| lifeless | stgraber: yah, that will be similar | 20:34 |
| stgraber | for now I simply override modprobe and insmod with a simple "exit 0" ;) | 20:34 |
| lifeless | bug 850687 | 20:34 |
| ubottu | Launchpad bug 850687 in lxc (Ubuntu) "Should disable cap_module by default" [Wishlist,Triaged] https://launchpad.net/bugs/850687 | 20:34 |
| stgraber | hallyn: user namespaces will solve all that right? :) | 20:34 |
| hallyn | yup! | 20:36 |
| hallyn | they already solve that - you just can't then use the container :) | 20:36 |
| stgraber | hallyn: "can't then use the container", because of the VFS part? | 20:38 |
| hallyn | lifeless, stgraber, well if the modprobe/rmmod one seriously bugs you now, then we should push the fix into the package instead of wiating for an upstream release... | 20:39 |
| hallyn | i thought it ws just a security concern | 20:39 |
| lifeless | hallyn: bit of both | 20:39 |
| hallyn | stgraber, not just that, there are lots of places that we default to denying containers privilege to resources which they own anyway | 20:39 |
| hallyn | if i can get this last set of 8 patches into the kernel, then we can work on relaxing the security checks (and handling files) | 20:40 |
| stgraber | hallyn: did any of that patch that was written/pushed during the sprint make it to the kernel? I'd have thought the pid ns attach and reboot/shutdown one would be upstream by now... | 20:41 |
| hallyn | no, it didn't. | 20:41 |
| hallyn | daniel's laptop got stolen, and eric's been busy with his dayjob | 20:41 |
| hallyn | so both lxc-attach and reboot patches got lost | 20:42 |
| hallyn | i'm hoping we can push both again next week | 20:42 |
| slangasek | ouch | 20:42 |
| hallyn | yeah | 20:43 |
| stgraber | argh, didn't know for Daniel's laptop, that really sucks... | 20:43 |
| hallyn | that also postponed some merging of lxc patches | 20:43 |
| * hallyn tries hard to not be tied down to any one machine or phsyical location :) | 20:43 | |
| stgraber | at least we have the patches on lkml/git, it's just going to be short if we want these upstream for 12.04 | 20:44 |
| stgraber | unless we can convince our friend in the kernel team to carry these as an Ubuntu delta ;) | 20:44 |
| hallyn | a few 6-packs might help | 20:44 |
| hallyn | but, maybe I should see if we can prod to have those pushed this week | 20:45 |
| stgraber | if that's what it takes, I'm sure we can get some ARM server company to sponsor that :) | 20:45 |
| hallyn | excellent | 20:45 |
| stgraber | hallyn: lxc uploaded | 20:45 |
| === dendrobates is now known as dendro-afk | ||
| barry | stgraber: that amd64 build is going in the wrong direction. first 2 minutes, than 9 minutes, now 14 minutes 'til it builds :). no need to change anything, i just thought it was funny. the i386 build gave me the information i need. | 20:47 |
| hallyn | stgraber, great, thanks. | 20:47 |
| stgraber | barry: interesting ;) I'm guessing that's because the buildds are busy with long running builds | 20:48 |
| barry | stgraber: that, or there's a little robot on an exercise wheel behind lp's web ui, rolling dice and laughing at us. your explanation seems more plausible, but i'm sticking to mine. | 20:49 |
| stgraber | :) | 20:50 |
| hallyn | stgraber, http://people.canonical.com/~serge/lxc-drop-sys_module.debdiff (though that's against my tree, but apply against yours) if you wanted to quickly push a fix for cap_sys_module too. | 20:53 |
| hallyn | (actually i wonder if dropping cap_mac_admin will end up breaking packages) | 20:55 |
| === mpt_ is now known as mpt | ||
| hallyn | (that'd be fun) | 20:55 |
| stgraber | hallyn: is cap_sys_module also restricting reading the module list (lsmod)? just wondering as I think we want that change anyway, I'd just need to update my default config when doing d-i testing | 20:55 |
| hallyn | no. lsmod should still work | 20:55 |
| hallyn | i can lsmod as unprivileged user | 20:56 |
| stgraber | good | 20:56 |
| stgraber | what's cap_mac_admin doing? don't remember seeing that one before (do we have a list of all the cap_* somewhere? :)) | 20:57 |
| hallyn | uh, sure - linux-2.6/include/linux/capability.h :) | 20:57 |
| hallyn | LSMs use that to gauge who can change policy | 20:57 |
| stgraber | got to love kernel documentation :) | 20:58 |
| hallyn | and mac_override, who can bypass it | 20:58 |
| hallyn | so I assume this will keep containers from loading apparmor policies. | 20:58 |
| hallyn | we need to talk to jjohansen at uds about apparmor namespaces and how to handle all of this, of course | 20:58 |
| hallyn | well, oneiric container starts up fine though (without those caps) | 20:58 |
| * hallyn installs apache2 as another test | 20:58 | |
| stgraber | so we'd probably have to revert the cap_mac_* ones once we have the apparmor namespace change done in lxc or will that just work without the capability? | 21:00 |
| * stgraber has no clue how apparmor actually works (if that wasn't clear ;)) | 21:00 | |
| slangasek | in a way that is comically incompatible with how selinux works :) | 21:01 |
| * jjohansen reads back scroll | 21:01 | |
| dobey | is there an update to make pbuilder/etc know about precise, on older Ubuntus yet? | 21:01 |
| barry | tumbleweed: rock. thanks for the confirmation. | 21:02 |
| slangasek | (Debian bug #634081 is a beautiful thing) | 21:02 |
| ubottu | Debian bug 634081 in slapd "/usr/sbin/slap* hard links break SELinux" [Normal,Open] http://bugs.debian.org/634081 | 21:02 |
| tumbleweed | barry: you did make it nice and easy :) | 21:02 |
| sbeattie | stgraber: capabilities(7) contains an overview of what each capability is, though definitely not in enough detail. | 21:02 |
| barry | tumbleweed: :) | 21:02 |
| hallyn | stgraber, well, amusingly, cap_mac_admin will be targeted at the user namespace | 21:02 |
| hallyn | so we shouldn't have to relax the check *if* we can use them | 21:03 |
| hallyn | wait - no they wont | 21:03 |
| hallyn | so yes, probably :) | 21:03 |
| tumbleweed | dobey: running into any particular problems? | 21:04 |
| dobey | tumbleweed: i can't do pbuilder create to make a chroot for it? | 21:05 |
| tumbleweed | dobey: on what release? | 21:05 |
| dobey | on 11.04 | 21:05 |
| tumbleweed | dobey: right. natty and maverick haven't got debootstrap backports | 21:06 |
| tumbleweed | I think there's also a ubuntu-dev-tools/distro-info thing I need to do for one or two of them | 21:07 |
| dobey | what's the best way to make a pbuilder chroot then? is there a base.tgz i can just download from somewhere? | 21:08 |
| geser | dobey: cd /usr/share/debootstrap/scripts && sudo ln -s gutsy precise | 21:08 |
| tumbleweed | what geser said :) | 21:08 |
| dobey | ah ok | 21:09 |
| stgraber | hallyn: I'm confused ;) | 21:13 |
| hallyn | stgraber, so yes, we may end up re-enabling mac_admin in containers | 21:21 |
| stgraber | hallyn: ok :) | 21:22 |
| stgraber | hallyn: I'll wait for LXC to build on everything, then push that extra change then | 21:22 |
| hallyn | depends on what we can do with apparmor namespaces | 21:22 |
| hallyn | stgraber, ok, thanks. and hopefull i don't break anyone... | 21:22 |
| hallyn | (maybe libvirt in a container - but who'd do that? :) | 21:23 |
| stgraber | at least I seem to remember jjohansen being marked as essential for the LXC session at UDS, so we'll hopefully know more then | 21:23 |
| hallyn | yup | 21:24 |
| jjohansen | heh yeah I am planning on being there, but I can provide info now if you would like | 21:24 |
| jjohansen | currently apparmor need MAC_ADMIN to load policy | 21:25 |
| jjohansen | but I am more than open to discussion revisions/changes that maybe needed. | 21:26 |
| hallyn | jjohansen, are there any packages that will just fail to install or run without MAC_ADMIN? or will they just not end up installing a policy? | 21:30 |
| jjohansen | hallyn: the packages shouldn't fail, but the policy will fail to load | 21:30 |
| hallyn | jjohansen, fwiw, if, when apparmor namespaces are done, a child namespace will be contained by an overall policy, then I think we can let containers have CAP_MAC_ADMIN. | 21:31 |
| hallyn | cool | 21:31 |
| jjohansen | right, even as they are right now the child namespace can't manipulate the parent's namespace with CAP_MAC_ADMIN, but that doesn't mean much as it has access to the rest of the system if it wants. | 21:32 |
| hallyn | jjohansen, i suppose i should check for any apparmor uds sessions too | 21:48 |
| jjohansen | hallyn: heh if your interested sure, but don't feel compelled, we can discuss lxc bits in lxc sessions, etc | 21:50 |
| hallyn | ok, great! | 21:50 |
| === AaronMT is now known as AaronMT|away | ||
| hallyn | hm, there seems to be a bug in tunctl. 'tunctl -u 1000' is *not* making 1000 own tapN | 22:24 |
| === AaronMT|away is now known as AaronMT | ||
| === AaronMT is now known as AaronMT|away | ||
| === gallth is now known as tgall_foo | ||
| === dendro-afk is now known as dendrobates | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!