[00:02] <zul> evening
[00:03] <bderrly> afternoon
[00:32] <mruiz> hi all
[00:44] <Hobbsee> hey all
[00:46] <awen_> hi people
[00:46] <mruiz> hi Hobbsee
[00:46] <Hobbsee> greetings mruiz!
[00:47] <mruiz> :-)
[00:48] <mruiz> Hobbsee, Did you read my comment about bug 178869?
[00:48] <ubotu> Launchpad bug 178869 in gnome-voice-control "[FTBFS] gnome-voice-control due to automake-1.9 build-dep" [Undecided,New] https://launchpad.net/bugs/178869
[00:49] <Hobbsee> mruiz: no
[00:50] <tritium> Hi Hobbsee
[00:50] <Hobbsee> heya tritium
[00:59]  * tritium wonders what part of the topic changed...
[00:59] <zul> hey Hobbsee
[00:59] <Hobbsee> hiya zul
[01:00] <zul> good christmas?
[01:00] <Hobbsee> yeah
[01:02] <ion_> How often is it appropriate to request packages to be reviewed if the previous request wasn’t noticed or acted upon? I asked about http://revu.tauware.de/details.py?package=hardware-connected and http://revu.tauware.de/details.py?package=apt-mark-sync five hours ago.
[01:03] <zul> ion_: well it is the christmas break for most developers so you kind of have to be patient
[01:03] <ion_> I am in no hurry. I’m just asking not to offend anyone by spamming the request. :-)
[01:04] <imbrandon> ion_: normaly once a week ( mondays )
[01:04] <ion_> imbrandon: Okay, thanks.
[01:05] <zul> hey imbrandon
[01:05] <imbrandon> heya zul
[01:33] <persia> psus: -sa will probably solve your problem.
[01:33] <persia> jonnymind: -0falcon1 would be a good way to be lower than either an upcoming Ubuntu or Debian release.
[01:34] <persia> ion_: Once a day, but people may well not look except on Mondays.  On Mondays (any time zone) maybe every 6 hours is acceptable.
[01:35] <ion_> persia: Thanks.
[01:36] <persia> imbrandon: There's some further oddity in the buildd chroot.  I can't even get a manual apt-get dist-upgrade to work from a chroot into the buildd tarball: it seems to be more complicated than just a normal update.
[01:37] <TheMuso> Greetings all.
[01:38] <zul> hey TheMuso
[01:39] <TheMuso> Hey zul.
[01:39] <TheMuso> Have a good break?
[01:39] <persia> ion_: What is ./.gpb.conf ?
[01:39] <zul> yeah was kind of sick the past couple of days ago
[01:40] <TheMuso> Ah that sucks.
[01:40] <ion_> persia: The ”upstream” source and the packaging are in a single git repository but in different branches. That config file tells git-buildpackage which branch to generate the orig.tar.gz from and which branch to get debian/ from, so you can just cd to the repository tree and run git-buildpackage.
[01:41] <persia> ion_: OK.  VCS leftovers then.  Thanks.
[01:43] <ion_> persia: It *can* be removed, then one just needs to supply the branch names to git-buildpackage as parameters.
[01:44] <persia> ion_: I haven't used git-buildpackage, but I've been advised that for svn-buildpackage, it's best practice to strip all the VCS stuff when making the package.
[01:45] <imbrandon> persia: ahh that sucks
[01:46] <persia> imbrandon: Does it?  If there are enough people who believe that .gbp.conf should normally be included in a source package, I don't see any reason why it couldn't, but I haven't seen that file in many packages (even ones I know to be managed in git)
[01:46]  * persia realises that the wrong context was chosen :(
[01:48] <persia> ion_: apt-mark-sync commented.  Only GPL version, priority, and missing mechanism for collecting upstream code are blockers.
[01:49] <ion_> persia: Thank you. I’ll take care of the same issues for the other package as well.
[01:49] <persia> ion_: OK.  I won't review it now then :)
[01:49] <ion_> I’ll also make sure .gbp.conf doesn’t spill into the package.
[01:50] <imbrandon> persia: i ment about the buildd
[01:50] <persia> imbrandon: Right.  Sorry :)  The buildd tarball is available from http://launchpadlibrarian.net/10891721/chroot-ubuntu-hardy-i386.tar.bz2 if you want to have a play.
[01:51] <imbrandon> maybe here in a bit, i doubt i can do much better than yall did though
[01:51] <persia> (warning: 50MB behind that link)
[01:51] <imbrandon> onyl 50? wow
[01:51] <imbrandon> i figured much more, i just downloaded 6gb so another 50 wont be bad
[01:51] <persia> A lot of base is text, and bz2 does a pretty good job.
[01:52] <imbrandon> yea
[01:55] <persia> Hrm.  New Debian audacity doesn't work with JACK for some architectures, and current Ubuntu audacity doesn't seem to work with pulseaudio.  Anyone have any thoughts on how audacity should work?
[01:57] <brandonperry> it should _just_ work :-P
[01:58] <imbrandon> persia: imho whatever is default for hardy
[01:58] <imbrandon> but i dislike JACK sooo
[01:59] <persia> brandonperry: Yes.  I'm just not sure pushing through padsp is the right answer.  To me it makes sense to either whitelist audacity to block pulse, or to ignore the possible portaudio issues and force JACK.
[01:59] <persia> imbrandon: Do you use audacity?  What is your typical input source?
[02:00] <Fujitsu> persia: What are `some architecture'?
[02:00] <imbrandon> persia: files
[02:00] <imbrandon> eg ogg or mp3 or something other
[02:01] <persia> Debian bug #406754
[02:01] <ubotu> Debian bug 406754 in portaudio19 "portaudio19: FTBFS: #error Memory barriers are not defined on this system." [Serious,Fixed] http://bugs.debian.org/406754
[02:01] <imbrandon> if i use "live" input its generaly with jokosher+gst
[02:01] <persia> Err..  That's not right.
[02:01] <imbrandon> and yea i use it once or twice a week
[02:01] <brandonperry> persia, sorry, I not exaclty sober right noww
[02:01] <brandonperry> ignore me
[02:01] <imbrandon> but not a "ton"
[02:02] <persia> Fujitsu: all !i386 !powerpc
[02:02] <Fujitsu> Not even amd64?
[02:02] <persia> imbrandon: Ah.  So for your usecase, padsp would work fine.  Thanks.
[02:02] <persia> Fujitsu: Nope.
[02:04] <persia> Fujitsu: Actually, on review, it seems the bug I mentioned before is correct, just that the exposure in audacity is due to a private included library (Grr...)
[02:05] <Fujitsu> Woo!
[02:11] <ion_> persia: I take it i should file a bug at launchpad so that i can close it with the initial release?
[02:12] <persia> ion_: If there isn't already one there.  I tend to see lots of needs-packaging dupes, so please search to help reduce the count.
[02:12] <ion_> Ok
[02:20]  * Fujitsu wonders what the heck is wrong with the buildd chroot. It certainly won't dist-upgrade, but after installing (dpkg -i from /var/cache/apt/archive) bits of the dependency chain (from the new tzdata through libc6 through libc6-amd64...) it dist-upgrades fine...
[02:23] <persia> Fujitsu: Does it dist-upgrade fine for you?  I was getting an error about immediate configuration.  If it works for you, someone just needs to publish the upgraded chroot on launchpad.
[02:24] <Fujitsu> persia: Not from the start - I had to install a couple of bits (including libstdc++6) manually, then dist-upgrade worked.
[02:24]  * Fujitsu pokes harde.r
[02:25] <persia> Fujitsu: In that case, it just needs to be adjusted not to need manual installation (maybe a dependencies chain?) or needs the results of the manual push to be published.
[02:26] <Fujitsu> persia: Now I know how to unbreak it like that, I'm working out exactly what is wrong.
[02:28] <Fujitsu> OK, upgrading libc6(-dev) is enough to get it working, but that wants a new tzdata too.
[02:29] <ion_> persia: Is “and is licensed under the same terms as the upstream package, see above.” okay?
[02:30] <persia> ion_: Entirely.  I was asking for the addition of the text "v2", but that works just as well (if a bit more work).
[02:30]  * Fujitsu forgets when the problem appeared. Was it after the 24th?
[02:30] <ion_> persia: I was thinking of writing that to have no ambiguity about whether it’s “v2” or “v2 (or any later version”. :-)
[02:31]  * persia looks at logs
[02:31] <persia> ion_: Good choice
[02:32] <persia> Fujitsu: First reference to the problem I can find is 2007 December 25 09:37 UTC
[02:33] <Fujitsu> persia: So just after the new libc6 upload.
[02:33] <persia> Fujitsu: ~ 24 hours later.
[02:33] <Fujitsu> RIght.
[02:47] <Fujitsu> Simply adding to libstdc++6 a Pre-Depends on the new libc6 makes everything work perfectly.
[02:50] <persia> Fujitsu: Excellent.  Is that likely to break anything else?
[02:51] <Fujitsu> persia: I've no idea. It should be necessary, though.
[02:52] <Fujitsu> *shouldn't
[02:53] <persia> Fujitsu: As I understand it, our choices are to either upload an automagical fix (like that), or wait for someone to publish the results of a manual dist-upgrade.  I wonder why it worked for most people's local chroots.
[02:54]  * persia realises that the upgraded libstdc++6 probably can't build on the current buildds, so the manual path may be the correct choice.
[02:56] <Fujitsu> I'm trying to reproduce it in a clean chroot here.
[02:56] <Fujitsu> But it will need to be done manually on the buildds, right.
[03:07]  * Fujitsu shrugs, and decides that cosmic rays did something bad to the buildd chroots.
[03:07] <persia> ion_: Don't worry about it this time, but in general it's nice to have a little advertisement for the package and a link to the homepage in the needs-packaging bugs.
[03:07] <Fujitsu> I guess we poke somebody to upgrade libc6 manually and dist-upgrade all of the broken ones.
[03:07] <persia> Fujitsu: That sounds about right.  Monday, I'd think.
[03:07] <Fujitsu> I can't work out what makes them fail when a similarly versioned one here works fine.
[03:09] <Fujitsu> persia: I doubt anybody will be here on the 31st...
[03:10] <persia> It's part of the official Holiday break?  I thought it was considered a working day.
[03:13] <ion_> persia: Ok :-)
[03:14] <ion_> persia: I made the changes to apt-mark-sync. They should be visible in REVU soonish.
[03:16] <ion_> Oh, i accidentally uploaded a .changes file with both source and binary files. I wonder how REVU handles it?
[03:16] <Fujitsu> It won't even see it.
[03:16] <Fujitsu> It globs for *_source.changes
[03:21] <nixternal> imbrandon: are kdebindings going in /usr/lib/kde4/* ?
[03:37] <bddebian> Heya gang
[03:39] <nixternal> boo
[03:43] <bddebian> Heh, hi nixternal
[03:43]  * nixternal kicks imbrandon in the shin!
[03:44] <nixternal> imbrandon: I updated kde.mk to the latest from debian, removed utils.mk, and updated the .install files to follow the kde.mk, and all is seeming well thus far
[03:59] <Fujitsu> Blergh, I think apt is doing stupid things on the buildds. It's not even trying to upgrade libc6 until the end, so libc6-amd64 won't configure, so lib64gcc1 won't configure, so apt can't find anywhere to configure libstdc++6.
[04:00] <nixternal> Fujitsu: ya, been doing that for a few days now
[04:00] <Fujitsu> Right, but I'm trying to work out *why*.
[04:00] <Fujitsu> apt-get's debug output isn't the best.
[04:02]  * Fujitsu wishes he could manipulate apt's TODO list after it had calculated it.
[04:02] <ion_> persia: In case you still feel like reviewing, i (think i) implemented the changes you requested in http://revu.tauware.de/details.py?package=apt-mark-sync and http://revu.tauware.de/details.py?package=hardware-connected :-)
[04:11] <imbrandon> nixternal: sorry was afk
[04:11] <imbrandon> nixternal: sounds good
[04:12] <nixternal> my build box just over heated :)
[04:12] <imbrandon> heh
[04:12] <imbrandon> did you add install files for the other packages ?
[04:12] <imbrandon> or just what was there already ?
[04:13] <nixternal> just what was there so far...I will add the rest as needed
[04:13] <imbrandon> killer ok
[04:13] <nixternal> rules just includes the debian/cdbs/kde.mk now, as it controls everything for kde4
[04:13] <imbrandon> basicly just each of the top level dirs ( its a checkout of trunk in kdebinding )
[04:13] <imbrandon> kk
[04:18] <minghua> So no package is being built now?
[04:20] <Fujitsu> minghua: The four big architectures have broken buildd chroots, right.
[04:20] <minghua> Fujitsu: Thanks.
[04:21] <Fujitsu> This naturally happens a day or two after the Canonical world vanishes for a week.
[04:21] <CheGuevara> why do people mess with core packages like glibc right on christmas eve :P
[04:21] <minghua> Well, not a convenient time for buildds to break, of course.
[04:21] <minghua> But maybe they break every now and then, it's just we are noticing now because of the holiday. :-P
[04:22] <imbrandon> gnight all
[04:23] <CheGuevara> night imbrandon
[04:23] <Fujitsu> Night imbrandon.
[04:35] <Fujitsu> Oh blergh. LP is being braindead, yay.
[04:36] <Fujitsu> Any of the links on https://edge.launchpad.net/ubuntu/+source/gcc-4.2/4.2.2-4ubuntu1/+files/ work for anybody?
[04:37] <minghua> Fujitsu: Not for me.  I get 404 with OOPS numbers.
[04:38] <Fujitsu> minghua: That's what I thought.
[04:38]  * Fujitsu attacks kiko.
[04:39] <minghua> persia_: Hello there.
[04:39] <persia_> minghua: Hey.
[04:40] <minghua> persia_: In case you remember my problematic (or in your words, incorrect) test case about dates we talked about the other day, I changed my test case and enumerated all possible dates for testing.
[04:40] <minghua> :-)
[04:40]  * minghua is now much more confident about his code's correctness.
[04:41] <persia_> minghua: Excellent.  That sounds like the right question to be asking :)
[04:46]  * Fujitsu kicks apt.
[04:47] <Fujitsu> (both for having too little debugging output, and needing to be debugged in the first place)
[04:47]  * persia_ is unable to suspend disbelief that there is code which does not need to be debugged
[04:50] <Fujitsu> Shouldn't it be smart enough that if `apt-get install libc6' can't happen due to conflicts with the currently installed tzdata, it will install the new one which isn't conflicted with?
[04:51] <persia_> Fujitsu: Isn't that why aptitude was written?
[04:52] <minghua> I thought that's why apt was written in the first place...
[04:52] <Fujitsu> I would have thought that that case wouldn't have been too uncommon, but perhaps so.
[04:53] <persia_> There are a couple cases where apt dependency resolution can cause issues, which is part of why it became common to use `apt-get dist-upgrade` in sid, rather than `apt-get upgrade`.  aptitude is smarter about these things, and handles several cases better.  Updata-manager is even better, but only tuned for full release upgrades.
[04:53] <minghua> Fujitsu: It's probably very uncommon for daily (i.e., not buildd) use, as people would have used "apt-get upgrade" instead.
[04:54] <bddebian> persia_: Hey man.  I assume wx-config --ldflags is now wx-config --ld ?
[04:54] <minghua> Hmm, update-manager looked pretty stupid to me last time I used it for gutsy->hardy upgrade.
[05:07]  * Fujitsu wonders why libstdc++6 needs lib64gcc1 on i386. Removing that dep makes a dist-upgrade work fine.
[05:08]  * minghua can only say that listdc++6 on Debian i386 does NOT depend on lib64gcc1...
[05:09] <Fujitsu> Only -4ubuntu2 does here, where it appears we moved to symbol-based shlibs.
[05:09] <StevenK> Didn't -4ubuntu3 get built?
[05:09] <Fujitsu> StevenK: It got killed by the chroots.
[05:10] <Fujitsu> chroot failures, that is.
[05:10] <StevenK> Ahhh, it was killed by -4ubuntu2
[05:10]  * Fujitsu thought -4ubuntu2 FTBFS on amd64, which -4ubuntu3 was meant to fix, but didn't, because the chroot was borked.
[05:10] <minghua> * Fix typo in lib32gomp1 symbol file.
[05:11] <minghua> That's in -4ubuntu3's changelog, probably why.
[05:11] <Fujitsu> Oh, -4ubuntu3 built on amd64.
[05:11] <Fujitsu> But then why isn't amd64 unbroken?
[05:12] <minghua> Errr... because amd64 is 64bit?
[05:12] <Fujitsu> StevenK: If -4ubuntu2 was the thing that killed it, why is amd64 dead?
[05:12] <minghua> (if libstdc++6 depending on lib64gcc1 was the reason buildds got broken, that is)
[05:13] <minghua> Ahh, I apparently misread Fujitsu.
[05:13]  * minghua shuts up.
[05:15] <Amaranth> minghua: The upgrade program for gutsy->hardy hasn't been written yet, thus update-manager won't do a very good job with it
[05:15] <minghua> Amaranth: Oh.  Thanks.
[05:15] <bddebian> Gah, how the hell does 'g++' just all of the sudden stop working in a build?
[05:16] <Fujitsu> Right, why does amd64 libstdc++6 want lib32gcc1, while the i386 one wants lib64gcc1? That sounds wrong.
[05:16]  * Amaranth cries
[05:17]  * bddebian too
[05:17] <Amaranth> multiarch causes pain
[05:17] <persia_> Fujitsu: multiarch
[05:17] <Amaranth> That's for cross compiling, right?
[05:21] <superm1> wha, multiarch is in apt now?
[05:21] <Amaranth> no
[05:21] <persia_> Amaranth: Well, also to support a mixed 32/64 bit environment.  There are applications that do better with 32-bit due to odd code assumptions, and it'd be nice to be able to generate a binary for amd64.  Similarly, there are applications that really want 64-bit, and it would be nice to provide an i386 binary (even if it runs slowly).
[05:22] <Amaranth> at this point by the time apt would grow multiarch support it probably wouldn't be worth having anymore :P
[05:22] <Fujitsu> How very odd. In the broken chroot, one must install tzdata before everything else, for the moment. After that, installing lib64gcc1 then dist-upgrading works, but dist-upgrading without manually installing lib64gcc1 (even though the dist-upgrade tries to install it) fails.
[05:25] <Fujitsu> It seems the dist-upgrade just for some reason doesn't get around to installing libc6 before it tries to install lib64gcc1... Blah.
[05:28] <minghua> Fujitsu: Interesting case.  Did you test in a buildd yourself, or did you just read the logs?
[05:30] <Fujitsu> minghua: I have the chroot tarball and am trying things on it here.
[05:31] <minghua> Fujitsu: Would aptitude fare any better than apt-get?
[05:31] <Fujitsu> minghua: Oh yes, the upgrade works flawlessly there.
[05:32] <minghua> Fujitsu: Hmm.  I remember similar things happening when people tested woody->sarge upgrades.
[05:33] <minghua> That, among others, was the reason release notes start recommending aptitude for upgrading over apt since sarge.
[05:33] <Fujitsu> Oh, oops, I must have done something different last time.
[05:33] <Fujitsu> aptitude fails similarly this time.
[05:33] <Fujitsu> I'm sure I tried it before.
[05:34] <Fujitsu> aptitude has the sanity to install the new tzdata, however.
[05:36] <sandyang> :)
[05:36] <nenolod> one thing i have found disappointing (and should be fixed) is multilib in ubuntu
[05:36] <nenolod> there should be lib32 packages for all libs that are shipped
[05:36] <nenolod> i should probably make a blueprint about this ;)
[05:37] <Fujitsu> That sounds like a fairly big job, really.
[05:39] <persia_> nenolod: Are they really needed?  Unless there is a useful rdepends, I'm not sure we need it.  If there is a useful rdepends, adding another binary to the existing libs package seems appropriate.
[05:40] <nenolod> persia_, well, zsnes depends on lib32 of ncurses and such
[05:40] <Fujitsu> Where's 64-bit zsnes?
[05:40] <nenolod> Fujitsu, it's 32-bit.
[05:41] <Fujitsu> Why?
[05:41] <nenolod> Fujitsu, because it's x86 assembly.
[05:41] <Fujitsu> Ah. How silly.
[05:41]  * nenolod waits for the next "Why?"
[05:41] <nenolod> "because the developers are morons"
[05:41] <nenolod> actually, most emulator developers seem to be like this
[05:41] <nenolod> especially in playstation world
[05:42] <Fujitsu> Writing an emulator such that you need an emulator to run the emulator after a few years?
[05:42] <nenolod> yeah
[05:42] <nenolod> Fujitsu, i recently forked PCSX-df because it has died
[05:42] <nenolod> Fujitsu, i'm rewriting it with SDL. it's a disaster.
[05:42] <nenolod> :D
[05:42] <Fujitsu> No idea what that is.
[05:42] <Fujitsu> Hah.
[05:42] <nenolod> Fujitsu, PCSX-df is the "debian fork" of PCSX, which is a playstation1 emulator.
[05:43] <nenolod> Fujitsu, the in progress rewrite is UPE ( http://nenolod.net/upe ) but it's so insane, that i haven't gotten to a point where it's releasable yet.
[05:43] <nenolod> UPE is 64-bits safe though, which is something PCSX{-df} is not.
[05:51] <persia_> nenolod: Does it even run on amd64?  I've found not a few assembler issues when trying to port code.  If it would otherwise run, adding libcurses to ia32libs doesn't seem unreasonable.
[05:52] <nenolod> persia, it runs when compiled with -m32
[05:52] <nenolod> obviously it's not going to build with -m64
[05:53] <nenolod> cause it is dependant on 32-bits architecture
[05:53] <persia_> nenolod: In that case, generate a bug & candidate for ia32libs, and add a bug task and candidate for the emulator.  My concern is more that register handling is different, and some things break (especially for SMP).
[05:53] <nenolod> persia_, i'll work on trying to patch the debian package of zsnes to run on amd64
[05:54] <nenolod> persia_, it runs fine when chrooted into a 32bit environment
[05:54] <Fujitsu> Shouldn't we be thinking about replacing emulators that need emulation?
[05:54] <nenolod> Fujitsu, snes9x is the other emulator and it crashes on many obscure titles
[05:55] <persia_> Fujitsu: One would think this would be a natural step due to speed, but as in the case of xmms, it's not as easy as one would hope.
[05:55] <nenolod> (of course, ZSNES includes a 64-byte SPC700 ROM)
[05:55] <nenolod> (pagefault even says this publically)
[05:55] <nenolod> (so perhaps removal altogether of ZSNES is the only option since it contains blobs which are not DFSG free)
[05:56]  * persia_ encourages removal of non-free
[05:56] <nenolod> well, 64-byte SPC700 ROM is something that nobody cares about
[05:57] <nenolod> but technically, it makes ZSNES DFSG non-free.
[05:57] <minghua> Seriously?  64 byte?  How do you claim copyright on that?
[05:57] <nenolod> minghua, well they dumped the microcode from the Super Nintendo's DSP
[05:57] <nenolod> so i imagine SONY still holds a copyright on it
[05:57] <persia_> minghua: You can claim copyright on 1 bit, but defending it is the hard part: one has to show that it is the result of an independent creative process.
[05:58] <minghua> Can't some people do a clean-room re-implementation of that?
[05:58] <nenolod> i could try to patch out the microcode.
[05:58] <nenolod> it's not really needed
[05:58] <nenolod> i don't think
[05:58] <persia_> nenolod: That'd be need.  If you succeed, consider a repack for universe.
[05:58] <persia_> s/need/neat/
[05:59] <nenolod> minghua, hehe. i did a cleanroom reimplementation of the PS1 BIOS.
[05:59] <nenolod> minghua, including software executive layer
[05:59] <nenolod> :D
[06:00] <joejaxx> nenolod: that sounds fun
[06:01] <nenolod> joejaxx, it kind of works too. there's a long ways to go though.
[06:01] <joejaxx> nenolod: clean-room rev-eng is always fun
[06:04] <nenolod> at any rate, the binary blob starts at line 47 in zsnes/src/cpu/spc700.asm
[06:05]  * nenolod works on it
[06:45]  * Hobbsee waves
[06:48] <minghua> Hello Hobbsee.
[06:48] <Hobbsee> minghua: how gose it?
[06:49] <Fujitsu> Hey Hobbsee.
[06:49] <Hobbsee> hiya Fujitsu
[06:50] <minghua> Hobbsee: Quite well, although nothing really on Ubuntu front.  What about you?  School vacation time?
[06:50] <Hobbsee> minghua: yeah, on uni vacation.  nothing really ubuntu-related either, partly because all the buildds are dead, and no one cares enough to fix them, who actually can.
[06:50] <Hobbsee> minghua: work, etc.  sucky :)
[06:50]  * Hobbsee should do ubuntu stuff
[06:52] <minghua> Yeah, work.
[06:52]  * minghua needs to install Debian on a new box and migrate a server tomorrow.
[07:10] <sandyang> so quietly~~
[07:19] <nenolod> seems that lib32sdl is broken depends
[07:19] <nenolod> :D
[08:14] <nenolod> if anyone who works on ia32-libs is here, please look at https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/179031 as soon as you have time :)
[08:14] <ubotu> Launchpad bug 179031 in ia32-libs "lib32/libSDL depends on old libraries and needs to be rebuilt" [Undecided,New]
[09:47] <\sh> moins
[10:16] <Iuli> Hiya \sh
[11:19]  * Hobbsee waves
[11:20] <afflux> Hi. Upstream released a new version for a package that I created. What do I have to do to get that in the repos? Upload the new one to revu? I saw someone who used bugs with interdiffs attached. What's the preferred way?
[11:28] <\sh> afflux:well both ways :)
[11:30] <afflux> okay, I'll upload to revu
[11:34] <Schnitz> hi all
[11:35] <persia> afflux: interdiff is preferred
[11:35] <afflux> oh, okay.
[12:13] <mruiz> hi all. MOTU Q&A today?
[12:13] <persia> None scheduled in -classroom, but you're welcome to ask questions here anytime (and someone may well answer).
[12:15] <mruiz> persia, you're my MOTU hero :-)
[12:15] <geser> mruiz: dholbach is on vacation so unless someone jumps in for him, there won't be a session today
[12:16] <mruiz> thanks geser
[12:27] <Kmos> bug 164166
[12:27] <ubotu> Launchpad bug 164166 in ebug-http "FTBFS: tries to download from CPAN" [Critical,Confirmed] https://launchpad.net/bugs/164166
[12:27] <Kmos> can someone check this one
[12:27] <Kmos> i've attached a debdiff
[12:27] <Kmos> it builds fine in my pbuilder..
[12:28] <Kmos> ups.. i need to create a patch to the patches directory
[12:30] <mruiz> I need an opinion of the bug 178869
[12:30] <ubotu> Launchpad bug 178869 in gnome-voice-control "[FTBFS] gnome-voice-control due to automake-1.9 build-dep" [Undecided,New] https://launchpad.net/bugs/178869
[12:30] <persia> mruiz: What sort of opinion would you like?
[12:33] <\sh> mruiz: the problem is not gnome-voice-control...the problem is pbuilder-satisfy-depends-dummy
[12:33] <persia> \sh: Are you sure?  "automake-1.9" vs. "automake1.9".
[12:34] <\sh> persia: check the buildlog...
[12:34] <persia> (and yes, pbuilder-satisfy-depends-dummy is broken)
[12:34] <\sh> it fails at this point...and not in the build-dep of g-v-c
[12:35] <\sh> so p-sd-d is wrong assuming automake-1.9 is existing...automake1.9 is most likely more correct
[12:35] <persia> \sh: Yes, but it still FTBFS for me with sbuild.
[12:35] <persia> \sh: "automake-1.9" is defined in debian/control
[12:36] <\sh> persia: so pbuilder is again wrong...wrong error message
[12:36] <persia> mruiz: As a general note, usually we don't bump the standards version unless it's required, or the package isn't in Debian, as it would be unnecessary deviation.  Also, it's nice to not include config.guess or config.sub variance in the debdiff, as it makes it easier to read.
[12:37] <persia> \sh: Right.  There are two bugs: the pbuilder bug, and the FTBFS in gnome-voice-control.  The pbuilder bug is already recorded as bug #125107, but bug 178869 seems a good way to address the gnome-voice-control bug.
[12:37] <ubotu> Launchpad bug 125107 in pbuilder "[gutsy] pbuilder-satisfydepends-gdebi can't resolve pure virtual build-depends" [Undecided,New] https://launchpad.net/bugs/125107
[12:37] <ubotu> Launchpad bug 178869 in gnome-voice-control "[FTBFS] gnome-voice-control due to automake-1.9 build-dep" [Undecided,New] https://launchpad.net/bugs/178869
[12:38] <\sh> well, change automake-1.9 to automake1.9 (normally this could be done with automake, because it should point to 1.9 nowadays, right?)
[12:40] <mruiz> persia, just delete the config.{sub,guess} variance (if appears) from the debdiff?
[12:40] <persia> \sh: I thought the default was 1.10 these days (although I may be mistaken)
[12:41] <persia> mruiz: Right.  Personally, I prefer to move the autocopy from clean to configure if the autotools hints are to be autocopied, as it makes debdiffs nicer (although there are strong arguments against autocopy, which deserve respect).
[12:44] <mruiz> persia, I was reading your opinions about that and, in this case the autocopy is in "clean" section :-)
[12:45] <persia> mruiz: Right.  That's the part I don't like (although I'm not sufficiently in favor of arbitrary variance from Debian to encourage fixing it).  Specifically, if the files are to be copied at build time, they should be copied for configure: and not for clean: as the copy actually makes the package less clean.
[12:45] <mruiz> :-)
[12:46] <mruiz> persia, you're a debian/rules magician ;-)
[12:46] <persia> This is especially annoying for SRUs, as it means that the source package candidate for upload must be prepared in the target release, or it will not have the right hint files to properly compile for the target.
[12:47] <persia> Further, given sufficient variance in the hints files, there is a possibility of creating a FTBFS situation when backporting.  Anyway, enough ranting about that :)
[12:47] <\sh> persia: could be...gutsy was 1.9
[12:48] <persia> \sh: Really?  I thought I saw a bunch of 1.10 stuff during gutsy.  Maybe just pushing the leading edge.
[12:50] <afflux> RainCT: didn't you mix source and binary packages in bug #179085 ?
[12:52] <RainCT> indeed :P
[12:53] <RainCT> afflux: thx, changed that
[12:56] <totopalma> RainCT, o/
[12:56] <RainCT> hi totopalma :)
[12:56] <totopalma> :)
[13:04] <Kmos> :)
[13:04] <Kmos> persia: how about to add REVU ?
[13:04] <Fujitsu> There seems to be an extra space there.
[13:04] <Kmos> yeah
[13:04] <persia> Kmos: I'm not in favor of encouraging lots of NEW packages at this point.
[13:05] <Kmos> persia: you're right.. bug fixing is better
[13:05] <Fujitsu> Kmos: Have you uploaded ebug-http to your PPA without testing it?
[13:08] <Kmos> Fujitsu: i also use my ppa for testing :)
[13:08] <Fujitsu> Kmos: So you'll kill off the PPA buildds. Great.
[13:09] <persia> Kmos: Best to work locally first.  Something like that can take down the PPA for everyone.
[13:09] <Kmos> Fujitsu: no.. it won't kill it =)
[13:09] <Fujitsu> Kmos: Why not?
[13:09] <Kmos> it will fail with another build problem
[13:09] <Kmos> not the cpan one
[13:09] <persia> Kmos: Did you know that before you uploaded?
[13:09] <Fujitsu> You sure it'll fail there first?
[13:09] <Kmos> persia: yep
[13:09] <Fujitsu> ...
[13:09] <Kmos> Fujitsu: yes, I am
[13:09] <persia> Kmos: Why upload to a PPA if you know if FTBFS?
[13:09] <Fujitsu> You uploaded a known-dodgy package?
[13:10] <Kmos> i fixed it manually in the code
[13:10] <Kmos> but after I saw it fails in testing because of the required module
[13:10] <Kmos> not about the download from cpan
[13:10] <geser> Kmos: does the package you uploaded to PPA build now or still FTBFS?
[13:11] <Kmos> Fujitsu: because of the !~ problem
[13:11] <persia> Kmos: Right, but why upload to a PPA when you know it will FTBFS?  That's just a waste of resources.
[13:11] <wolfger> qa.ubuntuwire.com is not loading (at least, the two links in the topic)
[13:11] <Kmos> geser: still FTBFS..
[13:11] <Fujitsu> wolfger: Works for me.
[13:11] <Kmos> persia: i thought it won't FTBFS
[13:11] <Kmos> :-(
[13:11] <man-di> wolfger: works from here
[13:11] <persia> wolfger: works for me.
[13:12] <wolfger> hmm. works now. Maybe a hiccup on my end
[13:12] <Kmos> it won't break the buildds
[13:12] <Fujitsu> Kmos: You're meant to *know* that it won't FTBFS.
[13:12] <Fujitsu> You should test build before letting a package leave your system.
[13:13] <RainCT> wolfger: same happened here
[13:13] <persia> Further, only packages expected to work should be uploaded to a PPA
[13:14] <Kmos> right.. i won't do it.. i really thought it was fixed. :(
[13:16] <Fujitsu> Kmos: An easier solution is probably to just depend on libtest-expect-perl, or whatever the package is likely to be.
[13:17] <Kmos> libtest-deep-perl
[13:17] <Fujitsu> That sounds wrong.
[13:18] <Kmos> it's Test::Deep
[13:19] <Fujitsu> Didn't I see it wanting Test::Expect?
[13:19]  * Fujitsu rereads.
[13:19] <Fujitsu> requires Test::Expect
[13:20] <Kmos> libtest-expect-perl
[13:20] <Kmos> it's this one.. but isn't available at gutsy
[13:20] <Kmos> !info libtest-expect-perl hardy
[13:20] <ubotu> libtest-expect-perl: Automated driving and testing of terminal-based programs. In component universe, is optional. Version 0.30-2 (hardy), package size 6 kB, installed size 68 kB
[13:20] <Kmos> ah nice
[13:21]  * Kmos testing build
[13:22] <Kmos> - Test::Expect                     ...loaded. (0.30)
[13:22] <Fujitsu> That looks better.
[13:22] <Kmos> but it fails in the same thing that my package will fail in PPA
[13:22] <Fujitsu> Which is..?
[13:23] <Kmos> http://rafb.net/p/H8Lhkv41.html
[13:24] <Kmos> there isn't any patch upstream
[13:24] <Fujitsu> None of the subtests failed, but it failed anyway. Nice of it, really.
[13:26] <Kmos> hehe
[13:27] <Kmos> i've reported to debian the missing package on build-depends..
[13:27] <Fujitsu> I hope you used the existing bug.
[13:27] <Kmos> Fujitsu: yes :)
[13:28] <Hobbsee> Kmos: why not actually get the package to build, before reporting it to other distros?
[13:28] <Hobbsee> in case there is more
[13:28] <Kmos> Hobbsee: i reported about one specific bug.. this one is a new one =)
[13:29] <Kmos> http://rt.cpan.org/Public/Bug/Display.html?id=17988
[13:29] <Kmos> here it fails with 0.00% not 0.100%
[13:29] <Kmos> lol
[13:39] <Fujitsu> Kmos: ... your build succeeded.
[13:39] <Fujitsu> So you were expecting it to fail to avoid the hang, but it succeeded.
[13:40] <Fujitsu> So both failure conditions failed to be satisified.
[13:40]  * persia is somewhat confused as to whether failing to fail is entirely bad, although the consequences might be worse
[13:41] <Kmos> Fujitsu: really strange
[13:42] <Fujitsu> persia: I am a little glad that he mis-predicted both failure conditions, as if one of them had actually failed, we'd have one buildd out of action.
[13:42] <Kmos> i should make a debdiff with the b-p package ?
[13:42] <Fujitsu> Kmos: b-d?
[13:42] <Kmos> libtest-expect-perl
[13:42] <Kmos> with this
[13:43] <persia> Fujitsu: Yes.  It just will look odd when collated: I'll need to think of appropriate phrasing.
[13:43]  * Hobbsee thinks Kmos should trash his own machine, not someone else's.
[13:43] <Fujitsu> persia: It is a little confusing like that, yes.
[13:44] <Kmos> Hobbsee: my machine isn't too new.. more old =)
[13:45] <Hobbsee> Kmos: and that's any excuse?
[13:45]  * Fujitsu pities the buildds.
[13:45] <persia> Kmos: That might mean it takes a while, but you can at least reset your machine easily, whereas it's not so easy for a machine in a data centre
[13:45] <Kmos> Hobbsee: it isn't
[13:46] <Hobbsee> Kmos: so, uh, why do you choose to act that way then?
[13:46] <Kmos> Hobbsee: I want to test it with buildd machines.. like this case
[13:47] <Kmos> it builds fine there
[13:47] <Kmos> and it fails in pbuilder
[13:47] <Kmos> :(
[13:47] <persia> Kmos: You might try running sbuild against a buildd chroot if you want a real test.
[13:48] <Kmos> persia: i need to got some time to do it properly..
[13:48]  * Hobbsee suggests that you appear to have time now
[13:49] <persia> Kmos: Good idea.
[13:49] <Kmos> Hobbsee: not now.. i need to lunch and go medical doctor :(
[13:50]  * Kmos bbl
[13:52] <Hobbsee> Kmos: very convenient.
[13:53] <Kmos> Hobbsee: check the hours in Portugal.. it's 13:53 p.m and I haven't eaten lunch eat
[13:54] <Kmos> and i need to go doctor to get blood analyses.. isn't to be conveniente.. i really prefer to be here, for sure.
[13:54] <Kmos> cya
[13:54] <mruiz> Kmos, good luck
[13:55] <Kmos> mruiz: thanks
[14:02] <oskude> hi masters! is tcl/tk8.5 planned to be included in hardy ?
[14:03] <persia> oskude: Yes.
[14:03] <oskude> coool!
[14:03] <persia> oskude: For future questions of a similar nature, you can get an answer with a command like `rmadison tcl8.5`
[14:04] <oskude> aha, and whats that ?
[14:04] <LucidFox> persia> avidemux 2.4.0 has appeared on DMO
[14:05] <LucidFox> I haven't looked at it yet, though
[14:06] <persia> LucidFox: Cool.  Let's maybe wait for -2 to see if you can get all your fixes in.
[14:17] <LucidFox> He packaged it _after_ I reported about my fixes, so I'll look which ones went in and which didn't.
[14:32] <DarkSun88> Hi MOTUs
[14:39] <LucidFox> Hmm. It depends on libamrnb-dev, which is on DMO not in Ubuntu.
[14:40] <LucidFox> *but
[14:45] <persia> LucidFox: What is libamrnb-dev, and do we want it?  If it is useful, and good, could have two tasks on the sync request: one for the sync of avidemux, and one for an import of libamrnb
[14:50] <LucidFox> AMR NarrowBand speech codec
[14:51] <LucidFox> Yes, I think we need it. I, for one, do - my cellphone records sound in .amr format
[14:51] <LucidFox> Will it have to pass REVU?
[14:56] <persia> LucidFox: I'm not sure.  If we accept d-m as a sync/merge source, no.  If not, it should.  Best if it could pass REVU, but is a sync.
[14:58] <DarkSun88> persia: The build server ore down or have problems again?
[14:59] <persia> DarkSun88: Just fixed recently.  See the /topic.  Also, why ask me, rather than asking the channel?
[14:59] <LucidFox> amrnb won't pass as is. The libamrnb3 and libamrnb-dev packages are lintian-friendly, but amrnb contains 9 binaries in /usr/bin, all without manpages :/
[15:00] <LucidFox> and with really obscure --help
[15:00] <persia> LucidFox: Right.  Needs to get fixed somewhere for inclusion.  Can be d-m or REVU.  I'd prefer D-M, but suggest sending a request for comments to ubuntu-motu@l.u.c about using D-M as a sync/merge source just to get a firm opinion.
[15:01] <DarkSun88> persia: Sorry. I've seen you here and I've asked. I will not ask you in next time. :)
[15:01] <persia> DarkSun88: Thanks.  Feel free to ask me if it's something you know if interesting to me, or a continuation of a conversation: I just like to avoid highlights unless it really needs me :)
[15:01] <imbrandon> d-m /can/ be used as a sync source , its been stated before by colin that any apt-getable source is a viable sync source, it totaly depends on the package, they wonrt explisitly trust d-m as a whole
[15:02] <DarkSun88> persia: Ok. thanks.
[15:02] <imbrandon> debian unstable is the only "whole" repo
[15:02] <persia> imbrandon: Yes.  Anything is a viable sync source, and the scripts handle it, but we stopped syncing against most of the non-Debian sources post-Dapper.
[15:03] <persia> (or was it post-Breezy: I forget exactly)
[15:03] <imbrandon> neither actualy, there was alot of noise about it but we still sync occasionaly elsewhere
[15:03] <imbrandon> totaly depends on the package
[15:03] <imbrandon> debian-multimedia.org comes to mind
[15:03] <ion_> persia: As a continuation to yesterday’s conversation; i think i fixed the issues with the packages. If you still feel like reviewing, i’d be thankful. :-)
[15:04] <persia> imbrandon: RIght.  Given the nature of D-M, it might make sense to have a more comprehensive policy of a full sync from there for each cycle, and merging rather than local new upstreams, which is why I thought a RFC to u-m@ would be appropriate.
[15:04] <persia> ion_: Same day for me, and very near the end of it.  Maybe someone else would be up for a review?
[15:04] <imbrandon> ahh i like the per package basis, trusting it as a whole isnt good
[15:04] <imbrandon> its like REVU anything can be uploaded
[15:05] <persia> imbrandon: Even D-M?  What there is bad?  How does it work?
[15:05] <imbrandon> it works amost exactly like revu
[15:05] <ion_> persia: All right. :-)
[15:05] <persia> Ah.  Right.  That would be bad.  Thanks.
[15:05] <imbrandon> :)
[15:05] <persia> LucidFox: Please ignore my earlier comment about using D-M as a sync source :)
[15:06] <ion_> In case anyone feels like reviewing: http://revu.tauware.de/details.py?package=apt-mark-sync and http://revu.tauware.de/details.py?package=hardware-connected, but i can ask again on monday.
[15:07] <imbrandon> persia: the main diffrence between revu and d-m is revu runs lintian/linda on the packages , and d-m puts them in an apt-getable repo ( like a source only PPA )
[15:07] <imbrandon> thats the only two real diffrences
[15:07] <LucidFox> Upstream homepage is dead :/
[15:07] <persia> imbrandon: That makes me think a raw import from REVU would be safer, and I know that's not a good idea.
[15:08] <imbrandon> exactly , hehe
[15:08] <imbrandon> but on the other side of that i feel if a package is "good enough" it could be done, on a per package basis
[15:08] <imbrandon> buit it would have to be per package
[15:08] <imbrandon> ( both revu and d-m )
[15:10] <persia> imbrandon: Actually, due to the nature of REVU, I think the current manual upload is better, as the addition of an Origin: header wouldn't mean much.  For D-M, I don't have an objection to sync/merge on a per-package basis, but personally feel that it may be better to maintain in parallel or coordination, rather than striving for minimal diff to a non-Debian repo.
[15:10] <nxvl_work> can someone take a look at Bug #173294 and give me some feedback about RainCT's comments
[15:10] <ubotu> Launchpad bug 173294 in tuxpaint-config "There are no easy way to change tuxpaint configuration" [Low,Confirmed] https://launchpad.net/bugs/173294
[15:10] <imbrandon> persia: right
[15:10]  * persia is too tired for review, but meta-review is always fun :)
[15:10] <imbrandon> heh
[15:11] <imbrandon> i'm just walking up, my schedule is all screwy because of the holidays
[15:11] <imbrandon> seems to vary greatly from day to day the last two weeks
[15:11] <imbrandon> heh
[15:13] <imbrandon> hrm ff3 is quite nice, honestly my use of it the last 3 or 4 days seems that its UI is almost identical to FF2 except the address autocomplete , but it used MUCH less ram
[15:13] <imbrandon> win win imho
[15:13] <ion_> It also seems *amazingly* faster than FF2.
[15:13] <imbrandon> yea
[15:13] <ion_> E.g. Google Reader almost feels like a native application, whereas with FF2 everything is laggy.
[15:13] <imbrandon> i dident think there would be a major diffrence
[15:14] <persia> nxvl_work: In this case, no patch system is preferable, as the current package in the archives uses a no-patch-system solution (look at `lsdiff -z tuxpaint_0.9.17-1ubuntu1.diff.gz`).  There are two schools of thought about the use of debian/patches.  When the entire package is maintained in a VCS, debian/patches is confusing (but maintainers should use pristine-tar).  When only debian/ is maintained in a VCS, or the package is not maintained in a
[15:14] <persia> imbrandon: For things like that, try prism
[15:15] <nxvl_work> !vcs
[15:15] <ubotu> Sorry, I don't know anything about vcs - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[15:15] <imbrandon> yea i use prism, well tried it, its very slow
[15:15] <persia> nxvl_work: Version Control System
[15:15] <nxvl_work> oh! ok
[15:15] <imbrandon> persia: you got cut off at "package not maintain in a "
[15:15] <imbrandon> fyi
[15:16]  * persia dislikes buffers "...package is not maintained in a VCS, it's nice to use debian/patches to keep track of things.  In all cases, it's best to folllow existing practice when modifying a apckage."
[15:16] <imbrandon> :)
[15:16] <persia> s/apckage/package/
[15:16] <imbrandon> yea i thought about hacking a perl script togather for irssi that splits long lines , i tend to use them too
[15:17] <imbrandon> sometimes
[15:17] <ion_> imbrandon: splitlong.pl is bundled with irssi.
[15:17] <imbrandon> ion_: not my irssi ( you might mean irssi-scripts but i dont install that )
[15:17] <imbrandon> but thanks, i'll loook at it
[15:18] <nxvl_work> but it's a better practice to use it, is not clean to make changes outside debian/, if there are a lot of little changes is a PITA to try to apply one of them in upstream
[15:18] <nxvl_work> didn't it?
[15:18] <imbrandon> ion_:  is there an inline spell checker too ? hehe
[15:18] <imbrandon> nxvl_work: totaly depends on the package
[15:18] <persia> nxvl_work: Not in all cases.  If the maintainer keeps the entire upstream in VCS with their changes, merging back and forth is a lot easier without debian/patches.
[15:18] <ion_> % dpkg -L irssi | grep splitlong
[15:18] <ion_> /usr/share/irssi/scripts/splitlong.pl
[15:18] <DktrKranz> mh... I uploaded a package on my PPA and it keeps uploading itself again and again, have you ever had this issue before?
[15:19] <nxvl_work> mmm
[15:19] <imbrandon> nxvl_work: personaly i like changes directly to the source with apt-mirror , but i like patches with libvisual
[15:19] <imbrandon> depends on the package and maintainer
[15:19] <nxvl_work> i find easier to apply a patch
[15:20] <persia> nxvl_work: In many cases, using a patch system is indeed easier to understand, but it's definitely not worth adding a patch system when there are already ubuntu-local changes to the files you are patching, which changes are not removed by the application of a patch system.
[15:20] <nxvl_work> but, thats true, depends on the maintainer...
[15:22] <persia> nxvl_work: My personal habit is to use a patch system if there is one, and not add a patch system if there is none.  When I make a patch without a patch system, I always submit the patch to Debian so it can be tracked in the BTS (and this may mean separating patches pre-application).
[15:23] <persia> In the rare case where a patch only applies to Ubuntu, and there is expectation of carrying an Ubuntu delta for some time, it may make sense to add a patch system where there was not one previously, but in these cases, it is essential to refactor all the existing patches into the patch system prior to adding any adjustments.
[15:24] <nxvl_work> well my point is not for the debian case, i have a friend developing for gnome and he had a lot of trouble trying to use ubuntu changes because of none patch systems
[15:25] <persia> nxvl_work: Which package?
[15:25] <nxvl_work> because to understand the ubuntu delta from debian is easier, but from upstream isn't that simple
[15:25] <nxvl_work> persia: he's ephiphany developer i think
[15:26] <persia> nxvl_work: epiphany uses debian/patches
[15:26] <imbrandon> should be just as easy, diff against the orig tar to produce a upstream patch
[15:26] <nxvl_work> then he's and idiot :D
[15:27] <nxvl_work> he says something about the patch posted to qa.d.o IIRC
[15:27] <persia> nxvl_work: That may be.  Likely there's some confusion somewhere.  One of the things I prefer about the use of VCS or diff.gz patching is that one never has patches on patches, so any set of patches is easy to apply.  With patch systems, one sometimes has overlay patches, which can be very annoying to adjust.
[15:27] <imbrandon> those come from patches.ubuntu.com , not idea, only intended for debian, he should look at the package its self
[15:28] <persia> On the other hand, a big monolithic patch in diff.gz without explanantion of the changes and no VCS history anywhere is nearly useless when attempting to cherrypick good fixes.
[15:29] <persia> nxvl_work: One of the main reasons to try for minimal variance from Debian is to make the patches on qa.d.o as small as possible, and possibly easy to use.  For GNOME, Ubuntu and Debian have vast and significant differences, so those patches are mostly useless.
[15:29] <nxvl_work> mmm
[15:30] <nxvl_work> you are right about some points, and i understand them, but i'm still finding better to use patch system always, i see it cleaner, on the other hand i have had trouble with it on Bug #178046 it was really a PITA tu understand that patch
[15:31] <ubotu> Launchpad bug 178046 in dillo "dillo failed to unpatch" [Undecided,Confirmed] https://launchpad.net/bugs/178046
[15:31] <nxvl_work> but it's always a matter of who and how make the patch
[15:31] <nxvl_work> IMHO
[15:31] <cbx33> yo yo guys
[15:31] <cbx33> howz it going
[15:31] <nxvl_work> norsetto: here is the right person for this discussion :D
[15:31] <persia> nxvl_work: I don't object to your use of a patch system, but if you don't refactor the existing patches into the patch system, you render the package exceedingly difficult to maintain.
[15:31]  * cbx33 still hasn't gotten his raid working - think I'm about to give up....it shouldn't be this hard
[15:32] <cbx33> software raid.....
[15:32] <cbx33> should be easy....the array is built and working but I just can't boot to it
[15:32] <cbx33> it's because the raid10 module isn't in initramfs but I can't seem to get it in there
[15:32] <persia> nxvl_work: Also, while I agree the patch to dillo is hard to understand, I suspect you'll get good results from contacting the authors of that patch, who maintain it separately from dillo in a separate upstream location.  Their VCS should be instructive.
[15:32] <cbx33> dpkg-reconfigure linux-image was suggested to me......
[15:33] <cbx33> heheh ;)
[15:35] <nxvl_work> persia: i have already fix dillo :D there is a patch waiting for sponsor :D
[15:37] <imbrandon> food time, bbiab
[15:37] <persia> nxvl_work: That's not a safe way to solve that issue.  The changes to config.sub and config.guess should be pulled out of the offending patch.  Otherwise you're asking for future confusion.
[15:39] <cbx33> how do you specify modules when doing a dpkg-reconfigure for linux-image
[15:48] <nxvl_work> persia: so, what you are saying is that the best way is to make those changes directly on the config.{guess,sub} ?
[15:48] <persia> nxvl_work: No.  What I'm saying is that it is useless to patch a file that you are replacing during the build.  Better to not patch it than to play around with trying to reconstruct the original patched files just to make it build cleanly.
[15:49] <nxvl_work> mmm, but the changes must be done or they mustn't
[15:49] <mattva01> i'm pretty new to packaging and was wondering what was the best practice for adding a directory in each users home directory
[15:49]  * nxvl_work checks the patch
[15:50] <persia> mattva01: If that is truly required, best to have the package create it at runtime.
[15:51] <mattva01> ah thanks, and yes I know it is not ideal to do that
[15:52] <nxvl_work> persia: i'm not replacing it on the build, it's replaced on the clean
[15:55] <persia> nxvl_work: the clean: rule is called at build time.  It's still useless to patch a file that you plan to overwrite.
[15:55] <nxvl_work> mmm
[15:55] <nxvl_work> and how can i apply the patches and clean it? patching the modified version of it?
[15:55] <persia> nxvl_work: Anyway, there's a cleaner patch available in the Debian bug :)
[15:56] <persia> nxvl_work: Drop the useless patches from the monolithic internationalisation patch with filterdiff.
[15:57] <nxvl_work> persia: on which debian bug? on 457961?
[15:57] <persia> Yes
[15:57] <nxvl_work> thats the one i have use
[15:58] <persia> nxvl_work: The last patch, at the bottom of the bug, submitted 3 minutes ago?
[15:58] <nxvl_work> heh
[15:58] <nxvl_work> when i saw it there wasn't any patch
[15:58] <nxvl_work> :P
[16:00] <nxvl_work> as you wrote it, you should upload it, or you haven't a problem with me applying it?
[16:00] <persia> nxvl_work: I don't have a problem with you applying it.  I'm going to bed.  You get to test my patch, and see if it works for you, and prepare the candidate, etc.  I just thought making a patch would be easier than explaining what I meant.
[16:01] <nxvl_work> ok
[16:01] <nxvl_work> i will work on it right now
[16:01] <nxvl_work> thanks
[16:01] <nxvl_work> :D
[16:01] <persia> nxvl_work: Thanks.  Good luck :)
[16:01] <nxvl_work> persia: as i don't think i see you till next year, have a happy new year!
[16:02]  * nxvl_work *HUGS* persia and hopes the best for next year
[16:02] <persia> nxvl_work: Happy new year.
[16:05] <nxvl_work> persia: you are only removing the patches, didn't you?
[16:05] <nxvl_work> i mean only removing lines not adding/changing them
[16:07] <persia> nxvl_work: Right.  I haven't investigated the issue in depth (which is why I'm more than happy to have you investigate before an upload).  All I did was remove the sections of the patch for the two files that are being autoreplaced anyway.
[16:07] <nxvl_work> ok
[16:07] <nxvl_work> i will check it
[16:12] <psusi> question... when updating a package to a new upstream release, how do you get debuild -S to include the new .orig.tar.gz in the upload?
[16:13] <DktrKranz> psusi, -sa flag
[16:14] <psusi> hrm... ok... now... maybe the reason it isn't doing it by default is that I'm not using the correct version number?
[16:15] <nxvl_work> nop
[16:15] <nxvl_work> it doesn't do it by default
[16:15] <nxvl_work> you need to use -sa
[16:16] <psusi> the old version was 13-2ubuntu6... I made the new version 14-0ubuntu1
[16:16] <psusi> it does it by default it says if the version number ends in 1
[16:16] <nxvl_work> a merge?
[16:16] <psusi> but it looks like it wants it ot end in -1 maybe?
[16:16] <nxvl_work> mmm
[16:16] <nxvl_work> maybe on debian it does
[16:16] <nxvl_work> on ubuntu it doesn't
[16:16] <psusi> merge?  updated to a new upstream release
[16:16] <nxvl_work> psusi: thats a merge
[16:17] <nxvl_work> !merge
[16:17] <ubotu> Sorry, I don't know anything about merge - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[16:17] <nxvl_work> !merges
[16:17] <ubotu> Sorry, I don't know anything about merges - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[16:17] <nxvl_work> ubotu: did you know anything?
[16:17] <leonel> I'm on gutsy  and  have my  pbuilder for  gutsy   .. can I have in the same machine a pbuilder for Hardy and  feisty ??
[16:17] <nxvl_work> !merging
[16:17] <ubotu> Merging is the process of including changes from other distributions (most commonly Debian) into Ubuntu packages, and is typically a major focus at the beginning of each Ubuntu development cycle.  Please see https://wiki.ubuntu.com/UbuntuDevelopment/Merging for more information.
[16:18] <nxvl_work> !merging | psusi
[16:18] <ubotu> psusi: please see above
[16:18] <nxvl_work> leonel: yes you can
[16:18] <imbrandon> leonel: yes
[16:19] <psusi> yea... it does
[16:19] <psusi> it wanted the version to end in -1
[16:19] <psusi> and it automatically includes the .orig
[16:19] <nxvl_work> leonel: https://wiki.ubuntu.com/PbuilderHowto#head-1be378ab60d3bab23eefabce49cf7df927d46f81
[16:19] <nxvl_work> psusi: on ubuntu they don't end on -1 unless it's a sync
[16:20] <psusi> why?
[16:20] <leonel> imbrandon:  nxvl_work  thanks
[16:20] <nxvl_work> psusi: and don't think it's hard to write "-sa" on the command line
[16:20] <nxvl_work> leonel: there is a script mentioned there, i use it, and it works fine
[16:21] <psusi> of course it isn't... just seems that it should be -1 and just work
[16:21] <nxvl_work> leonel: i have modified some things for my personal use, like the place where it stores the files, but it works fine as it is
[16:21] <leonel> I had to do a  qemu image to make a pbuilder there for hardy ..    nxvl thanks
[16:21] <psusi> since this is the first version based on the new upstream
[16:22] <imbrandon> psusi: wrong
[16:22] <awen_> psusi: that's because debuild is a debian package and don't know how we do it in ubuntu :)
[16:22] <psusi> imbrandon: wrong?  how?  this will be the first upload using the new upstream
[16:22] <nxvl_work> psusi: on ubuntu the only case in which a packages ends on -1 is when that version it's synced from debian, if we make a change it's -XubuntuY
[16:22] <imbrandon> psusi: sure and if that is the case it needs to be -0ubuntu1 in ubuntu
[16:22] <psusi> why did we diverge in this way?
[16:23] <imbrandon> psusi: to make it all smooth, the package guide explains it pretty clearly
[16:23] <nxvl_work> leonel: it's a good practice to have VM to test the changes also, i do it so :D
[16:23] <psusi> yea, I went with -0ubuntu1 initially but now I'm wondering why it isn't -0ubuntu-1
[16:24] <imbrandon> -1 means the first debian revision, since this isnt a debian revision its a ubuntu one it needs -0 and then ubuntu1 for the ubuntu1 revision , thuis -0ubuntu1
[16:24] <imbrandon> its not divergance, its policy
[16:24] <nxvl_work> psusi: because of the standards, if a package don't use them, report it on LP and it will be fixed to use them
[16:24] <psusi> right, but why is it ubuntu1 instead of ubuntu-1?  why no -?
[16:24] <nxvl_work> psusi: because the policy say so
[16:25] <imbrandon> because dpkg interprets - in a special way
[16:25] <nxvl_work> the packages must be adjusted to the policy, not the policy to the packages
[16:26] <psusi> hrm... in what other ways does it have special meaning besides the one I just found where it automatically includes the .orig.tar.gz on first version?
[16:26] <imbrandon> there is no "automaticly" if it dosent the other way your orig tar is likely named wrong
[16:26] <imbrandon> to begin with
[16:27] <imbrandon> psusi: in lots of other ways, i sugest reading up on the version numbers in the package guide, each part has a specific meaning
[16:27] <psusi> well, yea, I had to name the orig with the -0ubuntu part ;)
[16:27] <imbrandon> no
[16:27] <imbrandon> then something else is wrong
[16:28] <imbrandon> your not folowing it corectly somewhere
[16:28] <imbrandon> whats the upsteram package name and version
[16:28] <psusi> it just thinks the upstream version is 14-0ubuntu
[16:28] <psusi> and then this is -1
[16:28] <imbrandon> right, and that 100% wrong and will be rejected
[16:29] <psusi> ok
[16:29] <psusi> was just poking around figuring out how it works and wondering why
[16:29] <imbrandon> again i will save you a little reading if you tell me the upstream version and package name
[16:29] <imbrandon> the package guide explains why and how
[16:29] <imbrandon> poking will likely get you wrong results , like in this case
[16:29] <psusi> dmraid-1.0.0.rc14
[16:29] <nxvl_work> psusi: on the Packaging Guide you can read about the why, it's a matter of good practices, if do what we want then it will be caos, we need to adjust the tools and the process to the policy and if the tools don't to them we adjust them or find out why it's so, there must be some reason
[16:30] <psusi> nxvl_work: obviously, I understand why there needs to be conformity.. I'm wondering why the policy is the way it is
[16:30] <nxvl_work> it isn't 14ubuntu1
[16:31] <nxvl_work> it is 14-0ubuntu1
[16:31] <imbrandon> psusi: then the orig needs to be named dmraid_1.0.0~rc14.orig.tar.gz and the version you have in the changelog needs to be 1.0.0~rc14-0ubuntu1
[16:31] <psusi> right
[16:31] <psusi> hrm... why did you change the . to a ~?
[16:32] <imbrandon> because its an rc, if you dont it will see it as a higher version when 1.0.0 proper is released
[16:32] <imbrandon> see all good reasons to read the package guide and understand why things are versioned they way they are
[16:33] <psusi> hrm... I used to see that done with 0.9.9-1.0.0 or something... but it looks like debian screwed up the version number a while back before our last sync
[16:33] <imbrandon> e.g. 1.0.0.rc14 > 1.0.0-1, wich is wrong, 1.0.0~rc14 < 1.0.0-1
[16:33] <nxvl_work> imbrandon: i will never ask before reading anymore!!
[16:33] <psusi> so the current version in the repos is 1.0.0.rc13-2ubuntu6
[16:33] <leonel> nxvl_work: i have a VM for each ubuntu version  :)
[16:34] <imbrandon> psusi: that means debian screwed the pooch on it and will need an epoch when 1.0.0 is released
[16:34] <psusi> err, yea... it used to be 0.9.9+1.0.0rc9-3.1, then it went to 1.0.0.rc13-1
[16:34] <imbrandon> yup someone screwed up badly
[16:34] <nxvl_work> leonel: for feisty there are no much changes anymore, i use gutsy and have a VM for hardy, i think thats enough
[16:36] <awen_> leonel: did you get your pbuilder work the way you wanted... else i have a pbuilderrc made ready for gutsy, hardy, sid and etch, if you're interested?
[16:36] <leonel> awen_:  where can I download it ?
[16:36] <imbrandon> anyhow in this particular case since someone already scrwed up you need the orig to be named dmraid_1.0.0.rc14.orig.tar.gz and the changelog version to be 1.0.0.rc14-0ubuntu1
[16:36] <imbrandon> psusi:
[16:36] <nxvl_work> awen_: it's better for him to do it himself, so he understands the why's and the how's
[16:37]  * imbrandon notes if you use ubuntu-dev-tools you can just use 'pbuilder-dist $dist create'
[16:38] <nxvl_work> i use $dist-pbuilder $action
[16:38] <nxvl_work> :D
[16:38] <awen_> imbrandon: that almost sounds too easy
[16:38] <imbrandon> nxvl_work: right but in that package there is already premade scripts :)
[16:39] <imbrandon> where "that package" == ubuntu-dev-tools
[16:39] <nxvl_work> imbrandon: $dist-pbuilder is and already make script :D i only renamed it and make some changes, i think it's the pbuilder-dist one
[16:39]  * nxvl_work checks
[16:39] <imbrandon> likely :)
[16:40] <awen_> psusi: seems imbrandon and nxvl_work has the better solution here :D ... but for inspiration: http://paste.ubuntu-nl.org/49834/
[16:40] <psusi> imbrandon: ok... that's what I went with first... just was wondering why debuild wasn't picking up the .orig automatically
[16:40] <imbrandon> psusi: if it isnt its not named correctly
[16:41] <imbrandon> make sure its EXACTLY as i said
[16:41] <psusi> imbrandon: it was... it doesn't end in -1 is why
[16:41] <nxvl_work> awen_: s/psusi/leonel/g
[16:41] <imbrandon> psusi: no it isnt why
[16:41] <imbrandon> psusi: trust me
[16:41] <psusi> imbrandon: it saw the .orig and iddn't complain, but did not automatically include it in the upload because it didn't think this was -1
[16:41] <imbrandon> i have done this a LONG time
[16:41] <imbrandon> psusi: it never does
[16:41] <awen_> nxvl_work: jep
[16:41] <imbrandon> you have to use -sa
[16:41] <psusi> it does if the version ends in -1
[16:42] <imbrandon> e.g. debuild -S -sa
[16:42] <imbrandon> psusi: but we dont do that in ubuntu
[16:42] <psusi> right...
[16:42] <imbrandon> your not working on debian
[16:42] <imbrandon> ubuntu != debian
[16:42] <awen_> leonel: for inspiration: http://paste.ubuntu-nl.org/49834/
[16:43] <imbrandon> thus the rule about if its -1 it will include the orig in the upload totaly dosent apply to us
[16:43] <imbrandon> i thought you meant it dident include it when building the package
[16:44] <nxvl_work> imbrandon: i think psusi is right, the debuild script only takes the orig.tgz if it's -1 cause otherwhise the orig must be already on the server unless it's -0ubuntu1, but it can not work with the last version number if there isn't an ubuntu change to take that too
[16:44] <psusi> ok... so now that I have it packaged... I should file a bug report requesting it to be uploaded, and what should I attach to the report?  just the diff and the url of the .orig?
[16:44] <imbrandon> including it in the upload is totaly diffrent
[16:44] <imbrandon> !sponsoring
[16:44] <ubotu> Sorry, I don't know anything about sponsoring - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[16:44] <imbrandon> !sponsors
[16:44] <ubotu> Sorry, I don't know anything about sponsors - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[16:44] <imbrandon> grr
[16:44] <imbrandon> there is a wiki explainign it somehwere, how to request a sponspr
[16:44] <leonel> awen_,    nxvl_work  thanks
[16:44] <nxvl_work> !sponsor
[16:44] <ubotu> Sorry, I don't know anything about sponsor - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[16:45] <psusi> iirc it was file a bug and assign it to ubuntu-sponsors or something
[16:45] <awen_> psusi: https://wiki.ubuntu.com/MOTU/Contributing
[16:45] <psusi> I really need to do this more often so I don't forget all this stuff
[16:45] <imbrandon> no you file against the source package ,and subscribe u-u-s or u-m-s
[16:45] <RainCT> nxvl_work: /me would like to know what the changes he did to pbuilder-dist are for the case they are interesting for inclusion in u-d-t
[16:45] <nxvl_work> https://wiki.ubuntu.com/SponsorshipProcess?highlight=%28sponsors%29
[16:45] <imbrandon> not assign, subscribe
[16:46] <psusi> that's it
[16:47] <nxvl_work> RainCT: it was only for storing the deb's on ubuntu/$dist instead of i don't remember where and to use $dist-pbuilder instead of pbuilder-$dist IIRC
[16:47] <RainCT> ah
[16:48] <RainCT> you can change the location where the files are placed by exporting a variable in ~/.bashrc
[16:48] <nxvl_work> RainCT: to store them on $BASE_DIR/$DIST instead of $BASE_DIR can be a good change
[16:48] <psusi> ohh... now I'm actually updating to the new upstream as more of a side item
[16:48] <psusi> the reason I started this update was to fix an existing bug report
[16:49] <RainCT> nxvl_work: it should already be doing this
[16:49] <psusi> so should I just request sponsorship on that report?
[16:49] <nxvl_work> RainCT: but the variables are created on the script, so i'm not sure if that will work
[16:50] <nxvl_work> mmm
[16:50] <nxvl_work> i use pbuilder-distribution, no pbuilder-dist
[16:50] <RainCT> nxvl_work: it should create a directory in $BASE_DIR for each different distribution, like: feisty-i386_result    gutsy-i386_result    hardy-i386_result    sid-i386_result
[16:51] <nxvl_work> RainCT: maybe, what i was using /usr/share/doc/pbuilder/examples/pbuilder-distribution.sh not pbuilder-dist
[16:51] <RainCT> ah, that's a different one
[16:51] <nxvl_work> i have copy that script on my $PATH
[16:51] <nxvl_work> RainCT: yep, i didn't know there was a pbuilder-dist script :D
[16:52] <RainCT> actually, it's the same but an older version
[16:52] <nxvl_work> the thing is that works :D
[17:00]  * RainCT is not sure if he should subscribe u-u-s to bug #177203 or look if debian does anything and, if they do, sync
[17:00] <ubotu> Launchpad bug 177203 in dosbox "Imperfect text information in .desktop file" [Low,In progress] https://launchpad.net/bugs/177203
[17:03] <imbrandon> psusi: also patches always welcome to allow -0ubuntu1 to include the orig in uploads too :)
[17:03] <psusi> imbrandon: huh?
[17:04] <geser> RainCT: as the last two dosbox uploads to Debian were NMUs, I don't expect an upload for this minor issue soon and would upload to Ubuntu
[17:07] <RainCT> geser: ok, thanks, I'll subscribe u-u-s then. or do you want to sponsor it? :)
[17:11] <nixternal> imbrandon: that kdebindings package is retarded
[17:12] <imbrandon> ?
[17:12] <nixternal> it is getting stuck at about 60% on something, and I can't tell why now
[17:12] <nixternal> I swore I went through and built it once last night
[17:12] <imbrandon> hrm , might needs a newer svn snapshot
[17:12] <nixternal> ya, I am going to make a snapshot here in a few
[17:12] <imbrandon> k
[17:12] <nixternal> right now I am cooking breakfast on my cpu
[17:12] <imbrandon> i just did svn export ....... and tar'd it up
[17:13] <nixternal> gotta love that export feature
[17:13] <imbrandon> :)
[17:13] <imbrandon> that one was 8 days ago, so its fairly old ( considering we're talking kde )
[17:16] <nxvl_work> Ng: ping
[17:48] <RzR> hi
[17:48] <RzR> is quilt encouraged in ubuntu package management ?
[17:51] <azeem> RzR: not that I know what is recommended, but quilt makes IMHO sense if you've got more than a handful of patches and/or quite large ones
[17:51] <pochu> RzR: I'd encourage you to use the patch system you like the more
[17:51] <azeem> or if you don't use cdbs so simple-patchsys is no option
[18:27] <RzR> azeem, pochu : ok thx lets do it now
[19:04] <ScottK2> I've been offline.  Are the bulidd's fixed yet?
[19:05] <stgraber> they should yes
[19:08] <ScottK2> stgraber: Thanks
[19:29] <ScottK2> blueyed: Are you around?
[19:31] <ScottK2> Anyone know what I need to install fix "make: phpize: Command not found"  when building a source package?
[19:33] <RzR> ScottK2: try php5-dev
[19:33] <stgraber> it's in php5-dev
[19:33] <ScottK2> Thanks
[19:34] <ScottK2> I don't normally do php stuff, but I'm trying to finish a library transition.
[19:44] <ScottK2> See you all later.
[19:45]  * pochu finally sends his application to become a MOTU!
[19:46]  * slytherin has a long way to go
[19:46] <stgraber> pochu: I was wondering when you'd apply for MOTU membership :)
[19:46]  * jonnymind is away: dinner
[19:46] <stgraber> looking at the number of upload I saw with your name in hardy-changes .)
[19:47] <pochu> stgraber: That's exactly what my sponsors were thinking ;-)
[19:48] <stgraber> :)
[19:50] <RzR> anyone here are also pending Debian Developpers ?
[19:51] <sladen> RzR: uh huh
[19:53] <RzR> this could happend :)
[19:53] <RzR> i know one
[19:55] <sladen> RzR: budget at least a couple of years for NMU
[19:56] <RzR> I'll test this
[19:57] <RzR> the race will start in a couple of days
[20:22] <TheMuso> Ooo nice. Buildds fixed again.
[20:28] <geser> Yes, elmo fixed them.
[20:31] <DarkSun88> Well. I hope that any MOTU check my package in u-u-s queue. :)
[20:33] <Adri2000> http://qa.debian.org/madison.php?package=homebank&s=unstable&a=source&text=on < I don't understand why the first line is displayed, as I request arch=source. if it's a bug, does anyone know where should I report it?
[20:41] <RzR> is it possible to use dput -f with PPA ?
[20:42] <jpatrick> don't think so
[20:49] <RzR> is it possible to use dput -f with PPA ?
[20:49] <RzR> oops
[20:49] <RzR> sorry
[20:50] <RzR> i am though ssh and dont see what i am typing
[20:50] <geser> Adri2000: it seems to be a bug, Kmos mailed Christoph Berg (myon) about it but I don't know if it fixed already
[20:50] <geser> RzR: why do you need to use dput -f?
[20:51] <RzR> to overwrite a bugged package without incremeting the version
[20:52] <geser> RzR: once it got accepted you need a new version
[20:53] <RzR> geser: i can handle this
[21:00] <TheMuso> o/c
[21:00] <TheMuso> ugh
[21:16] <imbrandon> hrm
[21:18] <geser> Hi TheMuso :)
[21:24] <imbrandon> hrm, if apt-mirror is purged should it remove the already downloaded data ( e.g. debs ) , if not what shoud it do with them
[21:27] <DarkSun88> Sorry, I've mistaked channel.
[21:40] <DarkSun88> Is there a scandisk program for FAT32 filesystem?
[21:40] <imbrandon> fsck.vfat
[21:41] <DarkSun88> Thanks.
[21:42]  * TheMuso wonders whether it does as good a job as the windows tools however.
[21:49] <txwikinger> since when is libc6-amd64 a i386 package?
[21:49] <jpatrick> txwikinger: it's a bug
[21:50] <txwikinger> ah :)
[21:50] <txwikinger> Just wondered :)
[21:50] <txwikinger> Does that break my pbuilder update?
[21:50] <geser> txwikinger: libstdc++6 wants the 32bit and 64bit libc installed
[21:51] <geser> txwikinger: shouldn't. which error do you get?
[21:51] <txwikinger> geser: E: Internal Error, Could not perform immediate configuration (2) on libstdc++6
[21:51] <geser> ah, that one
[21:51] <geser> the buildds had the same problem
[21:52] <txwikinger> well.. at least I am not alone :D
[21:52] <stgraber> txwikinger: the fix for the builds was : apt-get install libc6 tzdate && apt-get dist-upgrade IIRC
[21:53] <txwikinger> how can I do that for pbuilder?
[21:53] <geser> the problem only appeared on the buildds and \sh could reproduce it, other people didn't have the problem
[21:53] <geser> txwikinger: pbuilder login --save-after-login
[21:53] <txwikinger> maybe if I just create the tarball
[21:54] <geser> and when you logged in, update the pbuilder from inside
[23:20] <zul> evening