=== jasox is now known as jasox_afk
=== jasox_afk is now known as jasox
[02:05] <psusi> wtf?  I keep trying to upload a package to my ppa and it gets through the dsc, the tar.gz, and then gets stuck 2k/3k uploading the .changes file...
[02:29] <psusi> ahh I love it when the build queues are nice and short...
=== Zhenech_ is now known as Zhenech
=== Zhenech is now known as 64MAAFA2J
=== AlanChicken is now known as AlanBell
[07:47] <KNRO1> Hello, I'm getting "invalid value" when I try to link a project to an existing Bazaar branch. This is the branch lp:~mutlaqja/libindi/indi-sbig and this is the URL to set the project branch https://launchpad.net/indi-sbig/trunk/+setbranch
[07:47] <KNRO1> Any idea what's going on?
[07:49] <geser> you might want to ask in #launchpad if you don't get an answer here
[07:51] <KNRO1> looks like the names have to exactly match
[07:54] <KNRO1> actually not..
[08:35] <KNRO1> how can I ask to add a package to multiverse?
=== ripps_ is now known as ripps
[08:40] <KNRO1> or universe?
[08:50] <geser> a new package gets usually automatically into universe (DFSG-compliant license) or multiverse (non-free license, but redistributable)
=== almaisan-away is now known as al-maisan
[11:09] <l3on> Hi all... someone can tell me if I did the right thing in bug 899460 ?
[11:09] <ubottu> Launchpad bug 899460 in mrtg (Ubuntu) "mrtg bug was fixed upstream but is not available in stable or unstable ubuntu or debian packages" [Undecided,Fix released] https://launchpad.net/bugs/899460
[11:19] <geser> l3on: have you checked how hard it would be to extract a patch for a SRU? (not sure if it qualifies for SRU)
[11:20] <l3on> geser, I'm working on that :)
[11:35] <l3on_> geser, well.. It seems that the patch could be apply at current ubuntu version (oneiric, natty, maverick)
[11:35] <l3on_> what's the best way to do that ?
[11:41] <geser> check if a SRU would apply for it (not sure myself, I'd would probably ask ubuntu-sru for an opinion) and then prepare the SRUs
[11:52] <l3on_> geser, I fixed mrtg for oneiric natty and maverick
[11:52] <l3on_> I don't remember, I have to set 'natty-update' ?
=== 64MAAFA2J is now known as Zhenech_
[12:12] <dupondje> Hi, somebody could check if syncing tulip (http://packages.debian.org/source/unstable/tulip) is a good idea?
[12:13] <dupondje> package builds fine on Ubuntu precise here (pbuilder-dist)
[12:16] <l3on_> hey guys, someone can change this status from Fix Relaesed to Confirmed, please ? (bug 899460)
[12:16] <ubottu> Launchpad bug 899460 in mrtg (Ubuntu) "mrtg bug was fixed upstream but is not available in stable or unstable ubuntu or debian packages" [Undecided,Fix released] https://launchpad.net/bugs/899460
[12:17] <l3on_> geser, still around ?
[12:40] <geser> l3on_: yes, I'm around
[12:41] <l3on_> geser, can you change the status for bug 899460 ?
[12:41] <ubottu> Launchpad bug 899460 in mrtg (Ubuntu) "mrtg bug was fixed upstream but is not available in stable or unstable ubuntu or debian packages" [Undecided,Fix released] https://launchpad.net/bugs/899460
[12:41] <geser> the distribution for upload is "$release-proposed"
[12:44] <l3on_> yes I used it :)
[12:44] <geser> l3on_: opened tasks for maverick, natty, oneiric. Feel free to assign them to you
[12:44] <l3on_> How can I do it ?
[12:46] <l3on_> did :)
[12:46] <l3on_> s/did/done
[12:46] <l3on_> ok geser and now same procedure? I mean:
[12:47] <l3on_> status confirmed, assignee removing, ubuntu-sponsors subscribing ?
[12:48] <geser> yes
[12:48] <l3on_> Ok, thansk... :)
[13:09] <tumbleweed> dupondje: what makes you unsure about syncing it?
[13:12] <l3on_> hey guys, since bug 569827 is about deprecated 9.10, I can set it as Fix Released ?
[13:12] <ubottu> Launchpad bug 569827 in python-psutil (Ubuntu) "psutil.cpu_percent() returns 0.0 although CPU Usage is higher" [Undecided,Fix committed] https://launchpad.net/bugs/569827
[13:13] <l3on_> what's the best way in this case ?
[13:20] <tumbleweed> l3on_: can we find the patch that fixed it, and SRU it?
[13:21] <l3on_> tumbleweed, in 11.10 it works fine, bug is opened in Karmic Koala ! :)
[13:21] <tumbleweed> l3on_: yes, I can see that from the bug, but nobody has pointed at the upstream commit that fixed it
[13:22] <dupondje> tumbleweed: cause there seems to be blocked in debian to get it into testing
[13:22] <dupondje> but those are build issues, which I didn't had when building it in pbuilder
[13:24] <tumbleweed> dupondje: urm, debian bug 650653 seems to have failed the build on every architecture in debian
[13:24] <ubottu> Debian bug 650653 in src:tulip "tulip: FTBFS: No rule to make target `doc'" [Serious,Open] http://bugs.debian.org/650653
[13:26] <dupondje> weird, but it builded fine :)
=== jdstrand1 is now known as jdstrand
[13:38] <tumbleweed> I'll have a look in a bit. Just busy wit hsomething
=== l3on__ is now known as l3on
[14:13] <KNRO> Hello, how can I request to join the MOTU Science team?
[14:13] <tumbleweed> is motu science still alive?
[14:13] <tumbleweed> (it's great to see some interest in it, though \o/ )
[14:14] <KNRO> tumleweed: well, MOTU in general then. I need to maintain a set of science packages and I've been doing package management for a long period now and have everything synced with upstream. I also happen to be the upstream developer as well.
[14:15] <tumbleweed> are these packages that are maintained by the debian science team? if so I suggest joining them too
[14:16] <KNRO> they are maintained by MOTU
[14:16] <tumbleweed> which packages?
[14:16] <micahg> we could create a science packageset if there's sufficient interest, I think we have one person with PPU right now for quite a few science packages
[14:16] <tumbleweed> as to joining MOTU, you start by just doing things, and when people get tired of sponsoring uploads for you, you'll be told to apply for MOTU membership :)
[14:16] <KNRO> INDI and 3rd party drivers... for example: I'm _already_ maintainer for this package: https://code.launchpad.net/libindi
[14:18] <tumbleweed> looks like it's mostly being maintained by kubuntu people
[14:18] <KNRO> the thing is, I'm also tired of asking for syncing with upstream.. and sometimes packaging is not done correctly. Plus, this is hardware related drivers for astronomical instruments, I do packaging, then I clean them on new clean system, and test with _real_ hardware.
[14:18] <KNRO> I doubt anyone in MOTU now can do that
[14:18] <KNRO> clean=install
[14:18] <Resistance> libindi is maintained by Kubuntus
[14:18] <tumbleweed> yes, packages like that could definitly use some love by upstream :)
[14:18] <Resistance> not the MOTUs (directly)
[14:19] <tumbleweed> right, kubuntu maintain it for kstars
[14:19] <Resistance> ^
[14:19] <KNRO> Tumbleweed: so I ask in Kubuntu then?
[14:20] <KNRO> I'm also KStars developer :P
[14:20] <tumbleweed> KNRO: yes, it's in main not universe, so MOTU can't touch it
[14:20] <KNRO> tumbleweed: the _rest_ of the packages are in universe and multiverse.
[14:20] <Resistance> tumbleweed:  if i'm reading the source package page for libindi right, then the Kubuntu Members group has access, and that'd require Kubuntu Council intervention to change?
[14:21]  * Resistance is making wild assumptions, hence the question
[14:21] <KNRO> only libindi is in main.. everything else is in universe...
[14:21] <KNRO> Resistance: actually, I am put there as the maintainer. so I was able to make changes there to link to upstream.
[14:21] <tumbleweed> libindi also recently made it into debian, so ubuntu might start using that packaging
[14:22] <tumbleweed> (I don't know how much kubuntu people do their own thing vs pull from debian)
[14:22]  * Resistance peeks at debian
[14:22] <Resistance> tumbleweed is right, its in debian now
[14:22] <KNRO> hmmmm, how would you know that?
[14:23] <tumbleweed> packages.qa.debian.org/libindi
[14:23] <KNRO> so if a package is in debian, it is just copied over?
[14:23] <tumbleweed> no, it's more complex than that :)
[14:23]  * Laney blinks at the name of the team
[14:23] <tumbleweed> link-hover suggets it's the kde people :P
[14:24] <tumbleweed> KNRO: most of ubuntu is unmodified debian, rebuilt
[14:24] <KNRO> lol what KDE people specifically? I'm in KDE.
[14:24] <tumbleweed> KNRO: another large chunk is minor modifications of debian package (often temporary)
[14:25] <tumbleweed> and the remaining packages (like the current libindi package in Ubuntu) come straight from upstream, not debian
[14:25] <KNRO> Tumbleweed: but if libindi now in Debian, they will no longer take it from upstream?
[14:26] <tumbleweed> probably
[14:26] <tumbleweed> unless there's a good reason not to, that'd be the best way to go
[14:26] <KNRO> What about other packages in universe?
[14:27] <tumbleweed> what about them?
[14:27] <KNRO> how can I maintain them myself? or if I need to add a new INDI driver...etc...
[14:27] <Resistance> don't the MOTUs hold priority over Universe?
[14:27] <Resistance> (if i'm not mistaken)
[14:27] <tumbleweed> Resistance: what do you mean by that?
[14:28] <Resistance> tumbleweed: priority as in control over the Universe packages
[14:28] <tumbleweed> Resistance: MOTU can touch anything in universe/multiverse, but should exercise a little caution when touching something that's also seeded
[14:28] <tumbleweed> (around freezes)
[14:29] <tumbleweed> KNRO: https://wiki.ubuntu.com/SponsorshipProcess
[14:29]  * Resistance peeks at the u+1 dev schedule
[14:29] <Resistance> oic
[14:30] <micahg> well, MOTU should also be careful with seeded packages WRT new upstream releases that the flavors might not want (especially in an LTS)
[14:30] <Resistance> i take it the freeze you mentioned tumbleweed is the Debian Import freeze?
[14:30]  * Resistance is looking at the release schedule
[14:31] <tumbleweed> Resistance: no, alphas and other freezes that build ISOs
[14:32] <Resistance> well unless there's a time issue with the release schedule on the wiki, the next release (alpha) isnt until february, no?
[14:32] <tumbleweed> Resistance: I was replying to your question over packages in universe that overlap with packagesets
[14:32] <Resistance> ahh
[14:32] <Resistance> i see
[14:33]  * Resistance retreats to lurk mode once more :)
[14:39] <KNRO> Sponsorship is not clear? I file a "bug" for package inclusion ?
[14:40] <tumbleweed> KNRO: we prefer to bring in new packages via debian https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[14:40] <tumbleweed> so I encourage you to engage with debian science / debian qt people
[14:41] <KNRO> Tumbleweed: yes ok, what if Debian do not include these packages?
[14:41] <KNRO> Do yo also import Universe packages from Debian?
[14:41] <tumbleweed> most of universe is from debian
[14:41]  * Resistance points at ZNC as an example
[14:41] <KNRO> and multiverse?
[14:41] <tumbleweed> yes
[14:41] <KNRO> I have one package in multiverse...
[14:41] <Resistance> the version in precise atm is based off of debian universe's version
[14:42] <micahg> ~75% of universe is from Debian
[14:42] <KNRO> ok so debian it is :)
[14:42] <tumbleweed> KNRO: debian will almost always accept new packages
[14:42] <micahg> *unmodified from Debian
[14:42] <KNRO> if a package makes it to debian, no need to inform folks in ubuntu to include it ?
[14:42] <KNRO> it's automatic?
[14:43] <tumbleweed> semi-automatic. You don't need to poke anyone, but it needs manual review
[14:44] <tumbleweed> however, we are now at Debian Import Freeze. So *anything* new from debian needs to be requested
[15:00] <ScottK> micahg: 75% of the whole archive is unmodified from Debian, IIRC.  I think the percentage for Universe is higher.
[15:01] <micahg> well, the graph on merges.ubuntu.com looks around 75%
[15:03] <ScottK> OK.
[15:04] <Resistance> micahg:  tumbleweed:  for the "znc" package, they found a vulnerability in one of the modules... when the upstream fix is released, what does one need to do to get that fix included in the ubuntu repos (its in universe)?
[15:04] <micahg> I'm curious what the real numbers are
[15:04] <micahg> Resistance: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation
[15:05] <Resistance> micahg:  if the upstream fix also changes the version number, what then?  (the ZNC devs are releasing the fix as 0.204 rather than 0.202 (current version) )
[15:06] <micahg> Resistance: you need to get a patch (preferably from upstream VCS), to fix the issue, version updates for a CVE are usually not allowed
[15:07] <ScottK> (except for in the development release - i.e. precise)
[15:07] <micahg> right
[15:07] <Resistance> i fully expect this to be dumped into precise at some point (unless the code release with the fix is after the freeze)
[15:08] <Resistance> because the version of ZNC in question with the vulnerability is only in universe in precise (its in -backports for oneiric and natty)
[15:08] <micahg> Resistance: after it's in precise, you can request new backports
[15:12] <Resistance> well i found a patch...
[15:12] <Resistance> should i file a bug against the source package or the project?
[15:12]  * Resistance assumes the source package, but...
[15:13] <ScottK> Yes.
[15:19] <Resistance> the bug is now filed, complete with the patch from Debian, and a link to the upstream fix.  :)
[15:19] <Resistance> i'll let someone else fix it
[15:22] <tumbleweed> Resistance: why not do it yourself? :)
[15:22] <Resistance> tumbleweed:  because i have class in 10 minutes? :p;
[15:23] <Resistance> (and i fully expect to attempt to fix it after my last class is over, at 8PM :/)
[15:23] <Resistance> in the mean time, i'm busy :P
[16:13] <teratorn> hi, anyone have a clue what might be a simple up-to-date native shared library package I could use as an example to help in a new packaging effort?
=== l3on__ is now known as l3on
=== al-maisan is now known as almaisan-away
=== jasox is now known as jasox_study
[17:13] <Laney> cyphermox: I think something went wrong with valatoys: http://packages.ubuntu.com/precise/amd64/libafrodite-0.12-2/filelist
[17:30] <tumbleweed> dupondje: you'll notice that tulip builds with -b but not -B
[17:33] <andreas__> hi, can someone sponsor this? https://bugs.launchpad.net/pytz/+bug/885163
[17:33] <ubottu> Ubuntu bug 885163 in python-tz (Ubuntu Oneiric) "pytz dst() incorrectly handles Pacific/Apia day leap" [Undecided,New]
=== Quintasan_ is now known as Quintasan
=== jasox_study is now known as jasox
[19:09] <dupondje> tumbleweed: how you mean ?
[19:17] <tumbleweed> dupondje: it'll build when you are building the architecture-independant packages too, but not when you are only building the architecture-dependant packages (like the Ubuntu non-i386, and all the debian buildds do)
[19:17] <dupondje> ahhh! ok
[19:19] <tumbleweed> (pretty trivial to fix, if you want to provide a patch :) )
[19:20] <dupondje> is there a way to test it in pbuilder ?;)
[19:21] <tumbleweed> yes. --binary-arch
[19:28] <tumbleweed> andreas__: meh, the debian python-tz is rather out of date
[19:30] <tumbleweed> surely there are other important updates for it too?
[19:32] <andreas__> tumbleweed: I don't know, I'm not the maintainer, I was focusing on fixing this bug which is rather important for me
=== andreas__ is now known as ahasenack
[19:33] <ahasenack> tumbleweed: I assume you were talking about the new version that is out there, that could have been uploaded to precise instead of the patched package?
[19:33] <tumbleweed> yeah
[19:33] <tumbleweed> we follow tzdata upstream releases, and SRU them everywhere
[19:33] <ahasenack> yeah, I didn't do that because I'm not the maintainer and I wouldn't be able to verify the other changes
[19:34] <tumbleweed> I assume we don't do this for python-tz, because of the handful of roather unimportant reverse deps
[19:34] <ahasenack> and  because it's code
[19:35] <tumbleweed> still, not that useful when it's out of date
[19:36] <l3on> hey guys, is it today the freeze update ?
[19:36] <l3on> or the 12th ?
[19:36] <tumbleweed> oh, duh, it takes the tzinfo from tzinfo
[19:36] <tumbleweed> err zoneinfo from tzdata
[19:37] <ahasenack> tumbleweed: yes
[19:37] <ahasenack> it's not duplicated
[19:38] <tumbleweed> thankfully
[19:42] <tumbleweed> bdrung: sponsor-patch should be able to guess the task from the UDD branch
[19:43] <bdrung> tumbleweed: that makes sense.
[19:43] <bdrung> tumbleweed: patches are welcome. :p
[19:43] <tumbleweed> first... let me fix a bug in my last change there
[19:45] <tumbleweed> ahasenack: SRU uploads should be targetted at $release-update
[19:45] <ahasenack> aaarrrrghhhhhhhh
[19:45] <ahasenack> I forgot that
[19:45] <tumbleweed> np
[19:45]  * tumbleweed 'll fix them up
[19:45] <ahasenack> really? I love you
[19:45] <tumbleweed> err -proposed
[19:46] <ahasenack> yep :)
[19:46] <ahasenack> want me to push a fix? I can do that
[19:46] <ahasenack> in fact, I'll do it anyway, to remain consistent
[19:47] <tumbleweed> I'm busy uploading lucid. You can fix the others
[19:47] <ahasenack> ok
[19:52] <ahasenack> tumbleweed: done and pushed for maverick, natty and oneiric
[20:03] <tumbleweed> bdrung: fix committed
[20:10] <tumbleweed> ahasenack: removed the .11.10 from the oneiric one. Unecessary. All uploaded, pending SRU team review...
[20:10] <ahasenack> tumbleweed: ok, thanks again and sorry for that rookie mistake
[20:10] <tumbleweed> pish, np
[20:11] <tumbleweed> we generally make the rookies get everything perfect, though :)
[20:11] <ahasenack> tumbleweed: without that 11.10 from the release, will the updated natty package still upgade to the oneiric one?
[20:11]  * ahasenack checks
[20:12] <tumbleweed> ahasenack: there was only one release with that version, so a .1 was fine
[20:12] <ahasenack> so python-tz-2010b-1ubuntu0.11.04.1 to python-tz-2010b-1ubuntu2?
[20:12] <tumbleweed> 2010b-1ubuntu1.1
[20:13] <ahasenack> ok, that works
=== and` is now known as and
=== and is now known as and`
=== JanC_ is now known as JanC
=== yofel_ is now known as yofel
[21:32] <micahg> siretart: with only lintian overrides and gbp configuration left, is there a reason to not sync libav-extra from Debian?
[21:33] <siretart> micahg: did you check that all build dependencies are really the same?
[21:33] <siretart> micahg: if they are the same, then syncing it would indeed make things easier
[21:34] <micahg> I did a debdiff between the current version in Ubuntu and the one in Debian, the only diff was the versioning on the libav-source
[21:34] <siretart> cool
[21:34] <micahg> siretart: so, I'll test build and sync then
[21:34] <siretart> thanks!
[21:35] <siretart> it'll still need no-change rebuilds each time libav is uploaded, though
[21:35] <siretart> or to be more specific, each time libav-source is updated
[21:36] <siretart> but usually, future syncs of libav-extra should take care of that
[21:37] <micahg> cool
[22:22] <dupondje> siretart: there ?
[22:38] <siretart> dupondje: almost gone, but what's up?
[22:42] <dupondje> siretart: http://packages.debian.org/source/unstable/live-config
[22:42] <dupondje> can be synced ?
[22:45] <siretart> dupondje: I think it needs a merge rather than a sync
[22:46] <siretart> dupondje: also, I don't think that the upstart job for live-config is correct yet. I still need to file a proper bug and ask upstart-devel how to fix that
[22:49] <dupondje> siretart: all changes are in debian now, except a restart after reconfig of lxdm
[22:51] <l3on_> hey guys, someone can tell me how to fix this kind of bug? (bug 898027)
[22:51] <ubottu> Launchpad bug 898027 in pywbem (Ubuntu) "package python-pywbem (not installed) failed to install/upgrade: trying to overwrite '/usr/bin/wbemcli', which is also in package wbemcli 1.6.1-0ubuntu1" [Undecided,Confirmed] https://launchpad.net/bugs/898027
[22:51] <l3on_> wbemcli should conflict with python-pywbem (or viceversa), is it right ?
[23:03] <dupondje> btw
[23:03] <dupondje> somebody knows what we can do with https://launchpad.net/ubuntu/+source/eggdrop/+changelog ?
[23:03] <dupondje> the current version includes a SSL patch (delta with debian)
[23:03] <l3on_> dupondje, I looked at this
[23:04] <dupondje> we can merge it with the ssl patch, but the SSL patch is highly discouraged by upstream (eggdrop dev)
[23:04] <Resistance> i found a patch for a vulnerability in the ZNC Source package in Precise, how do i add the patch to the source package and have it uploaded and added into the Precise repos?
[23:04] <l3on_> Yes, you're right
[23:04] <dupondje> and if I look at the bugreports
[23:04] <dupondje> I see half of them caused by the bad ssl patch
[23:04] <dupondje> so ...
[23:04] <Resistance> tumbleweed:  'tis the patch i found for ZNC, and I want to apply it myself
[23:04] <dupondje> kick out the patch and sync (but lose SSL) ?
[23:05] <dupondje> or merge with a new crappy patch included still ...
[23:05] <dupondje> )
[23:05] <dupondje> Resistance: no new version released of ZNC for that ?
[23:05] <l3on_> dupondje, I chose to do nothing
[23:06] <broder> dupondje: what about "fix the patch"?
[23:06] <Resistance> dupondje:  released in 0.204, which is in alpha, upstream fix referenced (and a debian patch) in LP bug #913836
[23:06] <ubottu> Launchpad bug 913836 in znc (Ubuntu) "ZNC 0.202: vulnerability in bouncedcc module" [Undecided,New] https://launchpad.net/bugs/913836
[23:06] <Resistance> dupondje:  patches exist for ZNC 0.200 and 0.202 in Debian, and was updated in Debian
[23:07] <l3on_> . Note this patch does not have 64-bit or thread support
[23:07] <l3on_> dupondje, so can it build on amd64?
[23:07] <dupondje> 0.202-2 will get synced :)
[23:08] <dupondje> @ Resistance
[23:08] <l3on_> what about take directly dev version 1.8.x ?
[23:08] <dupondje> l3on_: it is build at least ;)
[23:08] <l3on_> lol
[23:10] <Resistance> dupondje:  when, because I need it backported to Oneiric and Natty too (per my backport requests which were approved by broder, see LP bug #887758)
[23:10] <ubottu> Launchpad bug 887758 in Oneiric Backports "Please backport znc 0.202-1 from precise to natty" [Undecided,Fix released] https://launchpad.net/bugs/887758
[23:11] <Resistance> and if those backports have the same DoS vulnerability, i'd request a re-backport or a specific import :P
[23:11] <dupondje> guess they do a last sync before freeze
[23:11] <dupondje> but you can bug a syncrequest
[23:12] <Resistance> where do i file that bug?
[23:12] <Resistance> against Precise?
[23:12] <Resistance> or just against Ubuntu?
[23:13] <Laney> !sync
[23:13] <ubottu> Helpful information for filing a sync request can be found at https://wiki.ubuntu.com/SyncRequestProcess
[23:21] <Resistance> Laney:  LP Bug #914026.  Is that formatted right?
[23:21] <ubottu> Launchpad bug 914026 in Ubuntu "Please sync znc 0.202-2 from Debian Sid to Precise" [Undecided,New] https://launchpad.net/bugs/914026
[23:23] <Riddell> can we take a swap day for a conference leave day which is on a weekend?
[23:23] <Riddell> oh hmm, wrong channel
[23:24] <l3on_> Resistance, why you don't use 'requestsync' script ?
[23:24] <Laney> Resistance: looks good (would be nice if you include the new changelog entries), but in future you might find it easier to use the requestsync script
[23:24] <Resistance> Laney:  which package has said script?
[23:24]  * Resistance is new at requesting syncs
[23:25] <Laney> ubuntu-dev-tools
[23:26] <jtaylor> I don't like the new command-not-found :(
[23:26] <jtaylor> I was so used to just copy pasting the command from the output
[23:26] <Resistance> Laney:  requestsync -d sid znc precise  <-- correct syntax?
[23:26]  * Resistance might redo the request if he feels it necessary
[23:27] <Laney> might be unstable instead of sid, and you don't need to specify precise (should be the default)
[23:27] <Laney> no need to re-file though, just add the changelog entries to your bug and it's ok
[23:27] <l3on_> and use '--lp' if you dont have a MTA configured
[23:28] <Resistance> Laney:  changelogs from debian?
[23:29] <Laney> yes
[23:29] <Laney> it's nice for reviewers to see the new changelog entries
[23:29] <Resistance> Laney:  so if ther's only one entry, just copy-paste from the changelog into the bug?
[23:29]  * Resistance has the debian changelog here on screen
[23:29] <dupondje> thre is an issue btw with changelog.debian.org :(
[23:30] <Resistance> dupondje:  i did dget <path to .dsc>
[23:30] <Resistance> :P
[23:30] <dupondje> http://packages.debian.org/changelogs/pool/main/p/python-poppler/ vs http://packages.qa.debian.org/p/python-poppler.html
[23:30] <dupondje> missing alot of changelogs :(
[23:30] <Laney> it doesn't work with 3.0 (quilt) afaik
[23:30] <jtaylor> that issue is quite old and very annoying :/
[23:30] <Laney> patches welcome, etc
[23:31] <Resistance> Laney:  could you take a peek at the bug again? (i.e. refresh)
[23:31] <Laney> looks good
[23:32] <Resistance> :)
[23:32] <Resistance> now i need to apply the patch to my fork :P