[00:34] <TheLordOfTime> is there a template for a package removal request somewhere?  or at least a wiki i can read about the process in ubuntu
[00:35] <micahg> TheLordOfTime: file a bug against the package, state the reason, and subscribe ubuntu-sponosrs
[00:37] <TheLordOfTime> micahg:  okay, that means i'll have to do further testing with saucy assuming it installs on the VM (I've had issues with doing that...)
[00:37] <TheLordOfTime> micahg:  but that's the process to get a package removed from Ubuntu in all future releases?
[00:37] <TheLordOfTime> because this would be a longer-term blacklist since Debian is breaking the upstream code for the given program causing it to fail...
[00:37] <micahg> devel and future, yes
[00:37] <TheLordOfTime> micahg:  did i miss a freeze date or something, yet?
[00:37] <micahg> well, if it needs a blacklist, state that as well
[00:38] <micahg> TheLordOfTime: for unseeded, no
[00:38] <micahg> for seeded, no
[00:38] <TheLordOfTime> unseeded as in...?
[00:38]  * TheLordOfTime isn't 100% acquainted with all the terms
[00:39] <micahg> not on an image
[00:39] <TheLordOfTime> ah okay
[00:40] <micahg> jbicha: owncloud needed 2 FFes filed for missing binary dependencies (I filed them)
[00:40] <TheLordOfTime> micahg:  what's the freeze date for unseeded?
[00:41] <micahg> TheLordOfTime: 36 hours before release
[00:41] <TheLordOfTime> because based on the internet download speed here i'm going to be downloading Ubuntu for three days
[00:41] <TheLordOfTime> micahg:  and scheduled release time is a while off then?
[00:41] <micahg> TheLordOfTime: Oct 17
[00:42] <micahg> we can actually remove packages a bit later than that
[00:42] <micahg> jbicha: that means owncloud itself most likely should've had an  FFe
[00:44] <TheLordOfTime> micahg:  oh good so i have at least a month to test this.
[00:50] <TheLordOfTime> micahg:  sponsors approves package removals / autosync blacklists?
[00:50] <micahg> yes
[00:50] <TheLordOfTime> did not know that o.O
[00:52] <TheLordOfTime> micahg:  i assume there's no "retroactive removal" from older releases, then?
[00:53] <micahg> correct, solutions can be found for issues if they're severe enough
[00:53] <TheLordOfTime> (except where Debian completely mutilates the package and causes a huge delta from upstream sources, which cases the program to completely not work)
[00:53] <TheLordOfTime> (which is reportedly what's going on here)
[00:54] <micahg> TheLordOfTime: that can be addressed in one of two ways, in Debian, or in Ubuntu
[00:54] <TheLordOfTime> micahg:  working it from both angles
[00:54] <TheLordOfTime> however Debian's "Bitcoin Maintainer Team" is the source of the mutilation of the program
[00:54] <TheLordOfTime> so they'll either tell me to go die in a fire, or they'll realize they made a huge fail and will slap themselves
[00:55] <TheLordOfTime> in either case, I'd like it to be fixed in ubuntu before I go stab debian
[00:55] <TheLordOfTime> although both requests will end up being filed at about othe same time
[00:55] <micahg> is there a bug complaint somewhere?
[00:55] <TheLordOfTime> micahg:  multiple in the upstream tracker
[00:55] <TheLordOfTime> but no evidence usable on the Ubuntu package
[00:55] <TheLordOfTime> and the Debian package's bugs are... well...
[00:55] <TheLordOfTime> old / unupdated
[00:55] <micahg> there's always tech-ette as a last resort if there's something the maintainer is doing that they shouldn't
[00:55] <micahg> package: bitcoin?
[00:55] <TheLordOfTime> source package: bitcoin
[00:56] <TheLordOfTime> micahg:  i'm in the dev channel now for the bitcoin people, their people have heard the reports
[00:56] <TheLordOfTime> but before I go spinning up an unstable image i want to ge tthe Ubuntu bug filed
[00:56] <TheLordOfTime> micahg:  so my current system of processing this is as such: (1) install Saucy, (2) test program versus Upstream code, (3) confirm/reject the upstream claims.
[00:57] <TheLordOfTime> (4) install Debian and update to unstable, (5) test Unstable code against Upstream code, (6) confirm/reject claims
[00:57] <TheLordOfTime> (7) file relevant removal requests
[00:57] <TheLordOfTime> (depending on results of 3 and 6)
[00:57] <TheLordOfTime> micahg:  because i really don't want to deal with Debian myself :/
[00:58] <TheLordOfTime> not without evidence.
[00:58] <micahg> TheLordOfTime: a package like this if it's ABI stable and regression free might be able to get a tech board micro release exception
[00:58] <TheLordOfTime> micahg:  from where?
[00:58] <TheLordOfTime> micahg:  Debian's the source fo the mutilation
[00:58] <TheLordOfTime> they're removing upstream included code
[00:58] <TheLordOfTime> replacing their handlers using certain build deps with other build deps
[00:58] <TheLordOfTime> preventing built-in signature verification from working which causes unusability in the program
[00:59] <TheLordOfTime> micahg:  if it's broken in both Ubuntu and Debian, either the package needs to be removed, or Debian needs to take the package and [CENSORED]
[00:59] <micahg> sounds like a bug, replacing internal code copies with library versions is standard fare for Debian, if that breaks something, that's probably at least severity: important if not RC
[00:59] <TheLordOfTime> micahg:  but i don't take upstream's claims at face value
[00:59] <TheLordOfTime> micahg:  well... let me put it this way
[01:00] <TheLordOfTime> even here on Precise, there is a PPA maintained by someone that actually uses Upstream's code and doesn't mutilate it.
[01:00] <TheLordOfTime> that PPA works for all versions of Ubuntu
[01:00] <TheLordOfTime> (saucy assumed, i'll test that too)
[01:00] <TheLordOfTime> as well, building from Upstream code seems to work as well
[01:00] <TheLordOfTime> the packages as in Precise and pre-raring are using old, unpatched code that won't work as is with the bitcoin network
[01:01] <TheLordOfTime> however there is precise-proposed code that would work
[01:01] <TheLordOfTime> raring's got a passable version, but there's CVEs that weren't fixed until unstable 0.8.3 which is reported 100% unusable
[01:01] <TheLordOfTime> hence my testing to confirm that
[01:02] <TheLordOfTime> if that happens, the "unusable" part means the package is literally unusable (importance: high in Ubuntu, maybe?)
[01:02] <TheLordOfTime> such that in order to sync with the rest of the bitcoin network it will return 'INVALID' on every thing it tries to download from the network, and will never sync uyp
[01:02] <TheLordOfTime> up*
[01:02] <TheLordOfTime> micahg:  at this point, i'm stating what upstream's told me
[01:02] <TheLordOfTime> however i ALWAYS try and confirm this.
[01:03] <TheLordOfTime> (and as a user of bitcoins myself, if these bugs are confirmed, that means it's a much wider problem)
[01:04] <TheLordOfTime> micahg:  all of this will be in (a) the bug report, and (b) the request for removal if I confirm this in Ubuntu and Debian
[01:04] <micahg> TheLordOfTime: sounds about right
[01:06] <TheLordOfTime> micahg:  (i know some would do importance: critical or severity: serious in Debian BTS, but i'm always a little more conservative with my bug importance settings)
[01:07] <TheLordOfTime> (although if I file a bug in Debian it'll probably be serious because completely unusable)
[01:24] <TheLordOfTime> micahg:  If I do my testing via a Live environment, would that be sufficient to gather evidence towards the bug?
[01:25] <micahg> maybe?  idk
[01:25]  * TheLordOfTime shrugs
[01:25] <TheLordOfTime> the VM is lagging so... :/
[01:41] <jbicha> micahg: really? it built here and owncloud is universe, right?
[01:41] <micahg> jbicha: binary dependencies
[01:41] <jbicha> oh
[01:42] <jbicha> thanks
[01:54] <TheLordOfTime> micahg:  a removal is permanent, right?  Or can it later be reversed?
[01:55] <micahg> it can be readded if there's a good reason (or from a sync next cycle)
[01:55] <TheLordOfTime> micahg:  so, basically, file a removal request for Saucy, and it could get readded in T-series by autosync?
[01:56] <TheLordOfTime> or would it stand to just stay removed?
[01:56] <micahg> yes, unless blacklisted
[01:56] <TheLordOfTime> okay, i'm probably going to go for the removal rather than blacklisting
[01:56] <TheLordOfTime> because hopefully Debian unfubar's the package and fixes it by T-series
[01:56] <TheLordOfTime> if not, there'll be more requests (and maybe a blacklist request)
[01:57] <micahg> let
[01:57] <micahg> let
[01:57] <micahg> let's have a discussion when you have all the facts
[01:57] <TheLordOfTime> cool.
[01:57] <TheLordOfTime> ... okay, as expected, daily build won't install... :/
[02:38] <micahg> any Ubuntu DDs use Xubuntu?  I need help with alioth
[07:02] <dholbach> good morning
[18:23] <micahg> jbicha: are you aware unseeded Universe packages require FFes as well?
[18:25] <jtaylor> micahg: I use xubuntu sometimes
[18:26] <jtaylor> and concerning ffe, as far as I know yes everything needs an ffe
[18:26] <jbicha> micahg: yes, I was sorta going off the ffe from comments 33 and 36 of bug 1077624
[18:27] <micahg> jbicha: that was a different cycle
[18:29] <micahg> release exceptions are supposed to expire at some point during the cycle
[18:29] <jbicha> and flightgear was ftbfs
[18:30] <micahg> that just means you'll have an easier time getting it approved :)
[21:08] <TheLordOfTime> micahg:  https://bugs.launchpad.net/ubuntu/+source/pdumpfs-rsync/+bug/1219978  <-- not anyhting i'm working on directly. but this might be a good reason to remove that package?   since it's dependency is indeed not in any versions since Lucid according to Launchpad.
[21:08] <TheLordOfTime> (saw it in the bug announcements channel)
[21:12] <micahg> ouch
[21:13] <micahg> how long has it been like that
[21:15] <micahg> TheLordOfTime: already done
[21:17] <TheLordOfTime> micahg:  not sure if your question was pointed towards the bug i linked but... it's been like that since post-Oneiric apparently, to answer your question.
[21:17] <micahg> yeah, it's a shame no one caught it until now
[21:17] <TheLordOfTime> and cool, that's good.  what about the other releases
[21:18] <micahg> not much we can do
[21:18] <micahg> if pdumpfs came back, we could backport it
[21:18] <TheLordOfTime> micahg:  so, set status Fix Released, comment it's removed in Saucy and later, make a note it can't be retroactively removed in other releases?
[21:18] <TheLordOfTime> i mean, while I'm on the bug and all... :p
[21:19] <micahg> yes, and you can note that if pdumpfs returns to Debian/Ubuntu, we can try to backport to any stable releases left
[21:21] <TheLordOfTime> done.
[21:21] <micahg> jtaylor: I'm thinking to make a pkg-xubuntu team on Alioth for packages that Xubuntu cares about that have been orphaned or are maintained by Xubuntu people
[21:21] <TheLordOfTime> micahg:  i assume the package is also blacklisted until the dependencies are resolved?
[21:22] <micahg> TheLordOfTime: it's not in Debian, so no need for blacklisting
[21:22] <TheLordOfTime> cool.  probably was removed from Debian because E:NonexistentDependency or something
[21:22]  * TheLordOfTime goes back to normal bug triaging
[21:22] <micahg> debian 596752
[21:23] <micahg> I have no evidence of pdumpfs-rsync being in Debian
[21:23] <micahg> anytime recently at least