[00:00] <jdong> ScottK: you can do it since you have the first thing that needs it
[00:01] <ScottK> K
[00:09] <pschorf> xtnight, i've finished the build
[00:10] <xtknight> pschorf, hey you'll have to type my name properly to highlight it :)
[00:10] <pschorf> haha
[00:10] <xtknight> post your debdiff though.
[00:10] <pschorf> wrong "knight" :(
[00:12] <xtknight> !info update-manager
[00:12] <ubotu> update-manager (source: update-manager): GNOME application that manages apt updates. In component main, is optional. Version 1:0.81 (gutsy), package size 863 kB, installed size 2144 kB
[00:13] <pschorf> xtknight, http://rafb.net/p/RJsS8U43.html
[00:14] <xtknight> pschorf, it looks like you've got two patches in there
[00:15] <xtknight> i would remove the regular .patch one
[00:15] <xtknight> dpatch is the proper extension
[00:15] <pschorf> oh, i forgot to delete the old file
[00:16] <xtknight> you can just remove the .patch from the debdiff
[00:16] <pschorf> just delete everything after its mentioned?
[00:16] <xtknight> you might want to add a description after DP: in the dpatch file.  i'm not sure if we did this last time but it's a good idea
[00:16] <xtknight> pschorf, delete diff -Nru /tmp/2jOmb0ofCy/f-spot-0.4.2/debian/patches/fix_gnome_screensaver.patch /tmp/N8qEZunigO/f-spot-0.4.2/debian/patches/fix_gnome_screensaver.patch
[00:17] <xtknight> and everything after
[00:17] <xtknight> line 45
[00:18] <pschorf> the description is to be added to the 00list file?
[00:18] <xtknight> nope the .dpatch file
[00:18] <xtknight> +## DP: No description.
[00:19] <xtknight> be careful about editing diffs though.  you can really only reliably delete entire diffs like we just did (for .patch), or edit existing lines without causing trouble.
[00:19] <xtknight> i'm not even sure if editing No description is safe, but we can test it.
[00:19] <pschorf> ok, i added a short description
[00:20] <xtknight> ok post what you have now again
=== danielm__ is now known as danielm
[00:21] <pschorf> http://rafb.net/p/F9nqjf83.html
[00:21] <jdong> ScottK: I'm gonna register the hardy-backports product on LP now
[00:21] <xtknight> pschorf, that looks good to me
[00:22] <xtknight> pschorf, let's test to make sure your edited debdiff applies
[00:22] <ScottK> jdong: Great.
[00:22] <xtknight> pschorf, first redownload an original f-spot in another folder.
[00:22] <ScottK> I guess I'll get clamav ready - maybe later tonight.
[00:22] <pschorf> ok, i have the source
[00:23] <xtknight> pschorf, cd into it and apply your debdiff
[00:23] <xtknight> patch -p0 < /path/to/debdiff
[00:23] <xtknight> if you don't get any errors, you're good
[00:24] <pschorf> xtknight, it worked
[00:24] <xtknight> pschorf, ok then it's time to upload it.  what section is f-spot in?
[00:25] <pschorf> do you mean main?
[00:25] <xtknight> yea
[00:25] <xtknight> pschorf, ok.  so post the patch via a comment on the LP page, status to "confirmed/no one" like last time
[00:25] <xtknight> this time we will subscribe ubuntu-main-sponsors since it is a main package
[00:26] <xtknight> pschorf, only change the f-spot (Ubuntu)
[00:26] <xtknight> pschorf, as other people have not tested the patch yet, you may want to do this
[00:28] <pschorf> i just posted it
[00:28] <xtknight> ok
[00:28] <xtknight> did you subsccribe them yet?
[00:28] <xtknight> i think you should test first
[00:28] <pschorf> ok
[00:29] <xtknight> use the binary packages produced
[00:29] <xtknight> first reproduce the bug
[00:29] <xtknight> then install your updated binaries and see if it fixes it
[00:29] <xtknight> f-spot is installed on all ubuntu installations by default
[00:30] <pschorf> ok
[00:30] <pschorf> i will look at it before subscribing ubuntu-universe-sponsors
[00:30] <pschorf> i need to work on an MP now, though
[00:30] <null_vector> Is it safe to call aclocal/autoconf in debian/rules?
[00:31] <xtknight> hope he knew it's u-m-s not u-u-s
[00:37] <Bruno_> is the chanlog updated after the fixes have been made in the dpatch shell?
[00:37] <up_the_irons> is this an appropriate channel to ask a question about backporting a package? (i've successfully backported several packages, but this libonig2 one is giving me trouble)
[00:37] <jdong> up_the_irons: what are you trying to backport, and what problems are you running into?
[00:38] <ScottK> up_the_irons: jdong is Mr. Backports, so you're talking to the right guy.
[00:39] <up_the_irons> jdong: the package is libonig2
[00:39] <up_the_irons> ScottK: cool :)
[00:40] <up_the_irons> jdong: i grabbed the source from gutsy and am trying to build it on dapper
[00:40] <up_the_irons> jdong: at the very end of 'sudo dpkg-buildpackage -us -uc -rfakeroot' I get:
[00:40] <up_the_irons> dh_testdir -i
[00:40] <up_the_irons> dh_testdir: I have no package to build
[00:40] <up_the_irons> make: *** [binary-indep] Error 1
[00:41] <up_the_irons> jdong: i tried commenting the line out in debian/rules, but i get a similar error from almost every line in the 'binary-indep' target.  If I remove the whole thing, I get farther, but then other problems arise
[00:42] <jdong> up_the_irons: let me take a look at the package
[00:42] <up_the_irons> jdong: thanks
=== elkbuntu_ is now known as elkbuntu
[00:42] <jdong> but commenting out dh_testdir won't get you anywhere useful :D
[00:43] <up_the_irons> yeah didn't seem to ;)
[00:45] <pschorf> xtknight: can I just install my .deb packages, or do I need to get rid of f-spot first?
[00:47] <jdong> up_the_irons: odd enough
[00:47] <up_the_irons> hehe
[00:48] <jdong> up_the_irons: the same errors show up in a test build under gutsy but the error is not fatal
[00:48] <up_the_irons> odd
[00:48] <jdong> up_the_irons: I'm gonna try a nasty hack (|| true) and see what happens :)
[00:49] <up_the_irons> jdong: ok :)
[00:51] <xtknight> pschorf, just install yours
[00:52] <xtknight> pschorf, by the way it's ubuntu-main-sponsors that needs to be subscribed, not ubuntu-universe-sponsors
[00:52] <xtknight> pschorf, ill be here and away a little.  lifting weights.  i need to get my butt off this seet
[00:52] <xtknight> :p
[00:52] <jdong> up_the_irons: yeah it definitely needs a newer debhelper than it has
[00:52] <jdong> up_the_irons: this is going to be an ugly monster :)
[00:53] <up_the_irons> jdong: oh man :)
[00:54] <up_the_irons> jdong: so the build-deps version (for debhelper) needs to be newer?
[00:54] <pschorf> xtknight, enjoy ;)
[00:54] <jdong> up_the_irons: that's correct
[00:54] <up_the_irons> jdong: gotcha
[00:54] <jdong> up_the_irons: not like anyone pays attention to debhelper dep versions while backporting anyway ;-)
[00:54] <up_the_irons> jdong: yeah true
[00:56] <jdong> up_the_irons: if you work hard enough at hacking it you can probably get it to build
[00:56] <jdong> up_the_irons: || true everything in binary-indep, then replace ${binary:Version} with actual version of the package in debian/control, etc
[00:57] <jdong> up_the_irons: but the official, correct stance is that the package requires a newer debhelper
[00:57] <up_the_irons> jdong: where do you suggest I start?  Or perhaps it would be easier just to grab the upstream source and roll my own .deb?  It's not gonna be for distribution, just for this one server i have
[00:57] <jdong> up_the_irons: start with the suggestions I mentioned above
[00:57] <up_the_irons> jdong: ok
[00:58] <up_the_irons> jdong: what's up w/ the version btw?  I noticed that problem too, says the version was empty or something
[00:58] <jdong> up_the_irons: that's what's wrong
[00:58] <jdong> up_the_irons: ${source:Version} in Dapper is actually ${Source-Version}
[00:59] <up_the_irons> jdong: roger
[00:59] <up_the_irons> makes sense
[01:00] <up_the_irons> jdong: so then is ${binary:Version} equiv to ${Binary-Version} ?
[01:00] <up_the_irons> jdong: i mean the dapper version
[01:01] <up_the_irons> not necessarily 'equivalent'
[01:01] <jdong> up_the_irons: I'm not sure, you can try it, but I just confirmed that Source-Version generates a working package
[01:01] <jdong> up_the_irons: well rather the build succeeds
[01:01] <jdong> whether or not it actually works is an adventure for the brave :)
[01:01] <up_the_irons> right :)
[01:01] <slangasek> ${Binary-Version} is not a recognized substitution
[01:01] <up_the_irons> slangasek: ok
[01:01] <slangasek> and Source-Version is deprecated in favor of ${binary:Version}
[01:02] <slangasek> (or ${source:Version}, depending on which semantics are more appropriate; in Ubuntu, the two are always equivalent)
[01:02] <jdong> for that matter, it probably wouldn't be a bad idea to bump libonig's debhelper dep to the appropriate version to enforce this
[01:03] <jdong> slangasek: do you know off the top of your head which debhelper version that'd be?
[01:03] <up_the_irons> woohoo: dpkg-deb: building package `libonig2' in `../libonig2_5.9.0-0.1_i386.deb'.
[01:03] <up_the_irons> worked
[01:04] <slangasek> jdong: hmm? to enforce what?
[01:05] <slangasek> jdong: these substitutions don't come from debhelper at all
[01:05] <jdong> slangasek: oh, they don't?
[01:05] <slangasek> this is dpkg-dev
[01:05] <jdong> slangasek: oh. Do you think we need a versioned build-dep against it to prevent these kinds of FTBFS?
[01:06] <slangasek> sorry, what kind of FTBFS was that?  I probably missed the beginning of the conversation
[01:07] <jdong> slangasek: the libonig package satisfies Dapper's build-deps but FTBFSes due to requiring these substitution variables... IMO that's a packaging bug
[01:07] <up_the_irons> ftbfs? :)
[01:07] <jdong> slangasek: of course the package was uploaded to Feisty first so it's unlikely anyone tested building it against earlier Ubuntu releases
[01:07] <slangasek> jdong: oh, well, if you care about the package being buildable on dapper, yes. :)
[01:08] <slangasek> jdong: in that case, a versioned build-dep on dpkg-dev (>= 1.13.19) is appropriate
[01:09] <jdong> slangasek: meh I don't feel like it... I'll add "file a bug in Debian" to the bottom of my TODO list :)
[01:09] <up_the_irons> haha
[01:09] <slangasek> jdong: not a very useful todo list item, Debian doesn't have any supported releases left which fail to satisfy that versioned build-dep...
[01:10] <persia> jdong: There's a whole heap of packages that have that problem, likely almost everything that underwent the transition.  Are you sure you want to file a bug for this?
[01:11] <jdong> persia: Cancel! Cancel!!!!!
[01:11] <xtknight> pschorf, back for a second
[01:12]  * persia looks forward to more sourceful backports for Dapper
[01:14] <pschorf> xtnight, i installed my deb packages but I still don't have any images in the screensaver
[01:14] <pschorf> xtknight*
[01:14] <xtknight> pschorf, ok, then i'd report that to the bug page and not subscribe sponsors
[01:14] <pschorf> ok
[01:14] <null_vector> Is anyone able to help me with an autotools issue with the FTBFS in xine-plugin?
[01:15] <pschorf> i may be using f-spot wrong, though
[01:15] <xtknight> pschorf, hopefully other people can try it too
[01:15] <pschorf> do I do anything besides select "use all photos"
[01:15] <xtknight> no idea
[01:15] <pschorf> ok, will report back
[01:16] <up_the_irons> jdong: thanks for your help.  libonig2 seems to be working on my box.
[01:18] <jdong> up_the_irons: cool
[01:32] <bddebian> Heya gang
[01:32] <protonchris> Hey bddebian
[01:33] <bddebian> Hello protonchris
=== hexmode` is now known as hexmode
[02:01] <jdong> asac: when you're bored and just feel like chatting, what are your thoughts on this PGO optimization build stuff for Mozilla?
[02:22] <mophead> What is the difference between this channel and ubuntu-devel?
[03:08] <pschorf> How would I read this in a diff file?  -			case "-slideshow":
[03:08] <pschorf> +			case "-slideshow": case "--slideshow":
[03:08] <pschorf>  				slideshow = true;
[03:08] <pschorf>  				break;
[03:09] <xtknight> what do you mean?
[03:10] <pschorf> what would that do when executed?
[03:10] <xtknight> it removes the line "case -slideshow": and adds the line that starts with a +
[03:10] <RAOF> pschorf: They're changing from only accepting "-slideshow" to accepting both "-slideshow" and "--slideshow"
[03:10] <pschorf> ok
[03:12] <xtknight> lol dont you hate it when you do nano | less
[03:12] <pschorf> haha
[03:13] <prana> hello! is bug 208894 (upgrade of Mercurial to 1.0) something that would be likely to get a FFe?  Updated Debian packages are in process (see linked debian bug 474877).
[03:13] <ubotu> Launchpad bug 208894 in mercurial "mercurial-1.x upgrade" [Wishlist,Confirmed] https://launchpad.net/bugs/208894
[03:13] <ubotu> Debian bug 474877 in mercurial "Upgrade Mercurial to 1.0 release" [Wishlist,Open] http://bugs.debian.org/474877
[03:15] <pschorf> xtknight, how do I apply a dpatch file to test it again?
[03:15] <RAOF> prana: It's impossible to tell without more information than is in that bug.
[03:15] <xtknight> pschorf, a dpatch file?
[03:15] <xtknight> hmm
[03:16] <pschorf> i think the patch file didn't run when we built it
[03:16] <RAOF> prana: It's possible (but unlikely at this stage), if it fixes a whole bunch of bugs.
[03:16] <prana> RAOF: i.e. full debdiff etc?
[03:16] <RAOF> prana: Yeah.  Following the FFe process is good :)
[03:16] <RAOF> prana: Diffstat, diff of upstream changelog, etc.
[03:16] <pschorf> xtknight: the patch we created isn't in the 00list file
[03:16] <prana> RAOF: http://ftp-master.debian.org/new/mercurial_1.0-1.html would perhaps summarize.
[03:17] <xtknight> pschorf, you know, i just had that trouble
[03:17] <ScottK> prana: If you can't be bothered to do more than summarize, why should I expend my volunteer time caring?
[03:17] <xtknight> pschorf, one second :p
[03:17] <xtknight> yiikes
[03:17] <xtknight> i hope i didnt screw up my last few debdiffs
[03:17] <xtknight> oh well
[03:17] <xtknight> life happens
[03:17] <jdong> whoa, mercurial went 1.0?
[03:18] <pschorf> can we just type it in, or would that cause tons of trouble down the way?
[03:18] <xtknight> the next question is, why on earth didn't dpatch-edit-patch add the patch to 00list??
[03:18] <RAOF> prana: And the summary is a big, *big* evil set of huge, major changes.  That's likely to make anyone go "no", two days before final freeze.
[03:18] <prana> ScottK: i'm new; just asking for an opinion here since it looks more complicated than simply sucking over a new debian package.
[03:18] <xtknight> i think that'll be fine pschorf let me check though
[03:18] <jdong> xtknight: because you don't always want it in 00list :)
[03:18] <jdong> xtknight: probably a crummy answer though ;-)
[03:18] <xtknight> how do i get it to add it to 00list?
[03:18] <xtknight> i thought it did by default.  sily me
[03:18] <jdong> xtknight: just edit 00list
[03:18] <prana> ROAF: ok, that's what i thought.
[03:18] <pschorf> thanks jdong...i thought the same
[03:18] <prana> jdong: apparently, 2 weeks ago.
[03:19] <jdong> prana: cool. I guess I haven't been in touch with that side of things for a hwile now
[03:19] <xtknight> k
[03:19] <ScottK> prana: It's unlikely, but if it's mostly bug fixing, not impossible.
[03:19] <xtknight> pschorf, well yup add it to 00list.  ill be busy fixing my last few :D
[03:19] <pschorf> xtknight, should i just add it before the 98 and 99 patches?
[03:19] <xtknight> pschorf, add it as the last one actually.  i think.
[03:19] <RAOF> ScottK: The debian changelog suggests that there's a whole bunch of new/changed features.
[03:19] <jdong> ScottK: it looks fairly new-feature.
[03:20] <RAOF> Like, a page of text at 1280x1024 of new features :)
[03:20] <ScottK> Then no.
[03:20] <xtknight> pschorf, do you have any previous patches where you did dpatch?  might need to fix em
[03:20] <pschorf> xtknight, and then just debuild?
[03:20] <pschorf> no
[03:20] <xtknight> pschorf, yup
[03:21] <prana> yeah, theres 485 files changed with 10k insertions and 6k deletions in a uscan diffstat.
[03:21] <p> sorry, my other computer tanked
[03:21] <p> this is pschorf
[03:21] <prana> ok, thanks.
[03:22] <p> xtknight, do i just re-run debuild -S after changing 00list?
[03:23] <xtknight> p, run debuild without -S
[03:23] <xtknight> we also need new binaries
[03:23] <xtknight> -S only produces source changes
[03:24] <p> do i need to delete the old binaries?
=== p is now known as pschorf2
[03:24] <xtknight> p, no they will be overwritten.  but you can for safety
[03:24] <xtknight> rm *.deb that is
[03:25] <pschorf2> xtknight, now the build failed when applying the patch
[03:26] <xtknight> pschorf, ok
[03:26] <xtknight> pschorf, remove it from 00list
[03:26] <xtknight> for a second
[03:27] <xtknight> then run "debian/rules clean" (maybe with sudo)  we need to do that, before we add it to 00list.  otherwise it thinks there's a patch in there.
[03:30] <pschorf2> hmm,,,the build is still failing
[03:30] <pschorf2> can i copy the dpatch to a fresh source download and try there?
[03:31] <xtknight> yeah just nuke it
[03:31] <xtknight> and start overi guess
[03:31] <xtknight> copy you changelog
[03:31] <xtknight> and your dpatch, 00list to a fresh source
[03:45] <pschorf> xtknight, the build still failed with fresh source
[03:47] <xtknight> pschorf, ok one sec
[03:48] <xtknight> pschorf, do you have any idea why that may be?
[03:48] <pschorf> no, the dpatch file looks fine
[03:49] <xtknight> pschorf, try just building the fresh source
[03:49] <xtknight> see if that even works
[03:50] <pschorf> ok
[03:53] <pschorf> a fresh build worked
[03:53] <xtknight> well why dont you work off that and try and regenerate the .dpatch
[03:54] <xtknight> dpatch-edit-patch patch PATCHNAME
[03:54] <xtknight> patch -p0 < /path/to/undebianized/diff
[03:54] <xtknight> exit
[03:54] <xtknight> (add PATCHNAME to 00list)
[03:54] <xtknight> and try again :)
[03:55] <pschorf> i actually already regenerated to use with the fresh source
[03:56] <xtknight> it's stil not working?
[03:56] <xtknight> can i see the dpatch file?
[03:56] <xtknight> pastebin
[03:56] <pschorf> yeah
[03:56] <xtknight> and what bug is this again?
[03:57] <pschorf> http://rafb.net/p/5xflBW15.html
[03:57] <pschorf> bug 208629
[03:57] <ubotu> Launchpad bug 208629 in f-spot "f-spot doesn't work with gnome-screensaver" [Medium,Confirmed] https://launchpad.net/bugs/208629
[03:57] <xtknight> i'll try it in a second.  just as soon as i get this load of audacious-plugins off my shoulders :P
[03:57] <pschorf> alright
[04:05] <xtknight> pschorf, as a side note you should probably put your name in the dpatch as well not just email
[04:05] <xtknight> like it is in the changelog
[04:05] <xtknight> but i'm going to try the patch now
[04:05] <pschorf> ok
[04:07] <xtknight> pschorf, so yours ended up a little different than mine.  what's the exec f-spot thing.  is that another patch?
[04:08] <pschorf> i think
[04:08] <xtknight> hmm i see the guy who posted it on LP conventiently omitted half of the patch
[04:08] <pschorf> yeah
[04:08] <xtknight> well that's not good
[04:08] <pschorf> there were 2 parts in addition to the changelog stuff
[04:08] <xtknight> sec
[04:10] <xtknight> http://rafb.net/p/mWlYm939.html
[04:10] <xtknight> that's what i came with
[04:10] <xtknight> looks exactly the same
[04:10] <xtknight> let me try it
[04:11] <xtknight> i have a pbuilder where i can facilitate a clean build of it
[04:12] <xtknight> sometimes building on your main machine can get messy
[04:12] <pschorf> k
[04:13] <xtknight> ya it failed
[04:13] <xtknight> ok
[04:13] <xtknight> it's because we need to apply it in a different order, i guess
[04:14] <xtknight> generally that's what this means.  applying patch fix_gnome_screensaver to ./ ... failed.
[04:14] <pschorf> ok
[04:14] <xtknight> so we have to find an order where the rest of the patches dont conflict
[04:14] <pschorf> ok
[04:14] <xtknight> generally we do that by "dpatch-edit-patch patch fix_gnome_screensaver THELASTPATCH"
[04:14] <xtknight> 99 i think.  but i think that failed for me
[04:14] <xtknight> just a sec
[04:18] <xtknight> pschorf, ok
[04:18] <xtknight> pschorf, dpatch-edit-patch patch fix_gnome_screensaver 99_ltmain_as-needed
[04:18] <xtknight> we should very often use it like that, where we pick the last patch in 00list for the end of the command
[04:18] <xtknight> however this gives us some failures as we try to patch -p0... but we can fix these by hand
[04:19] <pschorf> ok
[04:19] <xtknight> basically based on common sense
[04:19] <xtknight> so get fresh source if you haven't alrady
[04:21] <pschorf> ok
[04:21] <pschorf> got the source
[04:22] <xtknight> ok
[04:22] <xtknight> so when you're in the interactive editor, try to apply the patch again like we always do
[04:22] <xtknight> you'll get errors
[04:22] <xtknight> but we can fix these
[04:25] <pschorf> ok
[04:25] <pschorf> i got a HUNK failed error
[04:26] <xtknight> pschorf, ok
[04:26] <xtknight> sorry i was a little preoccupied
[04:26] <xtknight> free now
[04:26] <pschorf> it looks like the data its trying to change in f-spot-screensaver is different than expected
[04:26] <xtknight> yea
[04:27] <xtknight> let's look at the .rej file
[04:27] <xtknight> these are the "rejects" :p
[04:27] <xtknight> basically you can tell it's just trying to remove a dash from the command line
[04:28] <pschorf> right
[04:28] <xtknight> but one of the patches changed the command line from bin/sh to bin/bash so the patch no longer works!
[04:28] <pschorf> ah...
[04:28] <pschorf> i'm with you
[04:28] <xtknight> pschorf, now since patch failed it created a mess.  delete .orig and .rej files
[04:28] <pschorf> ok, removed
[04:29] <xtknight> pschorf, as a matter of fact patch can leave behind .origs when patches dont *exactly* match but still work.  so you always want to make sure no .orig files are there (but also make sure you dont delete .origs if the package had them already).  this is why you always want to examine your debdiffs when you're finished with things, for unexpected changes.
[04:29] <pschorf> ok
[04:29] <xtknight> we are still in the interactive shell, which means it's watching what we do
[04:29] <xtknight> so just apply the patch yourself
[04:29] <xtknight> remove the dash in that file
[04:30] <xtknight> you could also use gedit, but then you'd have to delete the ~ backup file it leaves behind as well
[04:30] <pschorf> ok, file changed
[04:30] <xtknight> nano tools/f-spot-screensaver
[04:30] <xtknight> right?
[04:30] <pschorf> right, i used vim
[04:30] <xtknight> k
[04:30] <xtknight> so let's "exit"
[04:30] <pschorf> k
[04:31] <xtknight> pschorf, make sure you put your name and email and description in the dpatch file
[04:31] <xtknight> you know, there's something you should do right now to make it put your name and email always there
[04:31] <xtknight> at the end of your ~/.bashrc add this
[04:31] <xtknight> export DEBFULLNAME="My Name"
[04:31] <xtknight> export DEBEMAIL="asdf@gmail.com"
[04:32] <xtknight> and dch and dpatch will obey this. you'll still have to add description though
[04:33] <xtknight> those should match your gpg key of course
[04:33] <pschorf> ok
[04:33] <pschorf> i've edited the dpatch and .bashrc
[04:34] <xtknight> now with your new patch make sure you edited with "dch -i" also
[04:34] <xtknight> to add the changelog
[04:34] <xtknight> and add it to 00list!
[04:35] <xtknight> at the end.  because we made our patch after 99 was applied, with that command.
[04:35] <xtknight> applying patch fix_gnome_screensaver to ./ ... ok.
[04:35] <xtknight> mine works
[04:37] <pschorf> ok, mine's building
[04:37] <xtknight> cool
[04:38] <xtknight> you caught on to this pretty fast.  good job.  you learned as much as i did ever since i started doing it.  because i just learned dpatch-edit-patch today
[04:38] <xtknight> i just recently started fixing bugs again
[04:38] <pschorf> i spent a fair amount of time re-reading irc chat from earlier
[04:38] <pschorf> but i think i've got it
[04:38] <pschorf> ...for now
[04:38] <xtknight> i always check my debdiffs meticulously afterwords
[04:39] <xtknight> this is pretty much the foolproof method to ensure i did the right thing
[04:39] <pschorf> so you just check to see that it only changed the data that you actually meant it to, and go over the changelog?
[04:39] <xtknight> maybe you want to get a PPA so it's easier for people to check your patches
[04:40] <xtknight> pschorf, it should change 00list, the changelog, and add the  dpatch file basically.  and the binaries should work.  if those 4 cases are met, then you're set! (at least for dpatch patch systems)
[04:40] <pschorf> how do i get a PPA?
[04:40] <xtknight> dont misread it either.  the dpatch file will contain diff -Nru ,etc that's not another patch that's within the dpatch.
[04:40] <pschorf> ok
[04:40] <xtknight> pschorf, it's free and easy read here https://help.launchpad.net/PPAQuickStart
[04:41] <xtknight> have your gpg public key ready
[04:41] <xtknight> when they say sign CoC that means you have to go thru a process of signing it with your GPG key, not just reading it
[04:42] <xtknight> but that'll come up in the process
[04:43] <pschorf> ok, i've got that up and running
[04:43] <xtknight> what?
[04:43] <pschorf> i added the gpg key earlier, so it was pretty painless
[04:43] <pschorf> the ppa
[04:43] <xtknight> already? llol
[04:43] <xtknight> did you sign the CoC?
[04:44] <pschorf> yeah
[04:44] <xtknight> ok we'll see when we attempt to upload things then
[04:45] <xtknight> setup the dput rc file?
[04:45] <xtknight> dput cf
[04:45] <pschorf> do i run that in the dir with the deb and debdiff files?
[04:45] <xtknight> dput ppa asdf_source.changes
[04:46] <xtknight> there will be a .changes file
[04:46] <xtknight> you want to upload the source one not the i386 or amd64 one
[04:47] <xtknight> you dont need to run debuild again if you already have your changes
[04:47] <pschorf> i just have an i386 file
[04:47] <xtknight> ah ok then do run "debuild -S -sd"
[04:47] <xtknight> Note: If you're building an alternative version of a package already in the primary Ubuntu archive, build your source package using debuild -S -sd. If you're building an entirely new package whose orig.tar.gz is not yet in the Ubuntu primary archive, build the source package with debuild -S -sa.
[04:48] <xtknight> now actually
[04:48] <xtknight> umm
[04:48] <xtknight> they want you to name it like ~ppa
[04:48] <pschorf> ?
[04:48] <xtknight> that's just the most convenient for everyone.  so edit your changelog with "dch -e" and after that you can run "debuild -S -sd".  you do not need to recompile a binary to change the package version
[04:48] <xtknight> myapp_1.0.1-0ubuntu1~ppa1
[04:48] <xtknight> instead of myapp_1.0.1-0ubuntu1
[04:49] <pschorf> so instead of ubuntu2, i would have ubuntu2~ppa1?
[04:49] <xtknight> so just add ~ppa1 to your version.  i would keep the major version increment there, because otherwise regular gets preferred over ppa1
[04:49] <xtknight> yes
[04:50] <xtknight> and ~ppa2 for subsequent revisions, ~ppa3, etc
[04:50] <xtknight> of the same patch, at least
[04:50] <pschorf> ok, now i have the ~ppa1 version
[04:51] <xtknight> dput it to your ppa
[04:51] <xtknight> source.changes
[04:52] <pschorf> i got a no host in config error
[04:52] <xtknight> go through Creating your source package at https://help.launchpad.net/PPAQuickStart
[04:57] <pschorf> so should i post my new debdiff file on LP?
[04:57] <xtknight> yup
[04:57] <xtknight> this will be a debdiff for ubuntu2, not the ppa one
[04:57] <xtknight> Bug 208629
[04:57] <ubotu> Launchpad bug 208629 in f-spot "f-spot doesn't work with gnome-screensaver" [Medium,Confirmed] https://launchpad.net/bugs/208629
[04:57] <pschorf> right
[04:58] <pschorf> can i delete my old post?
[04:58] <xtknight> nope but dont worry about it
[04:58] <xtknight> just say the last one had no patch
[04:58] <xtknight> we need to test this one anyways too
[04:59] <xtknight> man f-spot's import feature is frustrating
[04:59] <xtknight> i have the option to import all 40000 pictures on my HD, or nothing at all.
[04:59] <pschorf> i did
[04:59] <pschorf> don't worry
[04:59] <xtknight> hehe
[05:00] <pschorf> who do I subscribe again?
[05:00] <xtknight> ubuntu-main-sponsors because f-spot is in main
[05:00] <xtknight> !info f-spot
[05:00] <ubotu> f-spot (source: f-spot): personal photo management application. In component main, is optional. Version 0.4.0-0ubuntu3 (gutsy), package size 1729 kB, installed size 8924 kB
[05:01] <pschorf> ok
[05:01] <pschorf> i think that one's finally taken care of
[05:01] <xtknight> well did you tes to see if f-spot is fixed?
[05:01] <xtknight> with the patch
[05:01] <xtknight> er gnome-screensaver
[05:02] <pschorf> yes
[05:02] <xtknight> oh so this one actually works
[05:02] <pschorf> yes
[05:02] <xtknight> nice
[05:02] <xtknight> upload it to your PPA if you want.  good practice
[05:02] <pschorf> is it normal to have to edit patch files?
[05:03] <xtknight> looks like it's on your ppa building right now
[05:03] <xtknight> yeah
[05:03] <pschorf> ok
[05:03] <xtknight> very common
[05:03] <xtknight> you mean adapt patch files to make them dpatch basically?
[05:03] <pschorf> right
[05:03] <xtknight> because people don't make them properly.  they make em before they apply all the other patch chain
[05:03] <pschorf> ok
[05:04] <pschorf> what time zone are you in, out of curiosity?
[05:04] <xtknight> eastern. 12am here
[05:04] <pschorf> ok
[05:04] <xtknight> you?
[05:04] <pschorf> central
[05:04] <pschorf> so 11
[05:04] <xtknight> when your package is done building you'll have i386 and amd64 debs.  but they'll take like 20 mins from the time of build completion till launchpad uploads them to ftp
[05:05] <xtknight> so i'm going to test your packages and comment on the bug
[05:05] <pschorf> k
[05:05] <pschorf> i need to call it a night, still have physics homework and class again at 9 tomorrow
[05:05] <xtknight> ok
[05:05] <pschorf> hope it works for you too
[05:06] <pschorf> night
[05:06] <xtknight> later
[05:33] <xtknight> for something like bug 212542 can i modify the original patch or do i have to make another patch to revert the changes done by a previous patch.
[05:33] <ubotu> Launchpad bug 212542 in compiz-fusion-plugins-main "Drop type=Utility from 01-animation-defaults.patch" [Undecided,Triaged] https://launchpad.net/bugs/212542
[05:34] <jdong> xtknight: ah, thanks for working on that one!
[05:35] <jdong> xtknight: the diff posted as comment #1 is a patch against the original patch
[05:35] <jdong> xtknight: that's the way I'd recommend it done too. Just apply that patch to the debian/patches dir
[05:35] <xtknight> yeah
[05:35] <jdong> xtknight: though, for this case, I recommend talking to mvo about it (he's usually in #ubuntu-devel during normal hours)
[05:36] <jdong> xtknight: because he's also planning to push a newer Compiz and I just talked with him 6hrs ago on including this fix for the new compiz release
[05:36] <xtknight> i mean the only possible ramification would be if debian chose to somehow change the orig patch as well, and then my patch somehow wouldnt get thru because it also modified the orig patch...
[05:36] <xtknight> ironically i need to talk to him about something else too
[05:36] <xtknight> hehe
[05:38] <jdong> xtknight: perfect timing. But since none of us can upload those changes anyway...
[05:38] <jdong> xtknight: and the main sponsor queue for stuff like this usually involves poking him anyway....
[05:38] <jdong> might as well cut out the middle man
[05:38] <xtknight> ah ya
[05:40] <nityad> Hello all, I am having trouble woth pbuilder passing a build of binary package with library dependencies. The error is dpkg-shlibdeps: failure: couldn't find library libstdc++.so.5. Can anyone point me to what the issue could be?
[05:41] <xtknight> nityad, make sure you set it up for universe if that's what you need
[05:41] <xtknight> nityad,  for example https://wiki.ubuntu.com/PbuilderHowto#head-5e61fa0f52f7f2442fb20f074813bd691744460b
[05:41] <xtknight> man has anyone else noticed copy/paste with xchat works about 1/3 times?
[05:42] <jdong> xtknight: real men use real IRC clients
[05:42] <jdong> (kidding :D)
[05:42] <xtknight> lol
[05:42] <xtknight> it's better than pidgin
[05:42] <xtknight> :P
[05:42] <jdong> of course IRC would be a better place if copy-paste didn't work at all :D
[05:43] <xtknight> yeah copy-pastebin is the new copy-paste
[05:43] <jdong> we can pop up an obnoxious IRC guidelines warning box whenever the user tries to paste!
[05:43] <xtknight> we really need some sort of integration
[05:43]  * jdong wonders how many HIG guidelines he can break in one proposal :)
[05:43] <xtknight> where a user can mouseover a 'pastebin field' and then a tooltip pops up..
[05:43] <xtknight> pasting completely becomes abstracted
[05:43] <jdong> how about a distributed mesh network clipboard system? :D
[05:43] <xtknight> bittorrent
[05:43] <xtknight> lol
[05:49] <xtknight> shouldn't Bug 201287 be confirmed/nobody and subscribed to ubuntu main?
[05:49] <ubotu> Launchpad bug 201287 in apache2 "apache2 init script support for 'status'" [Wishlist,In progress] https://launchpad.net/bugs/201287
[05:50] <RAOF> xtknight: It's probably waiting for a FFe, right?
[05:50] <xtknight> RAOF, hmm? well this is a bugfix for hardy we can still do that can't we?
[05:51]  * RAOF reads that as "add the feature 'status' to the apache init script".
[05:51] <xtknight> ah i see
[05:52] <RAOF> Also, it's been on either ubuntu-devel or -discuss.
[05:52] <xtknight> guess i'll leave that one be
[05:55] <jdong> RAOF: or you can read it as BUG: status {errors out, returns incorrect result} ;-)
[05:55] <nityad> xtknight, your pointer helped and pbuilder passed for the package. Thanks!
[05:55] <xtknight> nityad, you're welcome
=== asac_ is now known as asac
[06:33] <dholbach> good morning
[06:34] <no0tic> morning :)
[06:34] <null_vector> morning
[06:35] <dholbach> hiya no0tic and null_vector - how are you guys doing?
[06:35] <null_vector> can't complain
[06:35] <no0tic> everything ok :) you?
[06:36]  * Fujitsu complains about universe being too big to even install everything on a quad-Xeon in a day.
[06:36] <no0tic> universe is bigger than you can imagine :)
[06:37] <dholbach> hehe
[06:39] <dholbach> no0tic: still waking up, I hope caffeine will kick in soon
[06:42] <AstralJava> Morning dholbach, all. :)
[06:42] <dholbach> hiya AstralJava
[06:42] <no0tic> morning AstralJava
[06:50] <xtknight> what should i do with bug 110333 if the fix is in hardy already?
[06:50] <ubotu> Launchpad bug 110333 in autogen "missing includes in getopt.tpl" [Undecided,Fix committed] https://launchpad.net/bugs/110333
[06:52] <dholbach> xtknight: the changelog does not mention the fix, and 'caludo' mentions it'd be in 5.9.4, we have 5.9.3 is in hardy
[06:52] <xtknight> dholbach, i checked the file that his diff modified, and it already has the changes
[06:53] <dholbach> xtknight: ok perfect, then just say that you double checked the fix is in hardy and mark it as 'fix released'
[06:54] <dholbach> xtknight: good work
[06:54] <xtknight> dholbach, ok.  thx.  not worrying about gutsy then?
[06:55] <dholbach> xtknight: if somebody needs the fix in gutsy, they should nominate the bug to fixed in gutsy
[06:55] <xtknight> k
[06:55] <dholbach> if somebody does, you can refer them to http://wiki.ubuntu.com/StableReleaseUpdates
[06:57] <YokoZar> Can I ask someone to download and dput a package for me?  For some reason dput is failing on the server I have it on, and I can't upload from home.  It's 400 megs, however.
[06:57] <YokoZar> dput is failling with "killed" half way through, even on a dry run
[06:58] <warp10> Good morning
[06:58] <no0tic> morning warp10 :)
[06:58] <warp10> hey no0tic! ;)
[07:53] <null_vector> Anyone mind looking over a debdiff for 68852 ?
[07:54] <xtknight> bug 68852
[07:54] <ubotu> Launchpad bug 68852 in findutils "Error in man page, re: -printf \ escape" [Low,Triaged] https://launchpad.net/bugs/68852
[07:55] <xtknight> null_vector,  hmm  what do you mean?   i don't see a debdiff.  but anyway i can't do much.  i can only look over it since i'm not a MOTU :)
[07:56] <null_vector> I mean look it over before I add it.
[07:56] <xtknight> sure do you have a URL?
[07:57] <Tonio_> dholbach: ping ?
[07:57] <Tonio_> dholbach: hi ;)
[07:58] <null_vector> http://bobbyrward.info/findutils_4.2.32-1ubuntu3.debdiff
[07:59] <xtknight> null_vector, it looks just fine to me
[07:59] <xtknight> so long as that fixes the issue
[08:01] <null_vector> yeah that's all it is, just never used dpatch before
[08:02] <xtknight> ahh
[08:02] <xtknight> yes as long as it's added to 00list you're good
[08:04] <null_vector> thanks
[08:07] <xtknight> null_vector, and i can confirm that the patch does get applied during compile.
[08:08] <null_vector> awesome
[08:09] <xtknight> don't forget to subscribe ubuntu-main-sponsors
[08:10] <null_vector> How do I do that exactly?
[08:10] <xtknight> null_vector, press Subscribe someone else
[08:10] <xtknight> !info findutils
[08:10] <null_vector> doh
[08:10] <ubotu> findutils (source: findutils): utilities for finding files--find, xargs, and locate. In component main, is required. Version 4.2.31-1ubuntu2.1 (gutsy), package size 247 kB, installed size 1280 kB
[08:11] <xtknight> we can see that the package is in component main.  otherwise, you'd subscribe ubuntu-universe-sponsors
[08:11] <null_vector> right
[08:12] <null_vector> use u-u-s for multiverse or is that even in lp?
[08:12] <xtknight> u-u-s for multiverse also yeah
[08:13] <xtknight> every package is on lp
[08:13] <xtknight> not all of them have dedicated 'projects' though.  but that's sort of another thing altogether.
[08:24] <dholbach> hey ton
[08:24] <dholbach> hey Tonio_ :)
[08:42] <primes2h> Ciao a tutti.
[08:43] <primes2h> Hello to everyone.
[08:49] <primes2h> I need help from someone.
[08:50] <primes2h> I open a Bug about a translation problem in Xaos (Bug @211710)
[08:50] <primes2h> due to Xaos problem itself.
[08:50] <no0tic> bug 211710
[08:50] <ubotu> Launchpad bug 211710 in xaos "Wrong characters codification in Xaos translation." [Undecided,New] https://launchpad.net/bugs/211710
[08:51] <primes2h> J.B. Langston (OSX mantainer of the program) provide a patch for it but he can't test it.
[08:53] <primes2h> Moreover XaoS is in main so I don't know how to do.
[08:55] <primes2h> I meant "J.B. Langston provided a patch"
[08:57] <primes2h> May someone help me?
[08:57] <primes2h> please...
=== never|mobi is now known as neversfelde|mobi
[09:04] <tjaalton> I've got a packaging question: I need to filter certain files from all the other binaries but one, but doing 'dh_install -Xfoo; dh_install -pbar' seems stupid (since the package is a multi-GB proprietary app). Is there a way to know which package is being worked on, so I could do 'ifeq "$(CURPKG)" "bar"' or similar?
[09:09] <man-di> tjaalton: dh_install -pbar -Xfoo doesnt work?
[09:10] <man-di> tjaalton: but it would probably be more easy to have debian/bar.install files
[09:10] <tjaalton> man-di: dh_install -Xfoo does the trick for all the packages, but for -pfoo I don't want to do that
[09:11] <tjaalton> uh, -pbar
[09:12] <tjaalton> man-di: the filtering is done because there are binaries for different archtitectures (linia32, linop64, linem64t), so having a bar.install doesn't work
[09:15] <man-di> tjaalton: is your package using cdbs? then you could put your install code into install/bar:: target
=== doko_ is now known as doko
[09:15] <man-di> tjaalton: and customize it easily
[09:15] <man-di> tjaalton: its surely possible without cdbs too
[09:15] <tjaalton> man-di: nope, plain debhelper
[09:16] <man-di> tjaalton: then just dont use -Xfoo with -pbar
[09:16] <tjaalton> man-di: exactly.. but I have to specify it after the first dh_install run, which means that -pbar is handled twice
[09:17] <primes2h> Could someone help me, please?
[09:47] <lool> Hey folks
[09:47] <lool> I'd like to discuss handling of the mobile packages during the freeze
[09:48] <lool> To sum up the situation: UME is on a quite different from hardy (the current target for a first official non-alpha/beta release of UME is hardy.1), and we're also quite late on misc stuff which remains TBD
[09:48] <lool> Also, we're in the process of promoting much stuff from universe/multiverse to main/restricted; packaging still sucks in many of the packages
[09:49] <Fujitsu> So we're going to have enormous amounts of mobile stuff only stabilising in -updates?
[09:49] <lool> So the intent is to continue pushing as much work as possible into the mobile packages despite the freeze, that is instead of stabilizing what we have yet
[09:49] <lool> Fujitsu: Yes
[09:49] <lool> However, the "good" news is that hopefully this should be a self contained set of packages used only for mobile
[09:49] <lool> So it shouldn't affect desktop or server users at all
[09:50] <Fujitsu> Or nothing not seeded into -mobile, I hope.
[09:50] <lool> Well the seeds are also an issue lalala
[09:50] <lool> What might also happen is that we touch universe packages which users might care about, but only to patch them for lpia
[09:51] <Fujitsu> Ew.
[09:51] <Fujitsu> Ew.
[09:51] <Fujitsu> Ew.
[09:51] <Fujitsu> Mass SRUs == bad
[09:51] <lool> Yeah, I know someone would say that
[09:51] <lool> *knew
[09:51] <lool> Fujitsu: It is bad
[09:52] <lool> Please note however that not all the updates will go into hardy proper; we intend to use our ppa as a staging area and also as a place for stuff which we simply didn't get in a good enough shape for such updates
[09:52] <Fujitsu> I'm not sure that making any PPA look more official is a good idea, but I guess it's better.
[09:53] <lool> Fujitsu: Unfortunately, it's already the case
[09:53] <Fujitsu> So I've seen, though it's not exactly released yet.
[09:53] <lool> This is due to misc reasons, but one obvious explanation is that we have like 15 people from Intel who aren't anywhere close to MOTU, and a dozen of people from Canonical who are good but aren't MOTU either
[09:54] <lool> So we have kind of a sponsoring bottleneck
[09:54] <Fujitsu> Hm. Concrete numbers. I've never seen anything like that before.
[09:54] <lool> This is being addressed, but it's not going to be fixed soonish
[09:54] <Fujitsu> A good point.
[09:54] <lool> Fujitsu: Well these are guesstimates, but I could give you hard numbers by looking at the ubuntu-mobile team
[09:55] <lool> One hard number is that we're currently two core devs in the team, and no other Ubuntu uploader (no additional MOTU)
[09:55] <Fujitsu> Ow.
[09:55] <lool> (StevenK and myself)
[09:55] <lool> This is probably reassuring to the amount of stuff we could ever try to push to hardy :)
[09:56] <lool> Anyway, I wanted to give a heads up on the topic and I hope we can follow such a plan for the freeze and after the release
[09:56] <Fujitsu> You could just blindly sponsor lots of things. It has happened before.
[09:56] <lool> TBH, I think the packages are in such a shape that updates are highly desirable, despite the freeze
[09:57] <Fujitsu> I'm not worried about -mobile stuff. I'm more worried about the result of even simple rebuilds on parts of the archive.
[09:57] <Fujitsu> No-change rebuilds will cause problems.
[09:57] <lool> Example of highly desirable stuff is moving midbrowser to build against xulrunner-1.9 like everybody else instead of building its internal copy of firefox lalala
[09:57] <lool> Fujitsu: Ack
[09:58] <Fujitsu> We had too many changes late in the cycle to be sure that things will work again.
[09:58] <Fujitsu> libc6, CFLAGS/LDFLAGS changes...
[09:58] <Fujitsu> gfortran (although that's fixed)
[09:58] <Fujitsu> python-central...
[09:58] <lool> Fujitsu: That said, it looks like something we should deal with on the hardy support time frame
[09:59] <lool> I mean, would we consider for instance that foobar doesn't like the new LDFLAGS, we should really fix it in hardy in an update instead of waiting for a randome security upload to discover it
[09:59] <lool> But agreed, there's risk in touching that many packages
[10:00] <Fujitsu> Indeed, with the number of security updates we have to organise, I'm very concerned about how many things we'll find that break not because of our fixes, but toolchain changes... We'll see.
[10:01] <lool> Naturally, I'm around if anybody has additional questions on this topic; I'll try to do my best to ensure everything runs smoothly, but suggestions and help are welcome
[10:02] <Fujitsu> I guess that as long as you test well, not too much can go too horrifically wrong.
[10:03] <lool> I'm worried that we don't test all use cases, but I naturally test all the uploads I'm interested in; for example for claws, I would test the hildonized version, probably not the regular version
[10:04] <Fujitsu> Then I would be gravely concerned with your methodology.
[10:06] <Riddell> lool: why not just continue to use the PPA?
[10:06] <\sh> because it's crap...that way
[10:07] <lool> Riddell: It sucks for various reasons and it's used for multiple things; also we can't really quality control it
[10:07] <\sh> it's true, that we will have patches from mobile devs for universe packages, galculator or claws are two examples
[10:07] <\sh> and we need more people to work on this, for porting those patches towards newer versions
[10:07] <\sh> this is the problem right now..
[10:07] <\sh> (regarding universe)
[10:08] <\sh> and I wonder if we'll find any, without the respective knowledge...
[10:09] <\sh> lool, I think you'll be in praque...if it's feasable for you and the attending motus, please raise it and try to schedule a meeting :)
[10:09] <lool> I'm happy to have a meeting on the topic for sure
[10:09] <\sh> lool, what about the open job opportunity on the careers page?
[10:10] <lool> \sh: I think we're going slightly offtopic, but to give a quick answer I'm still looking into filing it, with some serious candidates in the pipe
[10:10] <lool> BTW there is also an UMD position open
[10:11] <\sh> lool, well, if you can find a packaging dude with universe ambitions working on your team...this will solve a lot of problems
[10:12] <\sh> lool, (I think it's not offtopic...mobile is really a cornercase regarding universe work)
[10:13] <\sh> there should be a good human interface between the ubuntu-mobile and ubuntu-universe ... regarding knowledge etc.
[10:13] <lool> In general, we're looking into having more of the existing team gain MOTUship and/or coredevship if they have such interest
[10:14] <lool> We fail by quite a huge margin in the UME community front
[10:14] <\sh> lool, push adilson ;)
[10:16] <lool> He *is* being pushed :)
[10:17] <\sh> anyways...it's a heavy load for universe people to carry those patches without knowing what they do or how they work, without the right knowledge...so I think it could be vital, if you and your team can do some knowledge transfer...
[10:17] <\sh> and to let universe people know who they can kick around when they have problems converting one patch from one version to another...
[10:18] <lool> It's hard to grow interest for lpia if people don't own devices and the supported devices are not very common
[10:18] <\sh> and they are expensive
[10:18] <lool> However, I'm working in support for virtual envs
[10:18] <lool> \sh: For many reasons, they are not common  ;-)
[10:18] <lool> Expensive, not really at the peak of the market, not a lot of supported devices (because single arch and scalability issues) etc.
[10:19] <\sh> well, this HTC is a nifty little thing...but over 1k euro..is above my budget...means, wife's killing me if I click on "buy now" @amazon ;)
[10:20] <\sh> lool, raise this issue @uds praque...i think it's vital for the communication between your team and motu :)
[10:21] <lool> I want to
[10:21] <\sh> lool, anyways...wine is ready for wine...uploaded sunday the new rev for adding lpia arch
[10:21] <\sh> s/wine/lpia/
[10:22] <lool> \sh: Did you stay on top of the pas discussion?
[10:22] <\sh> lool, and regarding claws, adilson wanted to push his changed patch towards claws upstream
[10:22] <lool> Yes; I personally think Ubuntu shouldn't be maintaining these
[10:22] <\sh> lool, the last bit of info: adam wanted to add lpia to p-a-s
[10:22] <lool> Some upstreams don't show lots of interest though
[10:22] <\sh> ok mee4ting now...cu later
[10:54] <pochu> lool: do you want this for the mobile folks?
[10:55] <pochu>    * Build a wesnoth-smallgui binary (closes: #469234)
[10:55] <pochu> debian #469234
[10:55] <ubotu> Debian bug 469234 in wesnoth "please provide a wesnoth-smallgui binary package" [Wishlist,Fixed] http://bugs.debian.org/469234
[10:55] <pochu> lool: it allows you to play in reduced screens, such as the n810
[10:56] <lool> pochu: Definitely!
[10:57] <pochu> lool: ok, the rest of the changes seem reasonably so I'll test it a bit and request a sync
[10:57] <\sh> back
[10:58] <\sh> lool, regarding wine, there is not much to do for LPIA UI
[10:58] <\sh> lool, so I think it's just as easy as adding lpia arch to p-a-s ...
[10:58] <lool> Probably not indeed
[10:59] <\sh> but ubuntu and debian packages are far from being the same (for ages now :))
=== LucidFox is now known as LucidFox_away
[11:06] <stani> ScottK or Pochu: I've added a patch for Bug #213653. What is the best to continue? A SPE 0.8.4.g release or apply the patch directly?
[11:06] <ubotu> Launchpad bug 213653 in spe "SPE.py crashed with TypeError in DrawUml()" [Undecided,In progress] https://launchpad.net/bugs/213653
[11:08] <pochu> stani: I think the patch is ok
[11:09] <pochu> I mean, uploading the patch directly
[11:09] <stani> ok
[11:09] <stani> will you take care of it?
[11:10] <null_vector> bug 212055
[11:10] <ubotu> Launchpad bug 212055 in electricsheep "Unable to download sheep" [Undecided,New] https://launchpad.net/bugs/212055
[11:11] <pochu> stani: yes
[11:11] <null_vector> should probably be wont-fix as there is no mirror and won't ever be one
[11:11] <stani> pochu: thanks!
[11:17] <stani> pochu: On http://packages.ubuntu.com/hardy/spe I see that spe depends on python-wxgtk2.6. Better would be like for phatch: http://packages.ubuntu.com/hardy/phatch
[11:17] <stani> pochu: Shall I update the control file in PAPT?
[11:18] <pochu> stani: yes
[11:18] <pochu> will change that too in this upload to Ubuntu
[11:20] <stani> pochu: Can I write "Recommends: wx2.8-doc | wx2.6-doc"
[11:22] <pochu> stani: I'd add that to suggests instead
[11:22] <POX_> pochu: why are you uploading -0ubuntu1 to Ubuntu instead of syncing with Debian?
[11:22] <POX_> (vide: phatch new upstream)
[11:23] <stani> pochu: but now it is "Recommends: wx2.6-doc", so why should it move from recommends to suggests?
[11:24] <stani> Hi POX_
[11:24] <POX_> hi
[11:24] <pochu> POX_: because we are about to freeze and I didn't know how long it could take to get into Debian
[11:24] <pochu> POX_: I'm requesting a sync right now
[11:24] <pochu> stani: adding the alternative is fine then
[11:24] <POX_> pochu: dinstall is running every 12h in Debian
[11:25] <pochu> It may fit better in Suggests though, as Recommends are installed by default...
[11:25] <stani> POX_: I think ScottK suggested to upload to both directly because of the freeze.
[11:25] <pochu> POX_: right, but it also needed sponsoring and then requesting a sync and waiting for an archive admin to do it...
=== Fujitsu_ is now known as Fujitsu
[11:25] <pochu> so better to go for the safe and upload, and later sync :)
[11:27] <stani> POX_: I will upload all patches for spe as 0.8.4.g to Debian, as for Ubuntu direct patches are prefered to a new upstream release.
[11:27] <POX_> pochu: I think I uploaded it to Debian before you uploaded it to Ubuntu
[11:27] <pochu> POX_: really? I didn't notice it then...
[11:27] <pochu> anyway:
[11:27] <pochu> Sync request mailed.
[11:27] <pochu> emilio@saturno:~/tmp$
[11:28] <POX_> pochu: I tagged it later, so maybe that's why you didn't notice
[11:29] <pochu> stani: shall I add the patch to python-apps too, or will you do another bug-fix release anytime soon?
[11:31] <stani> pochu: I can do a bug-fix release anytime, but patches are less work. Maybe in some hours someone else reports another bug and than I have to release every day which doesn't make also a lot of sense.
[11:31] <stani> so for debian I prefer to collect all patches and do an upstream release
[11:31] <pochu> stani: sure, I mean in the following days or weeks :)
[11:32] <stani> pochu: but this release can never be in Hardy, right?
[11:32] <stani> pochu: I planned to do one for Debian after I can not submit anymore patches for Hardy (which is 10 april?).
[11:34] <pochu> stani: the FinalFreeze is April 10th yes, but after that we can still upload bug fixes with ~motu-release ACK
[11:34] <stani> pochu: so to answer your question, no need to apply for debian, as I will then release SPE 0.8.4.g for debian when Hardy is released. (This bug is not critical.)
[11:35] <stani> POX_: ^^^
[11:35] <pochu> stani: ok, fine
[11:36] <stani> POX_: I hope that is ok for you too.
[11:39] <POX_> did I respond to RFS mail/ping after more than 24h?
[11:39] <POX_> just release it and I will upload if everything will be ok
[11:43] <stani> POX_: From now on I will mail RFS directly to you and in cc to PAPT. So I will send you a RFS for SPE 0.8.4.g on april 24. (If more serious bugs would be discovered, it will be more quickly.) As long as the bugs are minor, you can save yourself the hassle from applying the patches.
[11:46] <POX_> if I'm not on VAC, no need to cc anyone (except pochu :)
[11:47] <stani> POX_: ok
[11:47] <sistpoty|work> hi folks
[11:48] <POX_> stani: I have speciall mailbox for RFS mails (with high priority)
[11:49] <stani> POX_: do i have to use a specific subject (eg with RFS in it)?
[11:49] <POX_> so if you use "RFS: spe 1.1.1-1" in Subject, it will end there and will be checked once I get back from work (~18:00 or 19:00 GMT+1)
[11:49] <stani> POX_: great
[11:59] <stani> pochu and POX_: python-wxtools was missing as a dependency because of xrced. I have fixed in the control file of PAPT.
[12:00] <POX_> stani: please document all changes in debian/changelog
[12:03] <stani> POX_: what do i write instead of unstable when the release is not ready yet?
[12:04] <POX_> UNRELEASED
[12:10] <stani> pochu or POX_: Do I still need to mention the LP bugs a release closes in the PAPT changelog, if the bugs have closed already with patches in Ubuntu.
[12:13] <POX_> if they're closed already, no need to close them again, IMO
[12:13] <\sh> ROTFLBTC
[12:13] <\sh> bug #213868 -> read and laugh
[12:13] <ubotu> Launchpad bug 213868 in wine "Security Warning in Wine" [Undecided,New] https://launchpad.net/bugs/213868
[12:17] <stani> pochu: can you confirm that python-wxtools is added as a dependency for spe (see PAPT control file)?
[12:19] <jpatrick> \sh: users - the only bug we will never solve indeed
[12:20] <sistpoty|work> I guess the description of the bug should really be: make wine more safe when browsing ... oh nevermind ;)
[12:20] <\sh> jpatrick, I'm wondering what I should answer..."don't browse porn" or "well, wine copies windows behaviour, it can't be better then that"? ;)
[12:21] <jpatrick> \sh: "Can you please link to desired site to enabl us to try to reproduce"
[12:22] <jpatrick> descrbied*
[12:22] <jpatrick> damn keybaord..
[12:22] <broonie> \sh: IE does actually do the sort of popup he's asking for.
[12:23] <\sh> broonie, the bug is, that he thought he has a video file, which he wanted to show, but the website publisher gave him an .exe file...so imho it's layer 8 bug
[12:23] <\sh> s/show/watch/
[12:23] <sistpoty|work> heh, layer 8... nice one :)
[12:24] <broonie> Like I say, Windows does do those warnings so if you're going to be bug for bug compatible...
[12:25] <\sh> grmpf...now I understand the bug *harhar*
[12:25] <\sh> he used firefox on linux..got an .exe instead of avi and voila...wine gets hands on
[12:26] <\sh> and this bug is known, because we have this mime time attached...and that was something I wanted to stop, but people wanted it like that...
[12:26] <\sh> linux and wine don't know anything about signed exe files...without wine reimplementing the complete security infrastructure of windows
[12:26] <\sh> and that's not the intention of wine
[12:27] <\sh> -EIMHO
[12:28] <\sh> s/mime time/mime type/
[12:30] <\sh> well, anyways there is no way to protect someone from him/herself...don't browse malicious porn sites and don't trust publishers should be always top prio on every agenda, regarding daily browser usage
[12:31] <pochu> stani: python-wxtools -> uploading
[12:31] <stani> pochu: thanks
[12:32] <\sh> it's just like: "please prevent me via evolution/kmail/claws/ from clicking unkown attachments or pls prevent me from entereing my secure login data for paypal on phishing sites"...it's impossible to bugfix the human being
[12:32] <pochu> stani: thanks for spotting it!
[12:32] <stani> pochu: this is because spe now not provides anymore packages which are available in ubuntu already. So this makes this transition complete.
=== luka74 is now known as Lure
[12:33] <broonie> \sh: I suppose it's reasonable to expect that it'd do the same thing as it would with a native executable; I don't know off-hand what Firefox does there.
[12:33] <\sh> broonie, you see that it wants to use wine for the .exe file extention..it's totally obvious...
[12:34] <ScottK> \sh: I do think it's reasonable for wine to give you some warning that you are about to transition from the Linux security model to the Windows one.
[12:35] <\sh> ScottK, which windows security model? there is no such thing in wine afaik
[12:36] <\sh> ScottK, for this, wine needs more knowledge about the ms security stuff, but that's one step beyond the firefox "run .exe with -> wine"
[12:37] <elmargol> fta, are you planing to release a new miro version for hary? (I'm looking at your bzr branch atm)
[12:37] <sistpoty|work> hm... I guess I would make the mime type to run a wine wrapper, which would show a popup first
[12:37] <\sh> sistpoty|work, how do you determine the correct signature? you need the signature database of MS Windows
[12:38] <sistpoty|work> \sh: no, it would just show a generic warning, whenever wine would be called from a mime-type
[12:39] <sistpoty|work> (ideally, only if called from a browser, but I'm not too sure if mime can do that (actually I know almost nothing about mime-types))
[12:39] <broonie> \sh: Relatively few things delivered this way are actually signed.
[12:40] <\sh> sistpoty|work, well, depends on what firefox is useing...the mime type of wine.desktop or the binfmt we provide
[12:40] <stani> pochu: would for python-wxtools not better be part of recommends (I think only a small minority uses xrced)
[12:41] <\sh> sistpoty|work, changing wine.desktop is easy to call a gtk-wrapper and after that call wine
[12:41] <\sh> sistpoty|work, but, then you have two dialogs: firefox -> run dlg via wine , wine-wrapper-dlg -> the real wine call
[12:42] <\sh> broonie, most of the serious software vendors are using installation methods with signatures from verisign which are known by windows systems...(installshield, msi etc.)
[12:43] <sistpoty|work> \sh: oh, ff displays a dialog for wine already? If so, I guess this is merely a wishlist bug, which won't get fixed soonish ;)
[12:43] <pochu> stani: if I don't have python-wxtools and try to use xrced, what will happen?
[12:43] <\sh> sistpoty|work, firefox asks you normally, when you click on something which is determined as run by wine, how you wanna run it, and if
[12:44] <sistpoty|work> ah
[12:45] <\sh> broonie, the problem with this, you can deliver to debian/ubuntu as well. Think about a malicious debian package, which is provided from untrusted source site publisher...you click on it, because _you_ trust this publisher, gedebi starts and asks you again, and you tell gedebi to install it, enter your sudo pw....and voila..your system is now known as spambot99.0
[12:46] <\sh> broonie, it's really layer 8 or if you bugged by this before, I would say, it's also layer 9 (brain bug)
[12:48] <ScottK> \sh: All I really meant is if wine comes into play on a Linux host, then the user ought to be aware of it.  I don't think it should appear silently.
[12:48] <mok0> I am looking at the FTBFS of apt-howto. There are several problems with the package, one being that the build fails on a korean and russian language components. Is it in your opinion ok to leave those out?
[12:51] <\sh> ScottK, it doesn't :) you can read the dialog box...and it asks you if you want it to run with -> <insert app here>...and yes, we should protect people from commiting suicide..
[12:52] <ScottK> \sh: OK.  Just wanted to make it clear that was needed.
[12:52] <stani> can you not configure firefox so that it does never executes exe with wine, but just downloads it?
[12:52]  * broonie nods ScottK - it's surprising that a Windows executable will run on Linux. The "Run this app" prompt isn't so useful since it comes up all the time even when it's not so useful.
[12:52] <ScottK> mok0: At this point building is better than not building.  Ideally you'd fix the problem with the languages, but in the end they may have to be sacrificed.
[12:53] <\sh> stani, you can stop firefox from using the provided mime type...
[12:53] <mok0> ScottK: I think so too, just checking, bein' new and all
[12:53] <ScottK> broonie: I agree, but something is better than nothing.
[12:53] <stani> \sh: maybe that would be good default setup for ubuntu
[12:53] <\sh> stani, but this doesn't prevent people from downloading it and starting it via console or nautilus or whatever filemanager you have
[12:53] <ScottK> mok0: Agreed.  It's better to check.
[12:54] <stani> \sh: but at least they won't think anymore it is some video
[12:54] <stani> \sh: part of the trick is that they present an executable as a video
[12:54] <stani> \sh: forbidding to download any exe would probably a step too far
[12:55] <mok0> ScottK: I'll upload the package and file a new bug against it, then
[12:55] <\sh> stani, no..then it would never been run as wine app...wine.binfmt checks for MZ header...and mime-type checks for .exe extention...so .exe was provided..and not .avi or whatever video extention
[12:55] <ScottK> Sounds quite reasonable.
[12:55] <\sh> stani, that's why ff gave the wine app as runnable helper app
[12:56] <stani> \sh: what is a MZ header?
[12:57] <\sh> stani: it's the stub header for .exe files from microsoft since DOS 1.0 i think
[12:57] <broonie> stani: Header identifying an .exe
[12:57] <stani> ok
[13:00] <stani> you can never prevent that a user clicks on a virus exe (if he gets it from www, usb-stick, ..) but you can prevent firefox to execute them directly
[13:00] <pochu> stani: did you see my question above?
[13:01] <\sh> stani, yes, don't tell firefox to drop the "run <foo> as <bar>" dialog, because "User too lazy error"
[13:01] <stani> pochu: I will look into it.
[13:02] <\sh> stani, you can never prevent a user from doing stupid things...never and wine will run what user tells it to run...even viruses..that's a non bug^Wfeature of wine...
[13:02] <\sh> s/non/known/
[13:05] <stani> \sh: I think we agree on this
[13:05] <pochu> stani: if it simply shows a dialog saying "you need foo to use this plugin" we could (and should) lower every hard dependency (kiki, winpdb...) to Recommends... if it breaks, then we need to keep it as hard dependencies
[13:06] <ScottK> pochu: But not two weeks before we release.
[13:06] <\sh> guys, when a perl package is named: "Foo::Perl" the correct debian name of that package would be "libfoo-perl-perl" right?
[13:06] <ScottK> I think so.
[13:07]  * stani is looking into the xrced issue and needs a bit more time
[13:07] <\sh> well, regarding the naming policy for perl module packages it is like that, even when it sounds stupid
[13:07] <pochu> ScottK: not changing how upstream behaves, agreed. But if upstream code already shows the dialog, it's safe to lower it to Recommends
[13:08] <pochu> although I'm ok to postpone this to Intrepid
[13:08] <ScottK> pochu: At this point we should just be fixing critical stuff.
[13:08] <pochu> ScottK: hmm, you're right :)
[13:08] <ScottK> I don't think dropping depends to recommends qualifies.
=== LucidFox_away is now known as LucidFox
[13:09] <stani> pochu: it will fail with an import exception, so leave it like it as it is
[13:09] <pochu> stani: for your next major release, making plugins optional (show a dialog if they aren't present and don't crash) would be nice
[13:10] <stani> pochu: good idea
[13:11] <stani> pochu: I feel this applies the most to python-wxtools because it installs a whole bunch of other stuff which is not relevant to spe.
[13:12] <stani> pochu: the other plugins only install themselves
[13:12] <ScottK> pochu: From reading the bug, I'm not sure I understand your objection to the alexandria upgrade?
[13:13] <slytherin> Not exactly related to Ubuntu, but can anyone please tell me how does one usually proceed for creating a package from the code in svn?
[13:13] <pochu> ScottK: it needs the diff.gz to have postinst/preinst/prerm, which are autogenerated by debhelper, and will FTBFS if they aren't present. Also I don't like the fact that the upstream installation script (whatever it's called for Ruby packages) installs the debian/ files
[13:14] <pochu> ScottK: that may be ok and it's just me not understanding it though
[13:18] <ScottK> pochu: Since they host on Launchpad their upstream build system is excessively Debian centric.
[13:19] <ScottK> pochu: I read your comment as saying you didn't like the fact that postinst/preinst/prerm were present.
[13:19] <ScottK> Thanks for clarifying.
[13:21] <mok0> ScottK: I am puzzled. apt-howto_2.0.2-2 fails to build, yet the binary packages are in the hardy archives. How can that be?
[13:22] <ScottK> Maybe the build system changed in a way that breaks it since it was built.
[13:23] <mok0> ScottK: If I upload then, it means we will loose some language components that are there now
[13:24] <ScottK> So maybe leave it be.
[13:24] <mok0> ScottK: The package is in a state of shambles. There are outstanding bugs in Debian that are up to 2 years old
[13:24] <mok0> ScottK: yeah, I think I will leave it
[13:24] <ScottK> I'd suggest then that you leave it and move on.  There are plenty of other things to work on.
[13:24] <ScottK> Yes
[13:25] <mok0> Good
[13:25] <ScottK> At this point if you have to think about what to do for more than a few minutes, move on and find something else to fix that's easier.
[13:29] <pochu> stani: re PPA, sure, what about in 1 hour or so? it will be fast
[13:29] <stani> perfect
[13:30] <stani> pochu: haha, I didn't know you were a gstreamer gure
[13:30] <stani> guru
[13:32] <pochu> stani: I'm not, I'm just a stroller :)
[13:32] <arvind_khadri> hi,i am interested to join MOTU,how do i go about it
[13:32] <pochu> stani: i wish I was ;)
[13:32] <stani> pochu: I started diving into it and wow it is so powerful. I will do great things with this.
[13:33] <stani> pochu: only documentation sucks
[13:33] <pochu> welcome arvind_khadri :) the /topic has a few useful links, specially Contributing... go and check them out, and ask if you any questions
[13:34] <pochu> arvind_khadri: this one is likely the best: https://wiki.ubuntu.com/MOTU/GettingStarted
[13:34] <arvind_khadri> pochu, how do i go there?? :) am new here
[13:34] <arvind_khadri> pochu, i meant to /topic
[13:35] <stani> arvind_khadri: /topic is displayed on top of the chat
[13:36] <arvind_khadri> pochu, hey thanks for tat
[13:36] <pochu> arvind_khadri: it depends on your IRC client, but it's likely in the top of the window as stani said
[13:36] <pochu> that's this channel's topic (subject?)
[13:37] <stani> arvind_khadri: after reading the wiki, you probably can help a lot by fixing bugs you are able to do
=== danielm_ is now known as danielm
[13:43] <ScottK> stani: Earlier you mentioned you would be willing to look at wx related bugs.  Would Bug 213589 be something you could look into.
[13:43] <ubotu> Launchpad bug 213589 in drpython "drpython crashed with SIGSEGV in wxWindow::OnInternalIdle()" [Undecided,New] https://launchpad.net/bugs/213589
[13:45] <stani> ScottK: no problem, I' ll have a look
[13:51] <mok0> Is there a script to get the newest version of some source package from Debian? It's a nuisance to have to go the packages webpage all the time
[13:53] <ScottK> Add an unstable deb-src line to your sources.list and apt-get source?
[13:54] <mok0> ScottK: I use apt-get source to fetch the newest hardy version, so wont that function be disrupted?
[13:54] <ScottK> Yes.  It would.
[13:54] <ScottK> The rc bugs page has the .dsc links if that's what you're working off of.
[13:54] <mok0> ScottK: unless you could run apt-get with an alternate database
[13:55] <ScottK> You can dget -x with that.
[13:55] <mok0> ScottK: right, good idea
[13:55] <Adri2000> mok0: apt-get source chooses the newest version. if you want a specific version use apt-get source <package>=<version>
[13:55] <mok0> Adri2000: yes, but then I
[13:55] <ScottK> I think it does, anyway.
[13:55] <mok0> I'd have to look up what version I want
[13:55] <Adri2000> apt-cache madison <package>
[13:56] <mok0> Adri2000: Ah, cool
[13:56] <stani> ScottK: There is something totally wrong with drpython. It can not open any file.
[13:57] <ScottK> stani: I guess the next step would be to look to Debian to see if they have one that works better.
[13:57] <stani> ScottK: I was checking upstream.
[13:58] <ScottK> That's broken too?
[13:58] <stani> ScottK: I know the developpers.
[13:58] <ScottK> I see.
[13:58] <ScottK> Great.
[13:58] <stani> ScottK: I will check that now.
[13:58] <ScottK> Then I guess I asked the right person to look into it.  Thanks for doing it.
[13:59] <stani> ScottK: I started some years ago pyxides, which unites all python IDE developers. So we all know each other.
[13:59] <ScottK> Cool.
[14:03] <sistpoty|work> mok0: you can use apt-get -t<distribution>
[14:04] <mok0> sistpoty|work: ... with the unstable repo defined in sources.list , I presume?
[14:04] <sistpoty|work> mok0: yes (haven't tested it yet though)
[14:07] <munckfish> Hi, I'm updating ps3-kboot package which is in main. I've read up on Sponsorship and Revu, I believe this would be a sponsored change. But ...
[14:09] <munckfish> I'm confused as to how/where I should upload the updated source - the new orig.tar.gz 100MB, is a debdiff suitable here? Should I upload by attaching to the related LP issue?
[14:10] <munckfish> This is re LP 146230
[14:10] <ubotu> Launchpad bug 146230 in ps3-kboot "update ps3-kboot to 1.4.1" [Medium,In progress] https://launchpad.net/bugs/146230
[14:12] <stani> ScottK: there is a newer Debian package, but it doesn't seem it will fix the bug as it looks like only improving packaging: http://packages.debian.org/changelogs/pool/main/d/drpython/drpython_165-6/changelog
[14:12] <Hobbsee> cody-somerville: ping?
[14:13] <cody-somerville> Hobbsee, pong
[14:13] <stani> ScottK: There was a new upstream release Drpython, in which they changed the version numbering: http://sourceforge.net/forum/forum.php?forum_id=790209
[14:13] <Hobbsee> cody-somerville: /query?
[14:13] <cody-somerville> Hobbsee, Ack.
[14:14] <stani> ScottK: I'll see if that one works.
[14:14] <ScottK2> OK.
[14:17] <stani> ScottK2: This one seems to work. Now I should see if I can reproduce the bug, as it is not straightforward.
[14:18] <ScottK2> OK.
[14:19] <stani> The problem with launchpad bugs is that upstream developers don't look there and that bugs just get dust like what happened with spe. (Unless sourceforge and launchpad are linked.)
[14:19] <ScottK2> Hobbsee: It looks like the drpython package we have is totally broken.  If stani finds the new upstream makes it work, can we upgrade (please pre-ack the FFe for me)?
[14:19] <ScottK2> stani: Yes.  People need to push the bugs upstream.
[14:19] <Hobbsee> ScottK2: fine by me.  broken == useless
[14:19] <ScottK2> Hobbsee: Thanks.
[14:20] <stani> ScottK2: I noticed that the current package in Hardy forces python-wxgtk2.6, while the new one selects 2.8
[14:21] <stani> ScottK2: Moreover the new release has two starters: a normal one and one specific for wx2.6
[14:21] <stani> I guess that debian forces 2.6 as debian does not provide 2.8
[14:21] <sistpoty|work> munckfish: I guess the easiest way is to upload to revu
[14:21] <ScottK2> stani: Makes sense.  I wonder if the current one works with 2.8
[14:21] <munckfish> sistpoty|work: ok, thx for the advice
[14:22] <stani> ScottK: Would you prefer a patch to the current one?
[14:22] <sistpoty|work> munckfish: if you've got a link for the new orig.tar.gz coming from upstream, I can put this in revu's incoming, so you'd only have to upload the diff.gz, .dsc and as last one the .changes file
[14:23] <ScottK2> stani: Yes.  If there's a short path to getting the current one working, that's preferred.
=== emgent_ is now known as emgent
[14:23] <munckfish> sistpoty|work: ok, well
[14:24] <munckfish> so I couldn't upload all myself?
[14:24] <munckfish> sorry, I'm new to all this, just finding my feet, skin o my teeth style
[14:24] <sistpoty|work> munckfish: of course you can, I just thought the 100Mb size would be a problem
[14:25] <munckfish> No, I just didn't want to bung up LP unnecessarily if that wasn't the right place to upload to
[14:25] <sistpoty|work> heh, k
[14:26] <munckfish> though, yes, I'm sure 100MB is nothing
[14:26] <sistpoty|work> apart from that it takes time to upload, size shouldn't be a problem ;)
[14:26] <munckfish> sistpoty|work: I'll take a better look at Revu then, I thought it was just for brand new packages
[14:27] <sistpoty|work> munckfish: basically it is, but since it was requested that you put the package somewhere, feel free to use revu for this (of course ppa would be another option)
[14:27] <munckfish> ah
[14:28] <munckfish> PPA, yes, although I think because it's powerpc arch I think it wouldn't work
[14:28] <munckfish> that's what I heard
[14:28] <sistpoty|work> well, it wouldn't build binary packages, but it should still list the source... not too sure though
[14:29] <sistpoty|work> (the only thing that's needed for the archive is a source package)(
[14:29] <munckfish> ok well, that's given me some options.
[14:29] <munckfish> I'll check out both and pick one tonight
[14:29] <munckfish> sistpoty|work: thx!
[14:29] <mok0> ScottK: I finally got through tex4ht, bug 131239
[14:29] <ubotu> Launchpad bug 131239 in tex4ht "sync request" [Wishlist,New] https://launchpad.net/bugs/131239
[14:30] <sistpoty|work> np
[14:30] <mok0> ScottK: it needs a good look by the m-r team
[14:31] <sistpoty|work> mok0: did you test the package? can you give a summary of how you tested in the bug? thanks!
[14:33] <mok0> sistpoty|work: I have not tested it; I need to find something to test it on.
[14:34] <sistpoty|work> mok0: then please do ;)
[14:34] <mok0> sistpoty|work: rrrright... :-)
[14:34] <ScottK2> mok0: Looks generally desirable, but we ought to have some testing.
[14:34] <sistpoty|work> heh
[14:35] <mok0> sistpoty|work, ScottK, can you guys see what the bug IS?
[14:36] <mok0> It just looks like a wish for a general update of the package
[14:36] <mok0> But I can go & check the BTS bug numbers
[14:40] <stani> ScottK: I can confirm that drpython doesn't work with 2.6, with 2.8 it opens a file but throws an IndexError and the cursor keeps in the busy state, making drpython unusable.
[14:41] <ScottK2> stani: OK.  How's the new version look?
[14:41] <stani> ScottK: This might be a packaging bug. drpython.py is moved from its folder to /usr/bin, while drpython expects it to be in /usr/share/drpython together with the other source file.
[14:42] <stani> I guess Luca never tried to open a file on debian.
[14:42] <stani> Do you want me to try to move drpython.py back to /usr/share
[14:42] <stani> well with the new version everything is in the same dir as it is a zip file
[14:43] <stani> I am afraid if it is packaged in the same way (drpython.py in /usr/bin) it will also not work.
[14:45] <ScottK2> stani: OK.  Do you think you know enough about debian packaging to fix it?
[14:46] <stani> ScottK2: I first will test if that helps, but no unfortunately I do not know enough.
[14:46] <stani> about packaging
[14:46] <ScottK2> stani: OK.  If you can test if it helps, then we can maybe get someone else to package it.
[14:49] <mok0> ScottK: tex4ht testing complete, bug 131239
[14:49] <ubotu> Launchpad bug 131239 in tex4ht "sync request" [Wishlist,New] https://launchpad.net/bugs/131239
[14:49] <RainCT> heya
[14:50] <mok0> sistpoty|work: ^
[14:50] <ScottK2> mok0: Ack'ed
[14:50]  * ScottK2 waits for qt3 to build ....
[14:51] <Iulian> Hello RainCT
[14:51] <mok0> ScottK: OK, I leave tex4ht for now then, hoping for another ack
[14:51] <sistpoty|work> mok0: does it also produce html files?
[14:51] <mok0> sistpoty|work: yes
[14:52] <sistpoty|work> mok0: great!
=== hexmode` is now known as hexmode
[15:00] <sistpoty|work> hm... there is s.th. weird... both texlive (main) and texlive-full (universe) seem to build a texlive binary
[15:01] <sistpoty|work> erm... texlive-base (main) even
[15:01] <stani> ScottK: What I suggested didn't work. The only option is to package the new version http://sourceforge.net/project/showfiles.php?group_id=83074.
[15:02] <sistpoty|work> mok0: confirmed
[15:02] <stani> ScottK: About the bug in launchpad, I think that it should be reported to the upstream developers. I am not able to reproduce it, but I wouldn't say it is fixed.
[15:03] <mok0> sistpoty|work: do you want me to upload to LP an html file ?
[15:03] <sistpoty|work> mok0: no, I pretty much believe you that it works ;)
[15:03] <mok0> ;-) heh
[15:03] <stani> ScottK: Shall I send an email to the upstream developers about this bug?
[15:03] <sistpoty|work> mok0: please go ahead with it
[15:04] <mok0> sistpoty|work: great, thanks
[15:04] <sistpoty|work> mok0: thanks for taking care ;)
[15:04] <mok0> sistpoty|work: sure thing
[15:05] <mok0> sistpoty|work: u-a-a are already subscribed, so that it, yes?
[15:05] <DktrKranz2> stani: any issues with drpython? I'm working on new upstream (to be pushed in experimental, due to wxwidgets2.8).
[15:05] <sistpoty|work> mok0: it's already in the right form for a sync? then yes, that's it
[15:06] <stani> DktrKranz2: Are you Luka?
[15:06] <DktrKranz2> stani: yes
[15:06] <mok0> sistpoty|work: I can add a link to the debian package, and recap in a last comment
[15:07] <stani> DktrKranz2: The current version in ubuntu 165-5 is not able to open files. Not at all with wx2.6, but also not with wx2.8 throws an IndexError and keeps with a busy cursor
[15:07] <sistpoty|work> mok0: I guess testing/<component> should be good enough for a source. feel free to recap, if you think it makes it more clear
[15:08] <mok0> sistpoty|work: I do, otherwise they have to scan the whole discussion
[15:08] <sistpoty|work> right :)
[15:08] <stani> DktrKranz2: I was wondering why you were moving /usr/share/drpython to /usr/bin/drpython?
[15:09] <stani> why not just a start file with "python /usr/share/drpython/drpython.py"
[15:09] <mok0> sistpoty|work: I guess they have a automation script to get it going, so there is no need to paste a link there, or what?
[15:09] <stani> or "python /usr/share/drpython/drpython_wx26.py" for debian?
[15:11] <DktrKranz2> stani: something from the past, I suppose. I don't recall move something to usr/bin
[15:11] <sistpoty|work> mok0: not too sure, but I believe so
[15:11] <mok0> another one bites the dust
[15:11] <mok0> :)
[15:12] <stani> DktrKranz2: ok, I would propose my suggestion as otherwise it makes it more easy for when 2.6 and 2.8 both available (on experimental and ubuntu)
[15:13] <DktrKranz2> stani: btw, I have new upstream almost ready, I need to check it on debian with experimental enabled and then ask my sponsor to review and upload to exp, but I think your idea is good.
[15:14] <DktrKranz2> so I'll probably have something similar in next upload
[15:14] <stani> DktrKranz2: I am testing if I manage the latest drpython to work with 2.6
[15:15] <DktrKranz2> stani: I haven't checked deeply, but I guess you can lower required version, since there weren't intrusive changes, IIRC
[15:16] <DktrKranz2> if so, I can patch it and go to unstable, but that requires more testing
[15:16] <pochu> lool: wesnoth 1.4.1 is out, and Rhonda (the Debian maintainer) is working on the update, which will bring some improvements on wesnoth-tools too (a new binary added at the same time as wesnoth-smallgui). I'll for it and then request a sync.
[15:16] <stani> DktrKranz2: No, I just checked. It doesn't work. Probably it would be possible, this would mean refactoring the code.
[15:16] <DktrKranz2> ah, what a pity :(
[15:16] <ScottK2> DktrKranz2: Since stani isn't a motu, would you please help him get a fix uploaded to Ubuntu without a new upstream (if feasible)?
[15:17] <stani> ScottK2: It is not possible
[15:17] <ScottK2> Ah
[15:17] <stani> ScottK2: I tried several things, and it didn't work
[15:18]  * mok0 wishes there was a 1-a-day group he could joint...
[15:18] <mok0> s/t//
[15:18] <stani> ScottK2: New upstream release is necessary. New upstream release is of 28/2/2008 and previous one is from 07/04/2007
[15:18] <DktrKranz2> I guess having new upstream (if working properly) won't be too difficult
[15:18] <ScottK2> OK
[15:18] <stani> ScottK2: so a lot of bugs will be fixed
[15:19] <stani> I hope. I know that the main developer quit the project and that someone else is working on it, but mostly fixing bugs.
[15:20] <DktrKranz2> Yes, it's hard to push back patches :(
[15:20] <DktrKranz2> new drpython has eight or nine, almost all suitable for upstream inclusion
[15:20] <stani> DktrKranz2: Please test if you can open a file and maybe you can reproduce the bug #213589
[15:20] <ubotu> Launchpad bug 213589 in drpython "drpython crashed with SIGSEGV in wxWindow::OnInternalIdle()" [Undecided,New] https://launchpad.net/bugs/213589
[15:21] <DktrKranz2> stani: I'm at work on Windows ATM, I'll check tomorrow evening since I won't be at home tonight
[15:22] <stani> ScottK: Is there any other python-wxgtk bug?
[15:22] <ScottK2> Not that I've noticed recently.
[15:24] <DktrKranz2> stani: have you the chance to test it on debian too?
[15:27] <stani> DktrKranz2: No, sorry, I don't have a debian machine (yet?)
[15:27] <DktrKranz2> no problem, I have one at home, it just needs to be updated a bit
[15:28] <DktrKranz2> (and I really have to push my packages on PAPT!)
[15:28] <ScottK2> DktrKranz2: Yes.  Please do.
[15:29] <stani> ScottK: Would it be ok to leave a comment on the launchpad bug to report it on http://sourceforge.net/tracker/?group_id=83074&atid=568238
[15:29] <ScottK2> DktrKranz2: I'd prefer if you'd upload the new upstream straight to Ubuntu.
[15:29] <ScottK2> stani: Yes
[15:30] <stani> ScottK2: Unless POX is the uploader ;-)
[15:30] <ScottK2> DktrKranz2: Hobbsee already gave an IRC ack.  I'll give you one too.  Just please respond in the bug explaining why it's a new upstream and test it first.
[15:30] <ScottK2> stani: At this point I'm worried if sync's will get processed.
[15:30] <ScottK2> There's no guarantee.
[15:31] <sebner> RainCT: mok0: who is faster ^^
[15:31] <mok0> When fixing bugs, is it ok to let the patch go in diff.gz, or should I do it properly via debian/patches, quilt etc.
[15:31] <mok0> sebner: ?
[15:31] <sebner> mok0: festival
[15:31]  * mok0 looks
[15:31] <sebner> mok0: install all build-deps of festival ;) then it's working ^^
[15:32] <ScottK> mok0: Ideally you'd do it properly.  At this point if the package doesn't already have a patch system, you shouldn't feel obligated to add it for minor patches.
[15:32] <DktrKranz2> ScottK: ok then. I'll do some tests on Hardy and eventually update bug report accordingly. Once ready, I'll inform you before uploading it.
[15:32] <mok0> ScottK: it's a patch attached to a bug
[15:33] <mok0> sebner: I tried building it in sbuild
[15:34] <ScottK> mok0: OK.  Use your best judgement about adding a patch system.  We aren't as pedantic about it as Debian.  It's particularly OK not to add the patch system if you know we'll drop the change in the next release.
=== kitterma is now known as ScottK2
[15:34] <DktrKranz2> stani: if you want, I can upload it to PPA soon, just to have a wider testing.
[15:34] <mok0> ScottK: yeah that's my thought too
[15:34] <sebner> mok0: ? I got the same error while doing debuild ... Then I did a sudo apt-get build-dep festival and it was working + pbuilder build
[15:34] <sebner> mok0: but it doesn't matter. RainCT is originally on it
[15:34] <stani> DktrKranz2: That would be good. Did you notice this: http://sourceforge.net/tracker/index.php?func=detail&aid=1903248&group_id=83074&atid=568238?
[15:34] <ubotu> Sourceforge bug 1903248 "Possible Bug in 3.11.0" [Pri: 5,Open]
[15:34] <mok0> sebner: of course it works when it's already installed
[15:35] <mok0> sebner: because the build requires it :-)
[15:35] <mok0> sebner: so, you could make it build-depends on itself, but that seems pretty dirty to me
[15:36] <sebner> ^^
[15:36] <DktrKranz2> stani: I'll have a look. thanks.
[15:36] <sebner> mok0: RainCT already looked at it. Maybe we should wait on his opinion
[15:37] <mok0> sebner: I'll put my thought in another comment
[15:37] <sebner> mok0: k :)
[15:39]  * DktrKranz2 leaves
[15:39] <sebner> DktrKranz2: hf
[15:39] <mok0> sebner: there. :-)
[15:39] <ScottK> mok0: Did you ever reach any conclusion about atlas support for python-scipy (or was it numpy)?
[15:39] <mok0> ScottK: no, I forgot about that one
[15:39] <mok0> it was scipy AIR
[15:40] <ScottK> Someone might want to look into seeing if we need to fix Debian Bug #475017
[15:40] <ubotu> Debian bug 475017 in python-numpy "python-numpy: missing parentheses in /usr/share/pyshared/numpy/f2py/rules.py line 1222 (fixed upstream)" [Normal,Open] http://bugs.debian.org/475017
[15:40] <ScottK> That looks like an easy one to fix.
[15:40] <sebner> mok0: :) but I don't want to stop you working on my other bugs ^^
[15:40] <mok0> sebner: hit me
[15:41] <RainCT> sebner: still want me to sponsor festival or has mok0 already uploaded it?
[15:41] <mok0> RainCT: festival has problems
[15:41] <stani> DktrKranz2: You need to fix this, you have to replace c:/dpython.out to ~/.drpython/drpython.out
[15:41] <sebner> RainCT: see his comments ;)
[15:41] <sebner> RainCT: heya btw :)
[15:42] <RainCT> mok0: which?
[15:42] <ScottK> mok0: Did you really need a sync from Testing for Bug 131239 or can it be from Unstable?
[15:42] <ubotu> Launchpad bug 131239 in tex4ht "sync request" [Wishlist,Confirmed] https://launchpad.net/bugs/131239
[15:43] <mok0> ScottK: testing, unstable has unsatisfied build-depends
[15:43] <ScottK> OK.  Thanks.
[15:43] <sebner> ScottK: the fix in only to change one line in rules.py? for python-numpy?
[15:43] <sebner> *is
[15:43] <ScottK> sebner: From reading the bug it looked like a one line fix.  I haven't looked at the code.
[15:44] <mok0> sebner, looks like it, there's even a patch
[15:44] <sebner> ScottK: I'll take a look at it. But should't be necessary to create/use patch for it? (patch-system)
[15:45] <ScottK> No
[15:45] <mok0> sebner: we just discussed it before. With such a minor change it is ok to leave it in diff.gz
[15:45] <sebner> mok0: ah
[15:45] <mok0> sebner: you may leave a comment in changelog to that effect
[15:45] <sebner> mok0: yeah. clear ^^
[15:46] <mok0> ok sebner, hit me with a bug #
[15:46] <sebner> mok0: for python-numpy?
[15:47] <mok0> sebner: one of the ones you've tiraged, preferrably a sync :-)
[15:47] <mok0> I need one more bug for my quota
[15:47] <sebner> mok0: https://bugs.edge.launchpad.net/~sebner  . 8 to do :P
[15:48] <mok0> Ah, I get to choose! What luxury
[15:48] <sebner> mok0: you can't choose if you review all of them ^^
[15:48] <mok0> sebner: whoa there, I have a life
[15:49] <sebner> hrhr
[15:49] <ScottK> jdong and/or \sh: wine backport FTBFS on Gutsy.  I'd appreciate it if one of you could have a look.
[15:49] <\sh> ScottK, buildlog? :)
[15:49] <ScottK> http://launchpadlibrarian.net/13223894/buildlog_ubuntu-gutsy-amd64.wine_0.9.58-0ubuntu3%7Egutsy1_FAILEDTOBUILD.txt.gz
[15:50] <ScottK> https://launchpad.net/ubuntu/+source/wine/0.9.58-0ubuntu3~gutsy1
[15:50] <\sh> yepp
[15:50] <\sh> gutsy still have libungif right?
[15:50] <mok0> sebner: /me is going to stay off mailscanner :-)
[15:50] <sebner> mok0: well that's a FFe ;) and ScottK dislikes it ^^
[15:51] <mok0> sebner: so I see
[15:51] <mok0> sebner: I think he's right.
[15:51] <ScottK> Broken by design with Postfix and their dev's call it political.
[15:51] <ScottK> Using published interfaces is a very basic concept and they don't get it.
[15:51] <sebner> mok0: btw, if you keep reviewing my stuff you could be say something about me as a sponsor in future :)
[15:51] <mok0> ScottK: should it be removed ?
[15:51] <\sh> grmpf..packages.ubuntu.com is down :(
[15:52] <ScottK> mok0: No.  It works well with other MTAs that provide an interface that's appropriate.
[15:52] <ScottK> mok0: lamont and I have discussed making it conflict with postfix, but he wanted to discuss that with the mailscanner maintainer in Debian first.
[15:53] <mok0> ScottK: I was just thinking that, but wouldn't it be an abuse of that tag?
[15:53] <RainCT> mok0: http://packages.debian.org/search?searchon=contents&keywords=install.mak&mode=path&suite=stable&arch=any
[15:53] <ScottK> Probably.
[15:54] <RainCT> mok0: it doesn't build-depend on itself, but on libestools1.2-dev
[15:54] <mok0> RainCT: ah I stand corrected
[15:54] <sebner> RainCT: I already told him to install de build-deps ^^ maybe he missunderstood ^^
[15:54] <sebner> *the
[15:55] <mok0> RainCT: but the build-deps should be installed automatically by sbuild
[15:55] <mok0> sebner: ^
[15:55] <\sh> ScottK, https://edge.launchpad.net/ubuntu/gutsy/amd64/libgif-dev/4.1.4-2 <- but it's not in the archive -> http://archive.ubuntu.com/ubuntu/pool/main/g/giflib/+
[15:56] <ScottK2> Hmmm
[15:56] <\sh> damn
[15:56] <\sh> two versions
[15:56] <\sh> one in main
[15:56] <\sh> one in universe for gutsy
[15:56] <mok0> RainCT: will you fix festival then?
[15:56] <\sh> and I think that fails now
[15:56] <\sh> http://archive.ubuntu.com/ubuntu/pool/universe/g/giflib/
[15:56] <ScottK2> That's not good.
[15:57] <\sh> that -EDAMNCRAP
[15:57] <ScottK2> How to fix?
[15:57] <\sh> it should find the build-dep
[15:57] <ScottK2> We can get a give-back via DRU.
[15:57] <ScottK2> DRU/SRU
[15:57] <Hobbsee> dru?
[15:57] <Hobbsee> ah
[15:57] <\sh> because the package is already there
[15:57] <ScottK2> Can't type
[15:57] <RainCT> mok0: I'm trying if it works with pbuilder..
[15:57] <ScottK2> Ah.
[15:57] <Hobbsee> do you need a sru for a giveback?
[15:57] <mok0> RainCT: cool
[15:57] <\sh> ScottK, is it building in your pbuilder ?
[15:58] <ScottK2> I did, after release.
[15:58] <ScottK2> \sh: I didn't check it, jdong did.
[15:58] <Hobbsee> bah.
[15:58] <sebner> RainCT: mok0: I'm always test building and it worked :)
[15:58] <\sh> jdong, did it build in your pbuilder?
[15:58] <\sh> or sbuild?
[15:58] <mbt> Does anyone know if it is possible to get gdb to log each line of code as it executes when controlling a program?  I am trying to debug an interaction between two patches in a package and I am coming up needing more help from the debugger in doing so.
[15:58] <mok0> sebner: but did you use a pbuilder?
[15:58] <sebner> mok0: yep
[15:59] <mok0> sebner: weird
[15:59] <sebner> mok0: dunno. But you can be sure that I'm test-building *everything*. Also the syncs that you are ACKing ;)
[16:00] <mok0> sebner: you said something about having to install festival first
[16:00] <sebner> mok0: the build-deps of festival
[16:00] <sebner> mok0: for debuild
[16:01] <mok0> sebner: and why should I do that? sbuild handles it
[16:01] <sistpoty|work> mbt: not too sure, but you could set breakpoints and single-step then
[16:01] <sebner> sistpoty|work: heya :D
[16:01] <sistpoty|work> hi sebner
[16:01] <sebner> mok0: good question ^^
[16:01] <\sh> ScottK, it FTBFS because of the very same issue on my sbuild
[16:01] <mok0> sebner: there must be a missing build-dep
[16:01] <mbt> yeah, i basically need to get an overview of what's going on.  I am working with some breakpoints, but it seems that doing that changes the behavior of the app too lol
[16:01] <ScottK2> \sh: I'm trying it now on my i386.
[16:01] <\sh> ScottK, sbuild says it doesn't work...pls try a pbuilder ;)
[16:02] <sebner> mok0: we'll se
[16:02] <sebner> e
[16:02] <mok0> sebner: yup
[16:02] <ScottK2> \sh: I'm using pbuilder
[16:02] <\sh> ScottK, good :)
[16:04] <\sh> ScottK, and afaics it should work...if not we have a serious problem with our archives
[16:05] <\sh> ScottK, regarding https://edge.launchpad.net/ubuntu/+source/giflib/ it should just work
[16:05] <ScottK2> On i386 in pbuilder it found all the deps and is building
[16:05] <mok0> sebner: /me grabs mindi
[16:05] <\sh> ScottK, it found libungif I think
[16:05] <\sh> not libgif
[16:06]  * ScottK2 looks
[16:06] <\sh> when pbuilder didn't fix the build-dep "or" reading from left to right...pbuilder was known to read from right to left
[16:06] <sebner> mok0: :). it's just funny that cesare always adds comments but is not doing the review  ^^
[16:07] <ScottK2> That part had already scrolled out of the backscroll, so I'll do it again.
[16:07] <mok0> sebner: he's the big man
[16:07] <mok0> :)
[16:07] <\sh> ScottK, create a log file .)
[16:07] <sebner> hrhr
[16:08] <ScottK2> that would have been the smart thing to do.
[16:09] <\sh> ScottK, sbuild does it automatically send it to my inbox ;)
[16:09] <ScottK2> \sh: libgif-dev libgif4
[16:10] <\sh> ScottK, check your apt cache dir for the package and move it out of the way...
[16:11] <\sh> ScottK, my sbuild uses for gutsy clean archive.ubuntu.com Packages files...so it gets it directly from the server and if sbuild doesn't work...we are in trouble
[16:13] <ScottK2> Yeah.
[16:13] <ScottK2> Trying again
[16:14] <bdmurray> Is there were I would poke somebody for sponsorship of a package update?
[16:14] <\sh> ok.../me comes back a bit later...meeting
[16:15] <sistpoty|work> bdmurray: either ask here, or subscribe ubuntu-universe-sponsors for universe/multiverse to a bug (or do both ;))
[16:15] <ScottK2> \sh: Yep.  It's different libungif4-dev libungif4g
[16:15] <sistpoty|work> (bug with a debdiff)
[16:15] <ScottK2> \sh: But it's still building
[16:15] <bdmurray> I've subscribed the sponsors to bug 204457 and it has a debdiff.
[16:16] <ubotu> Launchpad bug 204457 in bughelper "no longer respects dontlist in info files" [Undecided,Fix released] https://launchpad.net/bugs/204457
[16:16] <bdmurray> Its the Bug Helper project that has the fix not Hardy yet.
[16:16] <RainCT> mok0, sebner: builds fine with pbuilder
[16:16] <mok0> RainCT: did you make any changes to it?
[16:17] <RainCT> mok0: no
[16:17] <mok0> weird
[16:18] <RainCT> mok0: which is indeed weird is that you need to have package libestools1.2-dev installed in order to be able to debuild the package (to get the new .dsc/.diff.gz)
[16:19] <RainCT> mok0: but if also seen this with some other packages before so I'm not sure if that's OK or not..
[16:19] <ScottK2> It's evil, but sometimes done to build-dep on yourself.
[16:19] <mok0> RainCT: it is evil
[16:19] <ScottK2> screenlets is another example.
[16:20] <sistpoty|work> RainCT: as long as it is in the build-deps, it's ok
[16:20] <RainCT> btw, is there some page that explains what exactly "debuild -S" does?
[16:21] <ScottK2> RainCT: It's dpkg-buildpackage -S + lintian + debsign
[16:21] <ScottK2> Technically it's not actually +debsign because it's got it's own, different, implementation IIRC, but that's the effect.
[16:24] <RainCT> new question, what does "dpkg-buildpackage -S" do? (internally, not what it is for) :P
[16:25] <ScottK> Makes the source package (creates .diff.gz, .dsc, .changes, etc.).  I think there's a man page with details.
[16:26] <sistpoty|work> basically it's a wrapper around dpkg-source
[16:27] <sistpoty|work> running debian/rules clean beforehand
[16:27] <sistpoty|work> and setting a few options
[16:29] <RainCT> ScottK, sistpoty|work: Thanks :). I was just wondering if it does something strange beside "debian/rules clean" and comparing the files to the orig.tar.gz
[16:29] <sistpoty|work> RainCT: none that I know of, but I'm not too good at reading perl :P
[16:35] <sistpoty|work> zul: did you test the new iscsitarget yet?
[16:36] <zul> sistpoty|work: no I dont have the hardware
[16:36] <sistpoty|work> hm... meh
[16:36] <ScottK> zul: You going to make soren test it then?
[16:36] <ScottK> I thought he was Mr. Iscsi.
[16:37] <zul> ScottK: if he had the hardware handy where he was at the momment then sure
[16:37] <\sh> ScottK, yes...the wonder of pbuilder and reading build-deps the other way around ;)
[16:37] <zul> ScottK: there shouldnt be any regressions it mostly so users can use it on hardy
[16:37] <_ruben> if only i had my iscsi up and runnning yet, would've loved to lend a helping hand
[16:37] <\sh> ScottK, actually we have a problem with sbuild and/or our archives for gutsy...I had this issue with a package in dapper
[16:37] <RainCT> Err http://ftp.uni-muenster.de hardy/universe totem-xine 2.22.0-0ubuntu3 403 Forbidden
[16:38] <zul> ScottK: besides we use open-iscsi rather then iscsitarget
[16:38] <RainCT> is this "normal" or is it some problem with the mirror?
[16:38] <_ruben> zul: erm .. one's an initiator and the other a target
[16:38] <\sh> RainCT, do you get the package from archive.ubuntu.com?
[16:38] <RainCT> \sh: haven't tried, I'm using http://ftp.uni-muenster.de as mirror
[16:39] <ScottK> zul: OK.  Please find a guinea pig to test it.
[16:39] <_ruben> btw .. iscsitarget doesnt require any special hardware
[16:39] <\sh> RainCT, try the archive.ubuntu.com...it could be a simple out of sync right now
[16:39] <RainCT> \sh: I can just get it from the website (http://archive.ubuntu.com/...), or?
[16:40] <_ruben> iscsitarget is what makes your hardware special so to speak
[16:40] <\sh> RainCT, yepp
[16:42] <RainCT> \sh: that works, thanks
=== tonyyarusso is now known as anthony
[16:43] <RainCT> sebner, mok0: festival uploaded, let's see if it works :)
=== luisbg_ is now known as luisbg
[16:44] <\sh> RainCT, kick muenster mirror ftp admin ;)
[16:44] <sebner> RainCT: hrhr. I hope. well I haven't had any problems with it. thx btw :)
=== anthony is now known as tonyyarusso
[16:44] <\sh> RainCT, and why the hell are you using a ost-westfalen-lippe server? ,-)
[16:45] <RainCT> \sh: lol. dunno, I used that "autodetect the fastest server" thing
[16:45] <\sh> RainCT, hmm? where are you now?
[16:46] <RainCT> \sh: that's in System -> Administration -> Software Sources
[16:47] <RainCT> iirc
[16:48] <RainCT> \sh: yes, "download from: [another...]",  "choose the best server"
[16:48] <mok0> hmm I just uploaded htmlgen wtf happened to it?
[16:49] <mok0> Ah, it's in main :-(
[16:50] <afflux> morning
[16:50] <sebner> afflux: morning? damn you! :D :D :D :P
[16:51] <afflux> yeah, right. My day started ~11h ago ;)
[16:51] <sebner> afflux: hrhr
[16:51] <sebner> mok0: any complains? I don't want to stop RainCT uploading festival
[16:51] <mok0> sebner: no no
[16:52] <sebner> mok0: good boy :P
[16:52] <sebner> RainCT: go go go :)
[16:52] <mok0> sebner: I was happy to get that stupid package off my hands ;-P
[16:53] <sebner> mok0: hrhr. maybe you should remaing with syncs? ^^
[16:56] <mok0> sebner: don't push your luck
[16:57] <mok0> :-P
[16:57] <\sh> ScottK, see #ubuntu-devel :)
[16:57] <sebner> mok0: ^^. would maybe be good if you also look at my merges to be a *real* sponsor though
[16:58] <mok0> sebner: Good idea
[16:58] <mok0> For some reason, I end up doing merges for main
[16:59] <mok0> sebner: which is less fun
[16:59] <sebner> mok0: why?
[16:59] <mok0> sebner: because I don't get to upload :-P
[17:00] <sebner> mok0: lol. ^^ IIRC I never did a main merge yet. hmm
[17:00] <\sh> RainCT, no I meant where are you living now? if it's not germany, it's strange ;)
=== thekorn_ is now known as thekorn
[17:00] <sebner> \sh: Catalonia alias Spain xD
[17:01] <\sh> sebner, so it's very strange...;)
[17:02] <sebner> \sh: btw, any progress on wine 0.59? Yesterday I talked to Scott. Means to have regressions and other crap
[17:03] <\sh> sebner, yepp...I discussed this with scott...there are some things which are not ok...e.g. systray
[17:03] <\sh> sebner, we have to check if it's possible to repair this again for 0.9.59..
[17:03] <sebner> \sh: ah yep. What do you thing. hardcore fixing or 0.58?
[17:04] <\sh> sebner, wine is not as easy as it seems...it's scott decision now, but my feeling says: if we can't fix those nasty buggers which worked before, stay with 0.9.58
[17:04] <\sh> and provide 0.9.59 via backports (or any later version)
[17:05] <sebner> \sh: seems to be the best then
[17:05] <\sh> but that's only my feeling because I had the very same decision in the past with amarok....and amarok was main ;)
[17:05] <sebner> \sh: amarok rocks ^^
[17:06] <\sh> not if you had a new upstream version 2 days before final ubuntu release ;)
[17:06] <sebner> \sh: btw. a stupid question. yes we have scott. but why we never took the packages from debian?
[17:06] <sebner> \sh: lol. it's clear that that couldn't work ^^
[17:07] <\sh> sebner, nope..during breezy Mark wanted to get scotts packages...and he wanted scott to be the one...so I was the one who catched scott packages and prepared them for breezy
[17:08] <sebner> \sh: any reason for that decision?
[17:08] <megabyte405> hey, is anyone here following the abiword 2.6 progress?  I'm Ryan Pavlik, the packager
[17:10] <emgent> heya
[17:10] <sebner> megabyte405: slangasek I think
[17:11] <\sh> sebner, dunno...debians packages are very complicated regarding the packages they provide...scotts packages were easy and well known in the wine debian community (as third party)...and actually da sabdfl wanted them, he got them :) and I'm happy with this decision
[17:11] <sebner> \sh: yes sure. just wanted to know :)
[17:11] <megabyte405> ok - well, just wondering, in the 2.6 series libwv (our library for reading word files) stopped being included in the main source tarball (the old source tarball being a big ol' conglomeration of things).  Unfortunately, Ubuntu has libwv-1.2 (the version we need) in Universe, which won't do.
[17:12] <megabyte405> We're getting an MIR ready, considering that before the code was basically just pasted into the AbiWord package and so reasonably a better solution should enjoy the same main-ness as the old solution, but I'm wondering if there's anyone familiar enough with things that we can save some time here
[17:13] <\sh> megabyte405, duplicated sources we try to avoid...imho that's why it got removed from the upstream tar ball..and having abiword in main, we can't build against universe packages...
[17:13] <\sh> megabyte405, most probably our core dev decided, that libwv is not a source which can be maintained for over 3 years...
[17:13] <megabyte405> \sh: I'm with upstream, and so I do know that that was one of the reasons we took it out of that tarball
[17:14] <pmjdebruijn> lo
[17:14] <megabyte405> \sh: I'm going to imagine that since in the previous release it wasn't used (older versions being used/included) it wasn't needed by a main package, but as it's an integral part of abiword, it's being very carefully maintained
[17:14] <pmjdebruijn> I'm trying to package an alternate version of troff (heirloom troff)
[17:14] <mok0> ScottK: you may want to take a look at bug 156158 for scribus, which you've uploaded earlier, it has a debdiff attached
[17:14] <ubotu> Launchpad bug 156158 in scribus "In Gutsy Gibbon, Url in Scribus does not launch Firefox" [Undecided,Confirmed] https://launchpad.net/bugs/156158
[17:14] <pmjdebruijn> however, /usr/bin/troff is already owned by groff-base
[17:15] <pmjdebruijn> should I use debian alternatives? if so, shouldn't groff-base support it as well?
[17:15] <megabyte405> DomL, the maintainer, is also the abiword maintainer, and he keeps everything running smoothly with wv
[17:15] <pmjdebruijn> or should I install heirloom troff as htroff?
[17:16] <\sh> megabyte405, well, main is being supported by canonical, so for every package in main, it needs a main inclusion report, and a decision made by <please ask in #ubuntu-devel who that is> who knows if libwv is good for main (means support for at least 3 years, regarding the version in hardy)
[17:17] <megabyte405> \sh: yep, am aware of those things, just was curious if someone oculd offer a quick opinion
[17:17] <megabyte405> will keep on going withthe MIR info and ask in #ubuntu-devel too
[17:17] <\sh> megabyte405, so best is, please address it on #ubuntu-devel :) and my opinion: we have openoffice which works very well with word files ;)
[17:18] <megabyte405> that's not a solution for me, however ;) - will ask on  -devel
[17:19] <soren> zul: iscsitarget is the iscsi server. You can just test it with open-iscsi as the initiator.
[17:20] <_ruben> thats more or less what i tried to say earlier :)
[17:21]  * sistpoty|work heads home... cya
[17:22] <megabyte405> perhaps a more -motu question: why is my ppa building against a newer version of cairo than I have in my installation of Hardy?
[17:22]  * \sh heads home too...
[17:22] <megabyte405> (as evinced by the fact I can't install the package i just built)
[17:22] <\sh> megabyte405, url?
[17:22] <\sh> your lp ppa page ;)
[17:22] <RainCT> \sh: Ah. Near Barcelona :P
[17:22] <megabyte405> https://launchpad.net/~abiryan/+archive/
[17:23] <\sh> RainCT, I said before...strange ;)
[17:23] <RainCT> ah sebner already answered
[17:23] <mok0> byebyebye for now
[17:23] <RainCT> \sh: and it isn't that strange.. Spanish mirrors suck :P
[17:23] <zul> soren: ok gotcha
[17:24] <\sh> megabyte405, which version of cairo?
[17:24] <jdong> \sh: it built in my pbuilder
[17:24]  * jdong looks
[17:24] <\sh> jdong, yeah...it's a problem reading the build deps in pbuilder, still...we need to get rid of libgif-dev build-dep for gutsy
[17:25] <james_w> megabyte405: cairo was uploaded about an hour ago, maybe it hasn't hit your mirror
[17:25] <james_w> megabyte405: have you apt-get updated?
[17:25] <megabyte405> ah, right - see discussion aobut spanish mirrors sucking
[17:25] <\sh> jdong, afaiks fontforge clashed with libgif (because of some strange deps) and that's why it FTBFS on sbuild
[17:26] <\sh> RainCT, well, ping <your spanish mirror> and ping <mirror of uni-muenster> ;)
[17:26] <jdong> \sh: ah, that's plausible
[17:26] <\sh> jdong, so changing for gutsy the libgif-dev | libungif-dev to libungif-dev | libgif-dev (or removing the libgif-dev b-d completly) solves the problem
[17:27] <\sh> jdong, which means, ScottK needs to do a small source change upload to backports for wine ;)
[17:27] <jdong> \sh: heh, sounds silly, but I guess reasonable. ScottK time :)
[17:28] <\sh> jdong, actually it is...and it's because sbuild is resolving the build-deps and deps of the included other build-dep (primary and secondary ones) totally different then pbuilder
[17:29] <\sh> jdong, the best thing to do: fixing pbuilder to the same dep resolving mechanism as sbuild, so everybody can see the same results as on our buildds
[17:29] <jdong> \sh: agreed
[17:29] <jdong> \sh: the aptitude pbuilder satisfier is nice for speed but that's all useless if it doesn't simulate our build env properly
[17:30] <\sh> jdong, fun part, even the apt-get satisfier works the same ;)
[17:30] <\sh> jdong, I sweared pbuilder many times because of that
[17:30] <RainCT> \sh: atm es.archive.ubuntu.com doesn't even answer.. 25 packets transmitted, 0 received, 100% packet loss, time 24039ms lol
[17:30] <\sh> RainCT, wow
[17:31] <RainCT> (you've to consider my crappy connection too, but the other one works)
[17:31] <RainCT> 12 packets transmitted, 12 received, 0% packet loss, time 33823ms
[17:31] <\sh> RainCT, and archive.ubuntu.com directly ?
[17:32] <RainCT> well this isn't really the best connection to test from.. each time I try I get a different time from ftp.uni-muenster.de
[17:33] <RainCT> 9 packets transmitted, 9 received, 0% packet loss, time 20827ms   for archive.ubuntu.com
[17:34] <RainCT> \sh: well, anyway, it's not only me who recommends German/French mirrors
[17:34] <RainCT> \sh: if you ask in cat.ubuntuforums.org or some other LoCo place they'll probably tell you the same
[17:35] <\sh> RainCT, hmm...well, yes, germany has some very good mirror servers...
[17:35] <\sh> with a lot of bandwidth sponsored by hard working tax payers like me ;)
[17:36] <\sh> so....now /me needs to head home ;)
[17:36] <\sh> cu later
[17:36] <RainCT> \sh: heh :)
[17:36] <RainCT> see you
[17:45] <ScottK> \sh or jdong: debdiff me and I'll upload it.
[17:48] <zul> soren: easier I uploaded to my ppa and getting the guy who opened the bug to test
[17:57] <norsetto> if I see another bug report on launchpad-integration I will start crying
=== macd_ is now known as macd
[18:21] <stani> pochu: are you there?
[18:21] <pochu> stani: short of
[18:22] <stani> I just did dput
[18:22] <stani> it said "Not running dinstall."
[18:22] <stani> is that ok?
[18:22] <pochu> I think so
[18:23] <stani> Also: Package includes an .orig.tar.gz file although the debian revision suggests
[18:23] <stani> that it might not be required. Multiple uploads of the .orig.tar.gz may be
[18:23] <stani> rejected by the upload queue management software.
[18:23] <pochu> that's ok
[18:23] <stani> can I track somewhere progress?
[18:23] <pochu> that's because for Debian, you must not upload the .orig.tar.gz if it's already in the archive (e.g. if it's -2 instead -1)
[18:23] <pochu> stani: it should already be in your PPA
[18:24] <pochu> hmm, it's not there yet
[18:24] <stani> but I did dput source.changes and it uploaded orig.tar.gz by itself
[18:24] <pochu> stani: what command did you run?
[18:24] <stani> dput /home/stani/sync/python/phatch/packaging/debian/phatch_0.1.3-0ubuntu1~ppa1_source.changes
[18:24] <pochu> btw, we are off-topic here, let's move to a query
[18:24] <stani> ok
[18:27] <pochu> stani: have you seen my messages?
[18:27] <zul> ScottK: tested and it works fine
[18:27] <stani> pochu: which messages? about ppa?
[18:28] <pochu> stani: yes
[18:28] <pochu> stani: in a privmsg
[18:28] <stani> pochu: me too
[18:28] <pochu> stani: are you identified on freenode?
[18:28] <pochu> err you aren't
[18:28] <stani> what does that mean?
[18:29] <pochu> stani: I haven't seen any message from you then :)
[18:29] <pochu> stani: /msg NickServ help identify
[18:29] <stani> just did that and now?
[18:29] <pochu> stani: it means you aren't "logged in" and thus you can't send privmsgs
[18:29] <pochu> stani: it should explain you how to identify
[18:30] <norsetto> zul: bug 208281 you mean?
[18:30] <ubotu> Launchpad bug 208281 in iscsitarget "iscsitarget will not compile" [Undecided,Incomplete] https://launchpad.net/bugs/208281
[18:30] <pochu> stani: join #heya
[18:30] <stani> wait, I log out and log in again
[18:31] <zul> no0tic:
[18:31] <zul> norsetto: yep
[18:32] <emgent> hello people
[18:32] <stani> pochu: I am back.
[18:32] <norsetto> zul: isn't that a sync btw?
[18:32] <norsetto> hi emgent
[18:32] <zul> no its a merge
[18:32] <emgent> someone can help me to write python-launchpad-bugs cookies support in anteater tool ?
[18:35] <emgent> uhm..
[18:38] <RainCT> emgent: what do you mean?
[18:40] <norsetto> zul: and why would that be a merge?
[18:41] <emgent> RainCT: i saw last jdstrand commit for solve firefox3 cookies problem
[18:41] <zul> because it came from merges.ubuntu.com
[18:41] <emgent> but i dont found docs for write support
[18:41] <emgent> i need little help :)
[18:42] <norsetto> zul: then Mom is wrong ....
[18:43] <emgent> RainCT: i'd like complete it first of UDS
[18:43] <norsetto> zul: looks like all our changes are now in debian, as a matter of fact your debdiff only contains the maintainer change
[18:43] <emgent> http://bazaar.launchpad.net/~ubuntu-whitehat/ubuntu-whitehat-project/uwht.dev/annotate/emgent%40emanuele-gentili.com-20080407235635-9c0rlcwmk0eu90ia?file_id=anteater.py-20080328174815-qukxnpiclv9834qw-3
[18:43] <zul> norsetto: fine..
[18:44] <sebner> zul: yeah. sync sync sync :D
[18:45] <slangasek> nxvl: ping? (re: bug #159371)
[18:46] <ubotu> Launchpad bug 159371 in sysvinit "Default MOTD for server should point to documentation URL" [Medium,Confirmed] https://launchpad.net/bugs/159371
[18:53] <RainCT> emgent: if you have  Obj = Connector.ConnectBugList()  or  Obj = Connector.ConnectBug()  you can then do  Bug.authentication = launchpad_auth_cookie  where launchpad_auth_cookie is the path to the cookie file. Is this what you mean?
[18:54] <emgent> thekorn reply to me in query :)
[18:55] <emgent> thanks Rin :)
[18:55] <nxvl> slangasek: pong
[18:57] <slangasek> nxvl: hi, seen my latest follow-up there? can you confirm that the change I've suggested is correct?  I'd like to get this uploaded today if possible
[18:58] <nxvl> slangasek: yes, i have just replied
[18:58] <slangasek> ok, thanks :)
[18:58] <nxvl> slangasek: i thought it should be the new md5sum and added that one
[18:59] <slangasek> so you agree that the change I proposed is correct?  Shall I go ahead and upload?
[19:01] <nxvl> slangasek: yes i do
[19:01] <nxvl> slangasek: if you want i can change it
[19:02] <slangasek> nxvl: I already have the change locally, so I can say you changed it and uploaded it anyway :)
[19:02] <slangasek> oh, one other thing - since this is really the md5sum from gutsy, not hardy, perhaps we should also label it "7.10 gutsy"?
[19:02] <nxvl> slangasek: :D
[19:02] <slangasek> (I meant to say that already in the bug report, but failed)
[19:03] <nxvl> yes
[19:03] <nxvl> thats what i was thinking also
[19:03] <nxvl> i don't really know how it works, but i think that too
[19:03] <slangasek> I think it's just a label, but we might as well make it a useful label
[19:05] <slangasek> nxvl: oh, haha, *one* more little thing - I just noticed that you put a space before the : in /etc/motd, which is incorrect in English orthography... do you mind if I change that too? :-)
[19:05] <xtknight> umm i'm having issues compiling epiphany-extensions from source
[19:05] <xtknight> on amd64
[19:05] <xtknight> when i try it in a pbuilder, the configure keeps looping over and over, and i get this message. configure: error: Unknown gecko "libxul" specified
[19:09] <slangasek> nxvl: ?
[19:11] <nxvl> where?
[19:11]  * nxvl look
[19:11] <nxvl> oh
[19:11] <nxvl> yes
[19:11] <nxvl> sorry about that
[19:11] <slangasek> no problem
[19:12] <slangasek> I should have noticed it in an earlier revision anyway :)
[19:12] <slangasek> nxvl: uploading, thanks for your contribution to Ubuntu :)
[19:13] <nxvl> thanks for your sponsoring :D
[19:13] <ScottK> norsetto: re launchpad-integration bugs: Just don't look.  Since (AFAIK) there's no proper documentation of Launchpad APIs, what we can do from the outside is really limited.
[19:13] <RainCT> there are some examples and such on the wiki, but I don't remember where..
[19:17] <xtknight> weird...getting different errors compiling epiphany-extensions depending on where i try it.  does anyone else mind trying it?
=== kitterma is now known as ScottK2
[19:18] <ScottK2> norsetto: ping
[19:19] <ScottK2> Nevermind
[19:20] <stani> pochu: can I follow somewhere progress after I imported to launchpad?
[19:40] <colinl> hello \sh :)
[19:42] <yannick_1m> hi there
[19:42] <colinl> \sh: there's one new launchpad bug on claws-mail that has a patch, if you want to/can take care of it :) : https://bugs.launchpad.net/ubuntu/+source/claws-mail/+bug/213960
[19:42] <ubotu> Launchpad bug 213960 in claws-mail "claws-mail crashed with SIGSEGV" [Undecided,Confirmed]
[20:01] <norsetto> scottk2: hi there
[20:03] <ScottK> He
[20:03] <ScottK> Hey
[20:04] <ScottK> I was going to ask you to ack an FFe, then I realized it was just bug fixes.
[20:04] <ScottK> norsetto: Are you coming to UDS?
[20:04] <norsetto> scottk okki, yes, I'm indeed
[20:04] <ScottK> Then we'll get to meet finally.
[20:04] <norsetto> scottk: :-)
[20:04] <ScottK> We can discuss the old MOTUs like mok0.
[20:05] <norsetto> scootk: oh man, he is ANCIENT ;-)
[20:06] <norsetto> scottk: dinosaurs were still roaming the earth when he was born (I'll have to buy you both a budweiser then)
[20:06] <ScottK2> Yes.  He's IIRC ~8 years older than we are.  I don't know if he's coming.
[20:07] <slangasek> a budweiser or a budějovický?
[20:07] <sebner> ScottK: norsetto : then show respect :P
[20:07] <norsetto> slangasek: if the first is the USA version, the second ;-)
[20:08]  * slangasek grins
[20:09]  * ScottK2 too
[20:21]  * tsmithe pokes slomo
[20:21] <tsmithe> :)
[20:26] <stani> pochu: are you there?
=== DRebellion__ is now known as DRebellion_
=== DRebellion_ is now known as DRebellion
[21:11] <emgent> heya blueyed
[21:12] <emgent> blueyed: bug #214137
[21:12] <ubotu> Launchpad bug 214137 in python-launchpad-bugs "[internal server error] while trying to file a bug" [High,New] https://launchpad.net/bugs/214137
[21:14] <ScottK> YokoZar: Does iTunes work yet?
[21:15] <YokoZar> ScottK: The latest version does, yeah.  It can only sync with older ipods though (which are just USB mass storage devices) - newer ipods and iphones are weirder
[21:16] <emgent> with wine ?
[21:16] <pschorf> i'm working on bug 209982 (creating a debdiff file) and the source for xmlstarlet doesn't have a debian/patches folder.  Can I just make one to put the patch into?
[21:16] <ubotu> Launchpad bug 209982 in xmlstarlet "many -N options gets dropped for command-line" [Undecided,New] https://launchpad.net/bugs/209982
[21:16] <YokoZar> emgent: yes, with Wine
[21:17] <emgent> ok, thanks YokoZar :)
[21:17] <pochu> stani: I'm now
[21:18] <stani> pochu: good news: I managed to get a hardy ppa for phatch, but ...
[21:19] <stani> pochu: unfortunately the bad news is, I don't manage to put up a gutsy ppa (or feisty or ...)
[21:19] <ScottK> YokoZar: Cool.  Maybe that'll get one kid off of Windows entirely.  Her iPod is a year and a half old.
[21:19] <stani> pochu: upload for gutsy gets rejected: MD5 sum of uploaded file does not match existing file in archive Files specified in DSC are broken or missing, skipping package unpack verification.
[21:19] <YokoZar> ScottK: no kidding.  iTunes is what was holding my girlfriend back too.
[21:20] <ScottK> Currently the PC the kids use dual boots for iTunes and they must get explicit permission to be in the "other" OS.
[21:20] <stani> pochu: what I did is change the changelog from hardy to gutsy run again debuild and upload with dput
[21:20] <ScottK> stani: You need to use a different version number too.
[21:21] <ScottK> stani: I usually add ~$RELEASE~ppa$REVISION to my PPA uploads
[21:21] <stani> version number for hardy is 0.1.3-0ubuntu1~ppa1
[21:22] <ScottK> So make the next one 0.1.3-0ubuntu1~gutsy~ppa1
[21:22] <stani> ok
[21:22] <stani> will try again, thanks a lot
[21:22] <ScottK> That'll give it a lower version number than an official backport if you do one of those
[21:23] <pochu> stani: is the .orig.tar.gz the same?
[21:23] <ScottK> pochu: That's the same error you get if you reuse a version number.  Guess how I know ....
[21:23] <pochu> stani: i.e. are the md5sum from the .changes files matching?
[21:23] <pochu> ScottK: ah, true
[21:24] <pochu> stani: ^-- you need to change the version... use something like 1.1-1~feisty1, for example
[21:24] <james_w> does anyone have an up-to-date Debian unstable box to hand?
[21:24] <pochu> or whatever, but not the same one
[21:24] <stani> ScottK: Will that give a problem when we go from the Zutsy Zallow to the Ancient Avantgarde? (just hypothecical in a far future)
[21:24] <pochu> stani: then use ~7.04 :)
[21:25] <ScottK> In theory
[21:25] <ScottK> We do use ~gutsy/~feisty etc for official backports, so I think it's fine
[21:25] <pochu> but in practice not, as by then you won't be at 1.1
[21:25] <stani> pochu: ok, so the version number is 0.1.3-0ubuntu1~7.04~ppa1
[21:25] <pochu> that's fine, yes
[21:26] <ScottK> Is that a higher or lower version number than ~gutsy?
[21:26] <stani> ScottK: I think lower
[21:27] <stani> pochu: the orig.tar.gz is the same of course. Should it change?
[21:27] <ScottK> That's fine.
[21:28] <pochu> stani: no, it should remain the same
[21:28] <pochu> bbl
[21:34] <keescook> \sh: geh, I'm sorry to be catching this so late, but there may be an interaction between a security settings that stopped working early in hardy and wine.
[21:34] <stani> Now I get with debuild: Undefined subroutine &Dpkg::Version::_g called at /usr/share/perl5/Dpkg/Version.pm line 204
[21:34] <keescook> \sh: basically, the /proc/sys/vm/mmap_min_addr was working early in hardy when AppArmor wasn't enabled.
[21:35] <keescook> \sh: I just now noticed that it isn't working (I'm getting it fixed shortly)
[21:35] <keescook> \sh: wine loads most things okay, but reports warnings from the prelinker about not being able to reserve memory.
[21:36] <ScottK> keescook: YokoZar will also be interested in that.
[21:36] <keescook> YokoZar: oops, I had mis-remembered your nick.  I was trying Z<tab>  ;)
[21:36] <YokoZar> keescook: Ahh yes we talked about that at UDS a bit
[21:36] <keescook> YokoZar: yeah, I'm terribly sorry this is so late.  :(
[21:37] <keescook> YokoZar: you can test it now by booting with apparmor.enabled=0 on the kernel command line.
[21:37] <keescook> that will cause the default kernel security system to be used, which implements mmap_min_addr correctly.
[21:37] <YokoZar> keescook: And that would allow Wine to reserve those memory areas?
[21:38] <keescook> YokoZar: that will make it behave like I had intended.  To allow those regions, one just needs to change /etc/sysctl.conf's entry for mmap_min_addr
[21:38] <keescook> YokoZar: however, most Wine program shouldn't need that region of memory.
[21:38] <YokoZar> Yeah I think it's for DOS compatibility or something equally archaic
[21:38] <keescook> so I was hoping Wine would handle it more gracefully, but I don't know that part of the codebase at all.
[21:38] <keescook> yeah, exactly.
[21:38] <YokoZar> I'm pretty sure Wine does it's best (those are, after all, warnings and not errors in prelink)
[21:39] <keescook> when I tested just now, e.g. notepad is fine, but wine spews errors about the first meg of DOS memory
[21:39] <keescook> right
[21:39] <YokoZar> The one thing that might be an issue is weird copy protection, which Wine also uses prelink for
[21:39] <YokoZar> But I don't know how to test those exactly
[21:39] <YokoZar> And Wine only handles some of them right anyway
[21:39] <keescook> I guess what I'm getting at is that once this is fixed in AppArmor, wine will always spew errors about that memory region, which might scare people.  :P
[21:40] <YokoZar> True, but only when run from the terminal ;)
[21:40] <keescook> hehe
[21:41] <ScottK> keescook: People being scared when running wine: Bug or Feature?
[21:41] <keescook> okay, cool.  I just wanted to give you a heads-up, since it was a rather late change.
[21:41] <keescook> ScottK: haha, yes, good point.
[21:45] <YokoZar> Wine is already scary when run from the terminal because of all the fixmes it inevitably dumps out
[21:45] <keescook> heh, good point.
[21:47] <stani> I solved it. Will try dput now.
[21:48] <ScottK> stani: What was the problem?
[21:51] <stani> ScottK: Just me messing around. I moved the files in a separate folder, cd to it and deleted the folder. The terminal got disconnected.
[21:51] <ScottK> Ah
[21:51] <stani> ScottK: just reopening the terminal in the right folder solved it
[21:52] <stani> This time accepted! Let's see if it wants to build.
[21:55] <stani> I like to change the version number of the already build package for hardy in the ppa so it also reflects the distrorelease. What would be the best way? Delete the package?
[21:56] <ScottK> Yes
[22:01] <blueyed> emgent: re #214317. Doesn't this happen on commit()?=
[22:02] <blueyed> emgent: it's caused by a missing LP cookie.. I had to get cookies for "lp" and "edge" (only had "edge" before)
[22:07] <emgent> blueyed: add comment :)
[22:08] <emgent> i add lp cookie autentication in anteater with thekorn
[22:08] <emgent> but he saw another problem
[22:24] <stani> ScottK: Do you know what means 1010 in Pending (1010) message for PPA?
[22:24] <ScottK> It means publisher hasn't run yet.  It's normal.  Just needs some patience
[22:26] <stani> Just try to understand.
[22:26] <ScottK> Sure.
[22:26] <ScottK> The publisher pushes packages out to the archive on a periodic (Don't recall when).
[22:27] <cody-somerville> I think it is the 15th of every hour IIRC
[22:28] <stani> But is 1010 or 1005 a message id?
[22:29] <stani> Hi cody-somerville: Congratulations with Xubuntu!
[22:29] <cody-somerville> stani, Thanks :)
[22:29] <stani> I am on xubuntu hardy right now ;-) (my old laptop pentium |||)
[22:30] <emgent> hehe Xubuntu people r0cks
[22:33] <cody-somerville> :)
=== FlareFlare is now known as Flare18
=== Flare18 is now known as Flare183
[22:45] <stani> ScottK: Phatch refuses to build on dapper as python-central is missing. Is there an easy work around?
[22:46] <ScottK> stani: No easy one.  You need to make debian/rules with debhelper.
[22:48] <ScottK> Dapper was transitional and the new python policy was only partly implemented in it.
[22:48] <stani> OK, than I leave it. So python-central exists on Edgy?
[22:48] <ScottK> Yes.
[22:48] <ScottK> stani: You know you can do backports to and get better exposure.
[22:48] <ScottK> !backports | stani
[22:48] <ubotu> stani: If new updated Ubuntu packages are built for an application, then they may go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging
[22:51] <stani> Seems good, but I just called my PPA repositories "bleeding edge" ;-)
[22:51] <stani> So it is meant for people who want the latest bugs ;-)
[22:53] <ScottK> Right.
[22:53] <jdong>  I call em Personal Packaging Atrocities
[22:53] <jdong> because that's what I usually put in em :D
[22:53] <ScottK> But if you want the Hardy package in the earlier releases, backports is a good way to do it.
[22:54] <ScottK> Personally, I think they're good for testing when you know the person that's running the PPA, but I wouldn't want to just use software from random PPAs.
[22:54] <stani> Yes, so we can wait some time after Hardy is released and see if not serious bugs arise.
[22:54] <ScottK> Fair enough.
[22:54] <stani> ScottK: I guess you don't dare to use my PPA's
[22:55] <ScottK> I like to stick to the Ubuntu repos for production use.
[22:55] <stani> I am just joking
[22:55] <ScottK> So far skype and acrobat are my only exceptions.
[22:55] <ScottK> ;-)
[22:55] <stani> what do you use medibuntu?
[22:55] <jdong> that's what I use...
[22:56] <norsetto> oh well, g'night all
[22:59] <emgent> blueyed: here?
[23:02] <ScottK> stani: Since I live in a country where distribution and use of some of the stuff that medibuntu distributes is illegal, I'm unlikely to have an opinion on it.
[23:03] <ScottK> Actually illegal is to strong.
[23:03] <ScottK> A civil wrong is a better way to put it.
[23:04] <stani> ScottK: Problem with Edgy: "Missing dependencies:                 debhelper (>= 5.0.38)                            "
[23:04] <jdong> nah, illegal I think is the correct term to describe it
[23:04] <jdong> if you download the right (err, wrong) things in medibuntu
[23:05] <ScottK> jdong: Well I don't think you can be criminally charged, just sued in civil court, but I could be wrong.
[23:05] <stani> ScottK: Can I just lower the version number. If yes, to which version for edgy?
[23:05] <ScottK> stani: It's probably that for a reason.
[23:05] <ScottK> You can try it.
[23:06] <ScottK> stani: You might look at debian/changelog for debhelper and see if there's anything in 5.0.38 that you need.
[23:06] <crimsun> yes, it's dh_python
[23:07] <crimsun> kinda sad that I remember the 5.0.38 requirement from "back then"
[23:07] <stani> I'll leave it. I prefer to play a bit more with gstreamer. I never got a request for Edgy.
[23:15] <emgent> 7query blueyed
[23:16] <jdong> are rmadison queries expensive on the servers?
[23:18] <jdong> I have this basic pre-backporting script that uses a sqlite-backed cache to query the various package versions available to test if a package is backportable
[23:18] <jdong> I don't wanna be an ass to the poor rmadison servers
[23:24] <ajmitch> that's a fun feature of update-manager, offering to start a new sshd for me in case I royally break things :)
[23:25] <jdong> it does?
[23:26] <ajmitch> yeah, because I'd started it via ssh
[23:26] <jdong> cool
[23:27] <jdong> didn't know that
[23:29] <Nafallo> it rocks :-)
[23:30] <jdong> ok quick poll: Will any angry mobs form if I add a MUTILATE_BUILD_DEPS non-default parameter to prevu?
[23:31] <jdong> whose functionality will sed out versions on versioned build deps, mostly aimed for people building packages personally for themselves?
=== danielm_ is now known as danielm
[23:55] <ScottK> jdong: I think adding to crack is like adding to infinity.  crack + crack = crack.