[00:03] SpamapS: With linux 3.1? [00:12] RAOF: been following this https://help.ubuntu.com/community/MacBookAir4-2 [00:13] RAOF: not sure which magical thing it did to enable the graphics, but it disabled the touchpad :( [00:13] ahh [00:13] it patched bcm5974 for the 4,2 [00:14] but the 4,1 only seems to work with the regular 3.0.0-12-generic version [00:14] all is well now [00:14] * SpamapS does a dance [00:17] XRANDR .. [check] [00:18] ooo suspend/resume even works [00:18] * SpamapS can actually consider *not* lugging his 15" MBP to UDS now [00:19] w00t === dendro-afk is now known as dendrobates [00:25] @pilot in === 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 [01:16] Bah. It's really annoying that I can't change the status on any of these merge proposals. [01:20] RAOF: you need a tech board member most likely [01:21] Yeah, I know. [01:21] it's unfortunate that nobody actively working on udd is on ~ubuntu-branches [01:21] Or to be a member of ubuntu-branches. [01:21] otherwise i would advocate the "harass them until they fix it" approach [01:22] James Westby's in ~ubuntu-branches :) [01:22] i thought he was doing linaro stuff these dyas [01:22] Oh, yeah. He is, isn't he. Damn! [01:23] that would make things a bit awkward [01:24] maybe the TB should be asked to look at the ownership of those branches === luist_ is now known as luist [01:48] 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:50] stgraber: Ta. I'll be sure to list them all in an email then. [02:06] how do i force debuild to create a .dsc that references the .orig file ? [02:07] smoser: -S -sa [02:09] thank you, kind sir. [02:09] you're welcome [02:18] RAOF/micahg: Or escalate the bug. [02:19] wgrant: Know what that bug is, offhand? [02:19] broder: james_w is in online services now [02:19] lifeless: Wha? [02:19] When did that happen? [02:19] danilo -> linaro [02:19] james_w -> jml's offsider [02:19] Ah, interesting. [02:20] Makes sense, though :) [02:20] RAOF: Bug #540250 looks relevant, but is meant to be fixed... [02:20] Launchpad bug 540250 in Launchpad itself "Cannot edit merge proposals for packaging branches" [High,Fix released] https://launchpad.net/bugs/540250 === dendro-afk is now known as dendrobates [02:21] Ahh. [02:21] Now I remember. [02:21] RAOF: What's an example merge proposal? [02:21] Is it for a stable series? [02:22] wgrant: Yes, I think they are. [02:22] is ahttps://code.launchpad.net/~om26er/ubuntu/natty/libdbusmenu/dbusmenu-fix-618587/+merge/71892n is an example. [02:22] Right. [02:22] That would be the problem. [02:23] 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] Because those branches are meant to be frozen. [02:23] I'm not sure if there is a bug for this... [02:23] Aha. [02:23] smoser: you also want to use -vOLD_UBUNTU_VERSION when merging from Debian [02:24] Bug #612391 [02:24] 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] If you can escalate that, it might get done :) [02:24] micahg, thanks... too late though. i should have know that. [02:25] smoser: I try to remember to check the source.changes file to make sure the other entries are there before uploading [02:26] wgrant: Sweet, thanks for that. [02:53] 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] slangasek: Err yeah you're right, multiarch is the solution that works around that problem [02:54] slangasek: cause we build the 32-bit bits on 32 that have the 32 bit dev packages [02:54] yep - at least, I hope it works around it :) [02:55] slangasek: do you know the status of OpenCL by chance? [02:55] Just as long as the WoW64 stuff can use the 32bit build :) [02:56] 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] RAOF: namely in the 32 bit package as well as the 32 bit foreign package [02:56] the 32-bit package is not a different package than the 32-bit foreign package [02:57] it's one package, built on i386 and installable on either i386 or amd64 [02:57] slangasek: actually nevermind, that's the proper way to do it, have the 32 bit-only package depend on that too [02:57] yep [02:57] YokoZar: I don't think I know what opencl is [02:58] 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] YokoZar: ok; not my department :) [02:58] slangasek: I thought that the amd64 buildds could use 32 bit packages, is that not correct? [02:58] Current Linux implementations may be driver specific (eg, only in the proprietary NVidia packages...despite the openness) [02:59] micahg: nope [02:59] micahg: You can depend on a package that only has a 32 bit component, but you can't build-depend on that. [02:59] micahg: there's no way to specify it in build-deps, for starters [02:59] slangasek: so how does one build a 64 bit app that has some 32 bit components? [03:00] 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] 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:01] ok [03:01] 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] whereas in oneiric they're built on 64 via ia32-libs [03:02] YokoZar: What are you particularly interested in re: OpenCL? [03:02] 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] RAOF: Wine already has an implementation of it so any Windows app that uses it would need it to work [03:04] RAOF: I'm not sure what Windows apps use OpenCL off the top of my head though [03:04] 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] RAOF: Well, I hope I can speed things along by being your use case then ;) [03:08] 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. [04:02] Good morning [04:02] jcastro: right now it says "error updating", but will try later [04:02] morning pitti [04:02] hey ajmitch, how are you? [04:02] good, how are you? [04:03] pretty well, although still a bit tired, thanks! [04:03] * ajmitch wishes that the long weekend here was a few days longer :) [04:23] @pilot out === 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 [05:09] doko_: FYI, keeping binutils in proposed queue, as the previous SRU hasn't been verified yet [05:09] doko_: if you want the second upload in -proposed now, please reupload with -v to include the previous changelog [05:13] 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 [06:54] pitti: FYI, bug 881250, SRU period might need to be truncated [06:54] Launchpad bug 881250 in tzdata (Ubuntu) "Clocks in Ukraine move back October 30, 2011" [High,Triaged] https://launchpad.net/bugs/881250 [06:54] micahg: yes, we generall move them to -updates right after verification, as they often tend to be urgent [06:54] there's a tzdata 2011m already [06:55] right, already in unstable === tkamppeter__ is now known as tkamppeter [07:07] pitti, are you not on the Sprint? [07:07] tkamppeter: no, I'll arrive on the weekend; only for UDS [07:07] pitti, interesting, as technical lead of the desktop team. [07:07] good morning! :) [07:08] tkamppeter: it's a DX sprint [07:08] tkamppeter: seb128 and didrocks are there [07:08] pitti, OK, thought it was an all-Canonical Sprint. [07:09] pitti, good to know to know who is in which time zone currently. [07:46] 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:47] cjwatson: That's worrying. If you can find a current example, I would love to see it. [07:47] wgrant: Try bug 728012 instead. [07:47] 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] cjwatson: he later added Bug #612391 [07:47] 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] Let's see. [07:47] micahg: Indeed, but AFAIK this still happens for development series. [07:48] ah [07:48] 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:49] The problem here is probably that upload permissions don't grant review privileges. [07:50] And there's no review team set. [07:50] So only ~ubuntu-branches has those superpowers... hm. [07:50] wgrant: here's an example: https://code.launchpad.net/~samuel-taylor/ubuntu/oneiric/pidgin-skype/fix-for-657125/+merge/75701 [07:51] I think we'd like it to be keyed off upload permissions rather than setting a single team. [07:51] micahg: that's a released series [07:51] cjwatson: Indeed. [07:51] I don't think I could've changed it before eitehr [07:51] It currently checks for membership in one of (branch owner, branch reviewer, LP admin). [07:51] Which made sense until package branches. [07:51] Because branch editing was restricted to the branch owner and LP admins. [07:52] does anyone know if there is a tool already in main that will convert markdown to html? [07:52] So isPersonTrustedReviewer should probably just check if they can edit the branch or are in the review team. [07:52] I can change this one: https://code.launchpad.net/~barry/ubuntu/precise/ubuntu-dev-tools/bug-881049/+merge/80253 [07:52] Launchpad bug 80253 in debconf (Ubuntu) "Can't launch ubiquity on 20070117 feisty-desktop-i386.iso" [Undecided,Fix released] [07:53] micahg: To Approved/Rejected? [07:53] jamespage: python-docutils [07:53] wgrant: no, but I don't think I can ever set those [07:53] Right, that's the bug. [07:53] micahg: I can; that's the bug. [07:53] tumbleweed: sweet - thanks for the pointer [07:54] cjwatson: wgrant: sorry for the noise [07:54] that's ok [07:55] man, switching from homegrown scripts to pull-lp-source and pull-debian-source has improved my life surprisingly much [07:56] I find them quite nice, saves having tons of deb-src lines [07:56] s/saves/avoids/ [08:22] jcastro: guidebook seems better now, thanks! [08:33] @pilot in === 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 [08:34] * dholbach hugs jamespage [09:36] <\sh> doko_, do you mind when I take some of the universe packages (from MoM) with your last uploader name tag? [09:36] why can I 'Reject' some merge proposal but not others? [09:36] * jamespage scratches his head [09:46] jamespage: natty / not-natty [09:46] jamespage: there is a bug. [09:51] \sh, not at all === doko_ is now known as doko [09:51] pitti, can we move the first one to -updates first? [09:56] doko: that's what happens by default if you don't want to replace the current SRU, yes [09:56] (still needs verification, as I said) [09:59] <\sh> doko, thx [09:59] <\sh> btw...are there any hints on how to fix format-security issues? [09:59] pitti, done the verification [10:05] \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] \sh: a common pattern is to prepend a "%s", if you really don't want interpolation [10:07] <\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:08] <\sh> and I'm not sure if gtk_message_dialog_new(...,...,...,...,"%s",message) is enough [10:08] \sh: using "%s" for the message will work fine [10:08] \sh: as I said, it depends: if message is _supposed_ to have format strings in it, then this will break [10:09] but if it's not, then "%s" is fine; then any % characters in message will appear verbatim [10:10] <\sh> pitti, kk :) thx :) [11:48] !regression-alert [11:48] 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] bug 881361, impact not yet determined. Non-default package. [11:48] 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:57] jasoncwarner_: can you approve the desktop-p-kubuntu specs for uds-p please https://blueprints.launchpad.net/sprints/uds-p?searchtext=kubuntu [12:10] @pilot out === 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: [12:10] Daviey: mdeslaur is looking into it now [12:17] jdstrand: yep, tracking in #ubuntu-server. Thanks. === kenvandine is now known as kenvandine[flush === kenvandine[flush is now known as kenvandine_afk [12:35] @pilot in === 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 [13:05] hello folks [13:06] hey sabdfl [13:08] hey sabdfl, how are you? [13:08] great thanks pitti, enjoying orlando already :-) [13:09] sabdfl: twisting^Wsprinting by the pool ♪ ♫ ? [13:09] pitti, grrr, you implanted an earworm ! [13:09] :) [13:09] Not to me. [13:10] * ogra_ guesses thats a matter of age :) [13:10] or of musical taste [13:33] 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] pitti: I got them moved now, but want to make sure it's not a script issue === Quintasan_ is now known as Quintasan [13:39] pitti: are you there? [13:40] doko: OK if I pickup the jffi merge? its borked at the moment in precise [13:42] jamespage, sure [13:43] doko: ta === kenvandine_afk is now known as kenvandine === zyga is now known as zyga-afk [14:25] 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:26] 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] its not about the hotel, but about the automatic scheduler that needs to know you are there [14:27] ok [14:27] 8unless you just want to hang out in corridors indeed :) ) [14:27] psusi: please register in LP, that's how they figure out the food and stuff [14:28] oh, food, right :) [14:28] * ogra_ forgot about that unimportant bit [14:30] 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] that would be awesome [14:37] is merges.u.c no longer been updated? [14:37] I was surprised at my first UDS that lunch was included for all attendees, free OS and free food? sweet! [14:39] RoAkSoAx: it should be. Don't forget we're syncing from testing [14:39] it's running right now, indeed [14:39] looks healthy to me [14:39] tumbleweed: ahh right!! [14:40] thought we were from unstable [14:40] cjwatson: any opinions on bug 881288? you were vaguely around for that conversation... [14:40] 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:41] I'm afraid I've been failing to get my head around the details of that thus far [14:42] it's probably better to bring it up with LP folks [14:42] ok, I'll file a bug [14:47] 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? [15:09] pitti: samba> oh, sorry, built it in a Debian env by mistake, forgot to watch out for the closure header [15:10] slangasek: Hey! Are you looking at the samba issue? [15:10] Daviey: no [15:11] I was looking at an unrelated samba issue [15:12] slangasek: Would you be able to, please? :) [15:12] over 100 dupes now :( [15:33] mdeslaur: no, of course not intentional -- it's the usual "LP picks random components" problem; I thought that would be uncovered during verification [15:34] pitti: ok, cool, thanks === zyga-afk is now known as zyga [15:54] anyone notice any issues with builders? i uploaded something to my PPA 40 minutes ago, and LP is saying "Start 2011-10-26" [15:55] 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:57] 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:58] 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] 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:59] slangasek: this is also a Debian bug and you're a maintainer :-) [15:59] 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 [16:00] so you guys should pick whatever fix that you think is appropriate to cover the gap now [16:00] 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] 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:01] slangasek: it's just a waste of effort if we fix it one way and then debian chooses to fix it another [16:01] rbasak: it's easy enough to fix it twice and in the meantime it's causing pain for users [16:01] so more effort is being wasted talking / worrying about it than would be wasted by implementing 2 different fixes === beuno is now known as beuno-lunch [16:02] 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:03] cjwatson: Do you have thoughts on this? [16:03] Or should I just keep submitting patches without any feedback in the hope that one will be acceptable? [16:03] It is really, really frustrating that we blocked on this for us to just throw anything into an SRU [16:04] rbasak: I don't think your patch would have fixed it anyway, after we investigated what was happening. [16:06] infinity: fine, but that's not my point. [16:06] 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] 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:07] hi all! i sent a mail to -devel which didn't yet come through. anything wrong with it? [16:10] 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:11] my opinion was to move update-inetd to the prerm, but AIUI slangasek had a reason not to do that [16:11] I had a reason why I didn't think update-inetd in the prerm was actually the right thing to do [16:11] doesn't mean it's not an appropriate workaround to fix users' upgrades in this case [16:12] Actually, it doesn't solve the upgrade issue. [16:12] also, I'm still not sure update-inetd is guaranteed to be reliable in that case [16:12] It's not. [16:12] because unpack perl -> unpack samba -> unpack perl-modules would still break [16:12] The real problem is that perl-modules is completely broken when it's half-configured during the 5.10->5.12 transition. [16:13] What's curious is that unpacking perl-modules 5.12 on a clean system allows update-inetd to work fine. :/ [16:13] It's only the bizarre half-upgraded state that breaks. [16:14] 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:15] well, that's because the modules all move from /usr/lib/perl/5.10 to 5.12 ... [16:15] (isn't it perl-base/perl-modules that matters?) [16:15] Err, that. [16:15] 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:16] and we probably should just move that [16:16] 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:17] 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] 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] yes [16:18] Riddell: ok - no hurry, just thought I'd check if it's something on your radar [16:18] 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] Thanks. [16:18] infinity: right - I just looked at tkamppeter's report, and see no perl, so perl-modules is already broken by that point [16:21] however, if it were in the prerm, then you could force things with Depends: perl, couldn't you? [16:21] nope [16:21] Depends gives you unpacked, not configured. [16:21] this is the "everything's ok, we're just upgrading and things are currently broken, don't mind our dust" [16:21] infinity: er, no [16:21] 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:22] if you get the sequence of unpack/configure events, you could issue them by hand starting from a natty chroot [16:22] infinity: depends is meant to give you configured; it's just that there are corner cases where configured doesn't mean usable. ;) [16:22] (sorry for being absent, chairing a meeting) [16:23] (because dpkg doesn't care that a dependency of an already-configured package has been removed) [16:23] slangasek: update-inetd configured doesn't mean usable in this case, but perl configured should [16:23] or maybe perl-modules configured [16:23] slangasek: Eh? perl-modules is pretty clearly unconfigured in these upgrade logs. [16:24] infinity: can you give me an example log? [16:24] (that shows perl state) [16:24] btw, there are two tracking bugs now [16:25] slangasek: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/856309 [16:25] Launchpad bug 862129 in samba (Ubuntu Precise) "duplicate for #856309 samba postrm depends on packages not guaranteed to be configured" [High,Triaged] [16:25] bug 877852 is the second master bug (due to LP bug) [16:25] 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:26] infinity: oh, that's interesting; it shows both of perl and perl-modules unpacked at version 5.12 [16:26] 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:27] (but apt tries to DTRT) [16:27] possibly the problem is perl-base not being unpacked yet? [16:27] slangasek: perl-base is configured. [16:28] sure [16:28] but not at the new version? [16:28] slangasek: Yes. [16:28] slangasek: Search through the terminal log. [16:28] oh [16:28] right, found it [16:28] slangasek: perl-modules is unpacked, perl-base is unpacked and configured, samba explodes, perl-modules is never configured. [16:29] this is what we get for using unreliable interpreters like perl; let's rewrite update-inetd in python [16:30] I'm too sick to detect reliably if that was sarcasm. [16:30] a pity === TheDaniel0108 is now known as Daniel0107 === Daniel0107 is now known as Daniel0108 [16:34] I'm not sure it'd be that hard to rewrite update-inetd to not depend on perl-modules [16:34] File::Copy: `cp`; File::Temp: `tempfile`. Well, close. [16:36] infinity: right, I can't reproduce the problem by just plucking the relevant perl bits out of that log [16:38] 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] infinity: I had perl-modules installed [16:40] Actually, what's responsible for setting @INC? [16:41] dunno, but something clearly has it set to the old path [16:43] the initial value appears to be embedded in libperl [16:43] (where I would expect) [16:43] so how can perl be 5.10.1 after perl-base 5.12.4 has been unpacked? [16:43] Except that libperl is unpacked at 5.12 at that point too. [16:44] yeah, and if it wasn't, you'd get a linker error [16:45] Okay, so, perl-modules configuration is a red herring anyway, since perl-modules doesn't have a postinst. [16:45] unpacked == configured. [16:49] jtaylor: ping [16:58] barry: pong [16:58] slangasek: Nevermind, I've gone crosseyed grepping that log. libperl and perl-base are upgraded after samba's unpack failure. [16:59] slangasek: Which then leads to wondering why we get perl-modules upgraded so early, if it depends on perl (>= 5.12) [16:59] 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] slangasek: (Well, okay, perl gets unpacked early too, but libperl and perl-base don't come until much later -- after samba) === dendrobates is now known as dendro-afk [17:01] barry: with what do you ahve an issue? [17:01] I had actually hopped it could be synced for precise with the new debian maintainer [17:02] 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] jtaylor: ultimately, that's my goal too [17:02] barry: yes it turned out to be free after all [17:02] jtaylor: excellent, we can drop that delta [17:02] jtaylor: i think we can also drop the dhpy2 and sslv2 deltas [17:02] I failed to remove it correctly (readded via a patch) but the debian maintainer asked the author who said it was free [17:03] 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] barry: one of the patches contains two seperate changesets [17:03] 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:04] 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] does the debian package enable the tests? [17:04] ah, maybe fix_kill_signal.patch too [17:04] jtaylor: that's the d/rules change i need to double check [17:04] changelog does not mention it :/ [17:05] bad, because 21.1-1 in debian was broken which would have been caught by the test [17:05] yep, it doesn't run the tests [17:05] so no sync, the tests are important [17:05] jtaylor: okay, i'll merge it and forward all the deltas to debian [17:05] all *remaining* deltas [17:05] jtaylor: thanks [17:06] this splits one patch into two http://bazaar.launchpad.net/~jtaylor/ubuntu/oneiric/m2crypto/cosmetics/revision/25 [17:06] And a cable guy is here. Might lose internets intermittently for a while. [17:06] but I guess that should be in debian already [17:08] jtaylor: i think so, but thanks for the link; i'll double check it all === deryck is now known as deryck[lunch] === beuno-lunch is now known as beuno [17:14] infinity: ah, right [17:23] 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:24] hallyn: curious. what branches? [17:24] slangasek, lxc from precise and sid [17:25] (I first did 'quilt pop -a; bzr remove .pc; bzr ci' in both) [17:25] diff -Nrup src ../lxc-sid/src shows no differences before the merge-package attempt [17:25] after, things like src/lxc/arguments.h go away [17:27] 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] oh i dont want to push that to the sid branch :) i just did 'bzr merge-package ../lxc-sid' [17:28] then i'll quilt push -a; bzr add .pc' [17:28] if i don't do that, then bzr gets all confuddled about the 'conflicts' in .pc [17:28] right, but that means the branch you're merging doesn't match the UDD branch anymore [17:28] so it will cause problems for future merges [17:28] hm, it keeps track kof that? [17:28] yes, the .pc conflicts are a horror, but doing it this way just defers the reckoning [17:29] in the end i was probably going to just sling back a debdiff anyway :) [17:29] ah [17:29] if you're not pushing to *either* branch, then that's fine ;) [17:29] but in that case, maybe MoM would be easier? [17:30] 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] i've not used MoM though. but purely by hand it was a bit hairy. [17:31] 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:32] conflicts from MoM's merge: 14 [17:32] how does one run mom? [17:32] 'grab-merge lxc' [17:32] it downloads the pre-staged merge from merges.ubuntu.com [17:32] (from ubuntu-dev-tools package) [17:33] 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:34] 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] hm? there shouldn't be a new upstream version [17:34] hmm [17:35] that's how the output reads to me, but I see that you're right [17:35] ok, I don't know what's causing that conflict then [17:35] 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] however, it is probably related to the 'criss-cross merge' warning at the top [17:35] stgraber, yes, that's what it amounts to :) [17:35] stgraber, i'll let you review if you don't mind [17:36] 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] stgraber, that'll be nice [17:36] hallyn: sure, send me the debdiff and I'll review + upload if it looks good [17:36] thx [17:37] slangasek, i'll have to go read up on criss-cross merge later :) [17:38] 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] 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] 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] hallyn: then we'll be able to use "-a armel" on x86 and get a working container [17:39] cool [17:39] i was meaning to look at libcap2 wrt multiarch. haven't yet though. [17:39] stgraber: yes, jhunt and I have multiarch libnih sorted out, I guess he'll be pushing soon [17:40] 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] (unless I discover that something else than upstart heavily depends on ptrace() in our boot sequence :)) [17:40] heh [17:41] * slangasek thinks that over briefly [17:41] nope, shouldn't be anything else [17:42]