=== Chipzz_ is now known as Chipzz === cpg is now known as cpg|away [02:00] tjaalton: seems -omap 4.1 is working as expected at panda [02:00] didn't have any issue with it [02:01] tjaalton: saw it's available at debian packaging git tree, but not yet pushed to debian [02:01] tjaalton: want to manually sync it? === cpg|away is now known as cpg === Logan_ is now known as log [03:58] rsalveti: ok, will do. also, is unity working for you on the panda? [04:04] @pilot out === udevbot_ changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of 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: [05:14] Godo morning [05:44] (erk, and hapy tpying!) [05:44] Goodo! [06:21] good morning [06:30] Hi all, can someone tell me where translations for the package gcr show up? I'm trying to complete the translations but I'm not sure about a number of strings [06:31] these strings to be specific: https://translations.launchpad.net/ubuntu/quantal/+source/gcr/+pots/gcr/nl/+translate?batch=10&field.alternative_language-empty-marker=1&old_show=all&show=untranslated&start=0 [06:39] freeflying, happy birthday! :) [06:45] trijntje: the 'gcr' package's Homepage field points here: https://live.gnome.org/GnomeKeyring [06:45] the Description says, in part, "This package contains the certificate viewer and prompter service." [06:49] sarnold: thanks, I'll try asking in the gcr irc channel === smb` is now known as smb [07:32] dholbach: thanks :) [07:39] wookey: I switched to PKG_IGNORE_CURRENTLY_BUILDING=1 in 1.57 version. It replaced NO_PKG_MANGLE=1 and gave us ddebs [07:42] wookey: can give you #linaro irc log of my discussion with lool about that switch. [07:52] hrw: This is fairly old, right? ISTR we had to patch pkgbinarymangler, but that should be all in Ubuntu precise at least [07:52] lool: it was natty time [07:53] yeah [07:53] I thought maverick, but whatever, it's "old" :-) [07:57] And today's confusingly useless use of cat award goes to: [07:57] cat /build/buildd/sssd-1.9.1/debian/sssd.upstart.in > /build/buildd/sssd-1.9.1/debian/sssd.upstart [07:59] no idea why cat instead of cp :) [08:00] tjaalton: No idea why a .in at all, if it's not mangled on its way to being the real deal. [08:00] infinity: it's the same line on debian too, there's an initscript for debian [08:00] cat $(CURDIR)/debian/sssd.$(INIT).in > $(CURDIR)/debian/sssd.$(INIT) [08:01] tjaalton: Seven kinds of special. :) [08:01] Maybe it was mangled once and somebody didn't undo it enough *shrug* [08:02] Yeah, did an 's/sed "expression"/cat/', assuming they may need to bring the sed back some day? Dunno. [08:02] Just rather entertaining. [08:02] (The things one notices while watching build logs at 2am) === mcclurmc_away is now known as mcclurmc === henrix_ is now known as henrix [08:16] well, is it allowed for packages to ship upstart files on debian? and would it then include both upstart and sysv initscripts on ubuntu? [08:16] I'd gladly get rid of that hack [08:18] tjaalton: Oh, I see what you're doing now. Selecting one or the other, check. [08:18] right [08:18] instead of a diff [08:18] tjaalton: I do believe it's perfectly reasonable to ship foo.upstart in debian/, and vorlon's submitted many a patch to do that, but I'm no expert on what the status of that is. [08:18] slomo: ^ [08:18] slangasek: ^ [08:19] slomo: Ignore that, tab completion fail. [08:19] it's now valid in unstable; until recently it wasn't [08:19] I recall there being a policy update about that.. [08:19] ah [08:19] (unstable and testing) [08:20] slangasek: ping re acpi-tools review, what to do with them :) [08:20] acpi-support [08:20] tjaalton: whimper; ENOTIME for the next couple of days, do whatever you think is best [08:21] slangasek: cool, I'll just upload, it's a no-brainer [08:21] tjaalton: If it's a no-brainer, any one of us no-brains will happily review it in the queue. ;) [08:21] infinity: heh, understood :) [08:22] bug 804109, fwiw [08:22] Launchpad bug 804109 in acpi-support (Ubuntu) "drop synaptics from racy /etc/acpi/asus-touchpad.sh" [Medium,Triaged] https://launchpad.net/bugs/804109 [08:22] RAOF, infinity: can I bribe one of you to review the SRU upload for bug 1016121? the crowd is getting angry :) [08:22] Launchpad bug 1016121 in ubuntu-defaults-builder (Ubuntu Precise) "wrong architecture (i386,amd64) packages downloading" [Undecided,In progress] https://launchpad.net/bugs/1016121 [08:24] pitti: Sure. I accept bribery in the form of kittens. [08:24] pitti: (It's my SRU day in ~6h anyway, but I'll check this one now) [08:26] infinity: http://cdn.memegenerator.net/instances/400x/28050481.jpg [08:26] pitti: Straightforward enough to me and, as an added bonus, I know exactly what that patch does. :P [08:27] infinity: meeow! [08:27] * pitti purrs happily [08:27] pitti: Oh, wow, a custom lolcat just for me. I feel special. [08:28] pitti: And accepted. [08:29] cheers! === henrix is now known as henrix_ === henrix_ is now known as henrix [09:02] xdatap1: so is that one patch you pointed out enough for you, or do you actually need the quantal ubuntu-defaults-builder in precise? [09:02] in the latter case, why don't you just use the quantal pacakge as it is? [09:03] pitti, we use the amazon cloud for building the images, so using the standard package from archive would be better. [09:04] xdatap1: quantal's version also has some adjustments for newer live-build, so I don't know whether it'd actually work with the precise live-build version [09:04] pitti, also we are planning to continue using precise cloud instances for building the CD, so we would need ubuntu-defaults-build to move on with the new features [09:04] xdatap1: I guess for now it might be best if we target individdual bug fixes that you need to precise, and I wrap them up in the next SRU? [09:05] pitti, if this is better I'm fine with it. But as far I can see all the changes from 0.31 to 0.38 makes sense in precise [09:06] pitti, on the same context, we need also the patch from this: https://bugs.launchpad.net/bugs/1062423 [09:06] Launchpad bug 1062423 in live-build (Ubuntu) "Precise version.sh doesn't know about Quantal" [Undecided,New] [09:06] xdatap1: e. g. 0.32 says "Adjust for live-build interface changes." which looks quantal only [09:07] pitti, mmm, yes, you're right [09:09] pitti, let's recap then. Patches for bug #1016121 , bug #1048207, bug #1062423 and if possible Bug #1029279 but I'm using a workaround for this so it's not urgent [09:09] Launchpad bug 1016121 in ubuntu-defaults-builder (Ubuntu Precise) "wrong architecture (i386,amd64) packages downloading" [Undecided,Fix committed] https://launchpad.net/bugs/1016121 [09:09] Launchpad bug 1048207 in ubuntu-defaults-builder (Ubuntu) ""el complete" in langpacks.txt breaks build" [Undecided,Fix released] https://launchpad.net/bugs/1048207 [09:09] Launchpad bug 1062423 in live-build (Ubuntu) "Precise version.sh doesn't know about Quantal" [Undecided,New] https://launchpad.net/bugs/1062423 [09:09] Launchpad bug 1029279 in ubuntu-defaults-builder (Ubuntu) "/usr/share/syslinux/themes/ubuntu-quantal/isolinux-live/*': No such file or directory from precise" [Undecided,New] https://launchpad.net/bugs/1029279 [09:11] xdatap1: 1016121 is in -proposed; marked 1048207 for next SRU round; 1062423 looks like a missing dependency? [09:11] xdatap1: i. e. you need syslinux-themes-quantal [09:11] if you want to build quantal images [09:14] pitti, correct me if I'm wrong, I wouln't have all syslinux-themes- packages in Precise in the future, don't I? So wouldn't make sense pointing to syslinux-themes-precise for all the version I build? [09:14] xdatap1: You really need to build quantal images in a quantal system - it's totally unsupported to do otherwise [09:14] xdatap1: no, you need to install them from quantal [09:14] xdatap1: Why not use a quantal chroot? [09:15] but as I said before, it's really easier to just take the quantal pacakge [09:15] at least live-build, u-d-b and syslinux-themes-* for the target releas [09:15] xdatap1: We build all Ubuntu images in a host system that's, oh, I don't even know what it is, one of precise/lucid/hardy [09:15] xdatap1: With chroots matching the release we're building [09:16] phone, brb === sgnb` is now known as sgnb === doko_ is now known as doko [09:22] back [09:24] cjwatson, pitti: let me rephrase the topic. The Italian team builds these localized images with ubuntu-defaults-build. From this cycle we try to use amazon cloud instances because building in local machine and then upload on the server it's way too long, takes nearly two hours [09:24] xdatap1: right, but surely you can install some additional packages there from the target release? [09:26] cjwatson, pitti : ubuntu-defaults-build do create a chroot for the target version. The bug #1029279 imho depends on the fact that the script ss looking for the directory on the host system and not inside the chroot. [09:26] Launchpad bug 1029279 in ubuntu-defaults-builder (Ubuntu) "/usr/share/syslinux/themes/ubuntu-quantal/isolinux-live/*': No such file or directory from precise" [Undecided,New] https://launchpad.net/bugs/1029279 [09:26] cjwatson, pitti : btw the general problem is. May we continue to update ubuntu-defaults-build on precise so that we can keep using precise for building next versions? [09:27] xdatap1: as I said, that's not enough -- you also need live-build, the syslinux theme, and possibly some dependencie of those === dholbach_ is now known as dholbach [09:29] pitti, so the short answer is "probably no"? I mean, it appears difficult to build a precise+3 on precise, don't you think? [09:29] xdatap1: I think it's a waste of time [09:29] right [09:29] xdatap1: I know ubuntu-defaults-builder creates a chroot - I mean that you should have another level of chroot to run ubuntu-defaults-builder in [09:29] That will be so much less hassle for you and us [09:30] And it will (modulo setup) work fine because it matches what we do === tkamppeter_ is now known as tkamppeter [09:32] the steps would be, then: precise cloud image -> ubuntu+n chroot -> ubuntu-defaults-build -> ubuntu+n chroot -> iso [09:32] at the end it would have two chroots [09:32] is it correct? [09:34] xdatap1: yes. [09:35] xdatap1: the last chroot is "implementation detail" of how to create an livecd-iso. [09:37] ok. I need to think about it. As far I can see it's not sustainable for us in the long run. :\ [09:38] unless I create something that makes it automatic... [09:40] xdatap1: there is sbuild juju charm that can create the first chroot. With small changes you can make the whole process as quick as: juju deploy livecd-build. and wrap your current build script in `schroot -c $target-distro` [09:41] xdatap1: and juju will bring your livecd building instanace up, set it up and download the scripts you want, and clean up afterwards. [09:41] xnox, thanks, I'll check for it. The problem is that quantal is next week [09:41] xdatap1: for added bonus you will then be able to use it not only with EC2 but locally with lxc containers.... [09:42] xdatap1: yeah, I see. [09:42] xdatap1: but... I am running quantal on EC2. There are quantal ec2 images published for each milestone. Use those?! [09:43] pitti, anyway, we'll need the patch for bug #1048207 because it affects also precise builds and we'll need it for the point release [09:43] Launchpad bug 1048207 in ubuntu-defaults-builder (Ubuntu Precise) ""el complete" in langpacks.txt breaks build" [Undecided,New] https://launchpad.net/bugs/1048207 [09:43] right [09:44] pitti, thanks, you're an hero! [09:46] xnox, quantal ec2 images? where is it? I can't find it in the list [09:47] xdatap1: http://iso.qa.ubuntu.com/qatracker/milestones/238/builds filter on the left for "Ubuntu Server EC2" only, for the quantal beta-2 milestone. The ami's are listed per region/arch in the right hand column. [09:47] xdatap1: I can't believe it wouldn't be sustainable. It involves a tiny amount of sysadmin effort once every six months to create the new chroots; they can be simple enough that you can keep them up to date automatically [09:48] xdatap1: Again, this isn't a theoretical exercise, it's what we do in production and it's easy [09:48] cjwatson: i think they do tear down and back up the EC2 instance ;-) so really they should puppetize / jujufy / etc it. [09:48] If you have no persistent storage, indeed, it would be a bit more effort [09:48] xdatap1: maybe there is a better way to find devel EC2 amis... but I don't know. [09:49] But not desperately much [10:01] with the last hint xnox gave me I should have solved. I'll check it out. Thanks ;) [11:02] where is the equivalent of Debian's PTS for ubuntu? How do I find out if gcc-4.7_4.7.2-3ubuntu1 is headed for quantal or not? [11:03] * wookey is having much fun with multiarch and compiler version skew across arches [11:03] https://launchpad.net/ubuntu/+source/gcc-4.7 [11:04] Can't tell you intent, but then nor can the PTS [11:04] right. cheers [11:04] You'd have to ask doko [11:06] it's meant for -updates, not uploaded to -proposed to avoid accidential migration before the release. found in the ubuntu-toolchain-r/ppa PPA [11:06] OK. but right yes _ i just found the PPA, which should solve my problem if it has arm builds too - ah yes it does. [11:07] wookey, there is bug, the packages don't build Go. but I assume you don't care [11:07] I've got apt in a right state - interesting to see if it can sort itself out [11:07] doko: correct :-) [11:08] PPAs are a really good idea :-) === MacSlow is now known as MacSlow|lunch [11:34] Is there a repo that has a built GCC 4.7.2 ? [11:34] seb128, did you have a chance to look at libgtk2-perl? [11:35] https://launchpad.net/~ubuntu-toolchain-r/ seems no to have it yet [11:35] doko, I had a look but I didn't manage to figure what is wrong (yet ... then got sidetracked in "need to land before freeze" issues) [11:36] for precise, Ubuntu 12.04, I mean. [11:40] not yet. buildd resources are needed elsewhere [11:44] mda [11:48] pitti: udisks2 support landed in checkbox [11:49] pitti: with GUdev help [11:49] zyga: yay you! [11:49] pitti: thanks a lot for helping me out :) [11:49] no worries [11:50] pitti: I hope that we can soon fix usb-creator too === cpg is now known as cpg|away [12:05] tjaalton: unity is working fine for me [12:06] rsalveti: on stock quantal? [12:06] tjaalton: yes [12:07] a few bugs, like a black line at the top of the screen, but working [12:07] huh, doesn't work at all here, compiz crashes === MacSlow|lunch is now known as MacSlow [12:08] rsalveti: what dri driver do you have? llvmpipe isn't actually built atm, and it doesn't seem to work either [12:09] tjaalton: well, I'm using the pvr-omap4 driver [12:09] right [12:09] don't think llvmpipe would work at this point on arm [12:09] not enough to be called as usable [12:09] nope [12:10] what i was wondering though is why cant we fall back to swrast [12:10] shouldnt that just kick in [12:10] that's what happens now, and compiz crashes [12:10] (i know it wont be usable but iu would actually expect more than a dead screen) [12:10] ah, so its compiz [12:11] I don't think we ever got compiz working with swrast with opengles [12:12] yeah, i wasnt aware its the client side thats at fault :) [12:13] seb128: hey, what changed recently that makes everything want write access to dconf? I know about pam-xdg-support but the thing is, applications that never needed @{HOME}/.../dconf/user (eg, evince (bug #1062531)) now need it [12:13] Launchpad bug 1062531 in evince (Ubuntu Quantal) "apparmor prevents evince from accessing /run/user/" [High,Confirmed] https://launchpad.net/bugs/1062531 [12:18] jdstrand, it's weird, nothing should have changed out of the location of the db... I need to check with desrt [12:19] jdstrand, but on that evince bug: apparmor="DENIED" operation="open" name="/run/user//dconf/user" [12:19] jdstrand, doesn't "open" mean it's having issue to access it to read? [12:21] jdstrand, I think the evince error message is buggy (checking) [12:22] seb128: it could be access(), it could be open() [12:22] jdstrand, yeah, that errors is displayed when " fd = open (filename, O_RDWR | O_CREAT, 0600);" fails [12:22] it could be creat() [12:22] seb128: is that in library code or in evince? [12:23] jdstrand, it's in libdconf [12:23] d-conf's client library [12:23] sigh [12:24] jdstrand, the way dconf works is that the daemon is only used for write, reading is done through direct mmaping of the db by the client through the lib [12:24] I'm tempted to just add a deny rule [12:24] jdstrand, do we need to restrict /run/user/ access at all? [12:25] we don't restrict ~/.config access do we? [12:25] jdstrand: all gnome apps will need that directory, it's for d-conf shared memory...it should go in the gnome abstraction [12:26] well that's great [12:26] jdstrand: the glib g_get_user_runtime_dir() now returns that directory now that the env var exists [12:26] cause that's yet another hole in the profile since, you know, know the confined application can write to gsettings [12:26] evnce worked just fine without the denial prior to this though [12:26] mdeslaur, it's not only GNOME, gsettings is a glib level api (so could be used by e.g qt or KDE clients) [12:27] s/, know/now/ [12:27] jdstrand: that's because when the new env var isn't set, it defaulted to the user cache directory in his home [12:27] jdstrand, well, it was writing to gsettings, the db was just in ~/.config, how is that different? [12:27] jdstrand: but that's less than ideal, as the directory isn't cleaned up on reboot [12:27] mdeslaur: I understand-- evnice doesn't have access to the oroginal value [12:29] apparmor_parser -p /etc/apparmor.d/usr.bin.evince|grep dconf [12:29] returns nothing [12:29] and there were no apparmor complaints [12:29] today, there are apparmor complaints [12:30] jdstrand: well, you had @{HOME}/** rw, [12:30] jdstrand, I don't understand the issue ... it was in .config which is not restricted in access, so it's normal there were no complain? [12:30] this is true [12:31] jdstrand, shouldn't just /run/user/ be whitelisted the same way? [12:31] it's technically part of the user's owned dirs [12:31] jdstrand: /run/user/$USER is the new place where apps will put all their temp stuff [12:33] seb128: my point was that I thought it *was* restricted in access. it isn't just evince-- it was a bunch of things. I have several profiles that are not shipped in ubuntu that all of a sudden need the access. I need to look at this more [12:33] * jdstrand sighs again [12:33] :-( === _salem is now known as salem_ [12:33] (it shouldn't be in the gnome abstraction, cause we don't want to expand write access, but I'll fix the profiles) [12:34] jdstrand: It should probably go in the user-tmp abstraction [12:34] jdstrand, you technically don't need write access there? [12:34] jdstrand: huh? it's a temp dir? why wouldn't apps get write access in there? [12:35] seb128: we don't want the gnome abstraction itself to have the write access, no. maybe in another abstraction. but that doesn't matter for this. we'll figure something out [12:35] jdstrand, well, why do you need "write"? the client lib is only reading the db, the writes go through dbus to the service [12:35] pitti: ok with this change to apport? http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/quantal/apport/ubuntu/revision/2103?start_revid=2103 [12:36] seb128: filename, O_RDWR | O_CREAT will file if not given 'w' [12:36] s/will file/will fail/ [12:37] oh, I see, right :-( [12:38] seb128: are you planning an upload of evince anyway? [12:39] jdstrand, no, I've nothing planned for it [12:41] ok [12:44] Riddell: sure, if that works for you; I'll apply it to trunk, and check with the test suite [12:50] barry, talked with jdstrand about getting python3.3 into main already in quantal (needed in r anyway). reason is to build python3-stdlib-extensions for 3.3. we should then strive to get rid of 3.2 in r [12:50] will start the opening of r with 3.3 as a supported version [13:07] notification area people: ping? [13:08] looks like there is a pretty bad bug with QSystemTray in 12.04 [13:08] related to the way SNI treats menus with separators === MacSlow is now known as MacSlow|errand === henrix_ is now known as henrix [13:32] slangasek, could you take a look at https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1060296 [13:32] Launchpad bug 1060296 in mountall (Ubuntu) "'df /' reports Filesystem '-'" [Undecided,Confirmed] [13:33] mpt: as it turns out, we're inserting quite a few package failures into the database. For 20120928 there were 97395 12.04 crashes and 2107 package installation failures. We don't get a signature for these yet, so they wont appear on the front page. [13:33] mpt: http://poppy-dev.local - I'm running that back-population in the background [13:33] so you should slowly see past days appear [13:33] ev, what's a "package failure"? installation? [13:33] yes [13:35] ev, so they haven't been showing up in the table, but have they been showing up in the graph? [13:35] mpt: correct, but not showing them in the graph is being fixed right now [13:35] ev: thunderbird and rhythmbox have their "own" crash dialogs (thunderbird tries to report to mozilla, rhythmbox want to restart itself). and those don't seem to be getting through to whoopsi and apport, do they? [13:35] xnox: correct; we filter those out in apport [13:35] ev, so are there any examples of package installation failures in the poppy-dev table? Nothing jumps out at me. [13:35] =( [13:36] xnox: see /etc/apport/blacklist.d [13:36] mpt: no, package installation failures wont show up in the table yet [13:36] * xnox would report to launchpad, but not mozilla.... [13:36] feel free to come over if I am being confusing :) [13:36] xnox, why? feel free to report to launchpad, but your bug won't get fixed [13:36] xnox: Mozilla is much better equipped to handle problems in Firefox than we are [13:37] indeed :) [13:37] they have a lot more people looking at crashes than we do [13:37] ev, even so, we should be collecting them for statistical purposes [13:37] (ie, they have more than one person looking at firefox crashes) ;) [13:37] (Firefox and Thunderbird crashes, I mean) [13:37] but they do not have the same privacy as we do. [13:38] mpt: agreed [13:38] filing a bug for that now [13:38] but... rhythmbox hiding it's own crashes? [13:40] xnox: hm? Elaborate please. [13:40] doko: +1 from me. also: https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-python33 [13:41] mpt: thoughts on getting two dialogs for firefox crashes? [13:41] seeing as how Mozilla will pop up one as well [13:41] One with a broken icon [13:41] I am familiar with it [13:42] and one that never, ever, works for me [13:42] but I digress [13:43] ev, ideally we'd just hook in to theirs [13:43] mpt: please feel free to update https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1064395 with your thoughts [13:43] Launchpad bug 1064395 in apport (Ubuntu) "Apport should still send reports to daisy.ubuntu.com for binaries in the blacklist" [Undecided,New] [13:44] Any idea if there will be fix for fglrx Bug #1058040 in final Ubuntu 12.10 release? Or we will have to use open source drivers? Thanks. [13:44] Launchpad bug 1058040 in fglrx-installer (Ubuntu) "fglrx-installer does not support HD2000-4000 "legacy" cards" [Undecided,Confirmed] https://launchpad.net/bugs/1058040 [13:44] ev: when rhythmbox crashes, it shows a rhythmbox crash saying "rhythbox crashed " and no apport / whoopsie dialogs. Can you check if you have rhythmbox crashes over the year? [13:44] maybe it has been crashing at decoding mp3 and that's blacklisted though =/ [13:44] xnox, ev: rb shouldn't block apport, some software do because they trap the signal to do custom handling, we usually patch those to restore the signal to not hijack apport [13:45] xnox, ev: or said differently "that's a bug" [13:45] :) [13:45] * xnox did seb128 join us?! =) [13:45] xnox, well, go on https://errors.ubuntu.com/ and enter "rhythmbox" in the text entry [13:45] xnox: https://errors.ubuntu.com/?package=rhythmbox [13:45] quite some rb issues there [13:46] hmm... [13:46] damn, seb128 beat me to it :) [13:46] but yeah, seems like we're getting reports for it [13:46] ev, your solution is nicer though, one click away and I learnt something ;-) [13:46] seb128: yeah, I really need to document (beyond the old post to ubuntu-devel) the URL parameters [13:47] or rather, just make the URL change to match the selected filter [13:47] so you learn them all the same [13:47] I think mpt suggested that a while back [13:47] Yeah, I wish more pages did that [13:47] xnox, I get an apport dialog if I kill -11 $(pidof rhythmbox) [13:48] ev, yeah, I like when urls reflect your queries ;-) [13:48] it also makes firefox's awesome more awesome [13:48] since it remembers the things you query most about and rank them higher [13:48] sounds like we have consensus :) - adding to my todo list [13:48] oh nice [13:48] * xnox same with chromium.... [13:48] ev, yes, in bug 1020580 (should that be a separate bug?) [13:48] Launchpad bug 1020580 in Errors "Permanent URLs for most common problems view" [Undecided,Fix committed] https://launchpad.net/bugs/1020580 [13:48] I don't generally remember URLs any more; I bang bits of them into firefox and it reads my mind [13:49] mpt: yeah, probably [13:49] as we can consider permanent URLs done [13:49] cjwatson: hahaha [13:50] * xnox can see a new "virus" popping up which clears user search history.... that will be pain. [13:50] ev, reported bug 1064398 [13:50] Launchpad bug 1064398 in Errors "errors.ubuntu.com URL parameters are secret" [Undecided,New] https://launchpad.net/bugs/1064398 [13:51] mpt: thanks [13:55] ev, what does "red background" means again? and greyed background? [13:55] ev, it would be really good to have a color code somewhere on the page for people like me who can't make sense of the color code ;-) [13:56] dholbach: heya [13:57] dholbach: I'm looking at libxml2 in the queue, it's introducing a new binary package without any FFe or even any bug linked to it at all. Do we actually need that udev in Ubuntu? [13:57] *udeb [13:57] stgraber: I didn't create the udeb [13:57] stgraber: that must be something automatic during the build [13:57] it's had a udeb for ages, I thought [13:58] http://launchpadlibrarian.net/119213170/libxml2_2.8.0%2Bdfsg1-5_2.8.0%2Bdfsg1-5ubuntu1.diff.gz [13:58] red/pink -> possible regression [13:58] grey -> not showing up in the latest version yet [13:58] stgraber, it's just autogenerated when built on ubuntu [13:58] seb128: indeed, it's on my list :) [13:58] WITH_UDEB := $(shell dpkg-vendor --derives-from Ubuntu && echo yes) [13:58] ifdef WITH_UDEB [13:58] $(if $(shell grep -q libxml2-udeb debian/control || echo yes),$(shell cat debian/control.udeb >> debian/control)) [13:58] TARGETS += udeb [13:58] else [13:58] $(if $(shell grep -q libxml2-udeb debian/control && echo yes),$(shell sed -i /libxml2-udeb/,\$$d debian/control)) [13:58] there's certainly a udeb in the archive right now [13:58] export DH_OPTIONS = -Nlibxml2-udeb [13:58] endif [13:58] ev, oh ok, I though pink was that, I wouldn't have guessed the grey one ;-) [13:58] ev, thanks [13:58] stgraber: so it looks like it's business as usual :) [13:59] yeah, that looks like autoregenerated control file [13:59] * Laney does a sad about libxml2 going out of sync [13:59] generated control is a curse from the pits of hell [13:59] Laney, the change is forwarded [13:59] hmm, ok, so it's just the diff being confusing... [13:59] doko, roaksoax says you moved freeipmi to main earlier today. is this transient: http://paste.ubuntu.com/1269287/ [13:59] seb128: sure thing [14:00] smoser: something is odd because freeipmi-common is missing from the archive at the current version [14:00] right. i hvae no idea how i would fix such a thing. i'm guessing you do. [14:00] Candidate: 1.1.5-3 == not current version. [14:00] right. [14:00] * cjwatson checks build logs [14:01] I strongly suspect that somebody overrode it between components twice in one publisher cycle [14:01] And thereby caused Launchpad to forget that it exists [14:01] cjwatson: That will be me and doko doing the operation concurrently [14:01] Yeah, it's Superseded [14:01] smoser, should be [14:01] Concurrently isn't a problem if you both do the same thing [14:02] Daviey: Somebody needs to do a no-change upload of freeipmi to resurrect this [14:02] ouch [14:02] cjwatson: for reference, is the a LP bug to track this feature? [14:02] mpt - did you report a bug for the broken icon? ;) [14:02] There is, somewhere - it's well-known by the relevant people [14:03] It's obviously not a feature :-P [14:03] ev, seb128: red/pink can also mean "private bug report" [14:03] I think it's either bug 180218 or related to it [14:03] Launchpad bug 180218 in Launchpad itself "override mismatch race needs to be fixed" [High,Triaged] https://launchpad.net/bugs/180218 === MacSlow|errand is now known as MacSlow [14:03] mpt, same color for "potential regression" and "private bug"? [14:03] Ah, bug 347279 is clearer [14:03] Launchpad bug 347279 in Launchpad itself "overrides on architecture-independent binaries in a single architecture leads to superseding the package on other architectures" [Low,Triaged] https://launchpad.net/bugs/347279 [14:04] seb128, I discovered that only by accident :-) [14:04] Perhaps [14:04] uploaded. [14:04] mpt, I see ;-) [14:04] for example bug 1030456 [14:04] Error: Launchpad bug 1030456 could not be found [14:04] indeed [14:05] chrisccoulson, no, I was never quick enough to get a screenshot :-) [14:06] mpt: screencast it? [14:07] good idea [14:07] Now, how to trigger a bug in Firefox/Thunderbird... [14:07] mpt, heh, it doesn't matter too much. i'll send a patch upstream for it in a bit. it's probably only a 1-line fix [14:07] mpt, crashme ;) [14:07] mpt http://code.google.com/p/crashme/ [14:08] it even allows you to pick the type of crash to trigger [14:08] oh cool [14:13] ok, got a screencast [14:20] chrisccoulson, reported bug 1064423 [14:20] Launchpad bug 1064423 in firefox (Ubuntu) ""Submitting your report..." shows missing-icon icon" [Undecided,New] https://launchpad.net/bugs/1064423 [14:21] mpt, thanks [14:21] chrisccoulson, now what should I do about the error report submission never working? Any obvious troubleshooting steps? [14:22] Every time, it's "There was a problem submitting your report.", both in Firefox and Thunderbird [14:22] mpt - are you sure the submission doesn't work? you don't get any feedback [14:22] and then the window disappears half a second later [14:25] mpt, do you have any reports in about:crashes? [14:26] the missing icon is my fault btw, we don't install it in the package [14:26] i thought you were referring to the icon on the launcher :) [14:26] chrisccoulson, yes, going back to January last year -- but that I can remember, it has *always* said "There was a problem submitting your report" [14:27] mpt, hmmm, do you use a proxy by any chance? [14:27] chrisccoulson, and when I follow any of the links, crash-stats.mozilla.com gives me a 404 error. [14:27] chrisccoulson, no, I'm at the Canonical office [14:29] mpt, well I guess Canonical has some proxying going on there [14:30] i should come in to the canonical office one day [14:30] mpt - ok, the icon fix was a trivial fix: http://bazaar.launchpad.net/~mozillateam/firefox/firefox-trunk.head/revision/1396 [14:31] seb128, elmo says no it doesn't :-) [14:31] chrisccoulson, \o/ [14:33]