| cyphermox | ceti331: it was an issue with compiz right? have you tried #compiz? | 00:00 |
|---|---|---|
| ceti331 | hah | 00:01 |
| ceti331 | its an issue with building ubuntu's fork of compiz | 00:01 |
| ceti331 | they didn't know and advised i came here | 00:01 |
| cyphermox | oh boy | 00:01 |
| ceti331 | "i dont know, i've never used their bzr stuff..." | 00:02 |
| cyphermox | the expo plugin isn't specific to ubuntu though | 00:02 |
| cyphermox | ceti331: join #ubuntu-desktop, ask smspillaz, he might know | 00:03 |
| ceti331 | before getting it compiling, we found that the git version from compiz was incompatable with the ubuntu-build framework | 00:03 |
| ceti331 | i.e. i can't compile compiz.org's expo source here in ubuntu , but i can from launchpad :) | 00:03 |
| ceti331 | ah ok | 00:03 |
| ceti331 | thanks | 00:03 |
| cyphermox | I'm not sure I follow, are you trying to build the compiz package? | 00:04 |
| ceti331 | my goal is to modify some of the compiz plugins or how they are triggered. I miss my Mac, but in theory one should be able to modify ubuntu to be as efficient... | 00:05 |
| ceti331 | i'm just trying to build "expo" | 00:05 |
| === cpg|away is now known as cpg | ||
| zul | is someone from the MIR team still around? | 00:57 |
| Shinobi | I have a corrupt link. How can i fix? | 01:26 |
| Shinobi | I can't delete it | 01:26 |
| === cpg is now known as cpg|away | ||
| robert_ancell | infinity, I think they're all built now | 02:10 |
| infinity | robert_ancell: Alrighty. | 03:20 |
| === cpg|away is now known as cpg | ||
| pitti | Good morning | 03:42 |
| alazare619 | can someone explain the ubuntu seed files to me | 03:43 |
| alazare619 | im trying to figure out how to build one | 03:43 |
| pitti | alazare619: https://wiki.ubuntu.com/SeedManagement documents how they work | 03:45 |
| === salem_ is now known as _salem | ||
| === cpg is now known as cpg|away | ||
| micahg | BenC: llvm-2.8 should just be removed from quantal as it was from Debian | 05:24 |
| infinity | micahg: Oh, yeah, I meant to do that. | 05:26 |
| infinity | micahg: 2.9 as well, but llvm-py hasn't been ported to 3.x yet, AFAIK. | 05:26 |
| alazare619 | livecd-rootfs tools is not correct | 05:27 |
| infinity | alazare619: I disagree. | 05:27 |
| micahg | infinity: at least llvm-2.9 isn't on the FTBFS list | 05:28 |
| infinity | micahg: It's not? It sure used to be. | 05:28 |
| alazare619 | the auto build script is missing a setup for --syslinux-theme "$project"-"$suite" \ needs to be added | 05:28 |
| alazare619 | otherwise it always uses onerics theme for syslinux | 05:28 |
| infinity | Silly people fixing LLVM. | 05:28 |
| infinity | micahg: Alright, I'll just yank 2.8 and leave 2.9 alone for now. | 05:28 |
| micahg | infinity: silly me syncing the fix :) | 05:28 |
| infinity | alazare619: We don't create ISOs with livecd-rootfs. (so, for us, it's correct). | 05:29 |
| alazare619 | you guys create seed files for the livecd-rootfs system with live-build | 05:30 |
| infinity | alazare619: But please do file a bug about your issue anyway, for when we decide to try to make live-build actually spit out Ubuntu ISOs. | 05:30 |
| infinity | alazare619: Erm. We do what now? | 05:30 |
| alazare619 | ok do explain how you build iso's then | 05:31 |
| alazare619 | cause the seed files on ubuntu's wiki point to live build seed files | 05:31 |
| infinity | alazare619: live-build doesn't take seeds as input. We ask live-build to install package sets via our configs in livecd-rootfs, yes. | 05:33 |
| infinity | alazare619: But that all just spits out a squashfs on the other end. Not an ISO. | 05:34 |
| alazare619 | i understand that | 05:34 |
| alazare619 | so the livecd-rootfs script has an error | 05:35 |
| alazare619 | does ubuntu devel not handle that? | 05:35 |
| infinity | Kay. And since syslinux doesn't exist in the squashfs, that's why I said the above bit doesn't matter to us. | 05:35 |
| infinity | The auto/* scripts in livecd-rootfs are specifically for how Ubuntu builds CDs. | 05:35 |
| alazare619 | yes | 05:35 |
| infinity | If you need something different locally, please do fork from there and tweak. | 05:36 |
| alazare619 | and thats where there should be a changed line tho | 05:36 |
| infinity | But a bug for you isn't (necessarily) a bug for us. | 05:36 |
| alazare619 | line 276 should be --syslinux-theme "$PROJECT"="$SUITE" | 05:37 |
| alazare619 | of config in livecd-rootfs | 05:37 |
| alazare619 | livecd-rootfs/auto/config | 05:37 |
| alazare619 | = = - | 05:38 |
| alazare619 | = is - in the line 276 i mean | 05:38 |
| infinity | alazare619: For you, yes. | 05:38 |
| alazare619 | without that being set it defaults the build to ubuntu oneric theme is what im saying | 05:38 |
| alazare619 | why for me what am i doing diffrent then "ubuntu" | 05:38 |
| infinity | alazare619: You understand what I'm saying when I say that we only use this to build squashfs filesystems that don't have syslinux (or a syslinux theme), because they're not ISOs? | 05:39 |
| alazare619 | well yes i do | 05:39 |
| infinity | What you're doing differently is building an ISO. We do that with an entirely different set of scripts (debian-cd), which you almost certainly don't want to use. | 05:39 |
| alazare619 | well yes and no | 05:39 |
| infinity | And there's nothing wrong with you using live-build and even livecd-rootfs to do what you're doing. What I'm saying is that your config WILL differ from ours. | 05:40 |
| alazare619 | who and what actually manages the iso building then | 05:40 |
| infinity | So your bugs aren't our bugs. | 05:40 |
| alazare619 | to pass the argument per say to them or will that never be incorporated since you guys dont use live build to build the iso too | 05:40 |
| alazare619 | wich i thought was true according to ubuntu wiki live build is used to build the iso too | 05:41 |
| infinity | Where on the wiki does it say that? | 05:41 |
| infinity | It's a lie if it does. ;) | 05:41 |
| infinity | But, some day, we'll fix live-build to produce ISOs that match "official" Ubuntu ISOs. Probably. And then ditch our weird infrastructure. That day isn't today. | 05:42 |
| infinity | Anyhow, for now, anyone who wants to build an ISO with live-build can't use our configs exactly. That's pretty much what I'm driving at. | 05:42 |
| alazare619 | im willing to help fork live-build so it produces it properly | 05:45 |
| alazare619 | but what exactly does live-build do wrong that it shouldnt? | 05:48 |
| infinity | Good question. It's on my TODO to look into it at some point. | 05:49 |
| infinity | We've always done livefs and ISO building in two stages, and we, frankly, didn't trust the shiny new tool to do just do it all for us, so we didn't let it. :P | 05:49 |
| infinity | We'll fix that at some point. | 05:49 |
| pitti | I haven't followed the whole discussion; just want to mention that the official Chinese images are being built with ubuntu-defaults-image, which uses live-build all the way (with some tweaks) | 06:09 |
| pitti | it does differ from the Ubuntu images indeed, though (most notably it does not have a pool) | 06:09 |
| alazare619 | yea only tweak ive done so far was add that line to the livecd-rootfs auto script | 06:12 |
| alazare619 | and changed config/chroot-local_hooks to config/hooks | 06:13 |
| alazare619 | as the new livebuild removed the chroot-local_ from it | 06:13 |
| infinity | pitti: Is it? nusakan doesn't touch it, except to publish it? | 06:15 |
| pitti | no, it's built from nusakan | 06:15 |
| pitti | well, "triggered by"; I guess it's actually built on the buildd machines, just like the regular livefses | 06:16 |
| infinity | pitti: Okay, so yeah. Like I said, "nusakan only touches it to publish it?" | 06:16 |
| infinity | pitti: If so, handy datapoint to know. | 06:16 |
| pitti | right | 06:16 |
| infinity | pitti: So, maybe this man wants to talk to you about ubuntu-defaults-image. :P | 06:17 |
| pitti | alazare619: if you only want to install some additional packages or do some tweaks, ubuntu-defaults-image is indeed much easier to use | 06:17 |
| alazare619 | nah | 06:18 |
| alazare619 | i want the full blown process | 06:18 |
| pitti | it won't help you much for really invasive modifications, though | 06:18 |
| alazare619 | im actually a sys admin lol | 06:18 |
| alazare619 | its a pet project i have going in down time at work | 06:18 |
| pitti | u-d-i more or less configures live-build to produce an Ubuntu-ish image | 06:18 |
| alazare619 | trying to build a distro with qt-razor by default and gnome-shell | 06:18 |
| alazare619 | ive done live-build with debian base of squeeze and wheezy and sid never ubuntu tho | 06:19 |
| alazare619 | but i actually want live build setup for auto so i can crontab the job to do a full clean and rebuild once a month for a new up to date iso | 06:23 |
| alazare619 | no real reason other then to say i did it | 06:24 |
| === tkamppeter_ is now known as tkamppeter | ||
| === cpg|away is now known as cpg | ||
| dholbach | good morning | 07:24 |
| seb128 | cjwatson, slangasek, xnox, stgraber: is anyone looking at the ubiquity issue which is breaking the quantal dailies for 2 days? | 08:13 |
| xnox | seb128: yes. i have been. | 08:13 |
| seb128 | xnox, how is that going? likely to be fixed today? | 08:14 |
| xnox | i got the 900MB big strace, which clearly shows SIGPIPE in apt. | 08:14 |
| xnox | seb128: either a fix, a workaround, or a downgrade should happen soon. | 08:15 |
| seb128 | xnox, right, so I guess one of the updates of 06-29 broke it? | 08:16 |
| xnox | seb128: well. apt & python-apt were updated =) | 08:16 |
| seb128 | xnox, right, and ubiquity | 08:16 |
| xnox | yeah. | 08:16 |
| brendand | seb128, is there a bug number? | 08:16 |
| brendand | (of course there is) | 08:17 |
| seb128 | brendand, bug #1020574 | 08:17 |
| ubottu | Launchpad bug 1020574 in ubiquity (Ubuntu) "SystemError: Broken pipe while installing language packs" [Critical,Confirmed] https://launchpad.net/bugs/1020574 | 08:17 |
| jamespage | hallyn, MIR already raise for xz-java | 08:17 |
| xnox | and now it has full strace attached as well. | 08:18 |
| dpm | cjwatson, RAOF, I think you're the only ubuntu-sru members online right now. So if you're around, may I ask you to have a look at bug 1018038 and approve the upload to precise-proposed? We're nearing the deadline for the Ubuntu App Showdown contest, this bug is blocking submissions and it would be very helpful to have it at least fixed in -proposed | 08:19 |
| ubottu | Launchpad bug 1018038 in quickly (Ubuntu Precise) "When using submitubuntu, should build depend on libglib2.0-bin" [Medium,Triaged] https://launchpad.net/bugs/1018038 | 08:19 |
| RAOF | dpm: You appear to be adding more than just libglib2.0-bin to debian/control; is that intentional? Also, you seem to be adding debhelper (>= 6) twice? | 08:27 |
| dpm | RAOF, mterry did the change and the upload, but I can look at how the update_file_content() function works to see if they're really duplicate arguments | 08:33 |
| RAOF | dpm: Ah, no. Reading context makes that clear. | 08:33 |
| dpm | ok, cool | 08:33 |
| didrocks | RAOF: dpm: update_file_content take a start/end stenza | 08:34 |
| didrocks | which are the second and third arg | 08:34 |
| didrocks | and replaces this with the 4th :) | 08:34 |
| RAOF | didrocks: Yeah, now that I've read the source that makes sense. Without reading the source the patch looks weird. | 08:34 |
| didrocks | RAOF: I wrote it for updating the copyright in every files, hence the start/end need. Interesting mterry used it for that :) | 08:35 |
| RAOF | dpm: Doneinated. | 08:36 |
| dpm | RAOF, \o/ thanks! | 08:38 |
| RAOF | SpamapS: Have you deliberately left a bunch of syncs from -proposed to -updates in the precise queue? | 08:38 |
| === cpg is now known as cpg|away | ||
| infinity | slangasek: There, new dpkg now prints errors to stderr, My PickyPants. :P | 08:53 |
| xnox | infinity: 8) | 09:12 |
| * dholbach hugs seb128 | 09:21 | |
| * seb128 hugs dholbach | 09:22 | |
| dholbach | :) | 09:22 |
| seb128 | dholbach, for once I did my piloting shift in solid way (I've been slacking for some of the previous ones, or rather too busy with other things to do a proper job of it) | 09:23 |
| dholbach | yeah, I can imagine | 09:23 |
| infinity | seb128: Does that mean you cleared out the queue, so I don't have to pilot when I wake up? | 09:25 |
| infinity | seb128: Splendid. | 09:25 |
| * infinity will sleep better now. | 09:25 | |
| seb128 | infinity, lol, not quite | 09:26 |
| seb128 | infinity, but if somebody wants to clear the SRU queue a bit, we are getting close of 40 items unapproved | 09:26 |
| seb128 | slangasek, ^ | 09:26 |
| seb128 | we are getting close from LTS freeze and things move too slowly atm, it's going to be an issue soon if we keep this delay in reviews | 09:27 |
| infinity | seb128: I'll do a bit of cleaning up tomorrow. | 09:28 |
| seb128 | thanks | 09:28 |
| infinity | seb128: slangasek is already at DebConf, so I suspect he'll be less inclined to SRUify. | 09:28 |
| seb128 | right | 09:28 |
| * infinity isn't sure what the complaint is, as he uploaded an SRU earlier today that got through unapproved in a matter of minutes. | 09:29 | |
| seb128 | the 4th of July and Canadian day didn't help this week either ;-) | 09:29 |
| infinity | seb128: Nope. Clearly not. Silly fireworks. | 09:29 |
| seb128 | infinity, can I cheat and wave my SRUs through? ;-) | 09:29 |
| seb128 | is that what you did? ;-) | 09:29 |
| infinity | seb128: I didn't cheat, I had RAOF review mine. :) | 09:29 |
| seb128 | lol | 09:29 |
| infinity | On the other hand, it was a reeeeealy easy review. | 09:29 |
| infinity | Anyhow, I'll poke the queues tomorrow. Seems like a better plan that starting any long-term projects before I jump on a plane. | 09:30 |
| infinity | seb128: Any specific urgencies, or just "everything"? | 09:31 |
| RAOF | seb128: And in general, feel free to ping (particularly on Tuesday); I'm happy to process the SRU queue in an order that's not strictly FIFO. | 09:32 |
| seb128 | RAOF, noted, thanks | 09:32 |
| seb128 | infinity, out of "getting some progressed" I would like to see ubuntu-sso-client in, it has some of the most reported issues on errors.ubuntu.com | 09:33 |
| infinity | seb128: Check. I thought that was on Steve's hitlist when he filled in for me on Monday? Maybe not. | 09:33 |
| infinity | seb128: Anyhow, I'll start there, and then just get FIFOish until I get bored. | 09:34 |
| seb128 | thanks | 09:34 |
| infinity | dholbach: I may steal some piloting time tomorrow to do SRU stuff instead, since this week's been a mess for that. :P | 09:34 |
| seb128 | I can do some extra sponsoring in exchange | 09:34 |
| Daviey | infinity: Hey, you are in the MIR team, right? | 09:34 |
| infinity | Daviey: I am now/again, yes. Talk to me about it in ~6.5h I'm going to sleep. Honest. | 09:35 |
| dholbach | awesome | 09:35 |
| dholbach | infinity, sleep tight | 09:35 |
| Daviey | infinity: ok, sleep tight. | 09:35 |
| infinity | Daviey: Better yet, talk to mterry, cause he's +1 this month, and MIR and +1 kinda go hand-in-hand. ;) | 09:35 |
| Daviey | infinity: I try to spread the world of pain we induce. | 09:36 |
| infinity | You could introduce less pain instead. | 09:36 |
| infinity | Just a thought. | 09:36 |
| Daviey | Nah, no fun tere. | 09:36 |
| infinity | Says you. | 09:36 |
| Daviey | infinity: sure you don't want to take a real simple package? it's a single py file. :) | 09:37 |
| infinity | Bug me in the morning. | 09:37 |
| Daviey | ok, thanks. | 09:37 |
| Daviey | didrocks: Hey, how are you doing? :) | 09:37 |
| infinity | Only C and POSIX shell are simple at this time of night. | 09:37 |
| infinity | Everything else is voodoo. | 09:37 |
| didrocks | hey Daviey, I'm fine, thanks! | 09:37 |
| didrocks | and yourself? | 09:37 |
| * xnox wonders if single.py file is like bzip2 base64 encoded binary blob ~3MB in size, similar to waf | 09:37 | |
| Daviey | didrocks: Pretty good.. As you are around and all.. fancy taking a seemingly simple MIR request? | 09:38 |
| Daviey | <silence> | 09:38 |
| didrocks | Daviey: if it's simple, I'm all for it. I still have on my backlog some long, complicated, and interdependant ones :) | 09:38 |
| didrocks | but don't lie, it has to be simple now! :) | 09:39 |
| Daviey | didrocks: bug 1021528 .. it really is just a 45 line python script packaged. | 09:39 |
| ubottu | Launchpad bug 1021528 in python-setuptools-git (Ubuntu) "[MIR] python-setuptools-git" [Critical,New] https://launchpad.net/bugs/1021528 | 09:39 |
| didrocks | Daviey: sounds easy enough, looking now :) | 09:39 |
| Daviey | much appreciated.. (it will be blocking openstack milestone uploads later today) | 09:39 |
| didrocks | Daviey: will be quickly done | 09:40 |
| didrocks | Daviey: I'm surprised, isn't openstack on launchpad? | 09:40 |
| didrocks | they are using git now? | 09:40 |
| tumbleweed | is setuptools-git even used in the Debian build process? | 09:41 |
| Daviey | didrocks: It's complicated.. github for code hosting, self hosted gerrit for code review, launchpad for bugs and bluepritns. | 09:41 |
| tumbleweed | surely it's something that's trivially patched out? | 09:41 |
| didrocks | Daviey: wow, quite an interesting setup! | 09:41 |
| Daviey | tumbleweed: well it is easily patched out.. yes.. but long trm, that is more work than having a tool do it for us. | 09:42 |
| didrocks | (I like the except: comment btw :p) | 09:42 |
| tumbleweed | Daviey: but when you are building from a orig tarball there's no git repository for it to use | 09:42 |
| tumbleweed | so it adds no value | 09:43 |
| jamespage | can someone give me a clue as to what I've done wrong here - https://launchpadlibrarian.net/109452563/buildlog_ubuntu-quantal-i386.hsqldb_1.8.0.10-13_FAILEDTOBUILD.txt.gz | 09:45 |
| Daviey | tumbleweed: Stop raising seemingly valid points. | 09:45 |
| didrocks | Daviey: I'm interested and about to raise the same question btw :p | 09:46 |
| cjwatson | I tend to think it's not worth patching out trivial bits of build system to avoid having them in main | 09:46 |
| cjwatson | Unless it's going to pull in some giant stack of stuff | 09:46 |
| didrocks | basically their build system is not shipping the MANIFEST file, right? | 09:47 |
| tumbleweed | however, these setuptools plugins that rely on the VCS to know what to include in a package break when you don't have the vcs metadata | 09:47 |
| Daviey | well, i admit i haven't dug into this myself.. i'm merely shepherding.. but base don the request, it seemed logical considering it's a 45 line python file with no deps. | 09:47 |
| tumbleweed | so you often end up having to patch MANIFEST.in | 09:47 |
| cjwatson | tumbleweed: It depends whether it's going to fail hard, or just fall back to looking at the tarball | 09:47 |
| didrocks | Daviey: speaking of no deps, it should dep on git I guess :) | 09:47 |
| tumbleweed | cjwatson: yeah | 09:47 |
| xnox | jamespage: do you really have dpkg-checkbuilddeps: Unmet build dependencies: "build-essential:native" in your package deps? If not, then it's a bug in buildd or something =) | 09:47 |
| tumbleweed | actually MANIFEST.in is for sdist, but one does have to frequently touch package_data in the setup.py | 09:47 |
| xnox | jamespage: surely you never add build-essential to depends...... | 09:47 |
| jamespage | xnox, no - and the test build I did worked fine locally using sbuild | 09:48 |
| jamespage | xnox, hence my 'either its broken or I'm being dumb' style question :-) | 09:48 |
| infinity | That would be the new dpkg. | 09:48 |
| Daviey | didrocks: Hmmpf.. on the face of it, this might be just for generating the source package. | 09:48 |
| infinity | Which so shouldn't be doing that... | 09:49 |
| tumbleweed | Daviey: I think it is. But as cjwatson said, if having teh package avoids patching, it's useful | 09:49 |
| Daviey | tumbleweed: That is what i said initially :/ | 09:50 |
| xnox | infinity: well looks like fallout from .5 - but HOW?! http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558095 | 09:50 |
| ubottu | Debian bug 558095 in dpkg-dev "dpkg: please accept ":native" multiarch qualifier in build dependencies" [Wishlist,Fixed] | 09:50 |
| infinity | xnox: Yeah, I knew exactly what change broke it when I saw it. | 09:51 |
| infinity | xnox: What I'm not sure about is how no one saw this. :/ | 09:51 |
| * infinity sighs as he goes about fixing. | 09:52 | |
| xnox | Daviey: well, for example gnome conditially includes git make snippet, to do build-from-git-foo. But it still builds fine without git. | 09:52 |
| infinity | Sleep is for the weak anyway. | 09:52 |
| xnox | Daviey: are you saying that upstream will not accept a patch: "build from tarball, without git, if no git available"? | 09:53 |
| tumbleweed | or conditionally import git integration when the command is sdist | 09:54 |
| Daviey | xnox: I'm not saying anything :) | 09:54 |
| xnox | =))) | 09:54 |
| xnox | Daviey: I'm not volunteering for writing any patches either ;-) | 09:54 |
| Daviey | bah | 09:56 |
| didrocks | Daviey: added some comments, but looks overall good apart from some quick fixes needed | 09:58 |
| infinity | jamespage: Thanks for the heads-up. Rebootstrapping a fixed dpkg now. :/ | 10:05 |
| jamespage | infinity, np | 10:06 |
| infinity | I'll have to look later into why this appears to have blown up for us but not caused a huge mess in Debian. | 10:07 |
| cjwatson | infinity: Maybe it matters that our sbuild understands :any build-deps? | 10:11 |
| infinity | cjwatson: It's not sbuild failing, it's dpkg-checkbuilddeps. | 10:11 |
| cjwatson | mm, ok, I can't think of a plausible way sbuild could be involved there :) | 10:11 |
| infinity | And it doesn't fail for me in a Debian chroot, only Ubuntu. | 10:12 |
| infinity | So, all I can think is that Steve's workaround hack had some fallout interaction here. | 10:12 |
| infinity | But since it's simple to back out the :native from checkbuilddeps for now to "fix" it, we can look at root causes and fixes later. | 10:12 |
| infinity | For now, I just need to make the chroots happy and get us building again. | 10:12 |
| infinity | cjwatson: Hahaha. | 10:18 |
| infinity | cjwatson: So, it could just be that the patch is busted. :P | 10:18 |
| infinity | cjwatson: Yup, confirmed. | 10:19 |
| infinity | cjwatson: Debian's build-essential isn't M-A:foreign, but ours is. Apparently, a native-arch build-dep that's marked M-A:foreign isn't "native" in this feature's world. | 10:19 |
| infinity | cjwatson: So, making the obvious(ly wrong, but will work for now) fix right now, and we can look into fixing this to not be broken later. | 10:20 |
| * cjwatson tries to understand that and concludes coffee and breakfast would help. | 10:21 | |
| cjwatson | Rather you than me :) | 10:21 |
| mvo | apw: if you could later check #1021298 that woudl be cool, it probably just shows my ignorance about ipv6, but help would be welcome (but lunch first :) | 10:22 |
| apw | mvo, ok | 10:27 |
| apw | bug #1021298 | 10:27 |
| ubottu | Launchpad bug 1021298 in squid-deb-proxy (Ubuntu) "squid-deb-proxy should advertise and use IPv6 addresses" [Medium,In progress] https://launchpad.net/bugs/1021298 | 10:27 |
| apw | mvo, can i have an ifconfig -a from the box which reports the error please | 10:29 |
| apw | mvo, and the output of /usr/share/squid-deb-proxy-client/apt-avahi-discover | 10:33 |
| apw | mvo, and avahi-browse -kprt _apt_proxy._tcp | 10:33 |
| apw | mvo, belay all that, i've made a new network to test this on | 10:39 |
| apw | mvo, i'll sort it out and get the branch updateds | 10:42 |
| Daviey | didrocks: thanks | 10:46 |
| infinity | cjwatson: Now that the crisis is averted, I might sleep on this before I upload the proper fix, but does this look sane to you for a correct interpretation of what should really be happening? | 10:51 |
| infinity | cjwatson: http://paste.ubuntu.com/1077890/ | 10:51 |
| cjwatson | infinity: the multiarch spec explicitly says "so long as the [package build-depended on using :any] declares itself as Multi-Arch: allowed" | 10:52 |
| cjwatson | so I don't think it's correct to extend that in dpkg without spec work | 10:53 |
| infinity | cjwatson: Oh, so the fact that the previous dpkg-dev (ie: the one in precise, and everything up until just now) allowed "foreign" was a bug? :P | 10:53 |
| cjwatson | well, a bug in either dpkg-dev or the spec :) | 10:54 |
| infinity | cjwatson: Well, allowed foreign, host, and all. | 10:54 |
| infinity | cjwatson: But okay, I can scrap the "fixes" to any to revert behaviour. | 10:54 |
| cjwatson | ok, if it's restoring previous behaviour then fair enough for now | 10:54 |
| infinity | We didn't use it much anyway, and I think we only used it for allowed stuff. | 10:54 |
| infinity | (gettext was allowed, anyhow) | 10:54 |
| cjwatson | the :native change looks ok as long as $a is the architecture of the package and not the current architecture or something | 10:54 |
| infinity | $a is package, $host and $build are what you'd expect. | 10:55 |
| infinity | (And the day those don't seem semantically backwards to me is probably the day I get a lobotomy) | 10:55 |
| cjwatson | it's worse when you encounter packages that permute the semantics of build/host/target ... | 10:56 |
| cjwatson | (I'm looking at you, nspr. Or maybe nss. IIRC they permute them *differently*.) | 10:56 |
| infinity | At least "target" probably only has one sane meaning. | 10:56 |
| cjwatson | I'm pretty sure at least one of those makes it mean host. | 10:56 |
| infinity | And by host, you mean build? | 10:57 |
| infinity | Cause I'd argue that target should mean host. | 10:57 |
| cjwatson | I meant autotools host. | 10:58 |
| cjwatson | But I could be misremembering; this was a while back. | 10:58 |
| infinity | Aaaanyway. | 10:58 |
| infinity | I'll revert the :any bits, if that's getting us closer to spec. | 10:58 |
| infinity | Yes, I'm restoring previous behaviour, but no, I don't care to. | 10:58 |
| cjwatson | Check with Steve first. Since he wrote that spec and the original :any patch, he should know ... | 10:58 |
| infinity | I suspect you'll find that 99% of our :any build-deps are all gettext anyway. :P | 10:59 |
| cjwatson | I might just be missing some extension spec somewhere | 10:59 |
| cjwatson | https://wiki.ubuntu.com/MultiarchCross | 11:00 |
| cjwatson | So that also says :native on foreign is disallowed. Why? | 11:01 |
| infinity | That makes no sense. | 11:01 |
| infinity | So, the patch was implementing the spec, but I'd argue the spec is wrong. :P | 11:01 |
| infinity | I'll talk to Steve about it before I fix anything. | 11:02 |
| infinity | My current workaround has us over the panic anyway. | 11:02 |
| cjwatson | It's not *necessary* to use :native for M-A: foreign, but I can't see why it should be *disallowed*. | 11:02 |
| cjwatson | But yeah, Steve may remember some argument that led to this. | 11:03 |
| infinity | Very weird indeed. | 11:04 |
| infinity | Cause I can't, for the life of me, determine a difference between a package with any M-A header or one without, if they're all BUILD_ARCH (ie: native). | 11:04 |
| * infinity shakes his head. | 11:04 | |
| infinity | Sleep with fix everything. | 11:05 |
| infinity | I also note that table assumes some cleverness on the part of the resolver. | 11:07 |
| infinity | I wonder if the latest sbuild is actually that bright about selection. | 11:08 |
| mvo | apw: thanks a bunch! | 11:17 |
| === MacSlow is now known as MacSlow|lunch | ||
| mpt | What are the use cases for the "Source code" checkbox in Software Sources? (1) Meeting GPL etc requirements to provide source code. (2) Letting developers get the code to fix a package. (3) ...Anything else? | 11:56 |
| mpt | ((2) being somewhat replaced by "bzr branch lp:ubuntu/name-of-package") | 11:57 |
| tumbleweed | there's also pull-lp-source which doesn't use APT | 11:57 |
| tumbleweed | (replacing 2) | 11:58 |
| tumbleweed | apt-get build-dep requires deb-src entries, but one can use mk-build-deps instead | 11:58 |
| cjwatson | source packages significantly better mirrored and thus much faster to download than bzr branch lp:... | 11:59 |
| xnox | mpt: (3) allowing people to easily rebuild packages with local patches / changes for example. Which system administrators often do. And users often do by following online tutorials/howtos. | 12:00 |
| mpt | ok | 12:01 |
| xnox | mpt: (1) is kind of not true. We provide the sources on our servers and mirrors. we actually do not require to force include downloading deb-src lines to comply with GPL. with GPL you must provide source "upon request" and a check box is easy to do that ;-) | 12:02 |
| tumbleweed | xnox: which makes 1 a use case for that checkbox | 12:04 |
| xnox | tumbleweed: yeah I know =)))))) i somehow looped in my argumentation. | 12:04 |
| xnox | while true: | 12:04 |
| xnox | punish(self) | 12:05 |
| mdeslaur | hrm, why _do_ we enable deb-src in a default install? besides taking longer to download Sources files, is there a particular reason why all our users would need that by default? | 12:07 |
| xnox | bdmurray: i was pondering if we can harvest launchpad bugs to find out how many % people have: normal installs, lvm installs, crypt installs, RAID installs | 12:07 |
| xnox | bdmurray: I understand that it would be under-reported. but still any numbers would help even to see at least any correlations. | 12:08 |
| hallyn | jamespage: \o/ thanks | 12:22 |
| jamespage | hallyn, TBH I did not really do anything other than look :-) | 12:33 |
| ScottK | Laney: Are the libs the depend on the libxml .la file in packages that are in Ubuntu, but not Debian? Without really looking at it in detail, it seems to me that getting rid of those dependencies is the thing to do. | 12:34 |
| Laney | I don't know. Aron said he'd taken care of Debian, but I didn't check for him. | 12:35 |
| Laney | and yes. See the bug I filed. There are only two packages. | 12:35 |
| ScottK | OK. | 12:35 |
| Laney | since they are both hosed atm, it was easier to unblock the update by just keeping it for now | 12:36 |
| ScottK | I accepted it. Please go back and clean up after they're fixed. | 12:38 |
| Laney | cheers | 12:39 |
| === vibhav is now known as ILoveUbuntuOMG | ||
| === ILoveUbuntuOMG is now known as vibhav | ||
| * BenC saw a notice on this window but can't find it | 12:54 | |
| === _salem is now known as salem_ | ||
| cjwatson | BenC: 06:24 <micahg> BenC: llvm-2.8 should just be removed from quantal as it was from Debian | 12:57 |
| cjwatson | ... ah, the answer to "how did this ever possibly work" is "it didn't" | 12:58 |
| cjwatson | that makes more sense. | 12:58 |
| apw | am i expecting usb sticks to be mounting on /run/media/blah now, and if so should /media point to /run/media (which it does not on my system) | 13:00 |
| Daviey | apw: I thought it was agreed it would be reverted... seb128 & slangasek know more | 13:01 |
| Laney | bug #1020759 | 13:03 |
| ubottu | Launchpad bug 1020759 in udisks2 (Ubuntu Quantal) "/run/media is an unnecessary divergence from the FHS" [Medium,Triaged] https://launchpad.net/bugs/1020759 | 13:03 |
| smoser | ahasenack, i'm aware of the issue, its covered under bug 974509 | 13:09 |
| ubottu | Launchpad bug 974509 in cloud-init (Ubuntu) "cloud-init selects wrong mirror with dns server redirection" [Low,Confirmed] https://launchpad.net/bugs/974509 | 13:09 |
| seb128 | Daviey, apw: what Laney pointed, upstream disagree with using /media being important and say people who want a fixed mounting should use fstab to define it | 13:10 |
| zul | didrocks: ping | 13:12 |
| didrocks | hey zul | 13:12 |
| zul | didrocks: saw the bug and just did what you asked for in python-setuptools-git | 13:13 |
| didrocks | zul: excellent! upload on the way? :) | 13:13 |
| zul | didrocks: just did | 13:13 |
| xnox | apw: Daviey: seb128: Laney: I totally dislike the whole /run/media/$user/$bla because when i become root I need to search and hunt for usb-media in random directories instead of /media/$UUID | 13:13 |
| didrocks | zul: ok, will wait for it to build, (looking at the diff meanwhile) then promoting to main | 13:14 |
| zul | didrocks: cool thanks | 13:14 |
| didrocks | zul: yw :) | 13:14 |
| apw | seb128, a tricky one, the $user part seems reasonable for security, perhaps a compromise ln -s /run/media /media | 13:14 |
| didrocks | zul: hum, is it me or you didn't do the most important change: depending on git? | 13:26 |
| zul | didrocks: argh! | 13:26 |
| didrocks | zul: I guess you just won some karma for a newer upload :p | 13:26 |
| zul | didrocks: i did | 13:26 |
| BenC | cjwatson: thanks, I'll stop porting it then :) | 13:27 |
| BenC | I had actually fixed the second problem already | 13:27 |
| didrocks | zul: hum, I don't see it in http://launchpadlibrarian.net/109463289/python-setuptools-git_0.4.2-0ubuntu1_0.4.2-0ubuntu2.diff.gz | 13:27 |
| didrocks | zul: oh, the "I did" was for acknowleding the karma winning, gotcha :) | 13:27 |
| zul | didrocks: gimme a sec ill add git to the depends | 13:28 |
| ahasenack | smoser: thanks for the bug number | 13:30 |
| zul | didrocks: uploaded with git depends | 13:30 |
| smoser | ahasenack, the real solution, there is "use a real dns provider" | 13:30 |
| didrocks | zul: excellent, thanks! | 13:30 |
| smoser | but, we will likely be changing that functionality soon. | 13:30 |
| ahasenack | smoser: chrome seems to do some pretty smart stuff | 13:31 |
| ahasenack | smoser: it tries to resolve some randomly generated names | 13:31 |
| ahasenack | smoser: if an ip comes back instead of a resolver error, it knows the isp is playing funky games | 13:31 |
| smoser | ahasenack, that is an interesting solution. | 13:32 |
| ahasenack | smoser: thinking out loud, we could try to resolve something like "shouldnotresolve.canonical.com" and get #is to never use that domain name :) | 13:32 |
| === MacSlow|lunch is now known as MacSlow | ||
| apw | mvo, ok have figured out why it occurs, now to figure out what to do about it :) | 13:35 |
| mvo | apw: so what is the 2min summary of what is happening? | 13:38 |
| apw | apt is saying "convert the address into and address" but its doing that in the context of "taking into account which address families i have routable addressing for" | 13:39 |
| apw | ie, its saying do i have a non-link local addy for ipv6, if not i can't use any ipv6 address even a link local one | 13:39 |
| apw | i'd argue that that is a bug but, for now i need to work out when that would occur and not return the advertised ipv6 addressing | 13:40 |
| BenC | cjwatson, infinity: Is there a plan to sync the tiff source that produces libtiff5? Several packages are dep-wait on it | 13:50 |
| cjwatson | BenC: blocked on me resolving the MIR feedback on jbigkit | 13:52 |
| cjwatson | which is indeed on my list if I can ever clear off emergencies :) | 13:52 |
| BenC | What's more of an emergency than supporting the one-true-lossless-image-codec!?! :) | 13:54 |
| Debolaz | Is the plan still to get rid of the alternate installer in 12.10? | 13:59 |
| * BenC hopes not | 14:00 | |
| cjwatson | that is the current plan, conditional on some ubiquity features being implemented | 14:00 |
| BenC | cjwatson: will there still be a net boot option of sorts? | 14:00 |
| cjwatson | yes, netboot certainly isn't going away | 14:00 |
| BenC | So is debian-installer still going to be around, it's just the alternate cd images? | 14:01 |
| cjwatson | (as in, even if Canonical weirdly decides to stop supporting it, I'm entirely prepared to do so all by myself :-P ) | 14:01 |
| BenC | …that are going away | 14:01 |
| cjwatson | right | 14:01 |
| cjwatson | even that's flavour-specific, so I guess a flavour might choose to keep them | 14:01 |
| BenC | Good good…count me in on the support-it-ourselves camp, if it ever comes to that | 14:01 |
| zul | didrocks: hey did it get promoted yet? | 14:02 |
| Debolaz | cjwatson: My main concern is somerthing that seems to be notoriously difficult to get right in installers: Full disk encryption. That's a mandatory feature for me. | 14:02 |
| cjwatson | Debolaz: full-disk encryption is one of the ubiquity features that this is conditional on | 14:02 |
| Debolaz | Good to know. :) | 14:03 |
| Debolaz | I love Ubuntu, but I'm jumping ship if FDE goes away. :) | 14:03 |
| didrocks | zul: I'm waiting for it to be published first | 14:04 |
| zul | didrocks: ack | 14:04 |
| cjwatson | and even if that weren't the case, as above, netboot installation will still exist either way and is basically the same UI as the alternate CD (you can even boot it from a CD, "mini.iso", if you prefer) | 14:04 |
| SpamapS | RAOF: no I forgot to go in and approve them | 14:04 |
| apw | is there an approved tool for looking up interface addreses, else can i rely on 'ip' being installed | 14:04 |
| SpamapS | RAOF: just as I did the sru-release bit, I got pulled away for family stuff. :-P | 14:04 |
| SpamapS | apw: for what purpose do you want to look up the address? | 14:05 |
| SpamapS | apw: most of the time its useless to know your own address... you need to know the address by which others can reach you | 14:06 |
| apw | SpamapS, i want to know if the local machine has a public ipv6 address | 14:06 |
| SpamapS | best way is to grab the hostname and look for an ipv6 address | 14:06 |
| Debolaz | Now if only support for apple keyboards could be fixed, ubuntu would be pretty darn perfect. :) | 14:07 |
| apw | SpamapS, or more correctly an address which would be returned under AI_ADDRCONFIG | 14:07 |
| apw | SpamapS, an | 14:07 |
| apw | SpamapS, and an approved way of doing that ? | 14:07 |
| mpt | Debolaz, I just finished sketches for full-disk encryption, so if it's notoriously difficult maybe you have comments on what I got wrong. ;-) <https://docs.google.com/a/canonical.com/document/d/1bZ4yQIVgGaUGSYu3qiUHnQt3ieBZoqunP_DcleHCr3I/edit#heading=h.n4153uoa2m9d> | 14:07 |
| didrocks | cjwatson: change-override is not in the PATH anymore, I found it on cocoplum, but is that wanted, are there some new way for promoting? | 14:07 |
| cjwatson | didrocks: https://lists.ubuntu.com/archives/ubuntu-archive/2012-June/045233.html | 14:08 |
| cjwatson | the copy you found on cocoplum is probably in an old tree only used for poppy (the sftp uploader); do not attempt to use it | 14:08 |
| * apw gets the feeling he is going to have to duplicate the code in apt for this in the end ... grrr | 14:08 | |
| didrocks | cjwatson: oh, seems I'm not on this ML | 14:08 |
| SpamapS | apw: hostname? | 14:08 |
| didrocks | cjwatson: excellent, using that now. That's why I prefered to ask you before doing anything :) | 14:09 |
| Debolaz | mpt: Glancing over it, it looks like one feature is missing: Overwriting the encrypted partition with random data. | 14:09 |
| cjwatson | didrocks: in general I'm steadily replacing programs on cocoplum with programs in ubuntu-archive-tools, so if you notice something disappearing from the former, look in the latter first | 14:09 |
| Debolaz | mpt: Before encryption takes place. | 14:09 |
| mpt | Debolaz, are you suggesting that should be optional? | 14:10 |
| didrocks | cjwatson: I'll from now on :) (also, I'll subscribe to this ML) | 14:10 |
| cjwatson | Debolaz,mpt: mm, the backend used to do that by default but it was outrageously slow so we turned it off by default | 14:10 |
| cjwatson | (lots of testers complained) | 14:10 |
| didrocks | cjwatson: thanks ;) | 14:10 |
| Debolaz | mpt: It must either be mandatory, or a possibility. | 14:10 |
| cjwatson | it must not be mandatory, but it may be optional | 14:11 |
| Debolaz | cjwatson: Optional is fine by me, but it must be there. | 14:11 |
| cjwatson | I agree it ought to be | 14:11 |
| mpt | cjwatson, Debolaz: If you're both right, that leaves only one option, and it's not one I like... | 14:11 |
| mpt | ... and that's a checkbox (or pair of radio buttons) offering two unpalatable choices | 14:12 |
| mpt | "Do you want this to be slow, or do you want it to be insecure" | 14:13 |
| didrocks | zul: done, please use arch:all for your next upload | 14:13 |
| cjwatson | Actually, there might be a second option | 14:13 |
| zul | didrocks: great thanks | 14:13 |
| cjwatson | (Let me just do a bit of bug archaeology before following up on that remark) | 14:13 |
| Debolaz | mpt: Seems like that has to be the way to go if making it mandatory isn't acceptable. | 14:13 |
| cjwatson | So, we did once try making the erasure on by default but cancellable | 14:14 |
| cjwatson | That didn't work well in d-i because of two bugs: firstly, there was no straightforward way to change the name of the Cancel button (bug 188085); secondly, the progress update was not very responsive (bug 218912) | 14:15 |
| ubottu | Launchpad bug 188085 in debian-installer (Ubuntu) "debian-installers encrypted erase disc cancel button should read Skip" [Wishlist,Confirmed] https://launchpad.net/bugs/188085 | 14:15 |
| ubottu | Launchpad bug 218912 in partman-crypto (Ubuntu) "takes a long time to respond when cancelling erase process" [Medium,Triaged] https://launchpad.net/bugs/218912 | 14:15 |
| cjwatson | The first bug is pretty intractable in d-i, but would be easy to fix in ubiquity | 14:15 |
| cjwatson | The second was never worth bothering to fix due to the first, but shouldn't be desperately difficult to do | 14:15 |
| cjwatson | (Original bug about poor performance: bug 151244) | 14:16 |
| ubottu | Launchpad bug 151244 in partman-crypto (Ubuntu Hardy) "encrypted lvm initialisation is very slow" [Medium,Fix released] https://launchpad.net/bugs/151244 | 14:16 |
| cjwatson | I think if we could fix 218912 and provide a better context-specific UI for cancellation, this would be a perfectly viable approach | 14:17 |
| mpt | A "Skip" button would be quite difficult to understand in Ubiquity, with partitioning going on in the background of other steps | 14:17 |
| mpt | (could be confused with skipping other steps) | 14:17 |
| cjwatson | It could be "Skip erasure" perhaps (or better wording) | 14:17 |
| cjwatson | I don't think it needs to be a single-word verb in any case | 14:17 |
| mpt | So, let's say we go the option route instead of the Skip route | 14:18 |
| * Debolaz is also happy BTRFS finally works with LUKS in 12.04 :) | 14:18 | |
| cjwatson | Anyway, just another option to consider | 14:18 |
| mpt | Would it make sense to have it on by default (but turn-off-able) if you're overwriting a Linux partition, and off by default if you aren't? | 14:19 |
| mpt | (e.g. if the disk is empty or has FreeDOS or something on it) | 14:20 |
| Debolaz | mpt: No. | 14:20 |
| mpt | No? | 14:21 |
| Debolaz | mpt: a) Protecting previous information about the system, which is what you assume is the reason, is equally important for all previous systems, not just Linux and b) The actual reason for overwriting data is to protect the current system, not the previous installation. If you don't do a complete random erasure, the structure of the encrypted system is a lot more visible and can reveal a lot of information. | 14:22 |
| mpt | Fair enough. | 14:22 |
| cjwatson | Debolaz: If you happen to know about this, I'd appreciate a reference to cryptographic studies that show increased ease of attack when the contents weren't randomly erased first | 14:23 |
| cjwatson | I can see the intuitive argument, but that's different from a proof :-) | 14:24 |
| cjwatson | The closest I've been able to find quickly is http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions 5.2, which is quite weak ("If you think this is a risk") | 14:27 |
| Debolaz | cjwatson: Unfortunately, I don't have any research papers on hand about it. :) | 14:29 |
| cjwatson | It's an interesting tradeoff; it matters until such time as you have written enough stuff to disk on the installed system to use all blocks, and after that point it's irrelevant | 14:32 |
| cjwatson | So it's particularly relevant on very large disks where it might take you a long time to use all blocks, but that's exactly the case where it will result in a very great deal of waiting around during installation before you can actually use your system | 14:33 |
| Debolaz | cjwatson: From a theoretical point of view: It gives the adversary access to ciphertext to use for analysis, while a with a randomized partition, he can't rely on any particular data (At least no significant chunks) being actually valid encrypted data. | 14:34 |
| cjwatson | I understand the prose theoretical argument, but this sort of thing is terribly susceptible to folk myth | 14:34 |
| cjwatson | And it's very easy to get the analysis wrong intuitively, or drastically misestimate the risks | 14:34 |
| xnox | but we use lvm as well with LUKS, doesn't that scatter the blocks of data to make the chipertext access harder? | 14:34 |
| xnox | or does lvm assign blocks continuously, while it can? | 14:35 |
| cjwatson | I've never really checked, but from occasional observations I've had the impression that it generally tries to assign continuously within an LV | 14:36 |
| xnox | my laptop is currently full-disk encrypted with plenty of space in the volume group, but I may be beyond the point of every block used at least once, due to using lvm volumes to back VMs and sbuild etc | 14:36 |
| Debolaz | xnox: No, because all blocks that are not ciphertext will be all zeros. So you just collect all blocks that has nonzero data in it, and there is your ciphertext, ready for analysis. This *is* theoretical though, in the sense that it's not feasible for most to break AES-CBC even with a lot of known ciphertext (Not to be confused with known plaintext) | 14:36 |
| cjwatson | That said I suppose I don't know whether its allocations within a PV are in order within the extents of that PV | 14:36 |
| xnox | Debolaz: i probably should start a spec for next cycle for things that are "nice to haves" | 14:37 |
| cjwatson | Debolaz: my concern is that if we (as an OSV) make it too inconvenient/slow/insert-bad-adjective to install a secure system, then the net effect will actually be a less secure world because people will choose not to bother | 14:37 |
| cjwatson | the correct answer when faced with a convenience/security tradeoff is not necessarily to crank the security dial up to 11 :) | 14:38 |
| Debolaz | cjwatson: That is a real concern and a tradeoff. So optional is fine for me. | 14:38 |
| Debolaz | cjwatson: As long as the possibility is there. | 14:38 |
| xnox | Debolaz: I would be willing to make this pre-seedable, but I am not sure if we want this in the UI | 14:38 |
| xnox | maybe a --enable-random-disk-wipe button or in the advanced partitionaire. | 14:38 |
| cjwatson | Debolaz: as a data point, the person who originally reported the "oh my god this is hopelessly slow and I don't want to bother with it" bug is a cryptographer ;-) | 14:39 |
| xnox | i think it's too much for the automatic installer to use (aka a checkbox) | 14:39 |
| xnox | =)))) | 14:39 |
| xnox | cjwatson: oooh the irony ;-) | 14:39 |
| xnox | cjwatson: can we feel unused blocks with random data post-install with a cron job? | 14:40 |
| xnox | s/feel/fill | 14:40 |
| cjwatson | not sure | 14:40 |
| cjwatson | I don't know how much of that relies on the device being unmounted for sanity | 14:40 |
| cjwatson | as in do you introduce some weakness by going through the fs | 14:40 |
| xnox | well yeah, cause we have four layers: fs, lvm, crypt, physical drive | 14:41 |
| Debolaz | xnox: Making it pre-seedable only gives people a strong incentive to maintain a separate version with it enabled though (Like the alternate installer). Might as well satisfy everyone, just keep it in an "advanced" tab or something if you want to avoid normies to accidentially get a slow experience. | 14:43 |
| xnox | Debolaz: $ ubiquity --enable-full-disk-erase | 14:44 |
| cjwatson | things that make UI designers shudder: advanced tabs :-) | 14:44 |
| * Debolaz would be fine with that. | 14:44 | |
| xnox | Debolaz: i used "pre-seedable" in the broad terms of not visible in the UI by default. at all. | 14:44 |
| Debolaz | As long as it's possible, and documented somewhere. :) | 14:45 |
| xnox | but "easy-enough to enable with those in the know" | 14:45 |
| xnox | but "easy-enough to enable *by* those in the know" | 14:45 |
| Debolaz | As an unrelated sidenote, I'm also happy that compiz has become a lot more stable in 12.04 | 14:48 |
| Debolaz | It haven't even crashed once yet. :) (Which wasn't exactly the experience in 11.10 and earlier) | 14:49 |
| xnox | Debolaz: yeap. same here. I even switched back to 3D from 2D mode! =) | 14:51 |
| Debolaz | 2D mode was a bit of a weird thing for me. It had a lot of small bugs and quirks I didn't like. | 14:52 |
| Debolaz | I might give xubuntu a spin for a while though. | 14:55 |
| Debolaz | Btw, does xubuntu have a dev channel? | 15:01 |
| xnox | Debolaz: #xubuntu-dev i think | 15:02 |
| xnox | Debolaz: nah, just #xubuntu | 15:02 |
| xnox | Debolaz: there is! #xubuntu-devel | 15:03 |
| * Debolaz goes to #xubuntu first to check if he's just missing something basic. | 15:04 | |
| frafu | Hi, The main coder of onboard is working on a prediction for onboard, the onscreen keyboard shipping with the LiveCD (no idea yet, whether it will be ready for quantal). The prediction will need dictionaries, but I suppose that it might not be possible to ship them with the LiveCD, because of the space they will occupy. Thus, we thought to have the onboard source package create two different debs: the usual onboard.deb and an onboard-p | 16:21 |
| frafu | rediction-data.deb. The first would go as always on the LiveCD. Do we have to do anything special to make the package with the prediction data available to the Ubuntu users, or will the ubuntu developers take care of doing the necessary when they upgrade the package shipping with ubuntu to onboard with the word prediction? | 16:21 |
| === zyga is now known as zyga-afk | ||
| === dendrobates is now known as dendro-afk | ||
| === dendro-afk is now known as dendrobates | ||
| === cpg|away is now known as cpg | ||
| infinity | @pilot in | 17:40 |
| === udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity | ||
| * micahg just discovered pull-lp-source can use a mirror | 17:46 | |
| dobey | infinity: hi! :) i can bug you to accept stuff into precise-proposed right? :) | 17:48 |
| infinity | dobey: I'm doing some of that today, yes. | 17:48 |
| dobey | infinity: great. i think seb would be very happy if ubuntu-sso-client could move forward :) | 17:49 |
| infinity | dobey: Yes, we talked about it last night. :P | 17:50 |
| dobey | ah ok | 17:50 |
| === rsalveti` is now known as rsalveti | ||
| OdyX | pitti: pyppd got released as 1.0.0 and I'm preparing the upload to experimental. There is an upstream license change from GPL-3 to Expat and I'm relicensing my debian/* contributions. Are you okay to have yours relicensed too ? | 17:54 |
| tumbleweed | micahg: that was an important feature for me | 17:55 |
| alazare619 | whats the official method of building an iso of a ubuntu spin | 18:11 |
| alazare619 | i know livecd-rootfs is for the chroot whats the actual iso method | 18:11 |
| ScottK | Uses debian-cd | 18:12 |
| alazare619 | like i have the squashfs and everything built | 18:17 |
| alazare619 | whats the bootloader ubuntu uses for its live cds? | 18:18 |
| alazare619 | syslinux? | 18:18 |
| === zyga-afk is now known as zyga | ||
| jdstrand | infinity: hey, so I am getting this lintian error these days: 'E: ufw: postrm-does-not-call-updaterc.d-for-init.d-script etc/init.d/ufw' | 18:58 |
| jdstrand | infinity: hmm, you are probably not the right person-- I read the changelog thinking you added this stuff, but you just merged | 18:59 |
| * jdstrand continues to look | 18:59 | |
| infinity | jdstrand: Which changelog? debhelper or lintian? | 18:59 |
| jdstrand | infinity: debhelper | 18:59 |
| infinity | jdstrand: Is it installing a real init script, not a symlink to upstart-job? | 19:00 |
| jdstrand | I ship an upstart job (ufw.upstart), and do this: dh_installinit --no-start --no-restart-on-upgrade | 19:01 |
| jdstrand | hmm, looks like precise had the same issue, and I didn't notice | 19:02 |
| jdstrand | oh, no it didn't | 19:02 |
| infinity | On precise, I have an upstart-job link. | 19:02 |
| infinity | And since I don't have your quantal package, I'm not sure what it's doing... | 19:04 |
| infinity | jdstrand: Throw me the deb? | 19:04 |
| infinity | Or will rebuilding the precise source on quantal have the same effect? | 19:04 |
| * infinity tries. | 19:04 | |
| jdstrand | ok, the quantal package is setting up a symlink | 19:05 |
| jdstrand | ufw -> /lib/init/upstart-job | 19:05 |
| infinity | Which is correct. | 19:05 |
| jdstrand | yeah | 19:05 |
| jdstrand | hmm | 19:05 |
| infinity | And what precise did too. | 19:05 |
| infinity | So, it could just be quantal's lintian being grumpy? | 19:05 |
| * infinity is using precise's lintian still, and sees no issues. | 19:06 | |
| jdstrand | huh | 19:06 |
| jdstrand | debhelper in quantal adds this to postinst: http://paste.ubuntu.com/1078515/ | 19:07 |
| infinity | Damn your testsuite. I assumed this package would build in seconds. | 19:07 |
| vadrao | Hi all, I am using Kubuntu 12.04 and trying to compile some systemc with Modelsim. I am getting several errors like "/usr/include/features.h:357:25: error: sys/cdefs.h: No such file or directory". That is, /usr/include/features.h references /usr/include/sys/cdefs.h which doesn't exist on my system, which is quite baffling since dpkg lists libc6-dev package as installed and I think that package should contain these header files...After running | 19:08 |
| vadrao | find, I found that those files now reside in /usr/include/i386-linux-gnu/ instead of previously /usr/include/ .. What prompted this and how can I solve my compiling errors now ? http://pastebin.com/EmSy5cLV | 19:08 |
| jdstrand | infinity: DEB_BUILD_OPTIONS=nocheck is your friend :) | 19:08 |
| infinity | jdstrand: Yeah, yeah. I didn't expect a suite of doom. ;) | 19:08 |
| jdstrand | yes-- it takes a while | 19:09 |
| jdstrand | the fun thing is I will now run it twice (for py2 and py3 :) | 19:09 |
| infinity | vadrao: I assume this is using a compiler we don't ship? | 19:09 |
| infinity | vadrao: Cause ours all look in those paths by default. | 19:09 |
| infinity | vadrao: If it's a non-Ubuntu compiler, you may just want to add -I/usr/include/i386-linux-gnu to your command line, or similar. | 19:10 |
| vadrao | infinity: Yeah you are right, I am using Modelsim's builtin gcc compiler for this. | 19:10 |
| jdstrand | right, so in quantal there is that extra bit of code, but it seems update-rc.d won't be triggered, cause I have /etc/init/ufw.conf | 19:10 |
| jdstrand | I think this is a lintian issue | 19:10 |
| infinity | vadrao: Yeah, we don't tend to support other people's compilers, but there's your answer, if you can't rebuild it to DTRT, just add the -I bits. | 19:11 |
| infinity | jdstrand: That bit of code seems questionably odd anyway, but you can ask vorlon about it sometime, he's been the one slowly integrating upstart support into upstream debhelper. | 19:11 |
| rtg | infinity, I'm having an interesting dpkg issue (I think). When cross compiling for armhf in an amd64 Quantal chroot, dpkg-buildpackage complains about 'Unmet build dependencies'. Non-cross-compiles are fine. | 19:12 |
| rtg | echo "dpkg-buildpackage -b -aarmhf -us -uc 2>&1 |tee log.txt"|schroot -c quantal-amd64 | 19:12 |
| infinity | jdstrand: That said, if postinst has that code, and postrm doesn't have "undo" code, lintian's probably not wrong. | 19:12 |
| infinity | jdstrand: (But it doesn't really affect us) | 19:12 |
| jdstrand | right. it isn't wrong, but I don't really need to fix it by adding other code that does effectively nothing :) | 19:12 |
| vadrao | infinity: OK thanks. How would the command look like in that case? an example. I am a novice :) | 19:12 |
| infinity | rtg: Entertaining, given that the last dpkg was meant to make cross-compiling easier. :/ | 19:13 |
| rtg | which is why I suspected dpkg | 19:13 |
| infinity | rtg: Your suspicion isn't wrong. :P | 19:13 |
| rtg | infinity, known bug then ? | 19:13 |
| infinity | rtg: Only because I skimmed #ubuntu-kernel backscroll when I woke up. :P | 19:14 |
| rtg | infinity, I'll try to regress the version and see if the problem goes away. | 19:15 |
| infinity | rtg: It will. | 19:15 |
| infinity | rtg: The question is if this is a dpkg bug, or if dpkg adhering more strictly to multi-arch spec just means we need to add a bunch of multi-arch headers to the packages it's whining about for you. | 19:16 |
| jdstrand | infinity: thanks or your help | 19:16 |
| rtg | infinity, ok. in the meantime those chroots are worthless for cross compiling so I think I'll install an older version until this gets sorted. | 19:17 |
| infinity | rtg: For now, though, downgrading to pre-yesterday versions of dpkg/dpkg-dev/libdpkg-perl and putting them on hold in your chroots (for i in $packages; do echo "$i hold" | dpkg --set-selections; done) will keep you happy while we sort it. | 19:17 |
| rtg | infinity, just so you know, downgrading to dpkg 1.16.4.3ubuntu1 did the trick. | 19:34 |
| infinity | rtg: Check. Was pretty sure it would. | 19:39 |
| Debolaz | Out of curiosity, does anyone in here use pidgin on vanilla ubuntu? And if so, do you have a really hard time noticing if anyone has written anything to you? The notification applet isn't designed to actively draw your attention, and pidgin doesn't seem to work well with the launcher wrt making noise when you have messages waiting. | 19:47 |
| Debolaz | If I'm not missing something obvious here, I'd like to have a look at improving the situation. | 19:47 |
| dobey | Debolaz: i think you can disable the plug-in in pidgin which integrates with the messaging menu. or you can just uninstall that bit. for me pidgin opens a new tab/conversation window when someone IMs me | 19:49 |
| Debolaz | dobey: But unless I check the window, I won't notice the new tab is there. That's the problem. | 19:49 |
| Debolaz | dobey: I currently have rewritten the messaging menu to blink to draw my attention, but I think the ideal way would be to have pidgin get a count on its icon when there are unread messages. | 19:50 |
| dobey | i guess you'd need to fix the plug-in to set a count on the launcher if it's not doing so already then | 19:50 |
| Debolaz | I'm also thinking about fixing the #1 annoyance I have with empathy and use that instead; That its "click and drag" feature on the contact list is a really, really, really bad idea under VirtualBox where the mouse will behave as if you click and drag from the side if you click into the window, causing contacts to either move, or worse, get deleted. | 19:53 |
| Debolaz | Arguably it might be something VirtualBox should fix, but empathy is the only application that explodes because of it. | 19:54 |
| * Debolaz should legally change his name to "Mr Edge Case" | 19:55 | |
| alazare619 | i know livecd-rootfs is for the chroot whats the actual iso method is there a script ubuntu uses to pull the bootloader for hte iso and creates the iso? | 20:04 |
| === dendrobates is now known as dendro-afk | ||
| === dendro-afk is now known as dendrobates | ||
| slangasek | infinity: hey, so what was the "everything" that broke with :native? | 20:21 |
| slangasek | seb128: SRU queue> hard for me to do much about that today unfortunately, sitting in an airport :/ | 20:21 |
| slangasek | Daviey: /run/media not sure about agreement, but I have intent to ensure it's reverted ;P | 20:23 |
| alazare619 | infinity, you here again? | 20:26 |
| slangasek | infinity: debhelper upstart support in Debian is finalized; we aren't ready to sync it into Ubuntu though because we've been using a different approach on /etc/init.d compat stuff than what was settled in Debian | 20:27 |
| slangasek | infinity: but you did the last merge of debhelper, no? | 20:28 |
| infinity | slangasek: I did the last merge, yeah. | 20:33 |
| infinity | slangasek: It doesn't seem to break anything (debhelper, that is), it just gives jdstrand scary lintian warnings. | 20:33 |
| slangasek | so whatever's broken for jdstrand is your doing, right? ;) | 20:33 |
| infinity | slangasek: As for dpkg, the breakage was that he declared the implicit build-essential build-dep as build-essential:native, while our build-essential is MA:foreign, a combination which the spec (and the implementation, which seems to match the spec) forbids. | 20:34 |
| * jdstrand just override it for now, fwiw :) | 20:34 | |
| slangasek | infinity: ok - yeah, found the pastebin in scrollback, that's entirely expected and is all about reducing the delta with Debian | 20:34 |
| infinity | slangasek: After sleeping on it, I think it's probably just that the implicit build-dep was wrong, so my quick workaround was perhaps the right fix. | 20:34 |
| infinity | slangasek: But I mean to bring this up with you a bit more in person. | 20:35 |
| slangasek | hmm, why is our b-e M-A: foreign? | 20:35 |
| slangasek | right-o | 20:35 |
| slangasek | we can discuss more effectively tomorrow :) | 20:35 |
| infinity | slangasek: The latest dpkg build-dep changes also broke the kernel team's cross-building chroots, but I'm unsure if that's a dpkg bug/misfeature, a breakage in the spec, or just that a bunch of stuff they build-dep on needs MA headers. | 20:36 |
| infinity | slangasek: I suspect perhaps the latter, combined with the implementation of the former being a somewhat draconian cutover. For now, they've just rolled their chroots back, and we can look at the hows and whys, again, in person. | 20:37 |
| infinity | slangasek: Well, s/tomorrow/Sunday/, unless you want to talk multiarch at midnight. I get in fairly late. | 20:38 |
| slangasek | that's the BEST TIME to talk multiarch | 20:38 |
| slangasek | c'mon | 20:38 |
| mu3en | maybe wrong channel, but is there some way to force grubpc install instead of grubefi install during server install? | 20:40 |
| infinity | slangasek: if there's beer, I agree. | 20:42 |
| infinity | slangasek: I'm still fuzzy, no matter how many times I read it, on the distinction between foreign and allowed, you may need to get me 3 gins deeps before you try to walk me slowly through it, especially as it affects build-deps, rather than normal deps. | 20:43 |
| slangasek | infinity: allowed is "foreign if the revdep asks nicely" | 20:43 |
| infinity | slangasek: And foreign is "allowed, if the native doesn't exist", from what I see in the spec. | 20:44 |
| infinity | slangasek: The binary dep definitions make a bit more sense to me than how they're mapped for source deps. | 20:44 |
| infinity | slangasek: But, yeah. Booze. Tomorrow. | 20:44 |
| slangasek | eep, seems like a gratuitous overloading of 'allowed' :) | 20:44 |
| slangasek | the build-dep side of things was done much more organically | 20:45 |
| === fenris_ is now known as Guest70358 | ||
| cjwatson | mu3en: boot the installer using BIOS rather than UEFI and you'll get grub-pc | 20:56 |
| mu3en | thanks cjwatson, i'll check my server settings. | 20:57 |
| === cpg is now known as cpg|away | ||
| === cpg|away is now known as cpg | ||
| === salem_ is now known as _salem | ||
| alazare619 | ok can someone point me to a guide from start to finish how ubuntu builds there iso's | 22:22 |
| alazare619 | i know livecd-rootfs is part of the mix for the chroot but what is after that etc | 22:22 |
| micahg | !regression-alert | 22:28 |
| 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 | 22:28 |
| micahg | Bug #1021946 | 22:28 |
| ubottu | Launchpad bug 1021946 in lo-menubar (Ubuntu Precise) "lo-menubar 0.1.1 from proposed repositories makes plasma-desktop to crash" [Undecided,New] https://launchpad.net/bugs/1021946 | 22:28 |
| micahg | not worth an incident report most likely, but it is a regression nonetheless | 22:29 |
| ScottK | micahg: Is it in proposed or updates? | 22:29 |
| micahg | -updates now | 22:29 |
| ScottK | Sigh. | 22:29 |
| Sargun_Screen | Is there any way to test out newer packages on a specific installer | 22:29 |
| ScottK | micahg: Can you upload something that reverts that change? | 22:31 |
| micahg | ScottK: hrm, the other one looked pretty severe in itself | 22:31 |
| micahg | 86 duplpicates | 22:32 |
| ScottK | micahg: -updates is zero regressions though. | 22:32 |
| ScottK | We don't get to screw a new bunch of people to unscrew others. | 22:32 |
| ScottK | That or find Sweetshark. | 22:34 |
| * micahg looks around for a desktopper | 22:34 | |
| ajmitch | ScottK: what about when it's a kernel update? | 22:34 |
| ScottK | As a practical matter it's unavoidable sometimes . | 22:34 |
| infinity | That was a pretty hefty SRU for a single bug... | 22:37 |
| Sargun_Screen | SRU? | 22:37 |
| infinity | Stable Release Update. | 22:39 |
| infinity | micahg: There's a comment that removing it and reinstalling it magically makes it happy. Which sounds a bit sketchy. | 22:39 |
| micahg | infinity: I saw that too | 22:44 |
| micahg | that's why I'd prefer someone who knows it to take a look before we start reverting | 22:44 |
| infinity | Bleh. Not sure why Steve released it. The comments on the original bug didn't look promising either. :/ | 22:44 |
| micahg | right | 22:45 |
| infinity | micahg: I'd be tempted to just push a revert through, but I dunno if, perhaps, the new breakage has to do with the new libreoffice and not lo-menubar. | 22:46 |
| micahg | infinity: right, lots of moving parts :) | 22:46 |
| infinity | Definitely could use someone who actually opens LibreOffice more than one a year. | 22:46 |
| ScottK | Since there's no one around to deal with it, I guess I'll remove it so it at least doesn't pile up more problems over the weekend. | 22:57 |
| infinity | ScottK: We're seeing about getting Ken involved. | 22:59 |
| infinity | ScottK: But yeah, removing it won't hurt particularly (you're loving this new power, aren't you?) | 22:59 |
| ScottK | Except I'm not. | 23:00 |
| ScottK | KeyError: 'precise' | 23:00 |
| infinity | It's the second time this week I've noticed you mentioning doing removals. :) | 23:00 |
| infinity | precise-proposed? | 23:00 |
| ScottK | Let me try that. | 23:00 |
| ScottK | Nope | 23:00 |
| infinity | Err, updates. | 23:00 |
| micahg | ken will take a look later this evening | 23:00 |
| infinity | ScottK: remove-package -n -m 'Busticated' -s precise-updates lo-menubar | 23:01 |
| infinity | ScottK: Seems to DTRT here. | 23:01 |
| infinity | ScottK: Might want a more verbose comment. :P | 23:01 |
| micahg | umm, ken didn't seem to be for removal either due to the crazy crasher | 23:02 |
| infinity | So, his opinion is that the current state is less broken than the previous? | 23:02 |
| infinity | Or, at least, similarly bad? | 23:02 |
| ScottK | Cockpit error. | 23:02 |
| micahg | yes, at least on the surface | 23:02 |
| infinity | Alright. | 23:03 |
| infinity | ScottK: Stay the execution? :P | 23:03 |
| ScottK | Slightly too late. | 23:03 |
| infinity | Or not. | 23:03 |
| ScottK | Actually I hadn't confirmed yet | 23:03 |
| ScottK | Just in tiem. | 23:03 |
| ScottK | time even | 23:03 |
| infinity | Mmkay. | 23:03 |
| infinity | I'm going to go back to my THRILLING laundry and packing. | 23:03 |
| ScottK | micahg: I'm leaving it with you then. | 23:03 |
| infinity | And trust that Ken will make this slightly less poop. | 23:03 |
| micahg | ScottK: I go offline in a couple of hours, better off with you or infinity | 23:04 |
| micahg | or jasoncwarner_ | 23:04 |
| infinity | micahg: I leave the country tonight. | 23:04 |
| ScottK | That's probably after both of us. | 23:04 |
| ScottK | I'm leaving for western Virginia, so it's probably even worse. | 23:04 |
| infinity | Hah. | 23:04 |
| micahg | awesome, the three who are usually around will be no where to be found :) | 23:05 |
| infinity | I'll be around for a bit, though, I'll try to liaise with Ken before I go, and make sure there's some trail of responsibility. | 23:05 |
| infinity | I don't think this is sever enough to warrant anything heavyweight and reporty, but it would be nice to make sure it doesn't get forgotten. | 23:05 |
| ScottK | micahg: I think an incident report is, in fact needed. | 23:05 |
| infinity | Or, we could report just so people don't forget. :P | 23:06 |
| infinity | s/sever/severe/ | 23:06 |
| ScottK | New rule "LO SRUs accepted only on Monday" | 23:06 |
| infinity | It was Tuesday... | 23:06 |
| infinity | Close enough. | 23:06 |
| micahg | jasoncwarner_: will you be around for a while? could you take charge of this? | 23:08 |
| jasoncwarner_ | micahg: it is my saturday. I'll be around for a bit (maybe an hour). Though I'm completely lacking context here. You said it was a regression in -updates. is this something we can just revert? | 23:09 |
| infinity | jasoncwarner_: The claim is that reverting it will just be trading one bad bug for another. | 23:10 |
| micahg | jasoncwarner_: well, the upload fixed Bug #754562 supposedly | 23:10 |
| ubottu | Launchpad bug 754562 in LibreOffice Menubar Extension "soffice.bin crashed with SIGSEGV in g_hash_table_lookup() (Libreoffice with lo-menubar crash from page preview)" [Undecided,In progress] https://launchpad.net/bugs/754562 | 23:10 |
| infinity | jasoncwarner_: Which may lower the overall urgency of the thing (going from broken to broken), but still worth seeing through. | 23:10 |
| ScottK | Although I claim me reverting it is probably going to motivate the people saying that to maybe do something useful. | 23:11 |
| ScottK | jasoncwarner_: I can remove it if you want, I"ll be around off and on for a bit. | 23:11 |
| Laney | I think you shouldn't get to introduce regressions in updates without a lot of thought. | 23:11 |
| infinity | ScottK: Possibly, but I suspect we have other ways to motivate. :P | 23:11 |
| Laney | I would remove it from updates. It can always be put back. | 23:11 |
| ScottK | Laney: ++ | 23:12 |
| micahg | maybe copy back to -proposed? | 23:12 |
| infinity | That, I can do. | 23:12 |
| ScottK | infinity: Is anyone actually commiting to do anything before Monday? | 23:12 |
| Laney | yes, put it back there. Get it some more verification. | 23:12 |
| jasoncwarner_ | +1 what laney said and I like micahg suggestion to put it back in -proposed to get more eyes on it... | 23:12 |
| infinity | Let me bounce it back to proposed, I'll let others sort out what to do with the one in updates. | 23:13 |
| ScottK | infinity: I know what to do with that one. Let me know when you're done. | 23:13 |
| micahg | hrm, it might just be lo 3.5.4 that's broke | 23:14 |
| Laney | Put the gun down. | 23:14 |
| infinity | ScottK: Copied, will take a publisher run. | 23:14 |
| infinity | micahg: This wouldn't be a shock. | 23:15 |
| infinity | micahg: Are you testing new lo-menubar against the lo from release and it's okay? | 23:15 |
| micahg | well, if it is lo and not lo-menubar, it's only regression-proposed | 23:15 |
| ScottK | So it can stay in -proposed until it's sorted. | 23:15 |
| micahg | but from what it sounds like, the update didn't fix the original bug as intended (just made the crashes stop, but broke the addon) | 23:16 |
| infinity | Indeed. | 23:16 |
| infinity | It's a broken SRU, no matter how you slice it, from the bug comments. | 23:16 |
| infinity | Even if the new and fancy crash is lo's fault. | 23:16 |
| Laney | Yet it managed to get to updates. Sounds incident-reporty. | 23:17 |
| infinity | Laney: Sounds like you just volunteered. | 23:18 |
| ScottK | \o/ | 23:19 |
| Laney | I conveniently have to leave now :-) | 23:23 |
| Laney | Will look into it tomorrow. | 23:23 |
| micahg | yeah, lo-menubar not working is better than hanging the DE | 23:24 |
| micahg | so, removal from updates seems warranted' | 23:24 |
| infinity | Right, well, I'll bounce it from updates once I've seen it published back to -proposed, and update the SRU bug. | 23:26 |
| infinity | micahg: Want to take care of the new bug? | 23:26 |
| micahg | infinity: take care ok? | 23:28 |
| micahg | *of | 23:28 |
| infinity | micahg: Mention what we plan to do, mark it with whatever shiny tags are appropriate, what have you. | 23:29 |
| infinity | micahg: Or just take it out back and shoot it. However you prefer to interpret "take care of". | 23:29 |
| micahg | sure, let me go mark everything up | 23:29 |
| micahg | and to top it off, there's no SRU master bug :( | 23:30 |
| infinity | Should there be? | 23:34 |
| infinity | I honestly find the concept rather pointless, except in the case of massive SRUs (like the kernel). | 23:34 |
| infinity | An SRU to fix one or two bugs hardly needs another one just to track that. | 23:34 |
| micahg | yes, because you can mark the master bug as failed if there are new issues and the other bugs are actually fixed | 23:35 |
| ScottK | We use a master SRU bug for KDE updates. | 23:35 |
| infinity | micahg: In this case, the "master" bug was the "one bug it was meant to fix". Even if it did fix that bug, it hardly fixed it well if it broke in another way. | 23:35 |
| micahg | infinity: I mean it when you SRU a new version, not just a single fix | 23:36 |
| infinity | What does annoy me, though, is the lack of bug dependencies. | 23:36 |
| micahg | infinity: that's in progress apparently | 23:36 |
| infinity | So, you could make the old SRU bug now depend on the new bug. | 23:36 |
| micahg | still, if you're pushing a new version, you need a bug to track issues related to that new version and unrelated to bugs fixed in the new version | 23:37 |
| infinity | micahg: Perhaps, yes. Depending on how one defines "new version". In this case, I'd be inclined to agree, since it was a big set of changes. | 23:37 |
| micahg | infinity: I'd include it for anything that does have a bug -> fix link in the changelog | 23:38 |
| micahg | s/does/doesn;t/ | 23:38 |
| infinity | (Sometimes, a new version really just fixes the 3 bugs that you already targetted in the changelog, and a master bug seems silly). | 23:38 |
| micahg | infinity: right, in which case, one of the fixes broke somethin | 23:38 |
| * infinity nods. | 23:38 | |
| infinity | Well, this fix might have broken something too. ;) | 23:38 |
| infinity | I routinely introduce segfaults by fixing segfaults. | 23:39 |
| infinity | Chase the pointer! | 23:39 |
| infinity | Whee! | 23:39 |
| infinity | (I don't routinely release such fixes, mind you, I tend to keep my stupidity and shame confined to my laptop most of the time) | 23:39 |
| micahg | right, well, it's true, but not readily apparent | 23:39 |
| micahg | bugs updated FWIW | 23:44 |
| micahg | anything else needed from me? | 23:45 |
| infinity | Nope. I've just bounced it out of -updates. | 23:46 |
| infinity | Back to my wonderful world of laundry, packing, kernel SRUs, and.. Whatever else I can squeeze in before my flight. | 23:46 |
| * micahg steps away | 23:48 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!