=== jbicha is now known as Guest67757
=== yofel_ is now known as yofel
=== Guest67757 is now known as jbicha_
=== Guest69218 is now known as vibhav
=== chu_ is now known as chu
=== alazare619_ is now known as alazare619
=== tomreyn_ is now known as tomreyn
[10:47] <jtaylor> what is the reason gzip is not m-a foreign?
=== shnatsel is now known as SergeLion
=== root is now known as Guest88783
[12:28] <larsduesing> are "Bugs" which are more a wishlist-item ok in launchpad? or how to handle them?
[12:28] <larsduesing> (after reading https://dev.launchpad.net/BugTriage I'm not really sure..
[12:37] <penguin42> larsduesing: Feel free to come over to #ubuntu-bugs for bug triaging
[12:52] <badfox> i have .deb pkg and i wanna upload it into my launchpad
[12:53] <larsduesing> oh, sorry.. :)
=== SergeLion is now known as shnatsel
[12:58] <SpamapS> badfox: do you mean a PPA?
[12:59] <badfox> SpamapS,  No i am not its owner
[12:59] <badfox> well lemme arrange it
[12:59] <badfox> i have posted in #ubuntu-motu too
[13:04] <badfox> SpamapS,  https://launchpad.net/ubuntu/quantal/+source/accountsservice/ now its version of Ubuntu is accountsservice 0.6.15-2ubuntu9 but i have its latest version accountsservice_0.6.21-1_i386.deb with me and how can i upload it .
[13:08] <SpamapS> badfox: you are out of date, debian has 0.6.21-4
[13:09] <SpamapS> badfox: all of that Ubuntu specific delta may be important too
[13:10] <badfox> SpamapS,  No they have 21-4 patch
[13:10] <badfox> but  source belongs to 21-1
[13:10] <badfox> so deb came out as 21-1
[13:10] <badfox> please tell me how can i upload it
[13:12] <SpamapS> badfox: to Ubuntu?
[13:12] <badfox> yes
[13:12] <SpamapS> badfox: you need to explain why we can drop all of the extra Ubuntu changes
[13:12] <badfox> Sp4rKy,
[13:12] <badfox> Sp4rKy,  sorry wrong ping
[13:12] <SpamapS> badfox: try 'requestsync accountsservice'
[13:12] <Sp4rKy> :)
[13:13] <badfox> Sp4rKy,  Thank you :)
[13:13] <badfox> SpamapS,  i am new to all these
[13:14] <badfox> SpamapS,  actually in launchpad i have seen that version difference is there between Ubuntu and Debian version
[13:14] <SpamapS> badfox: but please look at the changelog of 0.6.15-2ubuntu1 through 0.6.15-2ubuntu9 to see what has been changed in Ubuntu
[13:15] <badfox> so after taking source from Debian with grab script i have created .deb for it
[13:15] <badfox> SpamapS,  ok so you saying that i cant upload it into Ubuntu but at least to my launchpad ?
[13:19] <badfox> SpamapS,  Not possible ?
=== quirkyquark is now known as izx
[15:51] <slangasek> SpamapS, stgraber, bdmurray, RAOF: bug #1017001 is looking pretty serious; in addition to the two duplicates there, I think this matches another bug that bdmurray identified the other day about mishandling of circular dependencies on upgrade.  Do any of you know of recent SRUs of packages in the base system that might explain what's happening here?
[15:51] <ubottu> Launchpad bug 1017001 in apt (Ubuntu Quantal) "package resolvconf 1.63ubuntu14 failed to install/upgrade: ErrorMessage: pre-dependency problem - not installing resolvconf" [Critical,Confirmed] https://launchpad.net/bugs/1017001
[15:51] <slangasek> bdmurray: ^^ this also means it would really be helpful if we could safely get apt clone data again for upgrades :/
[15:53] <slangasek> bug #969536 being the other bug
[15:53] <ubottu> Launchpad bug 969536 in apt (Ubuntu) "package xserver-xorg-video-vesa 1:2.3.0-7build2 failed to install/upgrade: ErrorMessage: dependency problems - leaving unconfigured" [Undecided,New] https://launchpad.net/bugs/969536
[15:53] <slangasek> not as recent, and may or may not be the same root cause
[15:55] <SpamapS> slangasek: looking now
[15:55] <slangasek> ok
[15:55] <SpamapS> slangasek: frankly, the flow of SRU's has been so intense, its hard to recall any single SRU :-P
[15:55] <slangasek> SpamapS: unfortunately I'm going afk now for most of the day... if you can think of anything relevant though, highlight me and I'll try to look this evening
[15:57] <SpamapS> slangasek: indeed, I will disappear soon too, but I'll dig around a bit
[15:57] <slangasek> fwiw looks like jenkins doesn't see this issue. https://jenkins.qa.ubuntu.com/view/Precise/view/Upgrade%20Testing%20Dashboard/
[15:57] <slangasek> there are some upgrade failures on the lucid-universe test, but those are unrelated (the upgrade itself doesn't fail)
[16:00] <SpamapS> slangasek: seems like its circular.. upstart depends on initscripts depends on upstart ...
[16:00] <stgraber> slangasek: hmm, can't recall verifying any SRU that introduced a dependency change except for lxc and lxc just started depending on cloud-utils or something like that, so quite unlikely to be the cause
[16:05] <stgraber> slangasek, SpamapS: wondering if these bugs are related to what we say in bug 937196 a while back (and never managed to figure out exactly why it's happening only in some cases and never on my machine...)
[16:05] <ubottu> Launchpad bug 937196 in ifupdown (Ubuntu) "10.04 LTS -> 12.04 upgrade failed: ifupdown depends on upstart and initscripts but they are not configured" [High,Confirmed] https://launchpad.net/bugs/937196
[16:15] <SpamapS> stgraber: its possible. Perhaps we should reason about it a bit and figure out which one should be pre-depends of the others
[17:03] <BetaArk> H!
[17:04] <IdleOne> BetaArk: This being the weekend and all it may take some time to get an answer. Just ask and be patient :)
[17:05] <BetaArk> Anyone can help? I'm trying to compile ubuntu-gtk3 to have the overlay-scrollbars on my Archlinux-setup. I got gtk2 working with the overlay-scrollbars, but not with gtk3. How can I compile the latest gtk3 version and enable the overlay-scrollbar?
[17:06] <BetaArk> IdleOne: Thanks :)
[17:11] <ScottK> BetaArk: Wouldn't that better be asked on some Archlinux channel?
[17:13] <BetaArk> ScottK: yes and no.. I want to ask if ubuntu still patches or patch diff in newer versions..
[18:55] <alazare619> anyone in here
[18:55] <alazare619> im trying to get a fresh chroot enviorment of ubuntu newest kernel in the chroot to compile into a iso
[18:56] <alazare619> i suppose i could net install into a vbox and rsync it out of it to a chroot on my main drive but that seems hackish at best
[18:56] <penguin42> alazare619: Do you know debootstrap?
[18:57] <alazare619> yea i tried to debootstrap but it fails with the argument precise
[18:57] <penguin42> what version are you running?
[18:58] <alazare619> precise
[18:58] <alazare619> sudo debootstrap --arch=i386 precise chroot
[18:58] <alazare619> it failed
[18:58] <alazare619> should i use pae instead of i386 since the new kernel is linux-image-generic-pae?
[18:58] <penguin42> hmm, I'm not sure I have a precise install to hand, my quantal version certainly has it
[18:59] <penguin42> no, I don't think that's any different for a debootstrap - but can you explain what you're trying to do with the kernel
[18:59] <penguin42> alazare619: Do you have /usr/share/debootstrap/scripts/precise ?
[18:59] <alazare619> iwell im trying to make a iso
[18:59] <alazare619> same way xubuntu kubuntu etc are all made
[19:00] <alazare619> from scratch wich requires a chroot
[19:00] <alazare619> ive used live-build wich is similar for debian based before no problems  it uses debootstrap as well
[19:00] <alazare619> i just want an iso wth just gnome-shell and my hand picked apps etc just for gnome-shell
[19:00] <alazare619> nothing else no unity no nothing else but gnome-shell
[19:01] <penguin42> alazare619: Hmm I don't know how the ISO builds work
[19:01] <alazare619> https://help.ubuntu.com/community/LiveCDCustomizationFromScratch
[19:04] <alazare619> ooo now it resolves with arch i386
[19:04] <alazare619> heh go figure
[19:17] <KeithW> Hello -- I maintain the mosh package in Debian. Would Ubuntu entertain a request to sync the "testing" version into precise (universe), or are sync requests (for new versions) only for not-yet-released series of Ubuntu?
[19:18] <infinity> KeithW: The latter.
[19:19] <infinity> KeithW: Also, have you noticed the build failure with gcc-4.7 in precise on ARM?
[19:19] <infinity> KeithW: I just saw that last night, haven't had a chance to look into it.
[19:19] <KeithW> Yes, it's a bug in glibc that there is (I think) an open bug in Ubuntu for. It's been fixed upstream.
[19:19] <infinity> KeithW: Oh, point me at the bug?  (I'm the eglibc maintainer)
[19:20] <KeithW> https://bugs.launchpad.net/eglibc/+bug/1016349/
[19:20] <ubottu> Launchpad bug 1016349 in eglibc (Ubuntu) "htons() returns wrong type on non-{i386,amd64} platforms" [Undecided,Confirmed]
[19:20] <infinity> KeithW: Thanks.
[19:20] <KeithW> Pleasure doing business with you!
[19:20] <infinity> KeithW: Why do you want the sync to precise, BTW?  For the security/DoS issues, or just for new shiny?  I'm sure we can backport the DoS fix.
[19:22] <KeithW> Just for the UI improvements and better error messages in 1.2, mostly. We didn't consider the repeated escape sequence issue to be a security-sensitive bug (and didn't do an emergency release on Debian either).
[19:22] <micahg> KeithW: if there are new features in mosh, you can request a backport to precise with the requestbackport script in ubuntu-dev-tools (also available in Debian)
[19:22] <infinity> (Which goes to precise-backports, not precise-updates)
[19:22] <infinity> KeithW: Kay, yeah.  That would qualify as "new shiny", and not SRU-worthy. :)
[19:23] <KeithW> The hassle is just that we get people with support requests for stuff that we made smoother in 1.2 (but they're running 1.1.3 from the precise repo). Would be more convenient for us if we could get everybody up to 1.2, but I understand that's not the way it works. :-) Thanks for explaining.
[19:23] <infinity> KeithW: And thanks for the pointer to the glibc bug.
[19:23]  * micahg has to try to process some of the backport backlog tonight
[19:24] <KeithW> Anytime.
[19:24] <micahg> KeithW: well, once it's in precise-backports, you can let people it's available there and that they can select the newer version in the Ubuntu Software Center (through a drop down) or their favorite package manager tool
[19:24] <micahg> *people know
[19:24] <infinity> And thanks for mosh, for that matter.  It's friggin' magic.  Love it.
[19:25] <KeithW> Awesome!
[19:27] <infinity> KeithW: One question, since I'm too lazy to read docs.  Can I get mosh to stop adding itself to my xterm titles?
[19:27] <KeithW> Yes, in mosh 1.2. :-)
[19:27] <infinity> Hah.
[19:27] <KeithW> Set the MOSH_TITLE_NOPREFIX environment variable.
[19:27] <infinity> Kay.
[19:27] <KeithW> Mosh 1.2 was the "oh shit now we have a zillion users and they all want things" release.
[19:27] <infinity> Hahaha.
[19:28] <infinity> Yeah, it got widely publicised around 1.1ish.  Not sure where I heard about it.
[19:28] <infinity> reddit via G+, or some other strange roundabout way.
[19:28] <micahg> FWIW, 1.1 got backported all the way to lucid
[19:28] <KeithW> Yeah, I think broder took care of all that.
[19:29] <infinity> Right, so, same thing can be done for the current precise package.
[19:29] <micahg> well, 1.2.2 is in quantal, but yes, it can go to whatever releases someone's willing to test it on
[19:29] <infinity> Err, I meant quantal.
[19:30] <KeithW> I think 1.2.2 is what will be in Debian (7?), and I'll be satisfied if that's what quantal ends up with. If we can get 1.3 out by then, that would be awesome, but not sure we'll make it. (I also don't know exactly when your freeze is.)
[19:31] <micahg> KeithW: we can always backport 1.3 later if it misses the freeze
[19:31] <KeithW> Ok.
[19:31] <infinity> KeithW: Our Debian Import Freeze (as in, when we stop autosyncing) is July 5, Feature Freeze is August 23.
[19:32] <KeithW> Hooboy. Well, we'll see.
[19:32] <infinity> KeithW: But if it doesn't make it for Q, it can always be in R, and get backported from there.
[19:33] <micahg> KeithW: feel free to use requestsync (from ubuntu-dev-tools) between Debian Import Freeze and Feature Freeze, and past feature freeze, if it's important, use requestsync -e and explain why it's important
[19:33] <KeithW> Thanks!
[19:34] <KeithW> I have to say, as a developer, Ubuntu is a half-step ahead of Debian as far as well-built tools go, and then after Debian there is maybe a step or two to Fedora, and then there is a wide, wide gulf for every other platform.
[19:34] <infinity> KeithW: Alternately, ping me, cause I actually use the thing.  You know, if self-service tools that report bugs annoy you. ;)
[19:34] <KeithW> I used requestsync just yesterday or the day before to get 1.2.2 in quantal and it went through maybe yesterday. Now I am high on my newfound capabilities. :-)
[19:35] <infinity> Hahaha.
[19:35] <infinity> That may have been coincidence, I think Colin did an autosync run recently.
[19:35] <infinity> (Unless someone replied to your bug, then not coincidence)
[19:35] <KeithW> It's not normally an 18 hour response time?? Too bad. :-)
[19:36] <infinity> Oh, it can be minutes.
[19:36] <infinity> But not always. :P
[19:36] <infinity> Real humans on the other end of the line and all.
[19:37] <infinity> stgraber: Good news.  Your natty-running Panda hates me as much as the buildds, so debugging this (or hackishly working around it) shouldn't be too much effort.  I hope.
[19:39] <stgraber> infinity: cool :)
[19:39] <infinity> Oh, crap.
[19:39] <infinity> I was using "fall back to gcc-4.5" as a workaround to avoid the new 64-bit atomics in newer GCCs.
[19:39] <infinity> But we haven't rebuilt gcc-4.5 for armv5t.
[19:40] <infinity> So, I'm generating v7 binaries.
[19:40] <infinity> Bother.
[19:40]  * infinity head -> desk.
[19:41] <toabctl> i'm getting a "bus error" when i try to load images with clutter on 12.10 . see http://paste.ubuntu.com/1058035/
[19:42] <alazare619> can someone get me a copy of the preseed file for xubuntu
[19:42] <alazare619> what they use for the packages etc
[19:43] <jbicha> KeithW: the bug was good as it pointed out that the Ubuntu diff wasn't needed anymore
[20:05] <infinity> Ugh.
[20:05] <infinity> Dearest mono, why is your build system so ridiculously fragile?  No love, Me.
[20:10] <ScottK> Think about the mischief you'd be up to if you weren't distracted by mono's build system.  Perhaps it's a win for society?
[20:10] <ScottK> ;-)
[20:12] <infinity> ScottK: But.  But.  But...
[20:13] <ScottK> :-)
[20:13] <ScottK> Have a nice day.
[20:14] <infinity> ScottK: Would calling you a jerk be a CoC violation?
[20:14] <ScottK> Only if it weren't true.
[20:14] <infinity> Heh.
[20:15] <ScottK> Gotta run.  I hope you get it sorted.
[20:15] <infinity> Probably not today, now that I've been slowed down by having to build a compiler to build my compiler.
[20:15] <infinity> Maybe I'll go do something socially destructive while I wait on that.
[20:15] <infinity> Just for you.
[20:17] <nigelb> all the love :)
=== yofel_ is now known as yofel
[20:43] <toabctl> filled a bug with a test program for the mesa stuff (https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1017243)
[20:43] <ubottu> Launchpad bug 1017243 in mesa (Ubuntu) "Program received signal SIGBUS, Bus error." [Undecided,New]
[22:51] <robert_ancell> infinity, can I get you to have a look at the vala-0.18 upload?  It's just a new version of vala, I haven't opened a bug for it though as it's pretty standard
[23:12] <robert_ancell> hang on, RAOF and StevenK are also members of ubuntu-archive, can I haz cheezburger?
[23:12] <robert_ancell> ^^^
[23:12]  * RAOF is not an AA; no NEW for you!
[23:13] <RAOF> Also, is the new vala going to generate different C code, making SRUs a tedious business of filtering out thousands of lines of mostly useless diff? </bitter>
[23:13] <robert_ancell> RAOF, https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages says ~archive-admin is fine, and https://launchpad.net/~ubuntu-archive/+members#active says you are in there!
[23:14] <RAOF> Ok, that wiki page lies; there are now a couple of members of ~ubuntu-archive who aren't archive admins, but *are* SRU people.
[23:14] <robert_ancell> RAOF, well, a logical build system wouldn't pointlessly distribute all that C code
[23:14] <RAOF> I'm also down with that.
[23:15]  * robert_ancell beats his head against (pointless in my opinion) paperwork
[23:15] <robert_ancell> StevenK, I see you hiding there.  Are you also going to claim immunity like RAOF
[23:15] <RAOF> StevenK is a valid victim :)
[23:16] <robert_ancell> why are we so scared of new packages?  If you've got main, you should be able to upload to dev releases and just pull them back if there's a problem
[23:17] <RAOF> Could we rebuild everything with the final vala as a prophylactic measure? I just recently looked at an SRU that had last been uploaded when a 0.15 vala was current, and there was a huge amount of noise vs the 0.16 that ended up in the precise archive.
[23:17] <RAOF> robert_ancell: At least copyright-review; it's not trivial to pull packages that shouldn't be distributed, because we've got a huge mirror network.
[23:18] <robert_ancell> RAOF, don't get me started on how pointless debian/copyright is...
[23:18] <robert_ancell> RAOF, don't you just ignore the .c files by default?
[23:19] <infinity> robert_ancell: Same packaging as the previous vala?  Like, can I trust you, or should I review this? :P
[23:19] <robert_ancell> infinity, it's pretty much a sed replacement from 0.16 to 0.18.  It's the same quality as any other point release update I'
[23:19] <robert_ancell> d make
[23:19] <RAOF> robert_ancell: If they were guaranteed to be unused by the actual build system, yes (and we just shouldn't ship the damn things in the tarball). But that's not always the case, is it?
[23:19] <robert_ancell> we kind of need a different category between versioned sources in new and really new packages
[23:20] <RAOF> That I can agree with.
[23:20] <robert_ancell> 'cause this is going to happen next cycle, and the cycle after, and ...
[23:20] <infinity> robert_ancell: Yeah, yeah.  It's not a big deal. :P
[23:20] <robert_ancell> RAOF, oh yeah, it's a bit of a review nightmare then.  Can we automatically strip them out of the tarballs somehow?
[23:21] <infinity> robert_ancell: I assume there will be things in main {build-,}depending on this soon?
[23:22] <infinity> robert_ancell: Or should I dump it in universe for now?
[23:22] <robert_ancell> infinity, yep, if you can go straight to main that's great (baobab needs it now), or I'll do the MIR next
[23:23] <infinity> No need for an MIR for new versions of already-mainy stuff.
[23:23] <infinity> Off to main it goes.
[23:23] <infinity> Is there any hope that we'll be able to completely transition and dump all the old versions out? :P
[23:23] <robert_ancell> infinity, oh, so we could have done that for libpwquality?
[23:23] <RAOF> robert_ancell: Can you strip them in the debian/rules clean target?
[23:23] <robert_ancell> infinity, all of GNOME 3.6 should build with vala-0.18
[23:24] <robert_ancell> so practically yes
[23:24] <infinity> robert_ancell: libpwquality didn't have a previous version in main...
[23:24] <robert_ancell> ok
[23:24] <infinity> (But sure, if the MIR comes before the NEWing and is approved, there's no reason for an interim "dump it in universe first" step)
[23:24] <robert_ancell> ok, I'll do it that order next time
[23:25] <robert_ancell> RAOF, I guess we could
[23:25]  * infinity sees vala 0.14, 0.16, and now 0.18 in main and sighs.
[23:25] <infinity> And valac is still from 0.14
[23:26] <robert_ancell> infinity, it should be in the alternatives system now
[23:26] <robert_ancell> and we can probably drop 0.14 or are very close to being able to do so
[23:26] <jbicha> ooh, you could sync vala-0.16 to get 0.16 as the default vala
[23:27] <infinity> jbicha: I'm assuming that would also require a new vala-0.14 that no longer generates the valac package?
[23:27] <robert_ancell> jbicha, hey, I was confused by the alternatives numbering - if you know what we should be doing please do so
[23:30] <jbicha> infinity: it looks like Debian didn't bother doing that, but it's probably a good idea
[23:30] <jbicha> robert_ancell: I don't know what the numbers mean
[23:31] <robert_ancell> jbicha, I think they're priorities, but I don't know how we pick them.  We should probably copy Debian, but they're standardising on 0.16 for their release and we want 0.18
[23:32] <jbicha> I think we still want 0.16 as default until 0.18 settles a bit more though
[23:32] <infinity> I'd recommend using the version (minus decimal) as the default priority (so, 14, 16, 18, etc), and then make your selected default 50 or 100 or something.
[23:32] <robert_ancell> infinity, good idea
[23:32] <infinity> So, if you wanted 16 as the default, you'd have 14, 100, 18.
[23:33] <infinity> But you could also do the gcc-defaults/python-defaults route and have valac be generated from a separate source package that just drops symlinks in instead.
[23:33] <robert_ancell> damn, the MIR team is tiny.  And all outside my timezone I think
[23:33] <infinity> Obviously incompatible with an alternatives system, though.
[23:33] <infinity> doko_: Hey, add me to ~ubuntu-mir already. ;)
[23:34] <robert_ancell> bug 1017285
[23:34] <ubottu> Launchpad bug 1017285 in libpwquality (Ubuntu) "[MIR] libpwquality" [Wishlist,Triaged] https://launchpad.net/bugs/1017285
[23:59] <infinity> robert_ancell: There, and your binaries are all through NEW as well now.  Cheers.
[23:59] <robert_ancell> infinity, thanks!