=== a16g_ is now known as ypwong
=== forestpiskie is now known as Guest28422
=== Guest28422 is now known as forestpiskie
[10:07] <sil2100> infinity: hi!
[10:10] <sil2100> infinity: for raring, someone proposed a fix as an SRU (LP: #1204664) which basically disables a default key combination - this key combination seemingly works only once, all subsequent other keycombination-presses of this shortcut fail - I guess it's a bit wrong for an SRU, right?
[10:10] <ubot2`> Launchpad bug 1204664 in compiz (Ubuntu Raring) "control+super+d works just the first time running Ubuntu Unity." [Undecided,New] https://launchpad.net/bugs/1204664
=== mdeslaur_ is now known as mdeslaur
[12:49] <tseliot> stgraber, slangasek: I've found and fixed an issue in fglrx-experimental-13. I'm about to upload a new revision for the same SRU. The diff is minimal
[12:55] <tseliot> stgraber, slangasek: ok, uploaded and here's the diff http://paste.ubuntu.com/5981051/
[15:15] <rtg> cjwatson, infinity: the autopackage test failure for linux 3.11.0-2.5 appears to be bogus (closeall.op: No space left on device). Can I get it promoted ?
[16:48] <infinity> sil2100: How is that inappropriate for an SRU?
[16:51] <sil2100> infinity: as it's modifying default behavior, disabling a keyboard shortcut that was in during the release
[16:51] <infinity> sil2100: One that doesn't work? :P
[16:51] <sil2100> infinity: even thought it wasn't really working... ;p
[16:51] <infinity> sil2100: Though I think I misunderstood initially.  Why not just fix the bug instead of disabling it?
[16:51] <sil2100> infinity: someone said it was working when you used it for the first time!
[16:52] <infinity> sil2100: It seems to work for me in saucy, so clearly, there's a fix for unity7 to make it work...
[16:52] <sil2100> infinity: yeah, I had a discussion with upstream after asking you the question, and I think we somehow resolved it, since there is a way of fixing it somehow from what I know
[16:52] <sil2100> infinity: and they'll be backporting the fix to raring
[16:52] <infinity> sil2100: Excellent, then I'll pretend this conversation never happened.
[16:52] <sil2100> infinity: thanks ;)
[16:52] <sil2100> hehe
[16:54] <tseliot> infinity: can you approve the new revision of fglrx-experimental-13 in precise-proposed please? diff: http://paste.ubuntu.com/5981051/
[18:44] <mdeslaur> so...can someone explain why squid3 has not migrated from -proposed if the excuses page says "Valid Candidate"?
[18:58] <rbasak> mdeslaur: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt is saying migrating squid3 would make sqcwa and squid-prefetch uninstallable.
[18:59] <rbasak> (AFAICT)
[18:59] <mdeslaur> rbasak: ah! thanks, I didn't know that page existed
[19:01] <rbasak> mdeslaur: is this because the "squid" transitional package has disappeared in -proposed?
[19:02] <mdeslaur> rbasak: that seems plausible, yes
[19:07] <mdeslaur> rbasak: are you adding it back?
[19:07] <rbasak> mdeslaur: I wasn't planning on touching it. I wonder if Debian have intentionally removed it, and if so then perhaps Debian needs to fix packages depending on it, too?
[19:08] <mdeslaur> rbasak: debian still has "squid" in the archive
[19:08] <rbasak> Oh
[19:09]  * rbasak looks
[19:10] <rtg> infinity, linux 3.11.0-2.5 is still lodged in proposed because of the eglibc autotest failure. Could you drop kick it into release ?
[19:10] <infinity> rtg: Yeah, will do.  I was trying to see if I could reproduce the eglibc failure first, which I seemingly can't.
[19:11] <rtg> infinity, make a really small disk ?
[19:12] <xnox> mdeslaur: rbasak: they may have it, but is it build by the source package? Looking at debian/control of the package in sid, it no longer builds the squid binary package.
[19:12] <infinity> rtg: That's how to make the linux one fail.  The eglibc one seems weirder.
[19:12] <xnox> it may still be in the debian archive, however. as in debian they postpone removing the package.
[19:13] <infinity> rtg: Anyhow, given a shove.
[19:13] <rtg> infinity, thanks
[19:14] <mdeslaur> xnox: nono, they have a squid _source_ package
[19:14] <mdeslaur> xnox: which build a squid binary package
[19:14] <mdeslaur> xnox: they have _both_ squid and squid3
[19:14] <rbasak> Looks like we introduced a squid transitional package in Precise as an Ubuntu delta.
[19:15] <rbasak> And that we dropped this inadvertently in the last merge.
[19:15] <xnox> mdeslaur: oh =(
[19:15] <xnox> rbasak: i see.
[19:15] <rbasak>   * Dropped:
[19:15] <rbasak>     - debian/control: Dropped transitional packages from squid, no
[19:15] <rbasak>       longer required.
[19:15] <rbasak> Maybe more intentional than inadvertent!
[19:15] <rbasak> I'll file a bug.
[19:15] <rbasak> jamespage, yolanda: ^^
[19:22] <rbasak> I filed bug 1211942
[19:22] <ubot2`> Launchpad bug 1211942 in squid3 (Ubuntu Saucy) "Dropped squid transitional package blocks -proposed migration" [High,New] https://launchpad.net/bugs/1211942
[19:29] <infinity> rbasak: Was the transitional package introduced for lucid->precise?  If so, it's surely not needed anymore.
[19:29] <infinity> rbasak: And the right answer would be to make things stop depending on it.
[19:29] <infinity> (Not that keeping it would be wrong either)
[19:30] <rbasak> infinity: Debian do seem to be keeping it.
[19:31] <rbasak> infinity: it seems that we dropped it. But I suppose we could reintroduce it now that users have switched when they upgraded from lucid->precise? Is that what you're saying?
[19:32] <rbasak> (ie. reintroduce into universe)
[19:59]  * adconrad wonders where his co-lo server has disappeared to for the last half hour.
[20:00] <adconrad> rbasak: I wasn't suggesting we reintroduce squid2.  That would be confusing as heck if "apt-get install squid" got you an older version on saucy than it does on precise.
[20:00] <adconrad> rbasak: Our two options, IMO, are to carry the transitional package (so, reintroduce that), or make everything that depends on "squid" depend on squid3 instead.
[20:00] <rbasak> adconrad: right
[20:01] <adconrad> rbasak: Reinstroducing the transitional package seems the path of least resistance.
[20:01] <rbasak> Agreed. I'm just not sure what the logic was to drop the transitional package in the first place, which is why I filed the bug (as both yolanda and jamespage are EOD right now)
[20:02] <adconrad> rbasak: The logic was likely "people have done the LTS->LTS upgrade, and now we expect them to install squid3 directly", as is the case with most transitional packages.
[20:02] <adconrad> But in the case where things still *depend* on the transitional package, dropping it is probably less sane.
[20:02] <adconrad> rbasak: If I were you, I'd just upload to fix the bug, and not worry too much about the rationale.  :P
[20:04] <jbicha> you could just have squid3 Provides: squid now, right?
[20:04] <adconrad> You could do that instead, yes.
[20:04] <rbasak> As long as dependent packages don't make their Depends: versioned in the future.
=== adconrad is now known as infinity
[20:49] <cyphermox> ^ this replaces brcm-patchram-plus, which you should feel free to remove
[21:03] <jamespage> rbasak, that is whats commonly know as a mistake
[21:03] <jamespage> rbasak, lets get back in sync with Debian
[21:05] <rbasak> jamespage: by reintroducing squid 2?
[21:06] <jamespage> rbasak, oh - I see - Debian still has a squid source package
[21:06] <jamespage> rbasak, how odd
[21:06] <rbasak> Right
[21:07] <jamespage> rbasak, I'd re-introduce the squid binary package in squid3
[21:07] <rbasak> Sounds good
[21:07] <jamespage> rbasak, as we are skewed from Debian anyway
[21:07] <jamespage> rbasak, needs a merge as well
[21:15] <jamespage> ah - I see why mdeslaur was asking now!
=== infinity2 is now known as infinity