[00:49] mterry: ping [00:49] zul, hi [00:50] mterry, do you think a seperate package in python-cinderclient is really necessary? i packaged it like that so its conforming with the other openstack client packages (ex: python-keystoneclient) [00:50] zul, not necessary no, just a suggestion. I thought it was policy to keep only modules in python-* packages, but I'm not 100% on that [00:51] mterry: ok im going to leave it as it is the [00:51] er..then === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk [03:19] stgraber: i uploaded again earlier today, didn't mention === cpg is now known as cpg|away === cpg|away is now known as cpg === tkamppeter_ is now known as tkamppeter === vorian is now known as v [07:14] Hi. Could one with a recent Ubuntu test the proposed patch on the Debian bug #682032 (init_is_upstart behaviour in lsb_base's init-functions) ? [07:14] Debian bug 682032 in lsb-base "init_is_upstart warnings if upstart installed but not running" [Normal,Open] http://bugs.debian.org/682032 === smb` is now known as smb [07:51] Hi, what's the best way to maintain a localized (greek) ubuntu iso with also a few more packages from main preinstalled? [07:51] I think I once saw a wiki mentioning an "official" method, but now all I can find is https://help.ubuntu.com/community/LiveCDCustomization which mainly suggests using uck... [07:51] Nothing that I can use locally with seeds etc? Maybe live-build is the way to go? [08:41] hey everyone o/ I have pbuilder for several dists installed on my precise desktop, I'd like to be able to use previously built packages that are in the pbuilder results dir to do the next builds per pbuild machine, any doc on how to setup pbuilderrc to do that? [08:50] lynxman, I do something similar with sbuild [08:50] I use reprepro to manage a local archive which the schroots that sbuild uses pickup [08:51] I install the results of each build into the archive - and they then get picked up by subseqent builds [08:59] jamespage: oh excellent, I needed to migrate to sbuild at some point anyway, could you send me some example configs for that? [09:00] lynxman, sure [09:01] jamespage: can't be grateful enough :) beer++ [09:05] lynxman: you could bindmount the results dir into pbuilder and use this as an additional repository (or use reprepro with pbuilder) [09:06] jamespage: Mind copying me on those too? _@maxb.eu [09:06] I've done the bindmount thing with pbuilder in the past too, it works ok [09:07] maxb, I basically use the fact that sbuild bindmounts my home directory into the schroot to pickup the reprepro archive [09:07] geser: would that be possible just modifying my local .pbuilderrc [09:07] maxb, then I add "deb [arch=amd64] file:///home/jamespage/ubuntu-archive quantal main" to the sources.list in my schroot [09:10] By just modifying the sources.list in the base chroot? Or any more interesting way? [09:10] lynxman: Well, you'd have to get the results dir to actually have an apt index first [09:11] http://paste.ubuntu.com/1135760/ <-- something to do that, from the depths of my ~/bin :-) [09:11] maxb: that shouldn't be an issue :) [09:11] maxb: can easily build a trigger there [09:12] lynxman: yes, through BINDMOUNTS in .pbuilderrc should work [09:13] geser: lovely, thanks :) [09:21] zul: separate package in python-cinderclient> not vital for right now, but you might want to consider a separate package by way of planning for the future, because it'll make your life easier when switching to Python 3 - much the same reason why policy says we don't put binaries in C library packages, because the soname might change and then it'll be trouble. We ran into this with software-properties ... [09:21] alkisg: have you tried ubuntu-defaults-builder? [09:22] cjwatson: no, thanks, googling... [09:22] how do I add a bug to the 12.04.1 queue, to make sure it's fixed in the release? [09:22] alkisg: it was designed for the needs of localised ISO builders [09:22] oh, by adding the milestone [09:23] cjwatson: thank you, reading the man page, will install and test it :) [09:24] Ah right that was the page when I first saw it being mentioned: https://wiki.edubuntu.org/DesktopTeam/Specs/Oneiric/LocalizedCDImageTools === doko_ is now known as doko [10:13] @pilot out === udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | 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: [10:48] ev: mpt: Do you know when the new errors.u.c deployment is happening? I want to file a couple of bugs but they're kind of obvious so maybe you fixed them already. [10:50] Laney: we're somewhat stuck fighting dak at the moment. Not sure, but hopefully today/tomorrow. [10:50] dak?!?! [10:51] * Laney will wait a couple of days then [11:26] Laney: the canonical-admin-team archive [11:26] Laney: which I suspect is about 80% inertia and about 20% "it might not be the wisest thing ever to make the archive that Launchpad's own deployment relies on be hosted on Launchpad" [11:44] jbicha, OK if I merge eclispe? new rc in debian === zyga is now known as zyga-food [11:53] jamespage: sure, the only reason I didn't was because I was hoping http://bugs.debian.org/679328 would have been fixed soon [11:53] Debian bug 679328 in eclipse "eclipse: FTBFS with glib 2.32+" [Normal,Open] [11:54] jbicha, it might make it " I believe we already picked up the ubuntu patch (see #679328), but it is currently not uploaded yet due to the freeze" [11:55] I'm having a problem with a lucid pbuilder here. I keep getting "E: Failed to fetch http://ppa.launchpad.net/r0lf/stable/ubuntu/pool/main/a/autotools-dev/autotools-dev_20100122.1_all.deb: Size mismatch" even though size and md5sum match [11:55] the information in /var/lib/apt/lists/ppa.launchpad.net_r0lf_stable_ubuntu_dists_lucid_main_binary-i386_Packages perfectly. :-/ [11:56] yeah, it's not an RC bug for Debian [11:56] jbicha, hmm - so unlikely then [11:56] I guess it depends on whether 3.8.0 releases in time [12:10] @pilot in === udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | 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: mdeslaur === cpg is now known as cpg|away [12:19] Hi. Could one with a recent Ubuntu test the proposed patch on the Debian bug #682032 (init_is_upstart behaviour in lsb_base's init-functions) ? [12:19] Debian bug 682032 in lsb-base "init_is_upstart warnings if upstart installed but not running" [Normal,Open] http://bugs.debian.org/682032 [12:44] OdyX: by patch, do you mean the '/sbin/initctl version 2>/dev/null |grep upstart' ? [12:46] OdyX: if so, yes it contains that string: http://paste.ubuntu.com/1136045/ === zyga-food is now known as zyga [12:59] OdyX: bug updated. [13:01] jodh: many thanks ! [13:02] OdyX: np [13:09] hi, can I ask were to report a bug [13:10] shogunri1k, http://bugs.launchpad.net/ubuntu/+filebug will work, but if you have an ubuntu system, the preferred way is to run 'ubuntu-bug' [13:10] how do I run ubuntu-bug? [13:11] shogunri1k: https://help.ubuntu.com/community/ReportingBugs/ - there's also an #ubuntu-bugs channel that could help you out [13:11] Thanks [13:11] if you have a desktop, system you can hit alt-f2 and then type 'ubuntu-bug' [13:20] Maybe a dumb question, shouldn't the 'build failures' link in /topic point to http://qa.ubuntuwire.com/ftbfs/ instead of an out-of-date page? === mcclurmc_away is now known as mcclurmc [13:28] smagoun, you would seem to be correct. i dont know who here can change the topic. [13:28] but now i have a dumb question of my own. [13:29] i'm working on overlayroot. and i'd like to have the cloud -images carry a change to the default configuration file (/etc/overlayroot.conf) [13:29] what is the preferred/correct way to make that change such that future package changes to that file do not force prompts on upgrade? [13:30] the use of /etc/overlayroot.conf.local which is not installed by the package seems one option. [13:30] but i'm certain this is a known problem. [13:33] slangasek: 'apt-get install qemu-user-static:i386 on x86_64 kills the system. Is there any reason not to check the arch and not install binfmts on different arch? === Himmagery changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #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: mdeslaur [13:36] smoser: anyone can change the topic in this channel IIRC [13:36] well, that wasn't my question :) that was smagoun [13:36] but good answer [13:36] smoser: d'oh :) [13:36] smoser: FAIL :) [13:37] smoser: one sec, adjusting eyeglasses [13:37] it's ok, we're both from michigan [13:41] smoser: so, you want to modify another package's conf file? [13:41] well, its not "another package" [13:41] i want the cloud image build process to modify that config [13:41] to change the default behavior for that package for cloud images. [13:42] ah, I see [13:43] i guess http://wiki.debian.org/ConfigPackages (dpkg-divert) is one solution. [13:44] smoser: hehe, I was just looking at that page :) [13:44] or ucf (which i just want to avoid if i can) [13:44] smoser: I honestly don't know what the preferred way would be... cjwatson? [13:44] i just dont like to bother him :) [13:45] I don't know the answer to your question [13:45] This has always been under "avoid at all costs because all of the known methods are unsafe" for me [13:47] can overlayroot support a .d directory for config? [13:47] Yeah, keeping the overrides in a separate file is in general better [13:49] Laney, yeah, thats the other solution. but basically along the same lines as the .local file. [13:50] i think that is what i'll probably end up doing. but if there was an overall better solution, i wanted to use it. [13:50] Indeed. I don't think it's a bad solution. Having a directory offers more flexibility. [13:50] For example you'll run into similar problems if admins have provided their own .local files already. [13:54] How bad is it to have a source package which only ships a single transitional binary package? [13:55] * cjwatson tries to remember how he reproduced bug 926340 last time [13:55] Launchpad bug 926340 in aptdaemon (Ubuntu Precise) "aptd crashed with UnicodeDecodeError in _set_error(): 'ascii' codec can't decode byte 0xc3 in position 9: ordinal not in range(128)" [High,Triaged] https://launchpad.net/bugs/926340 [13:57] Laney, yeah, i agree on .d format being nice. i'll see if i can do that. [13:57] Laney: i do it all the time locally to satisfy dependencies when I have stuff installed from source, e.g. texlive [13:58] I'm talking about the archive here :-) [13:58] Laney: in the archive.... not sure. you will get lintian yelling 'empty package' =) [13:58] I doubt it emits that for transitional packages [13:58] Laney: why a separate source package and not build by the transition target source package, as it is usually done? [13:59] or is in main -> universe movement and hence you need a transitional package in main? [13:59] versioning hax would be required and it would make the package diverge [14:11] xnox! I've missed you [14:11] mpt: =))) [14:11] well I am off to Olympics for 5:30pm until midnight. I am in tomorrow ;-) [14:11] but will be busy. [14:11] uploaded [14:11] have fun [14:11] xnox, did you get a chance to review ? [14:16] mpt: reading. Why 5GB limit on the 5% & 1%? the minimal desktop installation is 8GB [14:16] mpt: "The disk is no longer nearly full. The alert closes by itself." Generally what can often happen: you have 10% of disk space [14:17] you start the upgrade: download packages, unpack, install, clean up. [14:17] during this process you run out of disk space, the upgrade fails, cleans up, and recovers some of the disk space. [14:18] xnox, those numbers are straw-man proposals for you to tweak, but I don't see 5 GB anywhere. Where is it? [14:18] although the disk space is now fine, it actually is not enough to complete the upgrade. [14:19] mpt: 1% or less than 50MB -> assumes that 100% is 5 000 or ~ 5GB (as in small install); similarly 5% or less than 250MB -> assumes that 100% is again 5GB [14:19] xnox, no, it says "both less than 1 percent *and* less than 50 MB" [14:19] so upgrade fails due to disk space -> trying to upgrade again will fail again. [14:20] xnox, combining relative and absolute is to avoid being nagged that you have, for example, "only" 100 GB left on a 10 TB drive [14:21] i see. [14:21] But like I say, the numbers are tweakable [14:21] ok. [14:21] what about the upgrade case. [14:21] For the upgrade case, does apt take care of that already? [14:22] "You attempted to upgrade or install new packages, which failed due to running out of disk space. Before attempting again you should prepare more free space!" [14:22] no it doesn't. [14:22] Why not? [14:22] it just gives you [14:23] "I/O Write Error" somewhere in the logs, fails with a cryptic "dpkg post-inst of $PACKAGE failed with error 254" and quits =) [14:23] mpt: but potentially that type of thing should be in apt, update-manager or somewhere there. [14:24] Ah, gotcha (aptdaemon) [14:24] xnox, yes, that way it would help people using apt-get upgrade, or USC, or update-manager, or Synaptic [14:24] cjwatson: mpt: sure or simply in aptdaemon [14:24] Er, I was talking to myself :) [14:24] About something else [14:24] doing it in aptdaemon alone would help all of those except for those using apt-get [14:25] cjwatson: your comment was applicable to two conversations ;-) simultaneously [14:25] Talented that way, apparently [14:25] cjwatson is just that good. [14:26] But even if fixed in apt, aptdaemon should still catch that specific error and turn it into a nice alert. [14:26] hmmm... true [14:27] mpt: "you have recently created: 10GB AllPixarsMovies.zip and attempted to upgrade your system (3GB) which caused you to run out of disk space" [14:28] "It's all your fault" [14:30] I suppose it's too much to hope for, but it would be nice if there was a general API for "I'm about to need this amount of disk space, don't try to use it for anything else" ... like the disk equivalent of malloc [14:30] So if you were doing an apt-get upgrade and a Firefox download and a torrent download at the same time, you wouldn't get contention for the remaining disk space. [14:30] mpt: did you know about sparse file systems? =) they say they are 10TB big, but actually they are backed by a lot of zeros and a 100MB disk drive [14:31] anyway.... [14:31] That sounds like [14:31] torrents usually do pre-allocation of the disk space. apt-get doesn't [14:32] Sparse files are great for pre-allocating large files... been using sparse allocation for a long time [14:33] mpt: in Russia the disk drive saves you! [14:33] =) [14:33] I used to use this kind of construct to create sparse images for VMs: dd if=/dev/zero of=sparse-file bs=1 count=1 seek=1024k [14:34] nifty [14:34] See also cp --sparse [14:35] tar, cpio and rsync also support it [14:38] I wonder if, say, Nautilus does [14:42] hallyn: as I recall, there was a reason not to; this has been discussed a couple of times, I don't remember if there's an open bug report though [14:44] mpt: I think not, there's a bug report for GIO https://bugzilla.gnome.org/show_bug.cgi?id=530094 [14:44] Gnome bug 530094 in gio "Nautilus (gio/gnomevfs) performs unneccessary copying of sparse files" [Enhancement,New] [14:46] TJ-, that's not quite what I was thinking of -- I was thinking more, if it's about to copy a 1 GB file, create a 1 GB sparse file first and then steadily fill it up with the data [14:46] so that other programs don't try to use the space [14:46] (if it's about to copy a file that isn't sparse to begin with, I mean) [14:47] mpt: Ahhh... I think the answer would be the same... since it can't create a sparse even for a sparse [14:47] probably [14:47] That might be an easy patch to add... I may play around with that in the next week or so [14:49] gema: Hello. I wanted to talk to you about our xen.org automatic testing. Lars Kurth has been trying to introduce us. [14:49] slangasek: bug 1033964 was the one prompting me this time [14:49] Launchpad bug 917660 in binfmt-support (Ubuntu) "duplicate for #1033964 Installing qemu-user-static in an i386 lxc container applies the binfmt changes to the host, breaking execution in that host" [Medium,Confirmed] https://launchpad.net/bugs/917660 [14:50] right [14:50] slangasek: they're not a problem in containers as they don't have permissions to cause trouble, but you can brick a host pretty trivially... [14:50] (What an exciting-sounding bug. Surely a security bug in the lxc containers?) [14:50] Diziet: no. [14:50] but you can do this in a chroot, and, how can we tell what the host architecture is then? [14:51] slangasek: I don't know, /proc/cpuinfo? [14:51] IMO that's a bug in the kernel - binfmt_misc should be per-filesystem-context. [14:51] what do you mean by a fs context? [14:52] It's enormously painful to work around this in binfmt-support, and I'm not sure it's even possible to do correctly. [14:52] cjwatson: i'm not either. [14:52] but postinst is pretty dangerous there [14:53] Good question :-) I'm not sure how to do it in the kernel, but what I actually want is for each chroot to have its own independent notion of what binary formats are associated with what executables, and for those executables to be executed within the same context as the binary that provoked binfmt_misc. [14:53] Where by context in this case I mean /proc/self/root. [14:53] so a binfmt namespace really :) [14:53] Yes. [14:54] do we have anyone going to ksummit who could bring this up? [14:54] hallyn: add it to the list after user, device and syslog ;) [14:54] stgraber: that puts it around 2018 [14:54] hallyn: I'm attending half of the last day of the kernel summit, maybe some of the kernel folks actually attend all of it [14:55] mpt: TJ-: not sure if this is relevant, but fallocate(2) with FALLOC_FL_KEEP_SIZE would be nice too. This would mean that on ext4 the filesystem can allocate space too, so large files will end up less fragmented [14:55] The only thing I can imagine being able to do in binfmt-support is to attempt to totally disable it in anything like a chroot, an lxc container, etc. And I'm not convinced that wouldn't break things for other people who have come to rely on its current behaviour of constructing a sort of fuzzy union of all the binary formats anyone might care about. [14:56] cjwatson: containers aren't a problem here, apparmor protects the host from them [14:56] cjwatson: the bot just quoted the title from the dup'd bug, but the original bug i quoted is more worrisome [14:56] Well, OK, but that in turn means that binfmt doesn't work properly inside a container for anyone who might actually want to use it. [14:56] just 'apt-get install qemu-user-static:i386' on any x86-64 host bricks it [14:56] well, my understanding is that there's nothing you can do in a chroot to add an extra binary format/architecture to binfmt, all you can do from a chroot is break things really badly [14:56] cjwatson: then they can tweak their apparmor profile [14:56] Not really very out-of-the-box. [14:57] all i'm saying is that containers aren't the problem. [14:57] Which was kind of the point of binfmt-support. [14:57] ok, i'll add binfmt namespacing (or somesuch) to the list of uds blueprints to raise. maybe we can discuss this on halloween [14:58] For the original bug: removing binfmt-support entirely would be incorrect, but perhaps qemu-user-static:i386 should stop delivering the particular binfmt entry for x86-64, or make that conditional on the running kernel, or something. [14:58] It's Multi-Arch: none, so I assume something like a chroot must be going on ... [14:59] cjwatson: what i was thinking this morning was just having qemu-user-static.postinst not install the entries depending on (somethingorother) [14:59] no, [14:59] i don't need to be in a chroot... not sure what you mean [14:59] Sure, you can manually install qemu-user-static:i386, but you have to be trying. [15:00] For it to happen accidentally, a chroot is more likely. [15:00] have to be trying, or have to be confused about multiarch. [15:00] 'sure, i want the 32-bit qemu user binaries' [15:00] I'd suggest that if [ "$(uname -m)" = x86_64 ], qemu-user-static.postinst should drop the x86_64 target. [15:00] Perhaps even just it should drop any target from that list that matches uname -m. [15:01] Likewise in prerm. [15:02] oh, is that the problem? i thought it wsa the inverse :) [15:02] it sounds worth doing to me === salem_ is now known as _salem === _salem is now known as salem_ [15:04] I believe so. [15:05] I have a similar problem with qemu-user-static, although for me it isn't fatal. [15:05] and woudl this solve that? [15:05] I run a 64-bit kernel with 32-bit userspace, in order that I can conveniently have 64-bit chroots without having to migrate the 32-bit filesystem I've had for ages. [15:05] (And run 64-bit VMs, for that matter.) [15:06] In order to make this work, I have to remember to disable qemu-user-static's x86_64 emulation. [15:06] Actually, I have a temporary hack in /etc/init/binfmt-support.conf to do that. [15:06] And yes, this fix would solve that problem too. [15:07] and uname -m shows x86_64 for you of course [15:07] Indeed. [15:08] Basically you want to avoid anything that matches either current userspace or the running kernel, I guess. [15:08] Or anything that the running kernel can do without help. [15:08] Which I guess must include current userspace (or else it's already being handled), so drop that bit. [15:08] is there an easy way of knowing "anything the running kernel can do without help"? [15:09] I'd be interested in that for a few other scripts ;) [15:09] (for example i386 can be run natively on some ia64, so it's not as simple as amd64/i386 on amd64) [15:13] I was hoping nobody would notice the handwaving [15:14] ('a miracle occurs') [15:14] Ideally the kernel would export this somewhere; otherwise I guess special-casing a few known ones would be fine really [15:34] xnox, anyway, the errors I didn't cover were the Raid ones, because I didn't know what kind of errors there are [15:34] Can you enlighten me? [15:57] @pilot out === udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #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: [16:00] @pilot in === udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #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: herton [16:00] stgraber: nothing you can do in a chroot> you certainly can register binfmts from inside a chroot, and the paths are always resolved relative to the current root [16:01] Unfortunately when you do that the results are visible outside the chroot too. [16:01] It's good that resolution is relative to the current chroot; I can never remember, but of course it wouldn't generally work if they weren't [16:02] slangasek: oh, I missed the fact that the paths would be resolved relative to the chroot, I somehow assumed it wasn't [16:02] stgraber: they are - but the problem then is that you want to be able to actually register different ones inside vs. outside the chroot [16:03] (I think it should inherit though... otherwise you can't bootstrap a pure-foreign chroot) [16:03] i.e., if you set one up outside the chroot, then chroot, you want the settings to carry over [16:47] micahg: thanks for explanation. I was hoping 12.04.1 would be a good rescue disk. :-) [16:48] game2: well, we don't include -backports packages on any images [16:48] micahg: yep :-( === mcclurmc is now known as mcclurmc_away [16:48] game2: you'd have to use quantal for something like that as it would have the newer version [16:49] game2: anyways, WRT the backport, xnox will have to give you an update, I'm happy to review/approve/upload before the point release goes out though if it's ready [16:49] cjwatson, do you have time for a Partner push for old time's sake? [16:51] micahg: thanks. I'm guessing it will not get much attention at the moment with 12.0.4.1 & q. But I can always build it here if I need it. [16:51] game2: if you're willing to do the testing, you can update the backport request and do all the tests it asks for [16:53] micahg: That's a very reasonable suggestion :-/ I'll do what I can.. [16:53] hum [16:54] does anyone has an issue with syncing make 2.82 from Debian experimental? [16:55] seb128: there's no make source... [16:55] make-dfsg [16:55] http://packages.qa.debian.org/m/make-dfsg/news/20110718T091906Z.html [16:55] fedora is using that version for 2 years [16:55] seb128: ah, you're asking policy wise, not functionally :) [16:56] I'm not a big fan of touching make but webkit fails to build with our version [16:56] no, it's rather I'm asking in case somebody knows better than me and has a reason why we should stay on .81 [16:56] seb128: I hope you're not planning on updating to 1.9.6, it breaks API [16:56] err...ABI [16:56] micahg, https://bugs.webkit.org/show_bug.cgi?id=93477 you mean? [16:56] bugs.webkit.org bug 93477 in WebKit API "1.9.6 drops symbols, breaking compatibility" [Normal,Unconfirmed] [16:57] yeah [16:57] micahg, I opened that bug, and I ran into it while doing the update [16:57] .symbols for the win [16:57] sorry, I didn't notice you were the one who submitted it :) [16:57] micahg, and do plan to update webkit eventually though, we can't stay on 1.9.2 for ever, I'm working with upstream to resolve build issues and abi compat issues [16:58] seb128: ok, I'm hoping they'll have 1.10 in time for quantal's release? [16:59] they will, they follow the GNOME release schedule [16:59] they will have 1.10 in septembre [16:59] cool [16:59] seb128: is webkit part of the GNOME MRE? [16:59] I doubt it is [16:59] it has no reason to be [17:00] they follow a similar schedule but that's about it, they don't have the same freezes, processes, release team, etc [17:00] seb128: well, we need to make sure we end up with a stable version in our releases [17:00] well, freeze are about features [17:00] the Ubuntu freeze doesn't prevent you to take bug fix updates [17:01] by the time we are in ff they will be as well [17:01] is it usually feature frozen then before our feature freeze such that we don't need to worry? [17:01] so 1.9.10 to 1.10 is a bug fix update [17:01] around the same time [17:01] I will ask for a ffe for 1 update if needed [17:01] but has not been an issue so far [17:02] ok, thansk [17:11] stgraber: could you have a look at my mp https://code.launchpad.net/~adam-stokes/ubuntu/quantal/gnome-vfs/lp977940-multiarch/+merge/114258 [17:11] stgraber: i think its ready [17:12] herton: or if you got a second to review my mp [17:12] either way [17:12] stokachu, I can't check other packages, I just work/take kernel patches [17:12] stokachu: so that one needs to get into quantal + precise-proposed right [17:13] stgraber: yea [17:13] stokachu: can you add that rebuild list to the bug? [17:13] sure thing [17:14] done [17:14] stokachu: the breaks/replaces probably should be mentioned in the changelog entry too [17:14] stgraber: you mind adding that comment ot the mp so i can remember to do it? [17:15] stgraber: ive got some other builds running right now [17:16] seb128: I guess the big question WRT make is why it's in experimental still after 1 year... [17:18] micahg, it has a rc bug but upstream argued it's not a bug [17:18] I will email ubuntu-devel about it [17:24] err.. am I crazy for thinking its crazy to let the GPG key agent thing in quantal just leave keys loaded forever? [17:25] SpamapS, it's a bug and will be fixed before release [17:25] seb128: \o/ [17:25] SpamapS, I guess you refer to https://bugzilla.gnome.org/show_bug.cgi?id=681081 ? [17:25] Gnome bug 681081 in gpg-agent "gpg passphrase cached forever" [Major,Resolved: fixed] === Zic is now known as Guest81042 [17:40] superm1: has this mythtv upload been build-tested? There's still a reference to debian/30-mythtv-sysctl.conf in debian/mythtv-common.install, which I would expect to cause a build failure [17:49] Hi [17:51] I'm trying to build a package using pbuilder. I created the base using sudo DIST=quantal pbuilder create. Nothing special (I have it running for precise). However, when compiling a package, I get this error: "dpkg-checkbuilddeps: Unmet build dependencies: build-essential:native" [17:56] rvr_: I've forgotten everything about pbuilder, but now might be a good time to give sbuild a try. Try 'mk-sbuild' in particular :) [18:05] SpamapS, I would prefer to "fix" the pbuilder :-/ === vibhav is now known as Guest78758 [18:06] stokachu: commented [18:08] rvr_: I wrote an article about using Pbuilder some time ago with some supporting scripts... maybe it will help you http://tjworld.net/wiki/Linux/Ubuntu/Packages/CreatingPbuilderVariations [18:09] Is there any reason to use pbuilder over sbuild (not trying to be argumentative, I'm truly curious) [18:09] sbuild is whats used on the buildds.. so it seems logical to want to use sbuild over pbuilder [18:11] http://askubuntu.com/questions/53014/why-use-sbuild-over-pbuilder [18:11] SpamapS, The builds I manage have been running with pbuilder + precise for a while, and I'm just trying to make them run in quantal with the minimal amount of changes possible [18:12] rvr_: sure. Just wondering why people choose pbuilder. [18:13] I did use pbuilder just during the 10.10 dev cycle... but sbuild seemed to pull ahead for me in the end. [18:13] Someone spotted this problem weeks ago http://irclogs.ubuntu.com/2012/07/06/%23ubuntu-devel.txt (search for "build-essential:native") [18:15] jamespage, ping [18:21] rvr_: Looking at the man-page for pbuilder, --extrapackages claims the build-essential is installed by default [18:21] rvr_: he's UK Time zone and likely AFK until UTC 0900 [18:22] rvr_: Have you logged into the pbuilder and checked what is installed ? [18:22] TJ-, build-essential is installed, the problem is the ":native" architecture [18:22] that I don't know why it wants to install [18:32] slangasek: doh, i was just trying to rapidly pull out the simple stuff, you're right. i build tested the original, not the updated [18:33] will sort it out later and do an actual build test with the changes [18:34] rvr_: commit 40d51dc36b23 introduced :native parsing to the scripts to fix debian bug 558095 [18:34] Debian bug 558095 in dpkg-dev "dpkg: please accept ":native" multiarch qualifier in build dependencies" [Wishlist,Fixed] http://bugs.debian.org/558095 [18:37] TJ-, Yeah, but that doesn't explain why pbuilder wants to install build-essential:native. And neither it is currently supported by apt in Quantal ATM [18:38] rvr_: what package is it you're trying to build? [18:40] rvr_: From reading the dpkg code, it looks like this will happen if the host and package arch are different [18:41] superm1: ok cheers [18:41] unless (defined($bd_value) or defined($bc_value)) { [18:41] $bd_value = 'build-essential:native'; [18:41] $bd_value .= ", " . $fields->{"Build-Depends"} if defined $fields->{"Build-Depends"}; [18:42] AFAIK, both are amd64 [18:43] I think you've been hit by code that wasn't thoroughly thought through [18:44] The patch has this clue: [18:44] +=item build_dep (defaults to 0) [18:44] + [18:44] +If set to 1, allow build-dep only arch qualifiers, that is “:native”. [18:44] +This should be set whenever working with build-deps. [18:46] :-/ [18:53] rvr_, pong [18:53] jamespage, Did you resolve your issue with build-essential:native? [18:54] * jamespage tries to remember [18:54] was that with hsqldb? [18:55] jamespage, Yes [18:56] I worked around it by dropping the native package [18:56] the combination of archs was confusing the buildd's [18:57] Were you building in different archs? [19:00] rvr_, hold on - I need to check again [19:01] jamespage: Hrm? What does that have to do with build-essential:native? [19:02] jamespage: The hsqldb/buildd issue was parsing the Arch: line in the source. [19:02] infinity, trying to remember - rrd has overwritten that bit of my short term memory [19:03] jamespage: Well, if you've seen something involving build-essential in some way, I'd like to know, cause it's like a dpkg bug I should fix. :P [19:03] jamespage: But, AFAIK, it should all be sane now. [19:03] infinity, actually it was - I remember now [19:03] infinity: rvr_ has hit it today, and we found your discussion with Colin about it with a note you would revert or investigate [19:04] TJ-: I did revert, and fixed build-essential instead, this was weeks ago. [19:04] TJ-: Where's the breakage that was hit today? [19:04] rvr_ will tell you ... he hit it... I've been diving into the source to understand it [19:04] rvr_: ? [19:05] (Also, before we continue, is this on a native build, or a cross-build? Cause if it's a cross-build, it's intentional that we expect build-essential:native to be installed) [19:06] infinity, Yeah, I'm trying to compile a package in pbuilder, and I get "dpkg-checkbuilddeps: Unmet build dependencies: build-essential:native". Just tried pbuilder-dist and same issue. [19:06] rvr_: Which version of dpkg-dev? [19:06] rvr_: And, uhm, is build-essential installed? [19:06] Yes, it is installed [19:06] rvr_: And is this a cross-build, or a native build? [19:06] Native, amd64 [19:07] (Also, while it shouldn't relate, pbuilder sucks, learn to love sbuild) [19:07] In my quantal pbuilder the dpkg-dev version is 1.16.7ubuntu3 ... and it has the $bd_value = 'build-essential:native'; line in checkbuilddeps [19:08] TJ-: Yes, as it should. [19:08] rvr_: What version of build-essential is installed? [19:08] infinity: OK ... when you said revert I thought you were referring to the commit in the dpkg git [19:08] Let me check, but it's a quantal base created some hours ago [19:08] TJ-: No, I reverted my workaround. [19:08] infinity: Ahh!! [19:09] Again, though, this was all weeks ago, and the buildds would be broken if the above was actually happening for everyone. [19:09] So... [19:09] There's something bizarre specifically with your setup. [19:10] In my quantal pbuilder its build-essential 11.5ubuntu3 [19:10]