[01:20] <hallyn> slangasek: so do you have another suggestion?  shoudl it just go into /lib/cgmanager/cgm-release-agent?
[01:21] <hallyn> slangasek: cgmanager-utils conflicts: i tested it;  with breaks it simply refuses to upgrade the packages;  with conflicts it removes the old cgmangaer-utils and installs the new package
[01:22] <hallyn> now it's possible that i should just remove the version - cgmanager-utils no longer is needed at all - uh, no longer exists
[01:27] <tdaitx> doko, it seems squid FTBFS in wily-proposed due to the libecap2 -> libecap3 change, squid <= 3.4 requires ecap 0.2 or 0.3 (ie. libecap2-dev) - only squid 3.5+ can use ecap 1.0 (ie. libecap3-dev)...
[01:27] <tdaitx> doko, I am trying to build, got an error due to a "logical-not-parentheses" warning, fixed it with a patch, then I am seeing lots of netinet/in.h and linux/in.h conflicts - ie. conflicts between libc6-dev and linux-libc-dev headers, any idea?
[01:27] <tdaitx> ... trying to build with libecap2 ...
[03:09] <hallyn> slangasek: reagarding the xs-testsuite, if i make it 'Testsuite' the dpkg in trusty will DTRT?  (I haven't found anything explaining the difference)
[03:16] <slangasek> hallyn: dpkg in trusty will complain that it's an unknown field, but we're talking about a ppa so it doesn't matter
[03:17] <slangasek> hallyn: how did you test that it refused to upgrade the packages?  I'm pretty sure your test was wrong
[03:17] <slangasek> hallyn: oh and yes, if cgmanager-utils no longer exists it should be an *un*versioned conflicts, not a versioned breaks
[03:20] <hallyn> slangasek: i install cgmanage ron trusty, then installed the 0.39-1 package there with dpkg -i, it refused.
[03:20] <infinity> Unversioned Conflicts/Replaces, if the goal is to smoothly punt it off the system.
[03:20] <hallyn> stgraber: ^ what exactly do you want in debian/control?  can you put it into the 'unstable' branch at https://github.com/lxc/cgmanager-pkg-ubuntu ?
[03:21] <hallyn> ok, will make that an unversioned C/R now
[03:21] <infinity> And raw dpkg won't do that right, you need apt or another frontend.
[03:22] <hallyn> bah.  why?
[03:22] <infinity> Because reasons.
[03:22] <hallyn> ok, but if it'll break for people trying to do it manuallywith dpkg that's still bad no?
[03:22] <infinity> dpkg will just tell you that you can't install something with something else that conflicts.  C/R paired is a hint to higher level frontends (like apt) to DTRT.
[03:22] <hallyn> but if we can all agree on unversoined C/R then that works for me :)
[03:22] <hallyn> oh, i see
[03:22] <hallyn> thanks
[03:23] <infinity> No, it's fine if complex upgrades like that can't be done with dpkg without first removing package A.
[03:23] <infinity> But it should be smooth with apt/aptitude/dselect/update-manager/etc, which C/R will make sure of.
[03:23]  * hallyn looks back up to see what else he needs to remember he messed up
[03:25] <hallyn> ok, so i think there's only the cgm-release-agent location left to worry about
[03:26] <hallyn> stgraber: ^ nm, we'll just leave the lintian warning for now and leave xs-testsuite as is
[03:43] <TJ-> Anyone familiar with ecryptfs-utils source-code around?
[03:45] <slangasek> hallyn: dpkg --auto-remove probably would've done the right thing for the Breaks case anyway
[03:45] <slangasek> hallyn: sorry, --auto-deconfigure
[04:20] <pitti> Good morning
[04:25] <tyhicks> TJ-: I'm on the way to bed but I'll see how much help I can provide in the span of a few minutes :)
[04:26] <TJ-> tyhicks: simple question this time I promise!
[04:27] <tyhicks> good :)
[04:27] <TJ-> tyhicks: I'm hacking on the ecryptfs-utils code to fix 'our' issue... but stumped as to where the source is included the linux/keyctl.h or defining KEY_SPEC_USER_KEYRING - can find its usages but no sign of where it is defined!
[04:30] <TJ-> tyhicks: I grep-ed but couldn't see it, but it has to be there: http://paste.ubuntu.com/12424557/
[04:31] <tyhicks> TJ-: the kernel defines it, which is why keyctl.h is in /usr/include/linux, and libkeyutils-dev also defines it in /usr/include/keyutils.h
[04:31] <tyhicks> TJ-: ecryptfs-utils uses the definitions from libkeyutils-dev
[04:32] <TJ-> tyhicks: I am planning on adding some intelligence so the code can pick the correct keyring to use, and allow the user to override the choice on the command-line
[04:32] <TJ-> tyhicks: Ahhhh! of course. I think I'm a bit too tired. Thank you.
[04:32] <tyhicks> TJ-: the intelligence part sounds good but I'm not a fan of the command line option
[04:33] <TJ-> tyhicks: I did "apt-cache showsrc ..." but totally missed "libkeyutils-dev"
[04:33] <tyhicks> TJ-: the kernel keyring, and all of the subkeyring belonging to a process, is too much complexity to expose to users
[04:33] <tyhicks> s/subkeyring/subkeyrings/
[04:33] <TJ-> tyhicks: I agree, but the 'intelligence' may not always be able to figure out the correct keyring
[04:34] <TJ-> tyhicks: I was planning on only exposing it to ecryptfs_insert_wrapped_passphrase_into_keyring
[04:35] <tyhicks> TJ-: actually, I think ecryptfs-utils may be using the wrong keyring
[04:36] <tyhicks> TJ-: I wonder what would happen if ecryptfs_add_auth_tok_to_keyring() inserted the key into the KEY_SPEC_SESSION_KEYRING
[04:36] <TJ-> tyhicks: I've been thinking that. It should be session not user
[04:36] <tyhicks> TJ-: or possibly the KEY_SPEC_USER_SESSION_KEYRING
[04:37] <tyhicks> TJ-: I think changing the keyring is the first approach we should take instead of trying to add intelligence about which keyring to use
[04:37] <TJ-> tyhicks: but I've also been looking at what the various tools do with keyrings. default, and pam_init, are both supposed to link the session and user keyrings. The problem with just 'user' is when using 'sudo' it doesn't attach to the user session, or the non-sudo user
[04:38] <TJ-> tyhicks: I'm aiming to set up enviroments with each scenario and then test various changes, starting with swapping user -> session, and working on up
[04:38] <tyhicks> TJ-: ok, big thanks for the help on this
[04:39] <TJ-> tyhicks: you're welcome. It's get another security feature that interests me. This may help me in thinking about implementing a systemd-cryptsetup LUKS key-file AskPass extension
[04:40] <TJ-> s/get/yet/
[04:40] <tyhicks> interesting
[04:40] <tyhicks> ok, I've got to run now
[04:40] <tyhicks> talk to you later
[04:40] <TJ-> tyhicks: thanks
[05:09] <pitti> wgrant: do you happen to have an estimate about when lcy01 comes back?
[05:11] <wgrant> pitti: I'd hope this week, but some issues have been hit.
[05:11] <wgrant> It is coming together, though.
[05:15] <pitti> wgrant: thanks
[05:55] <pitti> doko, infinity: can you please have a look at http://bazaar.launchpad.net/~ubuntu-release/britney/britney2-ubuntu/revision/496 -- does this make sense to you? anything else which we should trigger?
[05:56] <pitti> originally I only wanted to make this temporary as we are currently so low on capacity, but I think it actually makes sense permanently
[06:21] <dholbach> good morning
[06:23] <dholbach> happy birthday infinity!
[06:28] <pitti> ooh!
[06:28] <pitti> infinity: happy birthday, man!
[07:00] <pitti> doko, infinity: this is resulting in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gcc-5
[07:01] <pitti> doko, infinity: (note that binutils and linux weren't triggered before)
[08:35] <seb128> mvo_, hey, do you know if bug #1496291 is likely to be an apt or dpkg issue?
[08:35] <seb128> s-c didn't change in wily afaik
[08:39] <mvo_> seb128: dpkg or s-c itself, apt does not really deal with triggers
[08:39] <seb128> dpkg I guess
[08:39] <mvo_> seb128: I guess we need to find the cycle and break it, is there some helpful information maybe from dpkg?
[08:39] <seb128> lubuntu-software-center has similar issue and didn't change either since vivid
[08:39] <seb128> no, those e.u.c reports are useles s:-/
[08:40] <seb128> https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/1495077
[08:40] <seb128> might have, it's an apport report with logs
[08:41] <seb128> or https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/1495309
[08:43] <seb128> dbus has similar report
[08:43] <seb128> e.g bug #1496296
[08:43] <seb128> so maybe it's due to it?
[08:43] <seb128> Laney, ^ did you see anything like that?
[08:43] <Laney> we made the dbus one interest-noawait
[08:43] <Laney> but that was before 1.10
[08:44] <seb128> https://errors.ubuntu.com/problem/17ccb3737169df5ac7c589255576b7abbe898229 has 1.10 reports
[08:46] <Laney> where's a proper log?
[08:48] <seb128> Laney, https://launchpad.net/ubuntu/+source/dbus/+bugs?orderby=-id&start=0 the upgrade reports
[08:48] <seb128> I guess
[08:48] <seb128> at least they have apport/dpkg logs
[08:49] <Laney>  chain of packages whose triggers are or may be responsible:
[08:49] <Laney>   lubuntu-software-center -> libc-bin
[08:50] <Laney>  la cadena de paquetes cuyos disparadores son o pueden ser responsables:
[08:50] <Laney>   lubuntu-software-center -> libc-bin
[08:54] <Laney> OK, infinity probably fixed software-center on Friday
[08:54] <Laney> lubuntu-s-c should have the same treatment I think
[08:54]  * Laney JFDI
[09:00] <rbasak> infinity or stgraber: can we speak about DPDK packaging please? I'm still not happy about the current state of packaging and would like your opinion.
[09:05] <seb128> Laney, thanks for figuring out the details
[09:05] <seb128> mvo_, ^ btw, seems like s-c got fixed
[09:07] <Laney> don't know why these get attributed to dbus though
[09:12] <mvo_> seb128: lovely
[09:13] <mvo_> seb128: infinity is a hero
[09:14] <seb128> :-)
[10:50] <doko> pitti, that gcc list looks lovely ;)
[10:52]  * doko starts renaming all my packages to gcc-* 
[11:06] <doko> mvo_, could you have a look at http://autopkgtest.ubuntu.com/packages/a/aptdaemon/wily/amd64/ ?
[11:06] <pitti> doko: lol
[11:10] <jamespage> doko, hey - buildbot is blocking transition of sqlalchemy to the release pocket due to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794300
[11:10] <jamespage> doko, any ideas? its not been touched for eons in Debian
[11:11] <mvo_> doko: I suspsect the new packagekit broke it
[11:12] <doko> jamespage, no, I'll ping the maintainer. I really didn't want to get involved with that one, therefore I asked the guy to take it over
[11:12] <jamespage> doko, ack - thankyou
[11:12] <jamespage> (I saw you as an Uploader - hence the ping)
[11:15] <doko> there's a new beta
[11:33] <doko> jamespage, there's a new 0.8.x release, didn't check yet. but the test failures don't look like sqlalchemy related. I think ScottK is wrong
[11:33] <doko> ohh, ScottK left ubuntu ...
[11:33] <jamespage> doko, I also think they are not related to sqlalchemy
[11:37] <jamespage> doko, I'll poke at it
[11:42] <doko> barry, https://launchpad.net/ubuntu/+source/pyke/1.1.1-5build1/+build/7911076 is ply fallout
[11:52] <jamespage> doko, well that makes no difference
[12:43] <tjaalton> a question about Provides: a package depends on libfoo1 (>=1), and another incarnation of the library libfoo1-too Provides libfoo1.. there's no way to fulfil the dep with libfoo1-too?
[12:43] <cjwatson> versioned Provides are a thing now, but you'll be trailblazing a little bit
[12:44] <tjaalton> not on trusty though
[12:44] <tjaalton> ?
[12:44] <cjwatson> dpkg 1.17.11, which postdates trusty
[12:44] <cjwatson> so the short answer is no
[12:44] <tjaalton> right
[12:44] <tjaalton> sigh
[12:45] <cjwatson> best you can do is probably to make your shlibs generate alternate deps
[12:45] <tjaalton> that would need rebuilds?
[12:45] <cjwatson> yep
[12:45] <cjwatson> or hack the revdeps manually
[12:46] <tjaalton> ok
[12:46] <seb128> doko, is bug #1456323 still valid?
[12:47] <tjaalton> this is the mess with libosmesa6.. providing a renamed backport solves nothing (does solve -dev package installability though)
[12:47] <tjaalton> oh well
[12:49] <didrocks> tjaalton: btw, just confirming that I have no more crash at all with the xorg fixes, thanks again :)
[12:49] <tjaalton> didrocks: ok good
[12:51] <doko> seb128, yes, released is planned for second half of 2016
[12:51] <tjaalton> hm, maybe osmesa needs it's own build target again, so that it doesn't need to depend on libglapi. then the stock version would work just like it did on precise
[13:08] <seb128> dpm, pitti, do you have any idea why evolution-3.16 and evolution-data-server-3.16 mo files are not included in wily langpacks?
[13:09] <seb128> hum, https://translations.launchpad.net/ubuntu/wily/+source/evolution/+pots/evolution/+admin has 3.12 naming
[13:09] <seb128> I guess that's not good
[13:10]  * seb128 fixes that
[13:10] <seb128> unsure that's enough to have it included though
[13:20] <seb128> dpm, wgrant, https://translations.launchpad.net/ubuntu/wily/+source/evolution-data-server has 2 templates, that's wrong right? can we delete the second one?
[14:43] <rbasak> infinity or stgraber: can we speak about DPDK packaging please? I'm still not happy about the current state of packaging and would like your opinion.
[14:43] <doko> pitti, update_excuses.html doesn't seem to pick up the autopkg test status, still showing the binutils and linux tests as running
[14:44] <pitti> doko: yes, I know; still > 500 tests to run through (backlog from gcc-5), due to half of scalingstack being kaputt
[14:45] <stgraber> rbasak: I guess though I have close to no background on this, maybe infinity knows more?
[14:45] <infinity> rbasak: I'm not awake enough yet to go looking and having opinions.
[14:45] <rbasak> stgraber: thanks. Maybe best to leave it with infinity then?
[14:45] <rbasak> infinity: can we catch up later? We'd like to upload this week if possible, so I'd like to have your opinion today if I can get it please.
[14:46] <stgraber> rbasak: sure, if infinity has more of a clue as to what's happening or should happen with DPDK then that'd likely save time
[14:46] <stgraber> rbasak: also, you pinging me just reminded me of those two NEW reviews you asked for a while back, sorry, kinda dropped the ball with travel, will finish the review now
[14:47] <stgraber> rbasak: from what I remember, the packaging looked great and I just need to look at the licensing
[14:47] <rbasak> stgraber: yeah that makes sense. I think we have too many cooks with DPDK as it is :-/
[14:47] <rbasak> stgraber: (kimchi/ginger) thanks!
[14:49] <cjwatson> pitti: lcy01 is back up for buildds, FYI, and I think ChrisS is fixing the non-buildd stuff next.
[14:49] <pitti> cjwatson: ah, good to hear!
[14:50] <hallyn> slangasek: ok when i get some time today i'll move cgm-release-agent to /usr/lib/cgmanager/ .  Then that should hopefully get it ready
[14:54] <slangasek> hallyn: /usr/lib/cgmanager or /lib/cgmanager? The latter seems more correct :)
[14:54] <slangasek> hallyn: but it's also not something I'm going to stand on - this is the least of the packaging issues IMHO
[14:54] <stgraber> rbasak: I'm happy with ginger, for kimchi, you're missing a debian/copyright entry for ui/pages/help/gen-index.py which is LGPLv2.1+ and not Apache2 as debian/copyright declares
[14:55] <rbasak> stgraber: OK, thanks. Is that the only issue for kimchi?
[14:55] <stgraber> rbasak: yep, the rest of debian/copyright appears valid
[14:55] <rbasak> stgraber: OK I'll arrange a re-upload, thanks.
[14:56] <stgraber> rbasak: alright, rejecting kimchi then
[14:56] <rbasak> ack
[14:56] <stgraber> rbasak: I'll keep ginger in the queue until I have the new kimchi since it depends on it
[14:56] <rbasak> ack, thanks
[15:21] <hallyn> slangasek: sorry yeah that's what i meant
[15:21] <hallyn> it has to be /lib bc cgmanager can start very early
[15:34] <tkamppeter> hi, I have a problem with bug 1449875. I could fix it by adding a dependency to Ghostscript but the new dependency recommends tons of unneeded packages. Do all these get installed then, too?
[15:48] <doko> pitti, could you have a look at https://launchpad.net/ubuntu/+source/debmake-doc/1.0-1/+build/7523212 ?  could that be a binary mangler issue ?
[16:05] <jono> dpm, all set?
[16:06] <dpm> jono, yep
[16:06] <jono> dpm, ring ring
[16:07] <jono> dpm, can you call me?
[16:07] <dpm> jono, yep
[16:08] <jono> dpm, weird
[16:08] <jono> it is calling on my phone
[16:08] <arges> doko: bug 1490352 for binutils-arm64-cross, was this supposed to change Build-Depends field? or be a no-change rebuild? the diff is just changelog.
[16:08] <jono> but not my computer
[16:08] <jono> one second, dpm
[16:08] <doko> arges, oh, let me fix this
[16:08] <arges> doko: ok i'll reject the current upload.
[16:10] <doko> arges, reuploaded
[16:11] <arges> doko: ok thanks, i'll review that
[16:47] <bdmurray> Laney: I tried to add foundations-bugs, a team which is subscribed to bugs about packages, to sponsors-page.py (in TEAMS) but nothing is showing up. Should that team actually go in SPONSOR_TEAMS?
[16:48] <Laney> bdmurray: It looks at subscribers to individual bug reports
[16:48] <Laney> there is no knowledge of package subscribers
[16:48] <Laney> (IIRC)
[16:49] <bdmurray> ah, that would explain things
[16:50] <Laney> what would you want it to show?
[16:51] <Laney> I guess items it already knows about which are on packages that this team is subscribed to
[16:51] <bdmurray> bugs where foundations-bugs is a structural subscriber (I think that would work) and has patch or has linked branch
[16:52] <Laney> It's just show me all open bugs that <teams> are subscribed to currently
[16:52] <Laney> I'm not trying to change the sponsoring process from "subscribe ubuntu-sponsors" in general
[16:54] <bdmurray> Right, then structural subscriber and bug subscriber is ubuntu-sponsors would do that.
[16:56] <Laney> That would probably be useful for you
[16:57] <Laney> Maybe easier to consume the package-team-mapping though
[17:08] <mterry> @pilot on
[17:08] <udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[17:08] <mterry> @pilot in
[17:42] <hallyn> slangasek: http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.39-2.dsc
[18:16] <doko> seb128, Laney: gdk-pixbuf ftbfs,  leading to broken openjdk on architectures where it built
[18:21] <doko> meh, why sync a package which alreads ftbfs in debian ...
[18:52] <robert_ancell> doko, is anyone looking at the gdk-pixbuf issue?
[18:53] <hallyn> xnox: netcf never got promoted from experimental to unstable.  is that supposed to happen automaticlaly at some point?  at this point it'll fail due to newer libnl3, but i'm trying to figure out which debian pockets i need to push updates for.
[18:53] <hallyn> i.e. should i push one for both unstable and experimental?
[18:54] <xnox> hallyn: nothing ever gets promoted from experimental to unstable.
[18:54] <doko> robert_ancell, see #ubuntu-desktop, I mentioned it there too
[18:54] <hallyn> (i also should do a new version, which i'll send to unstable at some point)
[18:54] <xnox> hallyn: one has to manually upload into unstable.
[18:54] <doko> but I don't know if anybody is looking
[18:54] <xnox> hallyn: by default, one should upload just into unstable
[18:54] <hallyn> xnox: ok.  (i really need to go for DM )
[18:54] <hallyn> xnox: so if i push to unstable will the experimental version get obosleted?  i assume not,
[18:55] <xnox> hallyn: unstable is kind of like ~ devel-proposed, there is automatic migration from unstable into testing, kind of like proposed migration from devel-proposed -> devel.
[18:55] <hallyn> so i guess i'll push the current fix based on experimental, to unstable.  then send a new release to experimental
[18:55] <xnox> hallyn: and currently devel[-proposed] are aliases for wily[-proposed]
[18:55] <xnox> hallyn: why?
[18:55] <hallyn> xnox: why which?
[18:55] <xnox> hallyn: nobody uses experimental.
[18:55] <hallyn> heh.  i just figured *someone* out there is using it,
[18:55] <hallyn> but ok, i'll ignore it then and just go for unstable.
[18:55] <hallyn> that's what i was wondering :)
[18:55] <hallyn> thanks
[18:55] <xnox> hallyn: think of experimental, like a PPA, but simply only one, shared with all DDs
[18:56] <hallyn> can i ask you to sponsor the fix?
[18:56] <xnox> hallyn: yeah experimental == PPA in debian world.
[18:56] <xnox> hallyn: yes.
[18:56] <hallyn> great, thx
[18:56] <xnox> hallyn: dput to mentors.debian.net and give me url, i'll review, comment and maybe sponsor.
[18:57] <hallyn> perfect.  thx.
[18:57]  * hallyn notes pull-debian-source in wily seems broken
[18:57] <cjwatson> hallyn: Debian ftpmasters occasionally remove packages from experimental that have newer versions in unstable
[18:58] <cjwatson> you don't need to ask for that or do anything special to cause it to happen
[18:58] <cjwatson> the only manual action needed is if you actually want to keep a different version in experimental
[18:58] <hallyn> cjwatson: ok, that won' thappen for a week or two - i'll fix the current version in unstalbe first, then do an upload of a new release
[18:58] <hallyn> gotcha, thx
[19:17] <hjd> hallyn: re: pull-debian-source, bug 1453330?
[19:18] <hallyn> hjd: yeah that looks like it
[19:30] <hallyn> xnox: http://mentors.debian.net/debian/pool/main/n/netcf/netcf_0.2.3-4.2.dsc   (running out for lunch, biab)
[19:37] <xnox> hallyn: please fix all warnings -> http://mentors.debian.net/package/netcf
[19:38] <xnox> hallyn: since you are maintainer use 0.2.3-5 version; not nmu.
[19:39] <tkamppeter> hi, I have a problem with bug 1449875. I could fix it by adding a dependency to Ghostscript but the new dependency recommends tons of unneeded packages. Do all these get installed then, too?
[20:00] <asac> anyone konws if there is a way to globally set time format for console?
[20:02] <hallyn> xnox: for some of the warnings (like ancient standards version) i was going to fix that with the new 0.2.8 release.  this was meant as an emergency fix for the FTBFS
[20:03] <sarnold> asac: perhaps locale's LC_TIME -- but anything that does strftime itself is unlikely to get it right..
[20:03] <hallyn> huh, so -1 means nmu.  this is new to me
[20:11] <asac> yeah
[20:11] <asac> thanks sarnold
[20:11] <asac> thats what i thought too, just wanted to check
[20:11] <hallyn> xnox: (will ping when i re-upload)
[20:14] <xnox> hallyn: no, XXX-Y[.Z] -> XXX is upstream, -Y is debian maintainer/uploader, optional [.Z] is the nmus
[20:15] <xnox> hallyn: so maintainer does 1.0-1, 1.0-2, then two nmu happen at 1.0-2.1, 1.0-2.2, and then maintainer does 1.0-3 etc.
[20:15] <xnox> hallyn: essentially it's a historical convention.
[20:16] <hallyn> xnox: yeah that's what i meant, sorry
[20:16] <hallyn> i'm trying to figure out the watchfile.  given that netcf has the 1:
[20:17] <hallyn> oh uscan seems to ignore that, ok
[20:19] <mterry> Laney, do you know why gdk-pixbuf is ftbfs in proposed?
[20:19] <mterry> Laney, looks like some cve test failures
[20:19] <mterry> Laney, when I try to reproduce locally on my desktop, my computer freezes(!)
[20:38] <Laney> mterry: someone synced that?
[20:39] <Laney> https://buildd.debian.org/status/package.php?p=gdk-pixbuf&suite=unstable <- could have predicted this :)
[20:39] <Laney> https://bugzilla.gnome.org/show_bug.cgi?id=754387
[20:39] <Laney> I don't know how to fix it yet
[20:39] <mterry> Laney, heh
[20:40] <Laney> or, well, I didn't try those ideas in a package yet and upstream didn't say anything
[20:41] <mterry> Laney, we could skip the test...  or just remove it from proposed
[20:43] <Laney> skipping a test for a CVE sounds bad
[20:43] <Laney> doko already removed it anyway
[20:43] <Laney> so no bother
[20:49] <doko> mterry, looks that you actually like perl MIRs ... or else you would have demoted the recommends to a suggest in xdg-utils ;p
[20:49] <mterry> doko, oh no, what did I do?  :)
[20:50] <mterry> Laney, eh, skipping a broken test is ok  :)  But sounds good
[20:51] <mterry> doko, you removed gdk-pixbuf from proposed?
[20:53] <doko> mterry, yes
[20:53] <doko> mterry, just the binaries, not the source
[20:54] <mterry> doko, ah great, thanks!
[20:58] <hallyn> xnox: http://mentors.debian.net/debian/pool/main/n/netcf/netcf_0.2.3-5.dsc    can you please confirm that at line 8 in debian/copyright, that 'permissive' is what the rest of that license text describes?
[20:58] <hallyn> cause 'permissive' is mentioned but not defined in the debian doc about license files
[20:59] <xnox> hallyn: one doesn't need a tag, if one includes text.
[20:59] <xnox> so
[20:59] <xnox> Files: *
[20:59] <xnox> License:
[20:59] <xnox>  <full text>
[20:59] <xnox> or so i remember
[21:15] <hallyn> xnox: that's what it was doing, but lintian now complains
[21:15] <hallyn> so i spent 20 mins looking for a 'custom' tag i could add but didn't find that
[21:16] <xnox> hallyn: it's ok, i would take it with a broken licence tag, if the license is correct.
[21:17] <xnox> hallyn: but it is late now, for me. will look into it tomorrow.
[21:17] <hallyn> xnox: ok, thanks
[21:17] <hallyn> i'll go ahead and start on 1.2.8 then based on merging that and the 1.2.6 in experimental
[21:23] <mterry> @pilot off
[21:23] <udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[21:23] <mterry> @pilot ou
[21:24] <mterry> @pilot out
[23:39] <slangasek> hallyn: -2 uploaded
[23:42] <hallyn> awesome, thx