[00:00] ceti331: it was an issue with compiz right? have you tried #compiz? [00:01] hah [00:01] its an issue with building ubuntu's fork of compiz [00:01] they didn't know and advised i came here [00:01] oh boy [00:02] "i dont know, i've never used their bzr stuff..." [00:02] the expo plugin isn't specific to ubuntu though [00:03] ceti331: join #ubuntu-desktop, ask smspillaz, he might know [00:03] before getting it compiling, we found that the git version from compiz was incompatable with the ubuntu-build framework [00:03] i.e. i can't compile compiz.org's expo source here in ubuntu , but i can from launchpad :) [00:03] ah ok [00:03] thanks [00:04] I'm not sure I follow, are you trying to build the compiz package? [00:05] 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] i'm just trying to build "expo" === cpg|away is now known as cpg [00:57] is someone from the MIR team still around? [01:26] I have a corrupt link. How can i fix? [01:26] I can't delete it === cpg is now known as cpg|away [02:10] infinity, I think they're all built now [03:20] robert_ancell: Alrighty. === cpg|away is now known as cpg [03:42] Good morning [03:43] can someone explain the ubuntu seed files to me [03:43] im trying to figure out how to build one [03:45] alazare619: https://wiki.ubuntu.com/SeedManagement documents how they work === salem_ is now known as _salem === cpg is now known as cpg|away [05:24] BenC: llvm-2.8 should just be removed from quantal as it was from Debian [05:26] micahg: Oh, yeah, I meant to do that. [05:26] micahg: 2.9 as well, but llvm-py hasn't been ported to 3.x yet, AFAIK. [05:27] livecd-rootfs tools is not correct [05:27] alazare619: I disagree. [05:28] infinity: at least llvm-2.9 isn't on the FTBFS list [05:28] micahg: It's not? It sure used to be. [05:28] the auto build script is missing a setup for --syslinux-theme "$project"-"$suite" \ needs to be added [05:28] otherwise it always uses onerics theme for syslinux [05:28] Silly people fixing LLVM. [05:28] micahg: Alright, I'll just yank 2.8 and leave 2.9 alone for now. [05:28] infinity: silly me syncing the fix :) [05:29] alazare619: We don't create ISOs with livecd-rootfs. (so, for us, it's correct). [05:30] you guys create seed files for the livecd-rootfs system with live-build [05:30] 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] alazare619: Erm. We do what now? [05:31] ok do explain how you build iso's then [05:31] cause the seed files on ubuntu's wiki point to live build seed files [05:33] 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:34] alazare619: But that all just spits out a squashfs on the other end. Not an ISO. [05:34] i understand that [05:35] so the livecd-rootfs script has an error [05:35] does ubuntu devel not handle that? [05:35] 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] The auto/* scripts in livecd-rootfs are specifically for how Ubuntu builds CDs. [05:35] yes [05:36] If you need something different locally, please do fork from there and tweak. [05:36] and thats where there should be a changed line tho [05:36] But a bug for you isn't (necessarily) a bug for us. [05:37] line 276 should be --syslinux-theme "$PROJECT"="$SUITE" [05:37] of config in livecd-rootfs [05:37] livecd-rootfs/auto/config [05:38] = = - [05:38] = is - in the line 276 i mean [05:38] alazare619: For you, yes. [05:38] without that being set it defaults the build to ubuntu oneric theme is what im saying [05:38] why for me what am i doing diffrent then "ubuntu" [05:39] 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] well yes i do [05:39] 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] well yes and no [05:40] 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] who and what actually manages the iso building then [05:40] So your bugs aren't our bugs. [05:40] 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:41] wich i thought was true according to ubuntu wiki live build is used to build the iso too [05:41] Where on the wiki does it say that? [05:41] It's a lie if it does. ;) [05:42] 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] 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:45] im willing to help fork live-build so it produces it properly [05:48] but what exactly does live-build do wrong that it shouldnt? [05:49] Good question. It's on my TODO to look into it at some point. [05:49] 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] We'll fix that at some point. [06:09] 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] it does differ from the Ubuntu images indeed, though (most notably it does not have a pool) [06:12] yea only tweak ive done so far was add that line to the livecd-rootfs auto script [06:13] and changed config/chroot-local_hooks to config/hooks [06:13] as the new livebuild removed the chroot-local_ from it [06:15] pitti: Is it? nusakan doesn't touch it, except to publish it? [06:15] no, it's built from nusakan [06:16] well, "triggered by"; I guess it's actually built on the buildd machines, just like the regular livefses [06:16] pitti: Okay, so yeah. Like I said, "nusakan only touches it to publish it?" [06:16] pitti: If so, handy datapoint to know. [06:16] right [06:17] pitti: So, maybe this man wants to talk to you about ubuntu-defaults-image. :P [06:17] alazare619: if you only want to install some additional packages or do some tweaks, ubuntu-defaults-image is indeed much easier to use [06:18] nah [06:18] i want the full blown process [06:18] it won't help you much for really invasive modifications, though [06:18] im actually a sys admin lol [06:18] its a pet project i have going in down time at work [06:18] u-d-i more or less configures live-build to produce an Ubuntu-ish image [06:18] trying to build a distro with qt-razor by default and gnome-shell [06:19] ive done live-build with debian base of squeeze and wheezy and sid never ubuntu tho [06:23] 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:24] no real reason other then to say i did it === tkamppeter_ is now known as tkamppeter === cpg|away is now known as cpg [07:24] good morning [08:13] cjwatson, slangasek, xnox, stgraber: is anyone looking at the ubiquity issue which is breaking the quantal dailies for 2 days? [08:13] seb128: yes. i have been. [08:14] xnox, how is that going? likely to be fixed today? [08:14] i got the 900MB big strace, which clearly shows SIGPIPE in apt. [08:15] seb128: either a fix, a workaround, or a downgrade should happen soon. [08:16] xnox, right, so I guess one of the updates of 06-29 broke it? [08:16] seb128: well. apt & python-apt were updated =) [08:16] xnox, right, and ubiquity [08:16] yeah. [08:16] seb128, is there a bug number? [08:17] (of course there is) [08:17] brendand, bug #1020574 [08:17] Launchpad bug 1020574 in ubiquity (Ubuntu) "SystemError: Broken pipe while installing language packs" [Critical,Confirmed] https://launchpad.net/bugs/1020574 [08:17] hallyn, MIR already raise for xz-java [08:18] and now it has full strace attached as well. [08:19] 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] 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:27] 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:33] 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] dpm: Ah, no. Reading context makes that clear. [08:33] ok, cool [08:34] RAOF: dpm: update_file_content take a start/end stenza [08:34] which are the second and third arg [08:34] and replaces this with the 4th :) [08:34] didrocks: Yeah, now that I've read the source that makes sense. Without reading the source the patch looks weird. [08:35] RAOF: I wrote it for updating the copyright in every files, hence the start/end need. Interesting mterry used it for that :) [08:36] dpm: Doneinated. [08:38] RAOF, \o/ thanks! [08:38] SpamapS: Have you deliberately left a bunch of syncs from -proposed to -updates in the precise queue? === cpg is now known as cpg|away [08:53] slangasek: There, new dpkg now prints errors to stderr, My PickyPants. :P [09:12] infinity: 8) [09:21] * dholbach hugs seb128 [09:22] * seb128 hugs dholbach [09:22] :) [09:23] 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] yeah, I can imagine [09:25] seb128: Does that mean you cleared out the queue, so I don't have to pilot when I wake up? [09:25] seb128: Splendid. [09:25] * infinity will sleep better now. [09:26] infinity, lol, not quite [09:26] infinity, but if somebody wants to clear the SRU queue a bit, we are getting close of 40 items unapproved [09:26] slangasek, ^ [09:27] 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:28] seb128: I'll do a bit of cleaning up tomorrow. [09:28] thanks [09:28] seb128: slangasek is already at DebConf, so I suspect he'll be less inclined to SRUify. [09:28] right [09:29] * 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] the 4th of July and Canadian day didn't help this week either ;-) [09:29] seb128: Nope. Clearly not. Silly fireworks. [09:29] infinity, can I cheat and wave my SRUs through? ;-) [09:29] is that what you did? ;-) [09:29] seb128: I didn't cheat, I had RAOF review mine. :) [09:29] lol [09:29] On the other hand, it was a reeeeealy easy review. [09:30] 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:31] seb128: Any specific urgencies, or just "everything"? [09:32] 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] RAOF, noted, thanks [09:33] 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] seb128: Check. I thought that was on Steve's hitlist when he filled in for me on Monday? Maybe not. [09:34] seb128: Anyhow, I'll start there, and then just get FIFOish until I get bored. [09:34] thanks [09:34] 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] I can do some extra sponsoring in exchange [09:34] infinity: Hey, you are in the MIR team, right? [09:35] Daviey: I am now/again, yes. Talk to me about it in ~6.5h I'm going to sleep. Honest. [09:35] awesome [09:35] infinity, sleep tight [09:35] infinity: ok, sleep tight. [09:35] Daviey: Better yet, talk to mterry, cause he's +1 this month, and MIR and +1 kinda go hand-in-hand. ;) [09:36] infinity: I try to spread the world of pain we induce. [09:36] You could introduce less pain instead. [09:36] Just a thought. [09:36] Nah, no fun tere. [09:36] Says you. [09:37] infinity: sure you don't want to take a real simple package? it's a single py file. :) [09:37] Bug me in the morning. [09:37] ok, thanks. [09:37] didrocks: Hey, how are you doing? :) [09:37] Only C and POSIX shell are simple at this time of night. [09:37] Everything else is voodoo. [09:37] hey Daviey, I'm fine, thanks! [09:37] and yourself? [09:37] * xnox wonders if single.py file is like bzip2 base64 encoded binary blob ~3MB in size, similar to waf [09:38] didrocks: Pretty good.. As you are around and all.. fancy taking a seemingly simple MIR request? [09:38] [09:38] Daviey: if it's simple, I'm all for it. I still have on my backlog some long, complicated, and interdependant ones :) [09:39] but don't lie, it has to be simple now! :) [09:39] didrocks: bug 1021528 .. it really is just a 45 line python script packaged. [09:39] Launchpad bug 1021528 in python-setuptools-git (Ubuntu) "[MIR] python-setuptools-git" [Critical,New] https://launchpad.net/bugs/1021528 [09:39] Daviey: sounds easy enough, looking now :) [09:39] much appreciated.. (it will be blocking openstack milestone uploads later today) [09:40] Daviey: will be quickly done [09:40] Daviey: I'm surprised, isn't openstack on launchpad? [09:40] they are using git now? [09:41] is setuptools-git even used in the Debian build process? [09:41] didrocks: It's complicated.. github for code hosting, self hosted gerrit for code review, launchpad for bugs and bluepritns. [09:41] surely it's something that's trivially patched out? [09:41] Daviey: wow, quite an interesting setup! [09:42] 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] (I like the except: comment btw :p) [09:42] Daviey: but when you are building from a orig tarball there's no git repository for it to use [09:43] so it adds no value [09:45] 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] tumbleweed: Stop raising seemingly valid points. [09:46] Daviey: I'm interested and about to raise the same question btw :p [09:46] I tend to think it's not worth patching out trivial bits of build system to avoid having them in main [09:46] Unless it's going to pull in some giant stack of stuff [09:47] basically their build system is not shipping the MANIFEST file, right? [09:47] 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] 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] so you often end up having to patch MANIFEST.in [09:47] tumbleweed: It depends whether it's going to fail hard, or just fall back to looking at the tarball [09:47] Daviey: speaking of no deps, it should dep on git I guess :) [09:47] cjwatson: yeah [09:47] 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] actually MANIFEST.in is for sdist, but one does have to frequently touch package_data in the setup.py [09:47] jamespage: surely you never add build-essential to depends...... [09:48] xnox, no - and the test build I did worked fine locally using sbuild [09:48] xnox, hence my 'either its broken or I'm being dumb' style question :-) [09:48] That would be the new dpkg. [09:48] didrocks: Hmmpf.. on the face of it, this might be just for generating the source package. [09:49] Which so shouldn't be doing that... [09:49] Daviey: I think it is. But as cjwatson said, if having teh package avoids patching, it's useful [09:50] tumbleweed: That is what i said initially :/ [09:50] infinity: well looks like fallout from .5 - but HOW?! http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558095 [09:50] Debian bug 558095 in dpkg-dev "dpkg: please accept ":native" multiarch qualifier in build dependencies" [Wishlist,Fixed] [09:51] xnox: Yeah, I knew exactly what change broke it when I saw it. [09:51] xnox: What I'm not sure about is how no one saw this. :/ [09:52] * infinity sighs as he goes about fixing. [09:52] 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] Sleep is for the weak anyway. [09:53] Daviey: are you saying that upstream will not accept a patch: "build from tarball, without git, if no git available"? [09:54] or conditionally import git integration when the command is sdist [09:54] xnox: I'm not saying anything :) [09:54] =))) [09:54] Daviey: I'm not volunteering for writing any patches either ;-) [09:56] bah [09:58] Daviey: added some comments, but looks overall good apart from some quick fixes needed [10:05] jamespage: Thanks for the heads-up. Rebootstrapping a fixed dpkg now. :/ [10:06] infinity, np [10:07] 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:11] infinity: Maybe it matters that our sbuild understands :any build-deps? [10:11] cjwatson: It's not sbuild failing, it's dpkg-checkbuilddeps. [10:11] mm, ok, I can't think of a plausible way sbuild could be involved there :) [10:12] And it doesn't fail for me in a Debian chroot, only Ubuntu. [10:12] So, all I can think is that Steve's workaround hack had some fallout interaction here. [10:12] 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] For now, I just need to make the chroots happy and get us building again. [10:18] cjwatson: Hahaha. [10:18] cjwatson: So, it could just be that the patch is busted. :P [10:19] cjwatson: Yup, confirmed. [10:19] 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:20] 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:21] * cjwatson tries to understand that and concludes coffee and breakfast would help. [10:21] Rather you than me :) [10:22] 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:27] mvo, ok [10:27] bug #1021298 [10:27] 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:29] mvo, can i have an ifconfig -a from the box which reports the error please [10:33] mvo, and the output of /usr/share/squid-deb-proxy-client/apt-avahi-discover [10:33] mvo, and avahi-browse -kprt _apt_proxy._tcp [10:39] mvo, belay all that, i've made a new network to test this on [10:42] mvo, i'll sort it out and get the branch updateds [10:46] didrocks: thanks [10:51] 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] cjwatson: http://paste.ubuntu.com/1077890/ [10:52] infinity: the multiarch spec explicitly says "so long as the [package build-depended on using :any] declares itself as Multi-Arch: allowed" [10:53] so I don't think it's correct to extend that in dpkg without spec work [10:53] 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:54] well, a bug in either dpkg-dev or the spec :) [10:54] cjwatson: Well, allowed foreign, host, and all. [10:54] cjwatson: But okay, I can scrap the "fixes" to any to revert behaviour. [10:54] ok, if it's restoring previous behaviour then fair enough for now [10:54] We didn't use it much anyway, and I think we only used it for allowed stuff. [10:54] (gettext was allowed, anyhow) [10:54] the :native change looks ok as long as $a is the architecture of the package and not the current architecture or something [10:55] $a is package, $host and $build are what you'd expect. [10:55] (And the day those don't seem semantically backwards to me is probably the day I get a lobotomy) [10:56] it's worse when you encounter packages that permute the semantics of build/host/target ... [10:56] (I'm looking at you, nspr. Or maybe nss. IIRC they permute them *differently*.) [10:56] At least "target" probably only has one sane meaning. [10:56] I'm pretty sure at least one of those makes it mean host. [10:57] And by host, you mean build? [10:57] Cause I'd argue that target should mean host. [10:58] I meant autotools host. [10:58] But I could be misremembering; this was a while back. [10:58] Aaaanyway. [10:58] I'll revert the :any bits, if that's getting us closer to spec. [10:58] Yes, I'm restoring previous behaviour, but no, I don't care to. [10:58] Check with Steve first. Since he wrote that spec and the original :any patch, he should know ... [10:59] I suspect you'll find that 99% of our :any build-deps are all gettext anyway. :P [10:59] I might just be missing some extension spec somewhere [11:00] https://wiki.ubuntu.com/MultiarchCross [11:01] So that also says :native on foreign is disallowed. Why? [11:01] That makes no sense. [11:01] So, the patch was implementing the spec, but I'd argue the spec is wrong. :P [11:02] I'll talk to Steve about it before I fix anything. [11:02] My current workaround has us over the panic anyway. [11:02] It's not *necessary* to use :native for M-A: foreign, but I can't see why it should be *disallowed*. [11:03] But yeah, Steve may remember some argument that led to this. [11:04] Very weird indeed. [11:04] 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:05] Sleep with fix everything. [11:07] I also note that table assumes some cleverness on the part of the resolver. [11:08] I wonder if the latest sbuild is actually that bright about selection. [11:17] apw: thanks a bunch! === MacSlow is now known as MacSlow|lunch [11:56] 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:57] ((2) being somewhat replaced by "bzr branch lp:ubuntu/name-of-package") [11:57] there's also pull-lp-source which doesn't use APT [11:58] (replacing 2) [11:58] apt-get build-dep requires deb-src entries, but one can use mk-build-deps instead [11:59] source packages significantly better mirrored and thus much faster to download than bzr branch lp:... [12:00] 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:01] ok [12:02] 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:04] xnox: which makes 1 a use case for that checkbox [12:04] tumbleweed: yeah I know =)))))) i somehow looped in my argumentation. [12:04] while true: [12:05] punish(self) [12:07] 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] 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:08] bdmurray: I understand that it would be under-reported. but still any numbers would help even to see at least any correlations. [12:22] jamespage: \o/ thanks [12:33] hallyn, TBH I did not really do anything other than look :-) [12:34] 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:35] I don't know. Aron said he'd taken care of Debian, but I didn't check for him. [12:35] and yes. See the bug I filed. There are only two packages. [12:35] OK. [12:36] since they are both hosed atm, it was easier to unblock the update by just keeping it for now [12:38] I accepted it. Please go back and clean up after they're fixed. [12:39] cheers === vibhav is now known as ILoveUbuntuOMG === ILoveUbuntuOMG is now known as vibhav [12:54] * BenC saw a notice on this window but can't find it === _salem is now known as salem_ [12:57] BenC: 06:24 BenC: llvm-2.8 should just be removed from quantal as it was from Debian [12:58] ... ah, the answer to "how did this ever possibly work" is "it didn't" [12:58] that makes more sense. [13:00] 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:01] apw: I thought it was agreed it would be reverted... seb128 & slangasek know more [13:03] bug #1020759 [13:03] Launchpad bug 1020759 in udisks2 (Ubuntu Quantal) "/run/media is an unnecessary divergence from the FHS" [Medium,Triaged] https://launchpad.net/bugs/1020759 [13:09] ahasenack, i'm aware of the issue, its covered under bug 974509 [13:09] Launchpad bug 974509 in cloud-init (Ubuntu) "cloud-init selects wrong mirror with dns server redirection" [Low,Confirmed] https://launchpad.net/bugs/974509 [13:10] 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:12] didrocks: ping [13:12] hey zul [13:13] didrocks: saw the bug and just did what you asked for in python-setuptools-git [13:13] zul: excellent! upload on the way? :) [13:13] didrocks: just did [13:13] 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:14] zul: ok, will wait for it to build, (looking at the diff meanwhile) then promoting to main [13:14] didrocks: cool thanks [13:14] zul: yw :) [13:14] seb128, a tricky one, the $user part seems reasonable for security, perhaps a compromise ln -s /run/media /media [13:26] zul: hum, is it me or you didn't do the most important change: depending on git? [13:26] didrocks: argh! [13:26] zul: I guess you just won some karma for a newer upload :p [13:26] didrocks: i did [13:27] cjwatson: thanks, I'll stop porting it then :) [13:27] I had actually fixed the second problem already [13:27] 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] zul: oh, the "I did" was for acknowleding the karma winning, gotcha :) [13:28] didrocks: gimme a sec ill add git to the depends [13:30] smoser: thanks for the bug number [13:30] didrocks: uploaded with git depends [13:30] ahasenack, the real solution, there is "use a real dns provider" [13:30] zul: excellent, thanks! [13:30] but, we will likely be changing that functionality soon. [13:31] smoser: chrome seems to do some pretty smart stuff [13:31] smoser: it tries to resolve some randomly generated names [13:31] smoser: if an ip comes back instead of a resolver error, it knows the isp is playing funky games [13:32] ahasenack, that is an interesting solution. [13:32] smoser: thinking out loud, we could try to resolve something like "shouldnotresolve.canonical.com" and get #is to never use that domain name :) === MacSlow|lunch is now known as MacSlow [13:35] mvo, ok have figured out why it occurs, now to figure out what to do about it :) [13:38] apw: so what is the 2min summary of what is happening? [13:39] 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] 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:40] 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:50] cjwatson, infinity: Is there a plan to sync the tiff source that produces libtiff5? Several packages are dep-wait on it [13:52] BenC: blocked on me resolving the MIR feedback on jbigkit [13:52] which is indeed on my list if I can ever clear off emergencies :) [13:54] What's more of an emergency than supporting the one-true-lossless-image-codec!?! :) [13:59] Is the plan still to get rid of the alternate installer in 12.10? [14:00] * BenC hopes not [14:00] that is the current plan, conditional on some ubiquity features being implemented [14:00] cjwatson: will there still be a net boot option of sorts? [14:00] yes, netboot certainly isn't going away [14:01] So is debian-installer still going to be around, it's just the alternate cd images? [14:01] (as in, even if Canonical weirdly decides to stop supporting it, I'm entirely prepared to do so all by myself :-P ) [14:01] …that are going away [14:01] right [14:01] even that's flavour-specific, so I guess a flavour might choose to keep them [14:01] Good good…count me in on the support-it-ourselves camp, if it ever comes to that [14:02] didrocks: hey did it get promoted yet? [14:02] 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] Debolaz: full-disk encryption is one of the ubiquity features that this is conditional on [14:03] Good to know. :) [14:03] I love Ubuntu, but I'm jumping ship if FDE goes away. :) [14:04] zul: I'm waiting for it to be published first [14:04] didrocks: ack [14:04] 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] RAOF: no I forgot to go in and approve them [14:04] is there an approved tool for looking up interface addreses, else can i rely on 'ip' being installed [14:04]