[02:28] <mesquka> Hi
[03:50] <darkxst> chrisccoulson, have you considered pulling in mozjs188(i.e. firefox 17esr spidermonkey engine)?
[03:51] <micahg> darkxst: there hasn't been an upstream release yet, when that happens, we can look at getting it into raring
[03:53] <darkxst> micahg, the delta between upstream source and standalone release is just a couple of patches to change version numbers and library names
[03:53] <micahg> darkxst: yeah, but there might be changes before release which could result in SONAME changes which can be messy
[03:54] <darkxst> micahg, we can control the sonames tho http://people.ubuntu.com/~ricotz/mozjs/
[03:54] <darkxst> the only changes to the 17 branch should be security updates anyway
[03:54] <micahg> darkxst: control? yeah, but hacking around upstream breakage isn't fun
[03:55] <darkxst> well its not like they will landing api changes into an esr branch
[03:56] <darkxst> and if they do an official release, it wont be anymore than the 3 patches in the above link
[04:06] <darkxst> micahg, mozilla certainly dont seem to keen to invest time in providing great standalone releases anymore
[04:08] <darkxst> I ported gnome-shell/gjs to js188 and it solves basically all the issues with leaks and GC deadlocks
[04:13] <darkxst> looking at the other rdepends, no one else (apart from gjs uses custom bindings) so should all be trivial to port
[04:13] <darkxst> 60% a compatibility.h added to mozjs, the other 40% some sed magic
[04:23] <MrWGW-> astraljava: Studio is an official flavor from what I understand
[04:23] <MrWGW-> but beyond that, Canonical as the owner of the Ubuntu trademark can stop people from using it
[04:23] <MrWGW-> beyond that, they could if they wanted to stop people from using 'buntu'
[04:23] <MrWGW-> and I have zero problems with this
[04:23] <MrWGW-> if I do a cinnamon flavor, I'll call it cinnabuntu in all probability unless they let me call it Ubuntu Classic or Ubuntu Retro or something
[04:24] <MrWGW-> btw I'm suprised they didn't crack down on some of the weirder unofficial flavors like Ubuntu Satanic Edition
[04:24] <MrWGW-> there is a school of thought in corporate identity law that favors cracking down on anyone coming even close to infringing your trademark, because if you don't, the fear is that other companies might be able to say you're not defending it, and that its become a generic word
[04:25] <MrWGW-> this happened most famously with the word 'Cola'
[04:25] <MrWGW-> so I don't mind at all Ubuntu being protective about its brand identity
[04:25] <MrWGW-> at one time before I got into IT back in 2007, I was a graphics designer working in the world of corporate identity, at Interbrand
[04:25] <MrWGW-> I played a minor role in the development of AT&T's identity and in some airline branding and other things
[04:25] <MrWGW-> its fun stuff
[04:26] <darkxst> MrWGW-, don't know if I quite like their taste, but they have some amazing artwork in there
[04:26] <MrWGW-> Canonical does a much much better job at branding than the vast majority of open source projects, Ubuntu and redHat have had the most professional investments in that
[04:26] <MrWGW-> darkxst: Ubuntu's graphics are beautiful, but beyond that the Ubuntu font is a spectacular achievement in typography
[04:26] <slangasek> there's a standing public trademark policy that says you can use the ubuntu trademark for variants as long as they're built from the Ubuntu repository, official flavor or not: http://www.ubuntu.com/aboutus/trademarkpolicy
[04:26] <darkxst> MrWGW-, the satanic mob
[04:27] <slangasek> (Ref: "Remix")
[04:27] <MrWGW-> I really don't have any gripes with the Ubuntu project, I like its technical direction more than ny of the other major distros
[04:27] <MrWGW-> slangasek: right, I want to do a remix based on Cinnamon, which I love
[04:27] <MrWGW-> my desire is to use the Debian Cinnamon package, and integrate it with the beuatiful Ubuntu font, and the same desktop background that the contemporary mainline Unity release would feature
[04:27] <slangasek> Canonical has in fact stopped folks from using the Ubuntu name for things that aren't built from the Ubuntu archive - e.g., "EasyPeasy" which tried to call itself Ubuntu EeePC for a while
[04:27] <MrWGW-> btw what would be even better would be if Ubuntu just would reach out to Clement LeFebvre and work with him on merging the Unity and Cinnamon projects
[04:28] <MrWGW-> slangasek: and that's legitimate and I have zero problems with it, they're more than generous as it is
[04:28] <MrWGW-> IMO Cinnamon is more usable on conventional systems with a mouse and keyboard, whereas I suspect, but haven't had a chance to confirm, that Unity would be superior on tablets and phones
[04:29] <MrWGW-> and IMO it just doesn't make sense for there to be two separate competing GNOME 3 alternatives
[04:29] <MrWGW-> at some point this is probably going to have to happen in one form or another
[04:29] <MrWGW-> either Unity will have to get somewhat better desktop usability on conventional systems, or else some accomodation will have to be reached to stop the bleeding to Linux Mint
[04:30] <MrWGW-> and IMO the whole point of hte Unity project should be, well, Unity
[04:30] <slangasek> Unity is not trying to be a "GNOME 3 alternative"; it has its own consistent vision for the desktop (and other form factors)
[04:30] <MrWGW-> slangasek: its becoming painfully obvious that that vision is not entirely successful on conventional systems
[04:30] <MrWGW-> remember Unity was originally intended for netbooks
[04:31] <MrWGW-> many aspects of its design are optimized for systmes with small screens
[04:31] <MrWGW-> and lead to extreme pain on larger monitors in my experience
[04:31] <MrWGW-> now imagine if you could just click a button in Unity, and get a Cinnamon style Win95ish UI
[04:31] <MrWGW-> that would just instantly silence all Unity detractors
[04:31] <darkxst> MrWGW-, I am very happy with the Gnome3 vision - aka gnome-shell
[04:31] <MrWGW-> darkxst: some people are, but some people aren't, hence the surge in popularity that alternatives are getting
[04:32] <MrWGW-> and IMO Unity is better than GNOME 3
[04:32] <MrWGW-> I have used unity on Netbooks and it shines on that form factor
[04:32] <MrWGW-> and I suspect it will shine on tablets
[04:32] <MrWGW-> and btw if an Ubuntu phone comes out this year, I'll buy it
[04:32] <MrWGW-> if an Ubuntu TV comes out this year, I will buy it
[04:32] <MrWGW-> in fact...if its possible for me to build my own Ubuntu "TV" by cobbling together a small box and a big screen TV with an HDMI cable
[04:32] <MrWGW-> I'm going to do that
[04:33] <MrWGW-> you guys ought to put up a tutorial on how to roll your own Ubuntu TV system
[04:33] <darkxst> MrWGW-, I supect there are far more happy gnome3 users, than the odd few that right all the bad blogs
[04:34] <MrWGW-> well, I go to the San Fernando Valley Linux User Group, and the Simi Conejo Valley Linux User Group
[04:34] <darkxst> s/right/wright/
[04:34] <MrWGW-> the latter is known for its orchestration of the annual SCALE conference in LA
[04:34] <MrWGW-> which is one of the premiere Linux conferences
[04:35] <MrWGW-> at those two LUGs, I don't know of a single user, out of about 60 guys overall, ranging from n00b to expert, from an age of 17 for the youngest member to 80 something for the oldest, who is running GNOME 3
[04:35] <MrWGW-> a few of them are running Unity, not many
[04:35] <MrWGW-> also at SCALE last year, I didn't see anyone outside of the GNOME booth who was using GNOME 3 either heh
[04:35] <MrWGW-> now a lot of people are using KDE 4 and enjoying it, and a lot of people are using other desktops
[04:45] <darkxst> MrWGW-, why would I care what other people are using? I enjoy gnome-shell so I use it!
[04:46] <darkxst> and other than submitting the odd patch upstream, I have no affiliation with gnome
[04:46] <MrWGW-> darkxst: indeed so, I'm just saying, its not as well received as you think
[04:46] <MrWGW-> I myself still use Windows 98 on some gaming boxes
[04:46] <MrWGW-> I've taken some flak for that, so I'm the last person who would object to someone else's personal OS preferences
[04:51] <darkxst> yeh I know some people don't like it, and mostly that is due to the big learning curve, of completely different interface (and/or the early releases really being of alpha quality at best). But I also the supsect and this is just speculation, that the noise from the haters doesnt really correspend to the happy users
[04:54] <darkxst> I also suspect people also read the blogs from the haters, and then don't really give it a chance themselves
[05:48] <mesquka> Well, direct people to my blog, lets see if they try ubuntu then?
[05:57] <pitti> Good morning
[05:58] <pitti> OdyX: cups 1.6.1 in exp> congrats, great work!
[05:58] <pitti> tkamppeter__: ^ can we sync again, or does the Ubuntu package have a delta?
[06:06] <pitti> tkamppeter__: oh, we did already, nevermind; great!
[09:01] <Laney> quite a nice changelog there ;-)
[09:48] <Laney> tkamppeter: looks like you miss a (Breaks/)Replaces cups-daemon -> cups in the new cups?
[09:49] <Laney> for the manpages that weren't moved in 0ubuntu15
[10:04] <xnox> Laney: ++
[10:04] <Laney> suspect quite a few will see that this morning :P
[10:06] <Laney> -o Dpkg::Options="--force-overwrite" FTW
[10:06] <Laney> ::=?
[10:07]  * xnox did dpkg -i cups-daemon & then continued dist-upgrade.
[10:08] <Laney> meow
[10:20] <OdyX> Laney: that's fixed in 1.6.1 but not widely enough, see the git repository.
[10:20] <geser> Laney: bug #1099242
[10:20] <OdyX> Laney: /win 30
[10:20] <Laney> OdyX: righto
[10:20] <OdyX> damn.
[10:20] <Laney> 30? #debian-qa? NO.
[10:22] <OdyX> Laney: you can (get tkampetter) upload what's in git master branch to Ubuntu if that's urgent. I'd prefer to hold that release a tad more as I'm waiting for some translation updates.
[10:23] <Laney> OdyX: I suppose breakage like this in development releases isn't OMGcritical
[10:23] <cjwatson> It should be fixed ASAP
[10:23] <OdyX> Laney: 6 duplicates still.
[10:23] <cjwatson> The development release is not supposed to have upgrade errors (for long)
[10:23] <Laney> but people will continue to report it, so it should be fixed relatively soon
[10:24] <OdyX> Laney: I can generate a changelog for you, wait a sec
[10:30] <Laney> sure, I'll upload that
[10:30] <OdyX> Laney: upload to ppa in process
[10:30] <Laney> k
[10:37] <OdyX> Laney: pushed there https://launchpad.net/~odyx/+archive/printing/
[10:38] <geser> could someone copy/upload the version of libimobiledevice from quantal-updates to raring please? currently the version in raring is smaller than quantal-updates
[10:43] <cjwatson> geser: copied to raring-proposed
[10:45] <Laney> there's also chromium-browser kdegames in that situation (as well as some linux-*)
[10:46] <cjwatson> Yeah, I'm not touching chromium-browser :)
[10:46] <cjwatson> kdegames doesn't have newer source in quantal-updates than raring - nor do any linux-* that I can see
[10:46] <cjwatson> I don't tend to copy from -proposed routinely
[10:47] <cjwatson> People can do so manually if they want
[10:47] <Riddell> Laney, cjwatson: kdegames is now made from meta-kde
[10:47] <Riddell> I'll remove the source package
[10:48] <Laney> was looking in proposed too, indeed
[10:49] <cjwatson> Riddell: Not all its binaries appear to be superseded?
[10:50] <Riddell> cjwatson: mm so I see, I'll look into that
[10:50] <cjwatson> Riddell: Also I think it'd be a good idea to let meta-kde reach raring before you start removing superseded things
[10:50] <cjwatson> (Since removals don't go through proposed-migration, I tend to be very cautious about them)
[10:51] <Riddell> doh, too late
[10:51] <Riddell> hmm I don't see what's holding meta-kde
[10:52] <Riddell> oh, something on arm
[10:52] <mesquka> any program that runs right is obsolete
[10:54] <cjwatson> Riddell: ksudoku and kubrick aren't even attempted on armhf
[10:55] <Riddell> I wonder whyever not
[10:57] <Riddell> oh it's in the packaging, weird
[10:57] <Riddell> uses gl I guess
[10:58] <cjwatson> So either kdegames needs to become Architecture: any so that it can depend on them only on some architectures, or you need to drop those to Recommends
[11:04] <Laney> OdyX: Uploaded, thanking you. :-)
[11:08] <OdyX> Laney: np.
[11:20] <mlankhorst> infinity: can you review the mesa sru for precise?
[12:21] <tjaalton> cjwatson: huh, the new precise daily image is still 22MB bigger with just the backport stack on it, compared to .1
[12:22] <cjwatson> I expect there are other things different
[12:22] <cjwatson> Will be doing some analysis this week
[12:38] <mlankhorst> bbiab
[12:41] <xnox> tomorrow is my "logan day", I mean "patch piloting"
[12:42] <Laney> good job dholbach isn't around - 107 items…!
[12:46] <tjaalton> and only a handful of people can clean the queue up from bugs that shouldn't be there
[12:47] <tumbleweed> anyone can ask to join ubuntu-sponsors
[12:49] <tjaalton> yes please
[12:50] <tumbleweed> TheMuso: ^
[12:53] <tjaalton> hmm it was some other team where there is <10 members and >40 applied
[12:56] <xnox> tjaalton: ubuntu-reviewers?!
[12:56]  * xnox is still waiting to get into that one
[12:59] <tjaalton> xnox: that's the one yeah. and the numbers are 24/43 but still :)
[12:59] <tjaalton> only two admins :/
[13:06] <pitti> Laney: LibO and bluez-gstreamer also still use 0.10; is there any migration plan for those?
[13:07] <Laney> I have to figure out what's going on with those two
[13:07] <pitti> Laney: oh, and libpurple; although that by itself smells rather obsolete; do we actually still need that, or do we have sufficiently many telepathy plugins now?
[13:07] <Laney> possibly -haze can be dropped indeed
[13:07] <pitti> ISTR that someone mentioned that at UDS
[13:07] <pitti> (dropping purple)
[13:07] <pitti> that's AIM, Yahoo, Gadu-Gadu, and ICQ mostly
[13:09] <hrw> anyone with SRU power? I lost hope for bug 1085392 ;(
[13:10] <pitti> Laney: hm, I still don't see native telepathy plugins for those, at least not packaged ones?
[13:10] <pitti> meh
[13:11] <Laney> at least for ICQ/AIM you can use XMPP
[13:11] <pitti> Laney: urgh, and sessioninstaller -> python-gst0.10, but that can hopefully use GI now
[13:11] <pitti> Laney: oh, nice
[13:12] <Laney> though I'm not sure if there's UI to make it easy
[13:12] <pitti> account-plugin-icq depends on -haze
[13:12] <pitti> but testing
[13:13] <Laney> the plugins probably use haze indeed; I mean that you can set it up as an XMPP connection yourself
[13:14] <Laney> not that I've verified this - haven't used ICQ in many years
[13:14] <pitti> at least not with the accounts tool; once I uninstall accounts-plugin-icq, gst 0.10, and -haze there is no GUI for adding ICQ or MSN
[13:14] <pitti> Laney: yeah, same here
[13:14] <Laney> that's what I expected
[13:15] <Laney> but I can imagine entries which automatically populate the correct XMPP information
[13:15] <Laney> alternatively there is https://developer.pidgin.im/ticket/15299
[14:03] <zul> mterry:  hey so testrepository should be fine now
[14:03] <mterry> zul, ok, let me look
[14:15] <lamont> where did we hide the switch to allow/disallow guest logins via lightdm, I wonder.
[14:16] <mterry> lamont, /etc/lightdm/lightdm.conf
[14:16] <mterry> zul, so bug 1098605 can be marked fix released it looks like
[14:16] <lamont> right.  and by default it's allowed, so it wasn't mentioned there.  thanks mterry
[14:16] <zul> mterry: yeah it was missing the python-tz deps
[14:17] <mterry> zul, thanks!
[15:10] <coalwater> hello all
[15:11] <coalwater> there's this tool i usually see on omgubuntu, they create wireframes for mockups and stuff, what's the tool used for that ?
[15:12] <hallyn> zul: how did kvm used to get the custom version #? I don't see anything in debian/control
[15:12] <hallyn> (i.e. it's 1:84+dfsg-0ubuntu16+1.2.0+noroms+0ubuntu7 in raring right now)
[15:12] <zul> hallyn: no idea
[15:14] <hallyn> Daviey:  ^ do you know?
[15:15] <geser> coalwater: I'm not sure but it could be http://www.balsamiq.com/products/mockups
[15:16] <coalwater> geser: yea it looks like it, but it's not free?
[15:17] <geser> coalwater: no :(
[15:17] <coalwater> geser: is there a free alternative?
[15:18] <coalwater> geser: i found this  http://mashable.com/2010/07/15/wireframing-tools/
[15:26] <Daviey> hallyn: soryy, dunno
[15:59] <micahg> infinity: your dkms headers change had the result of removing the headers from the running kernel on my system
[16:00] <cjwatson> Only, presumably, because you used autoremove
[16:01] <micahg> well, the packages are marked as auto-installed
[16:01] <micahg> I'm using aptitude...
[16:01] <cjwatson> It would surprise me if this were the only instance of this kind of problem
[16:01] <micahg> it didn't do it yet, I'm looking at the screen
[16:01] <micahg> well, thanks to dkms, all old headers were kept until now
[16:02] <cjwatson> What I mean is I don't think this is necessarily v-failed.
[16:02] <cjwatson> (Because I don't think it is in general wise to blindly trust autoremovals.)
[16:03] <micahg> well, I guess it wouldn't affect most people that just use update-manager
[16:03] <cjwatson> There ought to be something that ensures that current kernel image/headers remain installed, certainly.  I don't think it should be dkms.
[16:03] <cjwatson> It arguably ought to be aptitude itself in this case.
[16:04] <cjwatson> Does aptitude not honour /etc/apt/apt.conf.d/01autoremove-kernels, or was that not yet in precise?
[16:04] <micahg> sure, but kernel images aren't marked as auto-installed, whereas headers are
[16:04] <micahg> not in precise
[16:04] <cjwatson> Ah, autoremove-kernels doesn't list headers, either
[16:04] <cjwatson> It probably should
[16:04] <micahg> or apparently in quantal
[16:04] <cjwatson> slangasek: ^-
[16:05] <cjwatson> micahg: I don't think it's sensible for us (collectively) to rely on dkms doing this, in any event.
[16:05] <micahg> cjwatson: oh, I agree entirely, but until it's fixed properly, this seems to be the wedge holding it together
[16:06] <cjwatson> We can't drop the dkms change because we have no other way to get the 12.04.2 images back within size limits.
[16:09] <micahg> cjwatson: since we have an extra week, isn't there time to get the proper fix backporteD?
[16:09] <micahg> sorry, 2 weeks
[16:09] <cjwatson> That's part of why I highlighted slangasek; but the extra two weeks are for more QA, not really for more fixes ...
[16:10] <cjwatson> I'm sure some are possible but only where really necessary
[16:11] <micahg> well, this would prevent a class of breakage (I'm wondering what unattended upgrades does here)
[16:11] <cjwatson> I'm going to wait for infinity or slangasek to comment.
[16:11]  * micahg runs off, will check backscroll later
[16:34] <wookey> is there a kernel dev irc channel or should I just ask here?
[16:34] <ogra_> there is #ubuntu-kernel
[16:34] <wookey> I want to know what of the kernel libfoo-dev build-deps are for host arch and which for build arch
[16:44] <pitti> cjwatson, infinity, stgraber: could one of you please set a migration blocker for pygobject?
[16:45] <cjwatson> pitti: done
[16:45] <pitti> cjwatson: thank you
[16:45] <hallyn> zul: so kvm has beena  transitional pkg since lucid.  i guess i can just remove it right?
[16:46] <zul> hallyn: in theory
[16:47] <infinity> hallyn: Yes.
[16:48] <infinity> hallyn: Assuming there are reasonable relationships in place that make an upgrade remove the old one.
[16:50] <infinity> cjwatson: kernel autoremove doesn't need to list headers because kernel images now suggest headers, which keeps them installed.  This works in raring.  None of this is backported to precise yet, though.
[16:51] <cjwatson> Suggests keeps things installed?  Is that new.
[16:51] <cjwatson> ?
[16:51] <infinity> micahg: If dkms was the only thing keeping your headers installed, then you didn't have metapackages installed?
[16:51] <infinity> cjwatson: It seems to DTRT here.
[16:52] <ogra_> suggests is the new recommends ?
[16:52] <infinity> (base)adconrad@cthulhu:~$ dpkg -l linux-\*[0-9]\* | awk '/^i/ {print $2}'
[16:52] <infinity> linux-headers-3.7.0-7
[16:52] <infinity> linux-headers-3.7.0-7-generic
[16:52] <infinity> linux-headers-3.8.0-0
[16:52] <infinity> linux-headers-3.8.0-0-generic
[16:52] <infinity> linux-image-3.7.0-7-generic
[16:52] <infinity> linux-image-3.8.0-0-generic
[16:52] <infinity> linux-image-extra-3.7.0-7-generic
[16:52] <infinity> linux-image-extra-3.8.0-0-generic
[16:52] <infinity> ^-- On a machine where I always autoremove after upgrade.
[16:54] <infinity> micahg: Or do you mean your running kernel wasn't the latest installed?  In which case, the dkms change would have changed nothing, since it depended on the metapackage.
[16:54] <infinity> micahg: It was always the case that the situation in precise was you'd only keep latest-installed headers on autoremove.  This should be fixed, but the dkms change shouldn't have made the situation any different.
[16:59] <infinity> I was on precise when I reported https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1029730
[16:59] <infinity> So, yeah, autoremove always removed everything but the latest.
[16:59] <infinity> This isn't new.
[17:24] <hallyn> infinity: so 'proper relationship' top make kvm go away, would be having another package break+replace it?
[17:24] <hallyn> or do i have to do more to make the binary package go away?
[17:33] <ogra_> grr
[17:33] <ogra_> so i had disabled all my SD card partyitions from showing up in the launcher ... with the last upgrade all of them suddenly show up again
[17:34] <infinity> hallyn: You might actually need a P/C/R relationship to make it go away completely.  I don't recall if things changed much with the addition of breaks.
[17:34] <xnox> hallyn: i see packages still dependind/recommending kvm, those should be fixed.
[17:35] <xnox> e.g. nova-compute-kvm, utah, possibly others.
[17:35] <infinity> xnox: That's a non-problem if something still provides kvm (assuming the dependency isn't versioned)
[17:35] <infinity> Still should be fixed anyway, but yeah.
[17:36] <xnox> infinity: well qemu-kvm does "Provides: kvm"
[17:37] <infinity> xnox: Indeed.
[18:03] <hallyn> xnox: infinity: good point, i'll file bugs agaisnt packages depending on kvm in the meantime
[18:12] <hallyn> stgraber: can qemu now be added to the ubuntu server set?  (even though it failed to upload?  but if it goes into server set i can push the fix at http://people.canonical.com/~serge/qemu-conflict-kvm.debdiff :)
[18:21] <stgraber> hallyn: added. It should stay in there until at least the next automated packageset update by cjwatson, but hopefully by then it'll be seeded and so won't be removed
[18:23] <cjwatson> Please make sure it's seeded ASAP then as I'm due another full update
[18:25] <stgraber> I guess it'll be as soon as it produces binaries
[18:25] <stgraber> (basically replacing the qemu-kvm/qemu-linaro sources)
[18:38] <psusi> ok, so if a package is synced from debian, and since quantal there has been only one new version that is a SRU like cherry pick bug fix due to debian also being in freeze, would it be appropriate to just request it be synced back into quantal?
[18:40] <cjwatson> psusi: No, if nothing else we always want to rebuild for older distributions
[18:40] <cjwatson> It can be an identical source package apart from the changelog if you like, but it'll need a different version
[18:40] <hallyn> stgraber: thanks, lemme see if i can upload then :)
[18:41] <psusi> cjwatson: I thought requestsync could copy the source but rebuild the binaries?
[18:42] <hallyn> stgraber: can i impose on you to quickly look at  http://people.canonical.com/~serge/qemu-conflict-kvm.debdiff (46 line debdiff) to make sure i got that right?
[18:42] <cjwatson> psusi: That's disallowed by the archive because binary file names will clash.
[18:43] <cjwatson> You can only do a copy-and-rebuild between *different* archives.
[18:43] <psusi> ahh
[18:45] <stgraber> hallyn: I'm never sure when to use Breaks and when to use Conflicts in such cases, though as kvm is a transitional package, I don't think it really makes any difference anyway, the rest look good
[18:45] <hallyn> stgraber: thanks, will push then.  just don't want tomake any changes that end up making future package stuff even more complicated
[18:45] <maco> i think conflicts is "they both have the same filepath included"
[18:46] <cjwatson> There are a few possible reasons for Conflicts - policy pretty much enumerates them
[18:46] <cjwatson> http://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts
[18:48] <psusi> so if I start with the raring version, should I add a new changelog entry with the oldver.1 or modify the version number of the existing entry?
[18:49] <cjwatson> I would do the latter, so that the diff from <currently in quantal> to <your new package> looks like an ordinary SRU upload.
[18:49] <psusi> ok
[18:49] <cjwatson> Credit appropriately, of course.
[18:49] <psusi> it's me either way ;)
[18:50] <cjwatson> ok
[18:50] <psusi> ohh, and I need to say quantal-proposed right?  not just quantal?
[18:52] <cjwatson> Either works
[18:52] <cjwatson> quantal will be mapped to quantal-proposed
[18:53] <psusi> wait, why is there not a name conflict going the other way?  if version 1 is built in quantal, then when raring opens, it's still version 1, but all the binaries are rebuilt arent they?
[18:53] <maco> dont think so
[18:53] <maco> not unless an actual full-archive rebuild happens
[18:53] <maco> by default, the old binaries are just copied
[18:54] <psusi> ohh... I thought they got rebuilt when a new cycle started
[18:54] <cjwatson> maco is correct
[18:54] <hallyn> stgraber: oh, bug 1099155 - that looks like the same network manager bug screwing up lxc-net right?  do you have an open bug for that?
[18:54] <cjwatson> They don't, it'd take ages and cane mirrors for not much benefit
[18:55] <stgraber> hallyn: yep, that looks like it. I don't think I saw a bug specific to lxcbr0, so I guess we can use that one from now on.
[18:55] <stgraber> cyphermox: ^
[18:56] <psusi> ok, and the merge shold be proposed into ubuntu/quantal/gparted right?
[18:56] <cjwatson> Probably easier to just attach a debdiff to a bug
[18:56] <cjwatson> UDD is a bit patchy for SRU handling
[19:32] <cyphermox> stgraber: thanks.
[19:32] <cyphermox> but right now, trying to figure out something funny with openssl
[19:34] <cyphermox> stgraber: cjwatson: not sure if it's openssl really because it doesn't seem like it changed in the right timeframe but here the wpa enterprise network can't be successfully authentified, i get TLS errors for the certificate
[19:35] <CodeRed> I'm getting an error on installing ubuntu through wubi " cannot download the metalink and therefore the iso " how to get through this ?
[19:36] <coalwater> i'm looking for a python project (preferrably one done with gtk (has gui) or something) that's looking for developers, and it would be great if there's a mentor who'll help me with the developing, i already am comfortable with bzr i just want to get used to python more, and learn doing gui apps
[19:39] <stgraber> cyphermox: NM is connecting fine to my network here, though arguably my certificate is self-signed and I told NM to ignore it :)
[19:39] <cyphermox> yeah
[19:40] <cyphermox> this one has a proper cert; but i did say to ignore the fact that I didn't pass a file
[19:40] <cyphermox> I think it's ignoring the fact that there is no ca passed rather than ignoring whether the CA matches ;D
[19:41] <cyphermox> http://paste.ubuntu.com/1531834/
[19:45] <cyphermox> stgraber: yeah, I think it's just that it's not ignorin the right thing; I'll have to go get the CA first to check
[19:45] <jbicha> how did the audit package migrate without readahead-fedora being rebuilt?
[19:46] <jbicha> http://people.canonical.com/~ubuntu-archive/nbs.html
[19:48] <stgraber> cyphermox: though that reminds me, I tried connecting to the Eduroam wireless at the ETS over the weekend and wpa_supplicant wasn't too happy about it
[19:49] <stgraber> cyphermox: but I don't see any mention of openssl in my syslog, so that was another problem
[19:54] <cyphermox> yeah, I think it's likely to be exactly the same issue
[19:54] <cyphermox> unless the UQAM wifi is broken, which is within the realm of possibility
[20:09] <slangasek> cjwatson: as for autoremove-kernels listing headers, I originally believed the current behavior was by design on the grounds that old kernels you're keeping around for recovery aren't going to need modules newly built for them; but IIRC infinity persuaded me that we should keep the headers too, this just isn't implemented yet
[20:10] <slangasek> infinity, cjwatson: er, suggests is certainly not *supposed* to have any effect on autoremoval
[20:12] <infinity> slangasek: Well, it definitely does.  Check your raring machines.  They all have headers matching all installed kernel images.
[20:13] <infinity> slangasek: And I'm not sure why it shouldn't have an effect.
[20:13] <slangasek> because suggests are *not* auto installed
[20:13] <slangasek> so not auto-removing suggests would be asymmetric and broken
[20:13] <infinity> slangasek: Unless you ask them to be.
[20:13] <slangasek> which we don't do
[20:14] <infinity> slangasek: No, but a human can.  And the auto* DB has no way to discern HOW you installed something.
[20:14] <infinity> (Or, rather, what relationship pulled it in)
[20:14] <infinity> So, if you install with suggests and recommends, and foo recommends bar, while baz suggests it, removing foo shouldn't remove bar.
[20:14] <slangasek> infinity: er, nobody in their right mind installs with suggests
[20:15] <infinity> I still don't see how the behavious is wrong.
[20:15] <slangasek> you're right that the auto* db doesn't know what relationship pulled it in; but *I* know suggests aren't pulling anything in here
[20:15] <infinity> It's non-obvious to me that I could silently lose functionality in some application because a suggests is removed when something else that depended on it is removed.
[20:15] <infinity> Anyhow, it appears to function the way I think it should currently. :P
[20:16] <infinity> So, I suspect I'm not alone in this belief.
[20:16] <infinity> Or, working the problem the other direction.  If I use a friendly frontend like dselect or aptitude that offers suggests when I install something, and I opt to install those suggests...
[20:16] <infinity> Should it mark them auto, or manual?
[20:16] <slangasek> manual
[20:16] <infinity> In your world, they'd have to be manual.
[20:17] <slangasek> and it does
[20:17] <infinity> But then the suggests stay installed even if the reason I installed them is removed.
[20:17] <infinity> Which is bizarre when we've put effort into making sure hard deps are removed, but we leave suggests as cruft?
[20:18] <slangasek> because when you manually select it for installation in the frontend, that's manual installation
[20:18] <infinity> Well, I don't doubt that's how the frontends currently work.
[20:18] <infinity> But I'd contend that in a drill-down menu for recommends/suggests, what I'd really want is "install these 5 of the 7 you're offering me, but mark them auto so they go away if I remove the parent".
[20:20] <infinity> Anyhow, for the kernel autoremoval case, we can also just blatantly ignore what the tools are or aren't doing as far as who believe the features should work how, and add linux-headers-$(abi) to the no-auto-remove list. :P
[20:20] <infinity> Cause it won't do any harm either way.
[20:21] <slangasek> my point is that if the headers are being kept installed, it's /not/ because of the suggests
[20:22] <infinity> slangasek: It pretty much has to be, nothing else on my system depends on them.
[20:23] <slangasek> have you been doing upgrades using update-manager?
[20:23] <infinity> No, apt at the command line and autoremove.
[20:23] <slangasek> hmm
[20:23] <infinity> (base)adconrad@cthulhu:~$ dpkg -l linux-\*[0-9]\* | awk '/^i/ {print $2}'
[20:23] <infinity> linux-headers-3.7.0-7
[20:23] <infinity> linux-headers-3.7.0-7-generic
[20:23] <infinity> linux-headers-3.8.0-0
[20:23] <infinity> linux-headers-3.8.0-0-generic
[20:23] <infinity> linux-image-3.7.0-7-generic
[20:23] <infinity> linux-image-3.8.0-0-generic
[20:24] <infinity> linux-image-extra-3.7.0-7-generic
[20:24] <infinity> linux-image-extra-3.8.0-0-generic
[20:24] <infinity> Exact matching sets of images and headers, which is what I'd expect if I'm right. :P
[20:24] <infinity> And I've done nothing special to make that happen.  Just upgrade and autoremove.
[20:24] <infinity> Andy's also seen the same behaviour since we made the change in the kernel.
[20:26] <slangasek> bug #1078544, btw
[20:26] <slangasek> (which seems to be an SRU you've approved :)
[20:29] <infinity> slangasek: Yeah, but I only use apt-get, and these are all makes auto.
[20:29] <infinity> slangasek: So unrelated.
[20:29] <infinity> s/markes/marked/
[20:30]  * slangasek nods
[20:31] <slangasek> but in my case, they're not marked auto; and if I mark them auto, they get removed
[20:31] <infinity> On raring?
[20:32] <slangasek> quantal in this case
[20:32] <infinity> Right, the image->suggests:headers thing is only in raring.
[20:32] <slangasek> ah
[20:33] <mterry> doko, you switched the devscripts python module to be python3 only it looks like.  This causes lots of problems with ubuntu-dev-scripts which is python2.  Like bug 1099091
[20:33] <infinity> slangasek: For evidence completeness: http://paste.ubuntu.com/1532171/
[20:34] <doko> mterry, yeah, I have to provide the module for python2 too
[20:34] <infinity> slangasek: Anyhow, I think apt's autoremove behaviour is correct here.  We may disagree on that point.  Either way, it does no harm to *also* add headers to the apt hack, so we may as well.
[20:34] <infinity> slangasek: And we'll want that if we backport to precise, where the images don't (currently) suggest headers.
[20:34] <mterry> doko, OK, assigned that bug to you
[20:34] <mterry> looks like it's the clearinghouse for these issues
[20:35] <doko> mterry, otoh, it won't hurt to keep these issues open for the relevant packages, that these require a port to python3. could you do that too?
[20:37] <infinity> Thanks for the subtle reminder to put devscripts on hold before I accidentally upgrade it again. :P
[20:39] <mterry> doko, molded dup bug 1099537 into an open issue that we should port the scripts
[20:41] <infinity> doko: Are you going to get to the devscripts upload today?  If not, I might revert the previous one in the short term to stop the flow of bugs and confusion.
[20:43] <doko> yeah, will do, and for the future, please propose to fix it, not revert it
[20:43] <infinity> I prefer fixing it. :P
[20:43] <infinity> Almost always.
[20:43] <infinity> In this case, I'm not sure how best to fix it, though.  I guess building and shipping the python2.7 bits but intentionally skipping the pyhton2.7 dependency?
[20:44]  * doko add this to the infinity-promised-to-fix list
[20:44] <infinity> I made no such promise. :)
[20:51] <stgraber> tkamppeter: hey, looks like cups-browsed depends on avahi but the upstart job doesn't. Causing quite a lot of pointless respawn of the daemon on my machine :)
[20:55] <stgraber> tkamppeter: http://paste.ubuntu.com/1532299/
[20:56] <stgraber> tkamppeter: should I upload directly to the archive or are you planning a cups-filters upload pretty soon?
[20:57] <tkamppeter> stgraber, thanks for finding that. Please upload the corrected cups-filters.
[20:58] <stgraber> tkamppeter: ok, doing that now then.
[20:58] <OdyX> ^ stgraber please upload to experimental.
[20:58] <OdyX> well, in that case it doesn't really matter, granted, but make sure it's committed to the repository. :)
[20:59] <stgraber> OdyX: I don't think I've got access to the Debian bzr branch, maybe tkamppeter can commit the change there then
[21:00] <tkamppeter> OdyX, why did you upload the CUPS package ubuntu-only? Why did you not simply make 1.6.1-2 for both Debian and Ubuntu, to keep the sync.
[21:00] <OdyX> stgraber: ah yeah, damn, I thought it was a git repository on alioth, sorry.
[21:01] <OdyX> tkamppeter: ah yeah, good catch. You caught me. :) I didn't want to upload at all, but the discussion here showed it was important to have it soon in Ubuntu. Also the fix only affected Ubuntu.
[21:01] <tkamppeter> stgraber, I can upload the change to the Debian BZR for you.
[21:02] <stgraber> tkamppeter: thanks
[21:02] <OdyX> tkamppeter: I didn't want to upload now in Debian as I'm waiting for manpage translation updates for both french and german. I also hope (and asked) that msweet would push a 1.6.2 soon'ish.
[21:42] <tjaalton> TheMuso: thanks :)
[22:14] <tkamppeter> jasoncwarner, hi
[22:29] <bdrung> cjwatson: the libibmad/libibumad transition is worked on and will be finished soon.
[23:04] <infinity> bdrung: Thanks for the heads-up.
[23:04] <bdrung> infinity: you are referring to the libibmad/libibumad transition?
[23:06] <infinity> bdrung: Yeahp.
[23:08] <bdrung> infinity: i ask the sponsoree. he wasn't aware of the missing packages, because he mis-scripted his checking of build dependencies. he will update the missing packages through experimental.
[23:25] <xnox> @pilot in
[23:26] <xnox> cjwatson: pitti: or stgraber: please reject https://code.launchpad.net/~ubuntu-branches/ubuntu/precise/postgresql-8.4/precise-proposed/+merge/139408
[23:30] <bdrung> stupid modem causing connection losses (despite having a reliable working openwrt router)
[23:48] <stgraber> xnox: done
[23:48] <xnox> thanks.
[23:48] <stgraber> xnox: hmm, and what timezone are you on? ;)
[23:48] <xnox> stgraber: =))))))))
[23:49] <xnox> stgraber: I patch pilot tomorrow. So I can do it a bit now, then sleep and then do more =)
[23:49] <xnox> just came back from coaching volleyball
[23:51] <stgraber> hehe, ok ;)