[00:10] <sistpoty> pochu: just reading the wesnoth FFe... wasn't there trouble in the past, because the Ubuntu version would have needed either an SRU or needed to be degraded?
[00:20] <pochu> sistpoty: looks like Edgy shipped with an unstable release (1.1.8), but I don't know of such situation
[00:22] <sistpoty> pochu: ok
[00:25] <persia> pochu: Could you please coordinate with Rhonda to try to get the eventual 1.4 to be a sync?  There's been a few security issues in the past, and I suspect that lenny will have 1.4, which would help with LTS support.
[00:26] <persia> (assuming FFe approval)
[00:26] <pochu> persia: we are already in sync ;)
[00:27] <pochu> persia: and Rhonda uploads the same day the wesnoth team makes a new release (he contributes upstream I think)
[00:27] <persia> pochu: That's why I ask.  I was hoping Ubuntu wouldn't be in advance when the release happens :)
[00:27] <sistpoty> persia: any hints, to ack or rej the FFe?
[00:27] <pochu> and the Maintainer is a wesnoth developer iirc
[00:28] <persia> sistpoty: I don't feel I ought influence the motu-release decision, but having similar upstream in an LTS and debian release seems sane to me, and I wouldn't expect a playable 1.5 for at least 6 months, if not a year.
[00:28] <persia> (oh, and 1.3.18 is an RC, although this is not clear from the versioning)
[00:28] <pochu> that's in the bug report :)
[00:29] <pochu> 13 development releases, 3 beta releases and one RC so far
[00:29] <sistpoty> thanks persia! (and no, I'm not influenced but rather ask for insights that I'm not having... which I gues should be motu-release duty ;)
[00:29] <pochu> and the changes in the RC are really small
[00:44] <Legendario> i would appreciate if someone could make a review on my packages on REVU: http://revu.tauware.de/details.py?package=odfviewer and http://revu.tauware.de/details.py?package=sive
[00:53] <persia> pochu: slomo: Thanks!  That's a great step forward towards having MIDI work.
[00:54] <pochu> persia: thanks to you for packaging wildmidi ;)
[00:54] <pochu> persia: did you see the TODO in the changelog? ;-)
[00:54] <persia> pochu: Actually, slomo deserves more credit than I: I just wrapped upstream in CDBS.
[00:55] <pochu> persia: you both deserve it, and you both have it
[00:56] <persia> I did see the TODO.  I'm not sure where that should happen, nor how to handle the various different ways that midi files are currently stored.
[00:56] <pochu> persia: and you ITP'ed it and are the maintainer, which is great too
[00:56] <jdong> ScottK: is there any reason bug 184614 is set fix committed?
[00:56] <ubotu> Launchpad bug 184614 in gutsy-backports "Please backport f-spot 0.4.1 from hardy" [Undecided,Fix committed] https://launchpad.net/bugs/184614
[00:57] <pochu> persia: perhaps "grep x-bzip ext/bz2/gstbz2dec.c" is helpful
[00:59] <Legendario> does anyone know this make error: [build-stamp] Error 2 ?
[01:00] <slangasek> Legendario: that by itself doesn't tell you what the error was
[01:00] <persia> pochu: Part of the problem is getting the MIME detection to work.  It might be acceptable to force "audio/midi", but "audio/x-midi" is still popular, and there are heaps of files that are listed as text/plain or text/html.
[01:01] <persia> Legendario: That means that the last call by make returned an error code of "2", rather than the expected "0", and so make quit.  Check the previous entry.
[01:02] <persia> pochu: Also, I'm not sure we have the infrastructure in place to correctly define what files should be considered "audio/midi" when they are found on the filesystem, rather than hinted by something passing Content-Type: (browser, mailreader, etc.)
[01:02] <persia> pochu: Or am I looking at a much more invasive and general issue than that implied by your TODO?
[01:03] <Legendario> here it is the whole thing: http://paste.ubuntu-nl.org/57009/
[01:04] <persia> Legendario: Your issue is with lines 121 and 122, and the error comes with line 123.  Likely you have a variable unset or set to an unexpected value.
[01:05] <Legendario> persia, which folder are the kernel modules installed?
[01:06] <crimsun_> /lib/modules/$(uname -r)
[01:06] <persia> Legendario: Typically /lib/modules/`uname -r` (or, used in a makefile, "/lib/modules/$(shell uname -r)/")
[01:07] <pochu> persia: no, you may be right. I didn't know midi was used for other things than midi sound files
[01:09] <persia> pochu: MIDI is really an events-based wire transport protocol.  A midi sound file is some encoding of a set of wire stream events, which is than translated into sounds by a tone generator.
[01:09] <pochu> persia: oh, that's... really new to me :)
[01:10] <persia> For the most common standard portable format, .mid and .midi are commonly used extensions, and it should be MIME-type audio/midi but I'm just not sure that everything is in place for various file consumers at this point.
[01:11] <persia> pochu: http://en.wikipedia.org/wiki/MIDI is a reasonable overview.  MIDI is typically used external to computers for either music generation or control systems (e.g. moving platforms, lights, etc.).  With computers used as sequencers, it became good to have a common file format to share event streams.
[01:12] <Legendario> persia, let's see if this solves it
[01:13] <persia> pochu: I believe that both timidity and wildmidi support all of SMF, XMF, and RIFF, but I've not investigated deeply enough to determine the right answer (my interest is more in realtime MIDI control, which spills into soundfonts, which spills into fixing the "no MIDI by default" problem)
[01:16] <Legendario> persia, got the same error... do u have the any idea?
[01:17] <Legendario> i am trying to pack this package: http://wiki.mediati.org/R5u870#Compiling
[01:19] <persia> Legendario: Perhaps there is no makefile in the modules directory?  I'd suggest entering your clean chroot, pulling the build dependencies manually, starting the build with debuild, and checking to see the state of the chroot at the point of failure.
[01:19] <sistpoty> ah... gnome feels so wrong *g*
[01:20] <jdong> sistpoty: :)
[01:21]  * sistpoty is still having troubles with gnome *g*
[01:21] <sistpoty> ls
[01:23] <emgent> :)
[01:23] <V3nd3tt4> sorry for my newbie question, If I build gstreamer-0.10.15, but I want to edit the description(because is too short, I must re-build the package ?
[01:24] <ScottK> jdong: I didn't set it that way.
[01:24] <jdong> ScottK: ok thanks, that's all I needed to know.
[01:24] <jdong> ScottK: btw what do you think about maintainer field, -backports vs -motu?
[01:24] <jdong> I personally don't care either way at this point
[01:25] <ScottK> I'd say backports, particularly for a Main backport, but I wouldn't remunge it if it's already munged once.
[01:25] <jdong> ScottK: ok, then I think jeromeg's debdiff for brasero is good for sponsorship
[01:26] <ScottK> K
[01:27] <jdong> ScottK: any particular status or process you'd like me to follow to communicate source-change backports?
[01:27] <pochu> V3nd3tt4: why do you want to edit the description?
[01:27] <ScottK> jdong: Just subscribe me on the bugs I guess.
[01:27] <jdong> ScottK: sounds good :)
[01:29] <V3nd3tt4> pochu: When I build the debian package (because is a test) I insert a short description for the gstreamer0.10.15 and plugin-base-0.10.15 and I want to do a good description
[01:29] <persia> pochu: Are you sure you want to close the timidity task?  We're still not shipping libgsttimidity.so, although it exists upstream, which would require someone to adjust timidity.  On the other hand, this may be a different bug.
[01:30] <pochu> V3nd3tt4: then yes, you need to update debian/control{.in} and rebuild the package
[01:30] <V3nd3tt4> pochu: thanks for your reply and sorry for my english and newbie question :P
[01:30] <pochu> persia: I closed it since we now have midi support... feel free to reopen it if you think it's an RFS
[01:31] <persia> RFS?
[01:31] <pochu> err, RFP
[01:31] <jdong> ScottK: for source-change backports, would you like an existing ubuntu motu maintainer: field to be mangled, or left as-is?
[01:31] <jdong> (I'm leaning towards left as-is)
[01:31] <pochu> V3nd3tt4: anytime. If you can improve the description, feel free to send a patch :)
[01:31]  * jdong laughs at the tag XSBC-Orig-Orig-Maintainer that just passed through his head :D
[01:31] <pochu> lol
[01:31] <persia> pochu: No, you're likely right.  I'll consider the missing libgsttimidity.so a different bug, but not yet even firmly enough wishlist to bother reporting.
[01:32] <V3nd3tt4> pochu: of course
[01:33] <pochu> persia: hmm, I guess a 'clone' feature in Launchpad would be useful in this case
[01:35] <persia> pochu: Maybe, but maybe not.  I think the original reporter's primary issue is now resolved.  Getting clean and proper MIDI support across the distribution (including libgsttimidity.so) seems more spec material to me (or just unspec'd feature goal, if someone does the work).  There are a large number of packages affected, and each needs different tweaking.  Maybe for the next LTS :)
[01:38]  * persia wants libSDL-midi to be able to control vegastrike from a low-end mixer board, or use a Tenori-on to play virtual chess on a projector
[01:40]  * sistpoty wants to have time to play vegastrike again *g*
[01:41] <persia> heh
[01:45] <pochu> persia: next LTS is quite far, what about intrepid? :)
[01:45]  * ScottK wants it to eat my vegetables for me so I don't have to do it to set a good example for the kids
[01:46] <pochu> ScottK: that would be hard to implement ;)
[01:47]  * ScottK wants.
[01:47] <ScottK> Implementation details are left to the programmers.
[01:49] <persia> pochu: I've only hit a couple of my release goals for hardy, mostly concentrating on REVU for the open window, and will be chasing other things.  Maybe someone else will hit it, but the couple people I know are working on MIDI are looking more at getting the next generation of synths and effects generators into the archive, and putting together an integrated sound generation suite.  Once that is accomplished, I would expect a spread from creator-
[01:49] <persia> Err.  That likely hit the buffer: "...putting together an integrated sound generation suite.  Once that is accomplished, I would expect a spread from creator-oriented materials to user-oriented materials (J), followed by cleanup, testing, and integration with other distros (K), followed by a comprehensive solution for MIDI for all installs (L)."
[01:51] <pochu> What does J, K and L stand for? :)
[01:51] <persia> pochu: intrepid+2, +2, and +3.
[01:51] <persia> s/2/1/1
[01:51] <pochu> persia: sound generation suite, as in something similar to Jokosher?
[01:51] <pochu> ah, ok
[01:51] <sistpoty> as long as HW midi will work for me OOTB, this all sounds sane :) (and I do have a keyboard, but cannot play it *g*)
[01:53] <persia> pochu: Not at all.  jokosher may be one part of it, but it's essentially a recording, sequencing, and (limited) mastering tool.  It's not enough on it's own.  Examples of the sort of thing I mean would be having jokosher use LASH to store the session, and use LV2, DSSI, etc. to call out for effects, etc. (all of which would also share the LASH session), with seamless integration into a mastering tool for CD production.
[01:54]  * pochu isn't very familiar with sounds other than pop music
[01:54] <persia> sistpoty: gstreamer-midi won't do that for you.  You likely either need timidity to have sane defaults, or use something like qsynth or zynaddsubfx for now.  intrepid ought have a fairly large suite of softsynths, and better coordination to get them working (and e.g. allow easy channel splitting so you can play woodwinds against brass).
[01:55] <sistpoty> heh, and it still won't help me play my keyboard w.o. practice *g*
[01:56] <persia> sistpoty: It's really up to you: keyboarding or vegastrike.  As much as MIDI programming interests me, I don't expect to let you combine them until intrepid+1 :)
[01:58] <emgent> hi persia :)
[02:02]  * ScottK2 tries out the new send an attachment via email to LP feature ...
[02:12] <jdong> ScottK2: I braindumped a proposal for a source-change backport procedure on the Backports wiki page, if you have some time I'd appreciate feedback:
[02:12] <jdong> https://help.ubuntu.com/community/UbuntuBackports#head-ef8cfa47259137092769be75f623d52e8f9ab352
[02:14] <ScottK2> jdong: I'm subscribed to the page.  Just read the diff.  Thank you for not adding a "Bug ScottK until he uploads it" step.
[02:14] <jdong> ScottK2: hehe the thought crossed my mind then I decided to spare your soul ;-)
[02:15]  * jdong looks at this Firefox backport again
[02:15] <ScottK2> It sounded generally reasonable, but I'd add the debdiff should have justification for modified dependencies.  e.g. changed build dep on foo from foo 0.5 to 0.3, as a result function bar is missing, but it's a good backport because ...
[02:16]  * ScottK2 aint doing that one.
[02:17] <jdong> ScottK2: I was unsure whether or not justification belongs on Launchpad or in the debdiff... I eventually concluded that it might cause the changelog to be too wordy
[02:17] <jdong> what do you think?
[02:17]  * jdong goes raid the Firefox bzr branch for patches :)
[02:19]  * ScottK2 reviews his bug sent in with attachments and files a bug on launchpad
[02:19] <Fujitsu> ScottK2: What'd it eat?
[02:19] <ScottK2> jdong: I see your point.  debian/changelog needs to have enough info to be sensible on it's own.
[02:20] <ScottK2> Fujitsu: The text of the file I attached is in the main bug, not attached.
[02:20] <Fujitsu> That sounds ugly.
[02:20] <ScottK2> Yeah.  Certainly violates the principal of least suprise.
[02:21] <ScottK2> Probably the approved design.
[02:21] <Fujitsu> Probably.
[02:21] <Fujitsu> Which bug?
[02:21] <sistpoty> so I couldn't attach a png icon by mail?
[02:21] <ScottK2> Excuse me if I'm a little grumpy about LP bugs.
[02:22] <ScottK2> I started yesterday with a long conversation about a bug 'fix' that ended up on "Yes, the 'fix' isn't actually a fix, but we don't really care."
[02:22] <persia> sistpoty: Lots of LP bits check MIME type.  image/png likely wouldn't be pulled as text.
[02:24] <ScottK2> persia: Why would it pull any attachments in at all?
[02:24] <ScottK2> Stunningly bad design.
[02:24] <ScottK2> I wouldn't make any assumptions at all about it not sucking in a particular way.
[02:25] <Fujitsu> Is the list of blacklisted attachments available anywhere? I can't find it.
[02:25] <ScottK2> It's certainly not on the feature page telling me I can do this now.
[02:26]  * ScottK2 is having trouble in this one deciding to bet on bad design or bad implementation.
[02:26] <persia> (just guessing randomly) ScottK, in part because RFC1521 is annoying.  Everything is an attachment, so it is the responsibility of the parser to determine which parts are "message" and which "attachment".  From what I understand, RFC 2045 helps with this, but I don't think it is "solved", and I don't think the LP MIME parser is based on a common library (as I don't know of a common library).
[02:26] <Fujitsu> Ah, it lists three categories on UsingMaloneEmail, but doesn't exactly say how they're determine.
[02:26] <pochu> good night folks
[02:27]  * persia can understand specs being private pre-release, but would like them to become public when the feature becomes public, for testing and review.
[02:27] <ScottK2> persia: This is a problem that's well solved in many MUA implementations.  I decline to give them a pass because the RFCs are hard to read.
[02:27] <ScottK2> Heya bddebian
[02:28] <Fujitsu> persia: It'd be particularly nice if stuff like this was public pre-release, as it can't be tested on ege.
[02:28] <Fujitsu> *edge
[02:28] <Fujitsu> My d key is failing :(
[02:28] <persia> ScottK: Maybe.  I've used several MUA implementations that did it badly, from the simply awkward to the stunningly unusable.  Anyway, I suspect the problem is related to testing, rather than just being bad on the face of it.
[02:29] <ScottK2> Well I've not had any trouble in a long time with any that were not developed in Redmond.
[02:29] <persia> Fujitsu: Yes.  That was precisely why I gave up porting mass-bug to LP: I could only test against production.  For now, mass-bug spams the BTS...
[02:29] <Fujitsu> I like Outlook's attachments.
[02:29] <Fujitsu> TNEF FTW.
[02:30] <bddebian> Heya gang
[02:30] <bddebian> Hi ScottK
[02:30] <ScottK2> This one could have easily been tested on dogfood.
[02:31] <Fujitsu> Does dogfood email?
[02:31] <Fujitsu> Or accept email?
[02:31] <ScottK2> I can't imagine a more basic thing to test with this new feature.
[02:31] <ScottK2> Dunno, but it's the test site, right?
[02:31] <Fujitsu> dogfood is largely for Soyuz testing, anyway.
[02:31] <ScottK2> Ah
[02:31] <persia> bddebian: I'm planning another review for wx2.4 in the next day or two.  Did you ever figure out what was happening with your patch for newpki-client?
[02:31] <sistpoty> hi bddebian
[02:31] <persia> Fujitsu: neither dogfood nor staging worked for me in feisty.  I haven't tested since.
[02:32] <Fujitsu> I know staging doesn't.
[02:32] <bddebian> persia: No, I never heard back from the maintainer again. :-(  I'll look to see if I still have it around but I think it was on my HD that died :-(
[02:32] <bddebian> Heya sistpoty
[02:32] <ScottK2> Well any project of non-trivial complexity that doesn't have a wuite for testing is either in need of very high powered engineering or fundamentally broken
[02:32] <emgent> one question: i was try to merge firebird2.0 and i was solved conflicts, but when i do debdiff i saw .po* changes introduced by debian.
[02:32] <Fujitsu> demo might, but it uses the prouction codebase.
[02:32] <bddebian> persia: Did you see that survex got "fixed" in Debian though?
[02:32] <emgent> if i try to build with new.dsc working fine
[02:32] <emgent> and compile fine, but debdiff dont work
[02:32] <pochu> ScottK2: btw can you ACK bug 193953 for gst-plugins-good0.10? There's a changelog.diff attached. The update is just a one bug fix.
[02:32] <ubotu> Launchpad bug 193953 in gst-plugins-ugly0.10 "Please update gst-plugins to 0.10.7" [Wishlist,Confirmed] https://launchpad.net/bugs/193953
[02:32] <emgent> some idea?
[02:32] <persia> bddebian: :(  OK.  If you have a chance soon, I'll try to pull it.  If not, I'll see if I can decipher what was intended.
[02:32] <emgent> persia, some idea? :)
[02:32] <persia> And yes, I saw your note about survex: brightened my whole day.
[02:33] <bddebian> How do I stop the generated maintainer scripts from running ldconfig?
[02:33] <ScottK2> pochu: If it's just bugfix it doesn't need an ack.
[02:33] <sistpoty> ScottK2: actually, I must admit, that I'm quite ok with LP recently... imho, it was much worse earlier
[02:33] <pochu> ScottK2: it's for main :)
[02:33] <ScottK2> Ah
[02:33] <ScottK2> pochu: I'm not touching Main stuff that starts with a G.  I know nothing near enough about it.
[02:33] <persia> bddebian: Why don't you want to run ldconfig?
[02:33] <pochu> ScottK2: hehe
[02:34] <emgent> why debdiff introduce to my result.debdiff debian translation indtroduced?
[02:34] <bddebian> persia: W: muine: postinst-has-useless-call-to-ldconfig
[02:34] <pochu> ScottK2: ok no worries.
[02:34] <ScottK2> sistpoty: I think they put way to much into features (a significant fraction of are misfeatures of some sort) and not nearly enough into making it a reliable, usable system.
[02:35] <persia> bddebian: Ah.  Yes.  I suspect you want the buildlog with DH_VERBOSE := 1
[02:35] <persia> (in other words, I don't know)
[02:36] <bddebian> Well where I'm confused a little is that it does create shared libraries in /usr/lib/muine but meebey told me not to call makeshlibs.  I'm not sure why.
[02:36] <ScottK2> sistpoty: This one I find their response inexplicable.  https://bugs.launchpad.net/malone/+bug/137448
[02:36] <ubotu> Launchpad bug 137448 in malone "New UI is confusing and counter inuitive for changing affected package" [High,Confirmed]
[02:36] <persia> bddebian: You don't want to call makeshlibs because they are plugins that will be loaded at runtime, rather than things the linker needs to enfore.
[02:37] <ScottK2> sistpoty: It's basically we didn't fix your issue, but added a couple of little triangles, so be happy.
[02:37]  * ScottK2 wants the pre-beta U/I back.
[02:37] <ScottK2> It was faster and cleaner and generally more usable.
[02:37] <Fujitsu> ScottK2: Was the content-disposition set properly on the bug you filed?
[02:38] <ScottK2> Fujitsu: What do you mean?
[02:38] <persia> ScottK: The RFC822 header Content-Disposition: in your mail
[02:38] <Fujitsu> ScottK2: LP is only meant to take the attachment as an attachment if it's not Content-Disposition: inline, but attachment.
[02:39] <bddebian> Oh, I have the newpki patch on my local windows box
[02:39] <ScottK2> Content-Disposition: attachment; filename="diffstat.txt"
[02:39] <sistpoty> ScottK2: didn't read the whole but... but I must admit that a) I very often wrongly click on "affects" when I want to change status and b) that the old way was complete and utter bs ;)
[02:39] <Fujitsu> ScottK2: OK, so it is YALPB.
[02:39] <ScottK2> Fujitsu: Yes it way
[02:39] <persia> bddebian: It's the copy from your windows box that I was having trouble applying :(
[02:40] <bddebian> persia: I know but at least I have it :-)
[02:40] <persia> bddebian: It's also in the BTS :)
[02:40] <bddebian> Oh, I actually remembered to submit it didn't I.. Heh
[02:40] <ScottK2> Fujitsu: I put the message source in the bug so they can see that.  Good point.
[02:41]  * Fujitsu grumbles at the gfortran transition, and tries to look further into it this afternoon.
[02:41] <jdong> WHOO it didn't FTBFS this time :)
[02:42] <ScottK2> jdong: Ship it.
[02:42] <jdong> (wow check out that confidence in my voice)
[02:42] <jdong> ScottK2: haha lemme put that in the Packaging Perversion Archive...
[02:43]  * jdong first volunteers his own Firefox profile to this evil experiment
[02:43]  * Fujitsu takes cover.
[02:45] <ScottK2> jdong: If you haven't go look up what wikipedia says PPA stands for.
[02:46] <ScottK2> jdong: Are you sure this brasero thing is ready to go?  I see it's in dep wait for one arch and FTBFS on another for Hardy.
[02:48] <jdong> ScottK2: amd64/i386/ppc are all fine, hppa FTBFS'es on half of the planet anyway...
[02:48] <ScottK2> Dep wait for IA64.
[02:49] <ScottK2> jdong: I commented in the bug.  Please comment back.
[02:53] <sistpoty> ScottK2: btw, thanks for your excellent work at motu-release. I guess we might have lost control w.o. you by now!
[02:53] <nxvl> what is the logic behind man pages numbers?
[02:54] <nxvl> which number belogns to what
[02:54] <ScottK2> sistpoty: Thanks.  You've been doing good work too.  Asking for a diff of the symbols was a great idea on the one telepathy lib
[02:54] <ScottK2> nxvl: man man
[02:54] <sistpoty> ScottK2: well, I must admit that I've been procrastinating at work *g*
[02:54] <ScottK2> ;-)
[02:54] <nxvl> ScottK2: there is explained? thnx
[02:54] <ScottK2> nxvl: Yes
[02:56] <emgent> ScottK2, one question: i was try to merge firebird2.0 and pbuilted fine, but debdiff include stupid .po* changes imported by debian
[02:56] <emgent> clean method to clean debdiff ?
[02:56] <sistpoty> good night everyone
[02:56] <ScottK2> good night sistpoty
[02:57] <emgent> ScottK2,  http://thc.emanuele-gentili.com/~emgent/security_fix/a.debdiff
[02:57] <ScottK2> emgent: Generally you can edit those out of the debdiff, but it depends.
[02:57]  * ScottK2 looks
[02:57] <emgent> this is a debdiff, but include debian .po*
[02:58] <emgent> changelog: http://rafb.net/p/tAV6eo67.html
[02:58] <emgent> if i try to build with .dsc working fine (i have .deb)
[02:58] <emgent> but debdiff it's not cleaned.
[02:59] <emgent> some idea?
[02:59] <ScottK2> Edit the debdiff.
[02:59] <ScottK2> That's what I've always done.
[03:00] <emgent> i'm think to use filterdiff -x '*\.po*' a.debdiff > b.debdiff
[03:00] <ScottK2> Should work.
[03:00] <emgent> ok thanks
[03:00]  * ScottK2 just uses vim, but you pick your tools
[03:00] <emgent> heheh sure!
[03:00] <emgent> :P
[03:02] <persia> ScottK; I'd encourage you to look at editdiff as a vim wrapper: it can help with the line number calculations, etc.
[03:02] <ScottK2> persia: Thanks.
[03:02] <ScottK2> In this particular case it's removing complete files from the diff, so it's pretty easy.
[03:03] <persia> Yeah, for that editdiff doesn't help.  vim is good, as are filterdiff, emacs diff handling, and a well written call to awk :)
[03:06] <jdong> HA! victory is mine.
[03:06] <jdong> I did get it to work :)
[03:06] <jdong> now I await victims^Wtesters
[03:10] <emgent> persia, ehehe
[03:18] <emgent> done i have two upload on hold :P
[03:41] <bddebian> persia: I'm re-doing the patch by hand now.  If it still doesn't work, I'm done.. :-(
[03:43] <persia> bddebian: That's fine.  I'm happy to chase the corner bits, but as your patch looked like it ought work, but I couldn't apply it at all, I wanted your help getting it into sane shape.
[03:43] <bddebian> Yeah, I have no idea why it doesn't apply.. :-(
[03:43] <bddebian> persia: Oh if you get bored I have a game debugging issue for you ;-P
[03:45] <persia> bddebian: I need a new case: I only have about 10 minutes of GL before I have to stop it.  If it's not GL, I'd be happy to take a look (but may not find it until tomorrow or so)
[03:46] <bddebian> persia: I packaged up the new attal and finally got rpath to work but it keeps segfaulting on me :-(
[03:49] <persia> bddebian: Excellent.  That's the point I can actually find something.  Is the new version in SVN?
[03:50] <bddebian> persia: yes and also on mentors I think
[03:52] <persia> bddebian: I can't find it on mentors, but I'll pull from SVN later, and try to get it to segfault, and see if I can make the code a little more defensive.
[03:52] <bddebian> Sweet, thanks man
[03:54] <persia> Any suggestions on a test case to crash it?
[03:54] <bddebian> Start it. ;-)
[03:54] <emgent> omg impossible...
[03:54] <bddebian> Actually I think as soon as I tried to open a scenario it barfed
[03:55] <emgent> if i pbuilt .dsc work fine, if i try to apply debdiff cleaned faild.
[03:55] <emgent> uhm..
[03:55] <persia> bddebian: That sounds like it won't be hard :)
[03:57] <jetsaredim> how do I go about building a package for both gutsy and hardy?
[03:57] <jetsaredim> into my ppa
[03:58] <ScottK> jetsaredim: #launchpad is the place for PPA questions.
[04:02] <emgent> ScottK, problem persist
[04:02] <emgent> if i use new-ubuntu.dsc for build work fine, but debdiff give error on apply.
[04:02] <emgent> but i dont saw the problem, strange..
[04:03] <ScottK> emgent: Did you remove all the po files from the debdiff?
[04:05] <emgent> yep
[04:05] <emgent> http://launchpadlibrarian.net/12160087/hardy_firebird2.0_2.0.3.12981.ds1-5ubuntu1.debdiff
[04:06] <emgent> it's cleaned, same change by hand in firebird2.0 directory
[04:06] <emgent> but i pbuilt ubuntu-new.dsc work fine
[04:06] <emgent> if i try to apply this debdiff give me an error
[04:06] <emgent> very strage.
[04:07] <emgent> i worked on more merges but i dont saw this strage situation..
[04:08] <emgent> if i dont solve this night, i will as to pitti monday
[04:08] <emgent> ScottK, you have some idea?
[04:10] <emgent> i think tht if someone upload by .changes there isnt problem
[04:10] <emgent> it's debdiff the true problem.
[04:11] <ScottK> emgent: Why are the patches your debian/changelog says you removed in the debdiff?
[04:11] <emgent> it's conflict
[04:11] <emgent> i just remove coflict in debian/patches/series
[04:12] <emgent> according to keescook and Luca Falavigna
[04:12] <emgent> but i dont delete .patch
[04:13] <emgent> if you saw changelog explain well, edit is only in debian/patches/series
[04:13] <emgent> +  * debian/patches/series
[04:13] <emgent> +    - removed ubuntu-port-hppa.patch FTBFS and disable.
[04:13] <emgent> +    - removed ubuntu-port-ia64.patch FTBFS and disable.
[04:15] <emgent> emgent@flybox:~/Ubuntu/Merges/firebird2.0$ ls /var/cache/pbuilder/result |grep firebird2.0
[04:15] <emgent> firebird2.0_2.0.3.12981.ds1-5ubuntu1.diff.gz
[04:15] <emgent> firebird2.0_2.0.3.12981.ds1-5ubuntu1.dsc
[04:15] <emgent> firebird2.0_2.0.3.12981.ds1-5ubuntu1_i386.changes
[04:15] <emgent> firebird2.0_2.0.3.12981.ds1.orig.tar.gz
[04:15] <emgent> firebird2.0-classic_2.0.3.12981.ds1-5ubuntu1_i386.deb
[04:15] <emgent> firebird2.0-common_2.0.3.12981.ds1-5ubuntu1_i386.deb
[04:15] <emgent> firebird2.0-dev_2.0.3.12981.ds1-5ubuntu1_all.deb
[04:15] <emgent> firebird2.0-doc_2.0.3.12981.ds1-5ubuntu1_all.deb
[04:15] <emgent> firebird2.0-examples_2.0.3.12981.ds1-5ubuntu1_all.deb
[04:15] <emgent> firebird2.0-super_2.0.3.12981.ds1-5ubuntu1_i386.deb
[04:15] <emgent> emgent@flybox:~/Ubuntu/Merges/firebird2.0$
[04:15] <emgent> (sorry for little flood)
[04:18] <emgent> i try to build it in my PPA
[04:18] <emgent> (too)
[04:20] <emgent> Accepted:
[04:20] <emgent>  OK: firebird2.0_2.0.3.12981.ds1.orig.tar.gz
[04:20] <emgent>  OK: firebird2.0_2.0.3.12981.ds1-5ubuntu1.diff.gz
[04:20] <emgent>  OK: firebird2.0_2.0.3.12981.ds1-5ubuntu1.dsc
[04:20] <emgent>      -> Component: main Section: misc
[04:22] <emgent> ScottK, some good idea? :P
[04:23] <ScottK> Then your changelog is confusing me.  I thought it meant you'd removed them.
[04:24] <emgent> removed conflict
[04:24] <emgent> in debian/patches/series
[04:25] <emgent> if you have little bit time try to merge firebird2.0
[04:25] <emgent> i used grab_merge.sh
[04:26] <emgent> it's all ok when solve conflicts but debdiff that result isnt clean and dont work.
[04:32] <persia> emgent: I'd recommend you manage merge diffs manually.  One of the big reasons we don't automerge is that there are subtleties involved that require human-level intelligence.
[04:32] <emgent> persia, sure i saw that
[04:33] <emgent> anyway it's late (5.33 am)
[04:33] <emgent> i will work on this later :P
[04:46] <emgent> persia, in PPA builted fine amd64 i386 lpia (saw mail now) :P
[05:17] <kdub> i want to try making debdiffs, but cant seem to find a good way to find 'bitesized' bugs, any help?
[05:22] <persia> kdub: Have you tried searching for the bitesize tag?
[05:23] <kdub> i think my problem is that i dont know how to look for tags... :-[
[05:23] <persia> kdub: They should show on the left from https://bugs.launchpad.net/ubuntu/+bugs
[05:24] <kdub> ah. there we go thanks persia
[05:27]  * jdong grumbles about mono's svn taking 8 minutes to log
[05:48] <desertc> I would like to help in testing the 08.04 features now that they are frozen.  Is that effort being done by MOTU or -QA ?
[05:50] <desertc> Probably the QA team now that I think about it more.  :)
[06:56] <warp10> Good morning!
[08:18] <Iulian> Good morning.
[08:30] <phoenix24> Hi!
[08:30] <phoenix24> I'm trying to build a package, using "debuild -b"
[08:30] <phoenix24> but always fails stating: secret key not found.
[08:31] <phoenix24> I managed doing: debuild -b -k<pbulic-key-id>
[08:31] <phoenix24> is that ok ?
[08:31] <phoenix24> ERROR: http://paste.ubuntu.com/4914/
[08:32] <slangasek> it's ok, but you'll find after a while that it's annoying to have to repeatedly do by hand.  The error means that the string in your changelog does not precisely match the name on your GPG key
[08:32] <slangasek> so you should either update your GPG key to add a UID that matches, or you should update the value of your DEBEMAIL and DEBFULLNAME variables to match your key
[08:33] <phoenix24> I've updated the env variables: DEBEMAIL & DEBFULLNAME.
[08:33] <phoenix24> How do i update GPG Key to match UID ?
[08:33] <persia> phoenix24: Do you have a comment for the matching identity on the GPG key?
[08:34] <phoenix24> Yes! comment => (phoenix24)
[08:35] <phoenix24> persia: what shall I reset it to ?
[08:36] <persia> phoenix24: I think it's Name (comment), but I'm momentarily forgetting the appropriate gpg call to extract it.
[08:37] <slangasek> gpg --edit-key <keyID>; adduid; add a new UID that includes just your name and email with no comment
[08:38] <persia> That works too :)
[08:39] <persia> Hah.  Yes.  It's `gpg --list-public-keys <keyid>` to find out what you have to match.
[08:40] <phoenix24> running `gpg --list-public-keys <keyid> : gives uid                  Chaitanya Sharma (phoenix24) <csharma24@gmail.com>
[08:41] <persia> phoenix24: You need a perfect match between the changelog entry and that output.  I'd recommend adding a new identity without the comment (as previously suggested), but adjusting your changelog works as well.
[08:43] <phoenix24> Works absolutely fine!
[08:43] <phoenix24> thanks persia slangasek !!
[09:22] <phoenix24> While doing a => bzr commit -m "* enable sh build.sh to build the .xpi" debian/rules
[09:22] <phoenix24> ERROR : bzr: ERROR: Path(s) are not versioned: debian/rules
[09:23] <Fujitsu> phoenix24: bzr add debian/rules
[09:24] <phoenix24> Fujitsu, Does this commit to the Upstream ? or my local bzr repo ?
[09:30] <tbf> hi, is there a chance, that someone reviews http://revu.tauware.de/details.py?package=gnome-lirc-properties - despite the feature freeze?
[09:31] <tbf> a modern UI for configuring LIRC powered remote controls should be quite useful for Hardy - imho
[09:31] <tbf> https://code.fluendo.com/remotecontrol/trac/browser/trunk/help/C/figures
[10:04] <joejaxx> phoenix24: if you do bzr add and bzr commit -m .... then your local repo
[10:05] <phoenix24> joejaxx: thanks!
[10:05] <joejaxx> phoenix24: but if you bzr push to a location that might be upstream for example a bzr repository on launchpad with bzr push location hee than yes
[10:05] <joejaxx> kndgkdjfn
[10:05] <phoenix24> ok
[10:05] <joejaxx> s/hee\ than/then/g
[10:06] <joejaxx> phoenix24: you are most welcome
[10:07] <proppy> oy
[10:27] <db-keen> How are tests supposed to be packaged? I'm seeing a variety of current practices.
[10:28] <persia> db-keen: What sort of test?
[10:31] <db-keen> persia: tests for a specific package
[10:33] <persia> db-keen: Do you mean validity tests to ensure the code is correct?  Tests to make sure the output is correct?  Tests to make sure the compilation was successful?  Tests for the user to apply to input to see how the package will manage it?  Tests to see if input meets a standard defined in a package?  Tests to see if the user understands the concepts presented in the package?  Tests to see if the user has a given piece of knowledge as part of an e
[10:34] <joejaxx> phoenix24: it was cut off
[10:34] <joejaxx> bah
[10:34] <joejaxx> persia: *
[10:34] <joejaxx> persia: Tests to see if the user has a given piece of knowledge as part of an e
[10:34] <persia> joejaxx: That's OK.  The remainder may safely be deduced :)
[10:34] <joejaxx> btw good morning persia :D
[10:34] <joejaxx> persia: lol ;)
[10:35] <db-keen> mostly code correctness
[10:35] <db-keen> my apologies for being so vague
[10:36] <persia> db-keen: I wouldn't bother packaging those at all, just rather run the suite once against the package to make sure it wasn't hopelessly buggy before uploading.  You might want to look at the autopackage test for some targets that can be used to optionally test during build.
[10:36] <persia> Of course, if you patch the code, it's nice to also patch the tests so that if someone else downloads the source they can still use the test suite.
[10:38] <persia> Err.  autopkgtest.  Sorry :)
[10:40] <proppy> gm persia!
[10:40] <hellboy195> persia: if you have time you may want to look at bug 163603 otherwise bug 193649 is worthless :( Debian Maintainer hasn't answered yet
[10:40] <ubotu> Launchpad bug 163603 in axiom "FTBFS: axiom_20050901-9ubuntu1 on hardy/i386" [Medium,Confirmed] https://launchpad.net/bugs/163603
[10:40] <ubotu> Launchpad bug 193649 in axiom "Merge axiom 20050901-10 from Debian(Unstable)" [Undecided,New] https://launchpad.net/bugs/193649
[10:41] <persia> hellboy195: Why do we have two open merge bugs?  I'd suggest 193649 is duplicate to 163603, and that 163603 needs a description edit and a new attachment.
[10:42] <db-keen> I couldn't seem to find documentation for how to use autopkgtest or a home page, only the descriptions of what it does.
[10:43] <hellboy195> persia: the first one only says that there is a FTBFS. 1 -2 weeks ago new debian revision arrived so I wanted to merge it but found out that it FTBFS and found that bug report
[10:43] <persia> db-keen: Install the package and read the adt-run manpage or look in /usr/share/doc/autopkgtest.  If that's not enough, I'm not sure where else to direct you, and will fall back to my suggestion that you not worry about the tests for now.
[10:44] <db-keen> I'm working on a packager for Ruby programs, and up until now, I've been ignoring tests. Almost every Ruby project has them, and for libraries intended for use by other developers especially, I feel programmers would be much more comfortable if they could see the tests run, but I suppose I can let it go...
[10:44] <persia> hellboy195: Sorry.  Misread them.  Does 193649 also fix 163603?
[10:44] <db-keen> thanks for your help
[10:45] <persia> db-keen: Understood, but autopkgtest is really the only thing in place to automate testing, and I don't believe it is run on the buildds.
[10:45] <hellboy195> persia: nope. that's the problem. 20050901-9ubuntu1 built fine under feisty. but if you try to rebuild it on hardy it FTBFS and als the new -10 one. But it seems that Debian folks didn't have a problem to build it
[10:46] <persia> Your other option is to run make test during the build (or whatever the rake equivalent is, if using rake), to verify the compiled code does what is expected.  I'm not sure if that is typically in build: or install:
[10:47] <persia> hellboy195: Ah.  No point uploading it until there is one bug that fixes them both.  Looks like there's something wrong with the linking for OUT.o, but determining what requires digging into the build tree.  I would guess a missing build-dep would be a likely candidate.
[10:47]  * Hobbsee waves
[10:48] <hellboy195> persia: Well I looked at it, geser looked at it. We have no idea :( Debian Maintainer isn't answering, so I thought I ask you.
[10:48] <persia> hellboy195: Ah.  What did you discover when you were looking for code.o in the build tree?
[10:50] <hellboy195> persia: buh, AFAIK I didn't look at code.o, we were looking at the rules file, the end of the build log ,..
[10:50]  * hellboy195 is away for lunch
[10:51] <persia> hellboy195: The buildlog in 163603 points at the inability to find a file.  I haven't tried a local build.  Enjoy your lunch.
[10:53] <geser> persia: http://paste.ubuntu.com/4800/ is the log where the output from the build is redirected to
[11:00] <persia> geser: This is different than the log from http://launchpadlibrarian.net/10461076/axiom.buildlog  Is it a different problem?
[11:01] <geser> persia: that's the same error. That seems to be the reason why the OUT.NRLIB/code.o file is missing
[11:06]  * persia is having difficulty with the syntax of out.spad.pamphlet
[11:10] <persia> Am I reading this correctly, that the documentation is used to generate list which is then compiled?
[11:10] <persia> s/list/lisp/
[11:11] <persia> Hmm..  Locally I fail on src/interp/category.boot.pamphlet, which is a different FTBFS.
[11:14] <geser> on amd64? I got there a different FTBFS than in the i386 pbuilder (that from the bug I could reproduce on i386)
[11:21] <persia> Yes, on amd64.  Looks like a build system error to me (but checking the i386 output).
[11:25] <persia> Odd.  The amd64 issue appears to be related to moving something from the interpreter directory to the autoload directory, whereas the i386 issue appears to be a syntax error in the generated source.  This package involves far too much magic.  Testing a sid build of sid source now to see if that helps shed any light.
[11:44] <polopolo> hello, I need some help
[11:46] <polopolo> I did the packageguide with hello, but when i do debuild it says:
[11:48] <polopolo> http://paste.ubuntu-nl.org/57047/
[11:48] <polopolo> can someone help me?
[11:50] <persia> polopolo: Do you have a Makefile in /home/paul/hello/hello-debhelper-2.1.1/ ?
[11:50] <polopolo> no
[11:50] <polopolo> howo can I get one?
[11:50] <polopolo> how can I get one?
[11:51] <persia> That seems to be the source of the error.  You might need to run configure:, but I would have expected that call to be in debian/rules
[11:51] <persia> (and someone ought internationalise dpkg-source)
[11:51] <RainCT> ScottK: uh.. where did you see the grab-revu script?
[11:52] <polopolo> so I need to run configure on hello-debhelper-2.1.1?
[11:52] <persia> RainCT: It is in the root directory of the source package.
[11:53]  * persia agrees that dget works just fine
[11:53] <RainCT> persia: ah, right, might be. thanks
[11:53] <persia> polopolo: Maybe.
[11:54] <polopolo> well, ok , I gonna do that
[11:54] <persia> polopolo: Can you post your debian/rules?
[11:54] <polopolo> ok
[11:55]  * RainCT is sure there are better ways to calm down than filling my mail box, btw :P
[11:55] <polopolo> hmmmm, maby I found the problem
[11:55] <persia> RainCT: filling your mailbox?  I thought everything was filed as bugs on LP.
[11:56] <RainCT> yes
[11:56] <polopolo> I gonna try it again
[11:57] <persia> polopolo: Also, just out of curiosity, was the make output Dutch?
[11:57] <RainCT> ScottK: on what architecture are you?
[11:57] <polopolo> there is some dutch yes
[11:57] <polopolo> does not work :(
[11:58] <polopolo> http://paste.ubuntu-nl.org/57048/
[11:59] <spectie> hey there all
[11:59] <spectie> is there any point in me putting in a sync request for a very simple package this late in the freeze ?
[11:59] <persia> polopolo: Hmm.  Strange.  That looks almost exactly like the debian/rules for the version of the package in the archive.
[11:59] <persia> spectie: Only if it fixes a bug
[11:59] <spectie> ok, it doesn't
[12:00] <persia> spectie: It's unlikely to be approved then.
[12:00] <spectie> there was one approved last week that i put in
[12:00] <spectie> but have the circumstances changed since then ?
[12:02] <polopolo> persia: so what should I do?
[12:02] <persia> Circumstances oughtn't have changed since the 15th, but there are different sorts of sync.  Adding a new package, or pulling a new upstream version requires a freeze exception, which ought show it achieves some goal necessary for hardy.  A simple package update to fix some bugs is welcome, whether by sync or by direct upload.
[12:03] <persia> polopolo: I'm not sure how to guide you.  You are calling ./configure in your build, but it doesn't seem to be creating your Makefile.  Maybe you have a leftover "build" file?
[12:04] <spectie> persia, ok
[12:04] <spectie> i might try putting it through anyway
[12:05] <polopolo> persia: I did excacly what it says here: https://wiki.ubuntu.com/PackagingGuide/Complete
[12:06] <persia> polopolo: Understood.  Still, your build log indicates that you aren't calling configure during your build, but it is in your rules, which confuses me.
[12:07] <polopolo> persia: http://paste.ubuntu-nl.org/57049/ mayby this was the problem?
[12:07] <polopolo> nothing
[12:08] <persia> polopolo: Ah.  Yes.  You want to add the debian/ directory to the unpacked source tarball.
[12:08] <DktrKranz> \sh_away, I've a possible fix for bug 185513 (and some of the segfaults reported recently). Mind if I upload a new revision or do you plan to make additional changes?
[12:08] <ubotu> Launchpad bug 185513 in wine "Wine packages overly large" [Low,Confirmed] https://launchpad.net/bugs/185513
[12:09] <persia> DktrKranz: You might also want to check with YokoZar on that (who, despite the changelogs, is very active on that package, if not the primary maintainer)
[12:10] <DktrKranz> persia, thanks.
[12:23] <hellboy195> DktrKranz: today is saturday :P
[12:23] <DktrKranz> hellboy195, and alpha 5 is over
[12:24] <hellboy195> persia: already testet axiom with sid build?
[12:24] <hellboy195> DktrKranz: yeah. so you know what it means
[12:24] <persia> hellboy195: layer 21 of 23 complete
[12:25] <hellboy195> persia: here it stopps at 0 of 23 complete :)
[12:26] <persia> hellboy195: Yep.  I suspect that building the sid source on sid will succeed, which will be fairly frustrating.  I'm not familiar with building lisp from documentation, and then compiling it, which makes fixing this a large learning experience.
[12:27] <persia> I'm really not certain I'll find a solution, but I'm beginning to doubt that at least one of the changes is required.
[12:27] <hellboy195> persia: damn! And the debian maintainer ignores us -.-
[12:30] <persia> hellboy195: Hard to blame that, if we did something odd to break a perfectly working package.
[12:30] <hellboy195> persia: well -9ubuntu1 built fine under feisty so it's really strange
[12:31] <DktrKranz> hellboy195, which one?
[12:31] <persia> Yep.  I can build 20050901-10 in a sid chroot without any problems.  One of the build-dependencies is different somehow, which might need working around, or might be a bug there that needs fixing.
[12:31] <hellboy195> DktrKranz: axiom
[12:32] <persia> hellboy195: Lots of changes since feisty.  The FTBFS list changes for every release (both new failures and new successes)
[12:32] <hellboy195> persia: unfortunately
[12:33] <DktrKranz> hellboy195, is FTBFS log the same of the one from lpia?
[12:34] <polopolo> persia: about whatyou say 30 min ago, do I need to unpackage the source file in hello-debhelper-2.2?
[12:34] <hellboy195> DktrKranz: lpia log?
[12:34] <persia> polopolo: That might be the easiest thing to do to compare your efforts against the archive.  I didn't see any obvious differences, but I didn't run diff.
[12:34] <DktrKranz> hellboy195, https://edge.launchpad.net/ubuntu/+source/axiom/20050901-9ubuntu1/+build/522011
[12:35] <hellboy195> DktrKranz: yep
[12:35] <persia> DktrKranz: amd64 gets s different error.
[12:35] <DktrKranz> I'll try on i386 then
[12:36] <hellboy195> DktrKranz: you don't need to. We already did
[12:36] <DktrKranz> ah, ok.
[12:36] <hellboy195> DktrKranz: but you can check my beagle debdiff if you want ^^
[12:37] <DktrKranz> finish off wine package first
[12:37] <persia> DktrKranz: Essentially, sid source builds on sid, but hardy source doesn't build on hardy, (nor does sid source), and it doesn't appear to just be about bashisms in debian/rules.
[12:37] <hellboy195> DktrKranz: isn't it broken?
[12:38] <hellboy195> persia: and sid source doesn't build on hardy, not to forget. no this bashism is fixed in debian afaik
[12:38] <DktrKranz> persia, did you try to export SHELL=/bin/bash in rules? This way you can be sure no bashisms are involved
[12:38] <polopolo> persia: well, the package hello has no files, so what should I do then?
[12:39] <persia> DktrKranz: Haven't tried that: I just trusted the patch.
[12:39] <persia> hellboy195: Care to give that a shot?
[12:39] <DktrKranz> If it won't FTBFS, there are bashisms somewhere, a mass check with checkbashisms might help, then.
[12:39] <hellboy195> persia: np.
[12:41] <DktrKranz> I fear it's not that, though. No axiom here: http://tinyurl.com/3cmval
[12:42] <hellboy195> Yeah I wanted to do the merge and afaik the only remaining change is that with the build loop
[12:43]  * hellboy195 is now building axiom
[12:43] <joejaxx> :D
[12:43] <DktrKranz> hellboy195, you may want to run "debuild binary" in a hardy chroot to see if int/algebra/OUT.NRLIB/code.o is available somewhere or with a different name
[12:43] <geser> who is currently not building axiom here?
[12:44] <hellboy195> geser: ^^
[12:44]  * geser checks now Debian sid axiom with Debian sid gcl (on amd64)
[12:44] <hellboy195> DktrKranz: yeah. I'll try that when finished ..
[12:45] <hellboy195> DktrKranz: but you mean logging in pbuilder right?
[12:45] <DktrKranz> Yes
[12:45] <hellboy195> k
[12:48] <persia> geser: I just ran that, and it was fine.  I don't have an i386 sid available.  Do you?
[12:48] <geser> persia: I'm using a hardy pbuilder but I installed there the gcl amd64 deb from Debian sid (instead of the hardy one)
[12:49] <persia> Ah.  That would be a different (and more sensible) test.
[12:49] <geser> persia: my current guess is that gcl on hardy seems to be broken as it is still building
[12:50] <hellboy195> geser: amd64 gcl?
[12:50] <geser> the next question would then be: how do we fix gcl in hardy?
[12:50] <geser> hellboy195: yes
[12:50] <hellboy195> geser: and what about i386?
[12:51] <geser> didn't try it out yet
[12:51] <persia> hellboy195: Try a compilation with sid gcl to see if it helps
[12:51] <geser> I started with amd64 as the FTBFS happens there sooner (less time waiting)
[12:52] <joejaxx> anyone know of any security related software they want packaged? :)
[12:52] <hellboy195> geser: maybe we have luck and the problem is gcl with both i386 and amd64
[12:52] <persia> joejaxx: It's post-feature-freeze.  Surely there are some security related packages that have bugs, no?
[12:52] <joejaxx> persia: not for hardy :P
[12:52] <joejaxx> hardy + 1 :)
[12:53] <joejaxx> i can look at the buglist
[12:53] <joejaxx> though*
[12:54] <persia> joejaxx: That would be great.  Hardy is LTS, so the more bugs that can be fixed in the security packages now, the more secure the datacentres will be after release.
[12:54] <hellboy195> persia: but we can forget this thing with SHELL=/bin/bash ;)
[12:55] <persia> hellboy195: Are you sure we can drop that patch?  I thought we needed it for something (looking at rules again)
[12:55] <hellboy195> persia: I don't think there is any bashism laft
[12:55] <hellboy195> *left
[12:56] <persia> hellboy195: After looking again, I think I agree with you.
[12:56] <hellboy195> only the superfluous heartbeat loop
[12:56] <hellboy195> persia: so, how can I install i386 gcl from sid in hardy pbuilder?
[12:58] <persia> hellboy195: I've never used pbuilder, so this may be wrong, but I think you log in with pbuilder --login, install the gcl debs you download from sid, and then start the build.
[12:58] <hellboy195> persia: We'll truy it
[12:58] <hellboy195> *try
[12:58] <hellboy195> persia: what do you use instead of pbuilder?
[12:58] <persia> sbuild
[12:59] <hellboy195> persia: difference?
[13:00] <joejaxx> too bad there is not a "last touched" date for launchpad
[13:00] <joejaxx> for bugs
[13:00] <geser> hellboy195: the way persia told you is exactly what I've done here
[13:00] <persia> joejaxx: There is, it's just not shown in the summary.  Sort by "Recently changed".
[13:01] <hellboy195> geser: but you took the amd64 package?
[13:01] <geser> hellboy195: yes, as I test on amd64
[13:01] <persia> hellboy195: pbuilder stores chroots in tars, sbuild expects schroot to provide them (either they exist, or are LVM snapshots).  They have slightly different algorithms for calculating build-dependencies.  They have different hook interfaces.  Beyond that, I'm not sure.
[13:01] <hellboy195> geser: k, ~32 mb are heavy ^^
[13:02] <hellboy195> persia: so you can't say sbuild is *better*
[13:02] <joejaxx> lol
[13:02] <geser> hellboy195: the axiom source package is 40 MB
[13:02] <hellboy195> geser: yeah I know ^^. I mean gcl
[13:02] <persia> hellboy195: They are different.  Both are good.  The buildds use sbuild (but not the sbuild from the archives).
[13:02] <hellboy195> persia: k
[13:02] <joejaxx> persia: sbuild from upstream?
[13:03] <persia> joejaxx: Define upstream.
[13:03] <joejaxx> debian
[13:03] <joejaxx> in this case
[13:03] <persia> joejaxx: Which sbuild in Debian (there were three, last I checked)?
[13:03] <joejaxx> oh
[13:03] <persia> Also, no, a custom sbuild.
[13:03] <joejaxx> oh ok :)
[13:08] <hellboy195> geser: what's again the command to build the package inside pbuilder?
[13:09] <hellboy195> dpkg-buildpackage -b
[13:09] <hellboy195> ?
[13:11] <persia> hellboy195: That ought work, but debuild -b is less characters
[13:12] <hellboy195> persia: nvm. I'm too stupid to do that. I installed sid gcl and now wanted to install the axiom depencies and now I have broken packages -.-
[13:14]  * hellboy195 makes his 2nd try
[13:25] <RainCT> emgent: is turba2 2.1.7 a bug fix release or is there any other change too?
[13:28] <polopolo> Hello all, I have some .ex files in my debian folder, should I remove it or not?
[13:29] <RainCT> polopolo: if you don't need them, yes
[13:29] <polopolo> Buy when do I know if I don;t need them?
[13:33] <Iulian> polopolo: Can you rephrase please?
[13:34] <polopolo> (14:28:09) polopolo: Hello all, I have some .ex files in my debian folder, should I remove it or no
[13:35] <Iulian> polopolo: RainCT just answered.
[13:35] <polopolo> (14:29:46) polopolo: But when do I know if I don't need them?
[13:35] <polopolo> when = how
[13:36] <Iulian> You can remove them with rm *.ex and .EX
[13:36] <vorian> polopolo: you might find the watch.ex useful
[13:39] <RainCT> polopolo: well.. you should know that :P
[13:41] <polopolo> well ok
[13:42] <polopolo> And extreme tux racer is not avalible on ubuntu, and the upstram version is now 0.4-1, should I include the changelist of the upstram in the debian folder, or should I leave this?
[13:44] <hellboy195> polopolo: it actually *is* in hardy
[13:44] <hellboy195> polopolo: http://packages.ubuntu.com/hardy/extremetuxracer
[13:45] <polopolo> :P
[13:45] <polopolo> ok, but I wanna larn packageing, should I leave this?
[13:46] <hellboy195> polopolo: if you are learning and want to try it then do it ;)
[13:49] <persia> polopolo: I'd suggest hunting bugs with the packaging tag to learn packaging, and comparing against the documentation.  Looking for mistakes in other packages is a great way to make sure you won't make them yourself.
[13:51] <polopolo> ok
[13:53] <polopolo> but feuture freeze is active, so it cannot be added on hardy, should I still upload it to REVU?
[13:53] <RainCT> polopolo: you can upload packages to REVU but they won't be actively reviewed
[13:54] <polopolo> but it will if the next version of ubuntu is ready to devolp?
[13:54] <RainCT> yes
[13:54] <RainCT> can a package be synced from Debian if it isn't through NEW yet?
[13:56] <persia> RainCT: No.  Debian NEW isn't publically available.  There are workarounds, but it's better to wait.
[13:57] <hellboy195> persia: compilling inside pbuilder is sooo slowly :(
[13:58] <persia> hellboy195: You picked the large, bootstrapping package.  Next time, go for something small, maybe a perl package so you can skip the compilation step :)
[13:58] <hellboy195> persia: argh! /me is happy to learn everybody something usefull ^^
[13:58] <hellboy195> *everyday
[14:00] <RainCT> persia: Okay, thanks, I'll ask motu-release if I cna do manual sync then.
[14:01] <persia> RainCT: Is it urgent?  Debian NEW doesn't typically take that long...
[14:02] <RainCT> persia: that's new to me then.. all my packages needed at least 2 weeks (right now I've one waiting there for over a month) :P
[14:04] <persia> RainCT: Well, you'll need an approved FFe for the NEW anyway.  May as well apply, and if granted, you can decide between -1 and -0ubuntu1 based on timing.
[14:07] <polopolo> Well, I found a package to do
[14:07] <polopolo> https://bugs.launchpad.net/ubuntu/+bug/194483
[14:07] <ubotu> Launchpad bug 194483 in ubuntu "[needs-packaging] Fotox" [Wishlist,Confirmed]
[14:08] <polopolo> but someone replied on it, should I change it or not?
[14:09] <hellboy195> persia: it's still compiling -.- but I suppose that at least the i386 gcl package is broken in hardy
[14:10] <persia> hellboy195: Excellent.  Next step is to figure out the variance, and what might cause it to be broken.  You may find trying to build in gutsy informative when determining the timing of the brokenness.
[14:11] <polopolo> persia = mentor of hellboy195?
[14:12] <hellboy195> polopolo: nope
[14:12] <persia> polopolo: Nope.  I just like to try to keep the record for volume of text in the channel :)
[14:12] <polopolo> ah
[14:14] <persia> polopolo: Regarding Fotox, as we're past feature freeze, I'd recommend looking to modify a package already in the archive, rather than creating a new one.
[14:14] <hellboy195> persia: so next step is it to build it in gutsy chroot?
[14:14] <persia> During each release cycle, we spend about 15 weeks on new features, and about 11 weeks on integration and bugfixing (this is the second of the 11).
[14:15] <persia> hellboy195: Might help to find out what happened, but checking the changelog might be a better next step, in case it is glaringly obvious.
[14:16]  * hellboy195 is noting everything down what persia says :)
[14:16]  * Hobbsee notes that she's done 4 release cycles.  wow.
[14:17] <hellboy195> Hobbsee: congratulation :)
[14:18] <hellboy195> persia: latest gcl in hardy is a sync!?
[14:18] <polopolo> persia: you mean that I should download a package form hardy, make it myself, and compare?
[14:20] <persia> polopolo: That would be a good learning exercise.  On the other hand, I'd recommend downloading a package that has a patch available for a bug (there are about 800 of those), and looking at how it is packaged.
[14:21] <persia> hellboy195: Does it need bash to build?  Maybe it didn't build correctly.  Maybe it is affected by something deeper in the stack.
[14:21] <polopolo> persia: ah, that way, ok, thank you
[14:21] <persia> polopolo: Once you have a rough understanding of how that package works, try applying the patch, and seeing if you can get it to work.
[14:22] <hellboy195> persia: axiom? I deleted the line with the BASH
[14:22] <persia> If you can apply the patch, and the patch actually fixes the bug, ask for an upload.  This way you don't have to learn it all at once, and can get started on working on Ubuntu while you learn.
[14:23] <persia> hellboy195: You said the last gcl was a sync.  If a sync has different behaviour, the builds are likely different.  The trick is to figure out why.  Common differences are related to bach, pkg-create-dbgsym, and similar differences in the basic build system.
[14:24] <geser> building the axiom from Debian sid with Debian sid gcl in a hardy pbuilder (amd64) works
[14:24] <hellboy195> persia: LP says it was a sync. How can I figure out these differences?
[14:24] <hellboy195> geser: i386 also
[14:24] <slicer> I found a bug in pulseaudio (moving input streams causes protocol errors), which I've fixed and sent a patch to the pulseaudio bug tracker. However, the issue will affect Hardy in a bad way if the fix is not included. Should I open a bug against the pulseaudio package and post the patch there as well?
[14:25] <persia> hellboy195: You can check the Debian build log and compare to the Ubuntu build log, but that only tells you so much.  You could compare the binary packages to make sure they have the same files, and see how they differ.  You could try compiling it locally to see if a recompile would fix it.  I'm sure you can think of some other tests once you get through those...
[14:26] <hellboy195> persia: we speak about gcl right?
[14:26] <persia> slicer: Please.  We're in featurefreeze, so not likely to get new upstream versions (although cherrypicking from upstream is common).  Having a local bug with a clear patch ought speed adoption.
[14:27] <persia> hellboy195: Yes.  From the experiments recently run, it looks like the FTBFS for axiom is caused by some difference in the gcl binaries (as they are the same source).
[14:27] <hellboy195> persia: I'll do my best
[14:27] <hellboy195> geser: are you on board? ^^
[14:28] <geser> hellboy195: I'm just trying to rebuild gcl and check if it perhaps helps
[14:29] <hellboy195> geser: k, so I'll differ the the packages
[14:35] <hellboy195> persia: geser : http://pastebin.com/m1fc7a1d0
[14:36] <persia> Hmmm..  What's in default.el?
[14:37] <hellboy195> persia: sec
[14:39] <slicer> About bug 194756 , should I also mark it Confirmed, seeing as I include a replicatable test-case and a patch to fix it, or should I leave that to the package maintainer?
[14:39] <ubotu> Launchpad bug 194756 in pulseaudio "Moving source-outputs causes protocol errors" [Undecided,New] https://launchpad.net/bugs/194756
[14:39] <persia> hellboy195: Also, given the different package size, it's worth checking the contents of files to see if they differ (unpack with dpkg -e and dpkg -x and take a look at diff -urN)
[14:39] <hellboy195> persia: k
[14:40] <persia> slicer: It's considered best practice to get someone else to confirm, rather than confirming it yourself.
[14:40] <hellboy195> persia: in default.el is : ;;;BEGIN gcl addition
[14:40] <hellboy195> (autoload 'dbl "dbl" "Make a debugger to run lisp, maxima and or gdb in" t)
[14:40] <hellboy195> ;;;END gcl addition
[14:40] <slicer> persia: That actually makes a lot of sense :) Thanks.
[14:41] <persia> slicer: Might ask for a volunteer in #ubuntu-bugs.  I think there is a testing channel, but I can never remember the name: maybe #ubuntu-testers?
[14:47] <geser> persia: do you have a sid chroot for test-building?
[14:47]  * pochu does
[14:47] <persia> geser: Yes, but only for amd64
[14:47]  * persia defers to pochu, who is currently in a more productive timezone
[14:48] <hellboy195> persia: http://pastebin.com/m5c6e95c2
[14:48] <geser> persia or pochu: could one of you run python-babel through it? /me wonders if the FTBFS also appears on sid or only in hardy
[14:49]  * geser hates FTBFS on arch:all packages synced from Debian
[14:49] <persia> hellboy195: That's your list of things to investigate
[14:49] <persia> geser: Far too common, unfortunately :(
[14:49] <pochu> geser: geser 0.9.1-2 or -4?
[14:51] <hellboy195> persia: debian has debconf (>= 1.2.0) and ubuntu has debconf (>= 0.5) | debconf-2.0, debconf (>= 1.2.0) <-- isn't that wired?
[14:52] <geser> pochu: -4 please
[14:52] <pochu> geser: sure, sec
[14:52] <geser> pochu: I didn't catch that sid has an other revision but -4 fails to build in hardy too
[14:52] <pochu> ok
[14:53] <geser> it fails here with: sed: can't read ./debian/python-babel/usr/bin/pybabel: No such file or directory
[14:55] <hellboy195> persia: or does the build-deps don't matter?
[14:56] <persia> hellboy195: They may or may not matter, depending on the rationale for the changes and mechanism by which the changes were determined.  Also, I'm not likely to have any more insights for the next few hours: while you will do better in general asking questions to the channel, this is especially true for the near future.
[14:57] <hellboy195> persia: k, and good night ;)
[15:00] <pochu> geser: same here. And there's no usr/bin, only usr/lib/python2.[45]
[15:00] <pochu> geser: do you want the log?
[15:01] <geser> pochu: no need for the log, but you could file a bug in the Debian BTS about it :)
[15:03] <geser> pochu: thanks, so I'll need to find out what changed in the build-depends and how to fix it
[15:05] <pochu> geser: filling
[15:05] <geser> perhaps it gets fixed in time for hardy
[15:09] <pochu> geser: just remove that sed line for Ubuntu. we don't care about it, as we have python2.5 as the default one
[15:13] <INOSHU> Hey
[15:13] <INOSHU> I got banned from the official Ubuntu channel a while back (they haven't cleared it yet), so I was wondering if you guys could help with a question...
[15:14] <LjL> INOSHU: no, they can't
[15:14] <INOSHU> oh
[15:14] <INOSHU> what channel should i ask in then?
[15:15] <LjL> INOSHU: you should have avoided getting banned.
[15:15] <INOSHU> -_-"
[15:15] <INOSHU> srysly
[15:25] <ScottK2> LjL: Good answer.
[15:26] <geser> pochu: and what about the missing usr/bin/pybabel?
[15:28] <ScottK2> RainCT: I was looking at the 0.26 source package in Hardy.  I'm on i386, but that's not relevant since I was reviewing the source.
[15:29] <ScottK2> RainCT: You folks who've been doing ubuntu-dev-tools need to be more careful about what you upload IMO.  Particulalry if you don't want your inbox filled.
[15:32] <RainCT> heh
[15:33] <RainCT> yes, some stuff I had lying around in the same directory slipped in :/
[15:35] <ScottK2> RainCT: I have yet to have pbuilder-dist work for me.  One thing or another always seems to fail.
[15:36] <ScottK2> RainCT: That's IMO an important script.  Please take a very careful look at it and test it through.
[15:36] <james_w> ScottK: what are your problems? It works for some people.
[15:37] <ScottK2> james_w: It's always something.  Currently it's that the arch argument is required.
[15:37] <ScottK2> The original script upon which it's based in 33 lines.  It works pretty well, but the current one seems to be far to complex.
[15:39] <RainCT> ScottK2: it shouldn't be requiring any architecture if you are on i386.. :S
[15:39] <ScottK2> RainCT: Yes.  That's my point, but it did.
[15:39] <RainCT> actually, iirc it shouldn't even work if you give it an arch
[15:40] <ScottK2> Which is wrong too.
[15:41] <RainCT> ScottK2: can you build for other architectures with i386? o_O
[15:43] <ScottK2> RainCT: Dunno.  Haven't tried.  Get the thing working at least with the default options please.
[15:44]  * RainCT is looking at it
[15:44] <james_w> ScottK2: http://paste.ubuntu.com/4918/ <- does that work?
[15:45] <RainCT> ScottK2: what does   dpkg-architecture -qDEB_HOST_ARCH; lsb_release -cs   say (just to be sure that there's not a problem with those)?
[15:46] <ScottK2> james_w: I really don't have time to test it right now.  I'm not an ubuntu-dev-tools developer.  I'm a user.  pbuilder-dist sid create needs to work.
[15:46] <ScottK2> RainCT: Looking
[15:47] <james_w> ScottK2: well, just making a complaint that it doesn't work isn't that helpful. If you want it to work then file bugs when it doesn't.
[15:48] <ScottK2> james_w: I did.
[15:48] <ScottK2> james_w: Please go look at the bugs against the package before getting all acussatory.
[15:49] <james_w> ScottK2: my apologies, found it now.
[15:50] <ScottK2> james_w: IMO the quality level of ubuntu-dev-tools is very low.  It wasn't that hard to find 10 valid bugs to file last night.
[15:50] <ScottK2> It's not a very big package.
[15:53] <ScottK2> RainCT: i386 and hardy
[15:58] <pochu> geser: I didn't think python-babel is meant to be executed by itself, but rather to be a module which is imported by other apps to manage l10n
[15:58] <pochu> geser: I may be wrong, of course
[15:59] <pochu> geser: and I am
[15:59] <pochu> pybabel - command line tool for working with message catalogs <--- from debian/pybabel.1
[16:01] <geser> pochu: usr/bin/pybabel looks autogenerated to me, so the question is why doesn't it get generated anymore
[16:03] <geser> unfortunately there aren't any build logs at debian, so one can't check what did change in the used packages
[16:03] <geser> when compared to the last successful build
[16:05] <ScottK2> There wouldn't be for an arch all package since they require at least one arch be uploaded as binary
[16:06] <geser> yes, that's exactly the problem
[16:11]  * RainCT is completely reviewing pbuilder-dist to see if he finally finds the stupid problems..
[16:18] <ScottK> RainCT: You might also consider adding Laserjock's original script to ubuntu-dev-tools and call it pbuilder-dist-simple or some such.
[16:19] <ScottK> It doesn't do all the things yours does, but for the simple use case it just works.
[16:20] <RainCT> ok
[16:21] <ScottK> Looks like the world just changed for emacs users: http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg02140.html
[16:24] <pochu> geser: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467188
[16:24] <ubotu> Debian bug 467188 in python-babel "FTBFS in a clean chroot" [Serious,Open]
[16:26] <james_w> RainCT: did you see that I added a patch to ScottK's bug that fixed his issue for me.
[16:38] <RainCT> james_w: yes :)
[16:38] <jeromeg> jdong: hello, are you here ?
[16:38] <slicer> If I have an updated version of a package that's already been through revu and uploaded to hardy, I should still just dput the updated package to revu, right?
[16:38] <RainCT> slicer: are there only packaging changes or is it a new version?
[16:38] <james_w> RainCT: cool, just checking, didn't want to duplicate work.
[16:39] <slicer> RainCT: There's a new version (bugfixes only), and quite a few updates to the packaging.
[16:40] <RainCT> slicer: ok, file a bug in LP then and upload the .diff.gz
[16:40] <slicer> RainCT: .. To the bug or to revu?
[16:40] <RainCT> slicer: to the bug
[16:41] <slicer> RainCT: Rgr that.
[16:41] <jdong> jeromeg: yeah, kind of, sup?
[16:42] <jeromeg> jdong: I would like to advocate a pdigin source change backport :)
[16:42] <jdong> jeromeg: oh sure done. Now you didn't think it would be that easy, would you?
[16:43] <jdong> jeromeg: I saw you were testing plugins a while back. Did they all work?
[16:43] <jeromeg> jdong: I just added the result of my testing to the bug report
[16:43] <jeromeg> they all worked
[16:43] <jdong> jeromeg: all without rebuilding?
[16:43] <jeromeg> jdong: of course :)
[16:43] <slicer> RainCT: What about the new .orig.tar.gz?
[16:44] <jdong> jeromeg: ok, that's very promising and shows that there's a good potential for this backport to work out
[16:44] <RainCT> slicer: it's not necessary, if the package contains a debian/watch or get-orig-source rule
[16:44] <jeromeg> jdong: there is just one that I can't find out how it works
[16:44] <jeromeg> it doesn't show up in the plugin list
[16:44] <jdong> jeromeg: from this point, I'd like you to collect at least 5 testers to confirm the same information from your PPA packages
[16:45] <jeromeg> jdong: I've already got one, but he can only speak french
[16:45] <jeromeg> he helped me this afternoon to review all plugins
[16:45] <jeromeg> without any issues
[16:45] <slicer> RainCT: There's a watchfile. I'll make the formal sourceforge release once I've got all the binaries compiled (and submit the bug after that).
[16:45] <jeromeg> for me it works fine on two computers
[16:46] <jdong> jeromeg: alright, please add that info to the bug report and await more testing
[16:47] <jeromeg> jdong: ok great, btw ScottK uploaded brasero
[16:48] <slicer> RainCT: Uh. I'm a bit lost though; against what package do I actually file the bug? Do you have an example bug I could peek at? Would make this easier :)
[16:49] <RainCT> slicer: the package you want to upgrade. in the description just write that it's a bug fix only release and a copy of the changelog (both Debian and upstream), and then attach the .diff.gz in a comment
[16:49] <RainCT> and subscribe ubuntu-universe-sponsors to it
[16:53] <slicer> RainCT: Ah, thanks :)
[16:56] <jdong> jeromeg: yep I saw that
[16:58] <jeromeg> jdong: got to go now, thank you for your input on pidgin
[16:58] <jdong> jeromeg: thank you for taking on the backport
[16:58] <jeromeg> jdong: well, it has to be done :)
[17:23] <tbf> jdong: saw you in the motumedia team. could you review gnome-lirc-properties at revu? we (fluendo, openismus, sistpoty) know that hardy is in feature freeze, but believe that an easy to use remote control configuration panel would be very useful for hardy
[17:23] <jdong> tbf: sorry, I am quite busy today, so if it is an urgent revu I'd suggest you ask someone else
[17:24] <tbf> jdong: ok
[17:31] <tbf> siretart, Fujitsu, sharms, TheMuso, crimsun_: broadcast to the remaining motumedia team: does one of you have time to review gnome-lirc-properties at revu? we (fluendo, openismus, sistpoty) really 'd like to see an easy to use remote control configuration panel in hardy - despite feature freeze
[17:32] <tbf> call it bad communication between openismus and fluendo, that we didn't upload a package to revu before feb 14th :-/
[17:34] <tbf> well or mainly bad communication between me and murrayc_
[18:44] <blueyed> RainCT: why has default of "section" for update-maintainer been changed to "universe" (instead of "main"), if there's no output from rmadison?
[18:45] <RainCT> blueyed: because there are more package in universe than main. or was there any reason to have it like that?
[18:45] <blueyed> RainCT: I though "no section output" => "main"? and this is true e.g. for gparted.
[18:46] <RainCT> blueyed: oh, will revert it then. thanks!
[18:47] <blueyed> RainCT: thanks. Luke fixed it btw, bug 179533
[18:47] <ubotu> Launchpad bug 179533 in ubuntu-dev-tools "update-maintainer does not get section automatically anymore" [Undecided,Fix released] https://launchpad.net/bugs/179533
[18:48] <RainCT> blueyed: oh, I see
[18:52] <RainCT> blueyed: Sorry for that. I'll probably upload a new version tomorrow once I finish some changes in pbuilder-dist and 404main.
[18:55] <blueyed> RainCT: great. Can you then merge the latest changes from my requestsync branch, too?
[18:56] <RainCT> sure, merge url?
[18:56] <blueyed> RainCT: http://bazaar.launchpad.net/~blueyed/ubuntu-dev-tools/request-sync-edit
[18:56] <RainCT> blueyed: have you fixed that new bug from Scott?
[18:56] <blueyed> RainCT: you had merged it for some bugfix, but I've committed some more.
[18:56] <blueyed> RainCT: what do you mean?
[18:57] <RainCT> ah no that was another script
[18:57] <RainCT> nvm :)
[18:57] <ScottK> No, I had a bug on requestsync too
[18:57] <ScottK> Two actually
[18:58] <blueyed> ScottK: I see now, e.g. bug 194615
[18:58] <ubotu> Launchpad bug 194615 in ubuntu-dev-tools "requestsync aborts if file isn't changed during editing" [Undecided,New] https://launchpad.net/bugs/194615
[18:59] <ScottK> That's one.  The other was asking if you want to edit the bug without showing you the text (which you need to know if you want to edit it).
[18:59] <blueyed> ScottK: while implementing this logic I somehow forgot that you're asked to confirm the request anyway at the end, so I might just drop it.
[19:01] <blueyed> ScottK: re the other bug.. do you think it should work as follows, if there's no need to edit: display the request for confirmation, but allow to edit?
[19:02] <ScottK> blueyed: I'm not sure of your design intent.
[19:02] <ScottK> Do you want to allow editing of all bugs or just ones for packages with Ubuntu changes to be dropped?
[19:04] <blueyed> ScottK: all bugs, so that you can e.g. say which other bugs it would fix. Currently, you'll get asked if you want to edit (if it is not necessary). The change would be, that this gets asked together with the confirmation at the end (and so the request has been displayed already).
[19:05] <ScottK> I would:
[19:05] <ScottK> 1.  Ask for why the Ubuntu changes can be dropped, if applicable.
[19:05] <ScottK> 2. Display the bug.
[19:05] <ScottK> 3. Ask if editing is wanted.
[19:06] <ScottK> 4. Ask if they want to send it.
[19:08] <blueyed> ScottK: one of the reasons for using sensible-editor was that you can better write about why the changes can be dropped, therefore this should start the editor already (and it makes no sense to ask later again about editing)
[19:08] <ScottK> blueyed: OK.  That makes sense
[19:09] <blueyed> so it should be: if editing is required, start the editor. If not, display the bug and ask to send or edit it.
[19:10] <ScottK> blueyed: I think send and edit are two different questions.
[19:10] <blueyed> after having used the editor, the bug would be displayed again and the user would get asked for editing/sending again.
[19:11] <ScottK> I suppose.  I'd keep the text about ctrl c to cancel.
[19:11] <blueyed> ok. I'll look into it tomorrow.. have to go now.
[19:11] <blueyed> RainCT: I ping you for merging again tomorrow..
[19:12] <RainCT> blueyed: okay
[19:13] <tbf> hmm.... seems saturday is a really bad time of week to ask for reviews... especially during feature freeze :-(
[19:24] <slicer> RainCT: Sorry to keep bugging you, but would bug 194836 be the correct method for the updating of the package?
[19:24] <ubotu> Launchpad bug 194836 in mumble "Update to 1.1.3 (bugfixes)" [Undecided,New] https://launchpad.net/bugs/194836
[19:25] <slicer> I'd like this to be right, so I can follow the same procedure in the future :)
[19:26] <RainCT> slicer: I think yes.
[19:27] <slicer> RainCT: Excellent :) Thanks for your help.
[19:33] <RainCT> tbf: I'm looking at it ;)
[19:34] <tbf> RainCT: woohoo! thanks alot! :-D
[19:36] <joejaxx> :)
[19:37] <soto> http://pastebin.ca/915393
[19:37] <soto> ^ What's the problem in my pdebuild?
[19:45] <slicer> soto: If I'm to guess, it's that you depend on libcurl4-openssl-dev which is a virtual package?
[19:46] <soto> slicer: Is that a problem?
[19:46] <ScottK> soto: It is.
[19:46] <slicer> soto: If I remember correctly, you're not allowed to depend on virtual packages.
[19:46] <geser> soto: which release?
[19:46] <slicer> soto: You should depend on package-which-provides-virtual | virtual
[19:46] <ScottK> An example of what to do is
[19:46] <ScottK> postfix | mail-transport-agent
[19:46] <soto> geser: Building on Feisty
[19:47] <geser> soto: libcurl4-openssl-dev exists only in gutsy and hardy
[19:47] <ScottK> Always pick one real package and then or the dependency with the virtual package.
[19:47] <soto> geser: Argh.
[19:47] <geser> soto: feisty has libcurl3-openssl-dev
[19:47] <ScottK> Of course if the virtual package doesn't exist at all, that's another big problem.
[19:48] <soto> geser: I don't know if the package requires libcurl4.
[19:49] <soto> Can I add Gutsy repos to pbuilder mirror list and it will fetch them automatically?
[19:51] <mirrado> Hi
[19:52] <mirrado> Can I ask packaging questions here?
[19:52] <ScottK> Yes
[19:53] <mirrado> I'm trying to package a game, but the source doesn't have a changelog.
[19:53] <jpatrick> mirrado: you should send an email upstream asking to add one
[19:54] <mirrado> I tried to generate one myself based on the svn log, but the log e very poor.
[19:55] <mirrado> I will follow your suggestion and send a request to upstream. Thanks.
[19:56] <geser> afaik there is now requirement for a upstream changelog
[19:56] <geser> s/now/no/
[19:57] <jpatrick> geser: (GNU standard I believe)
[19:57] <ScottK> Personally, I'm suspicious of package quality if it's not present.
[20:00] <soto> So can I easily backport a package from Gutsy to Feisty if there are many dependencies in Gutsy?
[20:00] <soto> So how can I ...
[20:03] <slicer> soto: Backport the dependencies as well. .. Though that's not necesarrily "easy".
[20:03] <soto> slicer: No it isn't :(
[20:24] <RainCT> tbf: commented
[20:26] <tbf> RainCT: thanks alot
[20:37] <asbin> hi oerybody
[20:37] <asbin> hi everybody
[20:39] <asbin> I recently add 2 packages in ubuntu (universe), and openned bug in launchpad for this - bug filled in the changelog of the packages (with "LP:") ... should I close the bugs myself or is there an automatic bot thaht will close it ?
[20:40] <tbf> RainCT: seems the correct priority setting would be "optional"?
[20:41] <RainCT> tbf: do you think the package is only likely to be useful if the user already knows what it is or has specialized requirements, or it breaks some other important package?
[20:42] <tbf> RainCT: no. "extra" just was there 'cause murray used that setting
[20:42] <RainCT> tbf: then it is optional :)
[20:43] <james_w> asbin: that is done automatically.
[20:44] <asbin> james_w: ok thanks !
[20:44] <asbin> ja
[20:44] <asbin> james_w: that's what I though
[20:48] <tbf> RainCT: ok, points 0 to 5 resolved. remaining issue: the lintian warning. well, the package is prepared for localized strings, but we do not have message catalogs at this point
[20:49] <tbf> RainCT: focus was on getting the code done properly for hardy, instead of advertisement and such, to get translations
[20:50] <tbf> RainCT: is see three possibe solutions: a) ignore the warning - b) temporarily hack arround the warning in debian/rules - c) quickly do a poor german message catalog
[20:51] <RainCT> tbf: I'd go with b for now
[20:52] <RainCT> tbf: just add a rmdir to a "binary-install/<package name>::" target in debian/rules
[20:56] <tbf> RainCT: "binary-install", not just "install"?
[20:57] <RainCT> tbf: yes. well, I'm not sure if it would make a difference in this package, but just to be sure.
[20:58] <tbf> RainCT: ok.
[20:58] <RainCT> tbf: the stuff in binary-install is one of the latest to be called
[21:00] <tbf> RainCT: hmm.... also using rmdir, instead of rm -r seems quite smart. that way debuild barfs, as soon as we've got message catalogs :-)
[21:20] <tbf> RainCT: hmm... seems revu refuses my updated package, 'cause "0ubuntu1" is smaller than "0ubuntu2"?
[21:35] <tbf> hmm.... either i am blind, or revu is slow... or some friendly "leprechaun" helped out...
[21:36] <tbf> revu has "0ubuntu1" now
[21:36] <RainCT> heh
[21:44] <siretart> ScottK: should bug #190645 have been marked 'confirmed' now?
[21:44] <ubotu> Launchpad bug 190645 in emacs-snapshot "please sync emacs-snapshot version 20080215-1" [Undecided,New] https://launchpad.net/bugs/190645
[22:03] <RainCT> tbf: (if you said anything, I didn't receive it..)
[22:04] <jpatrick> RainCT: he didn't say anything
[22:04] <tbf> RainCT: no, didn't say something, after telling your, that revu has my corrected package now
[22:06] <tbf> RainCT: ah, now i see, why i didn't see the new upload... most certainly looked at http://revu.tauware.de/details.py?upid=2104, instead of http://revu.tauware.de/details.py?package=gnome-lirc-properties
[22:08] <RainCT> tbf: ok. so, you didn't get my comments for this update or?
[22:08] <tbf> RainCT: no, didn't get any comments
[22:10]  * slangasek wonders if anyone here is interested in helping to triage release-critical FTBFS bugs this fine Friday afternoon
[22:11] <jpatrick> Friday?
[22:12] <slangasek> oh, Saturday
[22:12] <slangasek> whichever day it is :-)
[22:12] <RainCT> tbf: well, commented in REVU. I'll advocate it when that is fixed :)
[22:13] <RainCT> heh
[22:15] <tbf> RainCT: cool! just quickly cleaning dishes.
[22:49] <geser> slangasek: is there a list of those release-critical FTBFS bugs?
[22:50] <slangasek> geser: https://bugs.launchpad.net/ubuntu/hardy/+bugs
[22:50] <slangasek> infinity has been quite enthusiastic about reporting them, and at least half of them are no longer valid
[22:51] <hellboy195> geser: gcl rebuild done?
[22:52] <geser> hellboy195: yes, but it didn't improve the situation. Building axiom with this rebuild gcl failed again.
[22:53] <hellboy195> geser: k, I'm diffing the binaries. the only difference I noticed so far are slightly different build-deps
[22:56] <soto> How can I find out what package provides the virtual dependency libcurl4-openssl-dev
[22:56] <slangasek> apt-cache showpkg libcurl4-openssl-dev
[22:57] <soto> slangasek: I look at reverse depends?
[22:57] <slangasek> soto: if it's a virtual package, you should see a list of reverse-provides
[22:58] <slangasek> but, evidently it's not a virtual package, but rather a real one
[22:59] <soto> Pbuilder keeps telling me its virtual
[23:00] <slangasek> soto: that really means that pbuilder can't find it and as a result /assumes/ it's virtual
[23:00] <geser> soto: I guess because the dummy package pbuilder creates mentions it
[23:00] <slangasek> so you have a pbuilder configuration bug, or you're trying to build a package against a suite which didn't include libcurl4-openssl-dev
[23:00] <geser> soto: try if your feisty backport works if you change it to libcurl3-openssl-dev
[23:00] <soto> geser: Alright
[23:00] <hellboy195> geser: so would you mind try that out or doesn't this matter?
[23:01] <slangasek> right, if this is feisty, libcurl4-openssl-dev won't work because feisty was pre-libcurl4
[23:01] <soto> slangasek: Yeah, I tried to backport libcurl4-openssl-dev. It's in my local repo, I don't know why pbuilder wouldn't find it
[23:02] <slangasek> oh
[23:02] <slangasek> in that case, I assume it's because pbuilder is an ornery rattrap :)
[23:02] <geser> hellboy195: try out what? hardy and sid have the same gcl source package
[23:03] <hellboy195> geser: yeah but hardy has very slightly different build deps
[23:03] <geser> soto: does pbuilder know of your local repo?
[23:03] <geser> hellboy195: how can that be if the source package got synced?
[23:03] <soto> geser: Yeah, I believe it worked for another dependency
[23:04] <hellboy195> geser: THAT's the question
[23:04] <hellboy195> geser: http://pastebin.com/m5c6e95c2
[23:05] <geser> hellboy195: ah, you compared the debs not the source package
[23:06] <hellboy195> geser: I said binaries!? but the build depends should however the same or?
[23:06] <tbf> RainCT: hmm... how can i overwrite the current "0ubuntu1" package?
[23:06] <tbf> RainCT: i get "553 Could not create file." on calling dput
[23:06] <geser> hellboy195: line 10 and 14 are Depends not Build-Depends
[23:08] <hellboy195> geser: ah true. sry. but they also should be the same I suppose ^^
[23:08] <geser> hellboy195: the .dsc file is unmodified as you can see if you check the signature on it
[23:09] <tbf> ah, "dput -f"?
[23:09] <hellboy195> geser: that means?
[23:09] <geser> hellboy195: it looks like only the order got changed (due new dpkg) and the versioned dependency in libc6 is slight different
[23:10] <geser> hellboy195: both Debian and Ubuntu have the same source package
[23:10] <slangasek> geser: so, only academic interest in the list of FTBFS bugs? :-)
[23:10] <hellboy195> geser: so again we have no idea whats wrong with gcl?
[23:10] <RainCT> tbf: yes
[23:11] <RainCT> tbf: well, if you need the -f you should get another error message. dunno what this one means
[23:11] <geser> slangasek: I'm already chasing FTBFS (and fixing them where possible) for weeks
[23:11] <slangasek> geser: ok :)
[23:12] <tbf> RainCT: hmm... faq says "just wait 5 minutes on 553".... and indeed: this worked!
[23:13] <hellboy195> hi jono, our special guest :)
[23:13] <geser> slangasek: http://members.ping.de/~mb/hardy_build_status.html is the list I work with
[23:14] <slangasek> geser: ooh, that's a pretty list :)
[23:14] <tbf> RainCT: i've set the XSBC-Original-Maintainer field to "Openismus Package Team <packages@openismus.com>", but still have to wait for murray to setup this list
[23:14] <slangasek> geser: how often does it update? I see a package in main on there that I've fixed yesterday :)
[23:14] <geser> slangasek: cdrdao and workrave are waiting on a no-change rebuild of libgnomeuimm2.6 to pick up the correct dependency on libgnomemm-2.6-1c2
[23:15] <RainCT> tbf: okay, he has some time until you get a second advocate and the freeze exception
[23:15] <geser> slangasek: currently only manually as it was on qa.ubuntuwire.com which is still down
[23:15] <slangasek> (har, is there a version without hppa?)
[23:15] <geser> slangasek: I should setup a new cronjob for it
[23:15] <geser> slangasek: currently not
[23:16] <slangasek> geser: ah, doh.  what's taking qa.ubuntuwire.com so long to get back?  It took the release weather report page with it too :/
[23:16] <geser> slangasek: but I could produce one if there is interest
[23:16] <nixternal> my lord, the quality of the bug reports I have seen the past 24 hours is just horrible
[23:16] <hellboy195> geser is the FTBFS hunter
[23:16] <slangasek> geser: given that hppa accounts for > 50% of the items on there and largely require hppa porting, it could be nice
[23:17] <geser> slangasek: imbrandon is a SPOF for *.ubuntuwire.com and we are waiting on him currently
[23:17] <slangasek> geser: yeah, I'd already seen cdrdao and workrave by way of http://people.ubuntu.com/~ubuntu-archive/testing-ports/hardy_outdate.html, and that's on my todo list
[23:18] <geser> I asked already seb128 for the no-change upload but that was during the alpha freeze
[23:18] <tbf> RainCT: thanks alot for your help
[23:19] <slangasek> heh, no-change rebuilds for FTBFS bugs are still legitimate during an alpha freeze... :)
[23:20] <RainCT> tbf: you're welcome :)
[23:20] <geser> slangasek: it is a no-change upload of libgnomeuimm2.6 to fix the dependency conflict when installing libgnomeuimm-2.6-dev
[23:20] <slangasek> yep
[23:21] <RainCT> in what package is the gnome clock?
[23:21] <RainCT> gnome-applets?
[23:22] <tbf> RainCT: or panel
[23:22] <RainCT> tbf: true, thanks
[23:23] <RainCT> wow, gnome-panel has a lot of bug contacts
[23:23] <RainCT> :P
[23:23] <hellboy195> RainCT: well, gnome rocks ^^
[23:24] <RainCT> also true :)
[23:29] <jeromeg> slangasek: hello
[23:29] <jeromeg> the backport of tk8.5 to gutsy has been built 5 days ago, and it isn't released yet, how can that be ?
[23:30] <jeromeg> https://launchpad.net/ubuntu/gutsy/+source/tk8.5/8.5.0-3~gutsy1 shows it built
[23:30] <soto> What is the procedure for a package request on Launchpad? Prefix the title with RFP?
[23:31] <soto> Or [needs-packaging]?
[23:32] <jeromeg> soto: the later
[23:33] <slangasek> jeromeg: hi
[23:33] <slangasek> presumably, that no one has looked at the gutsy-backports queue in that time
[23:33] <soto> jeromeg: With square brackets as I wrote it?
[23:33] <jeromeg> soto: yep, that's ok
[23:34] <RainCT> tbf: advocated :)
[23:34] <jeromeg> slangasek: it's strange because tcl that was emrged at the same time got in, which means that we have only half of the tcl/tk couple in
[23:34] <jeromeg> slangasek: s/emrget/backported
[23:34] <slangasek> jeromeg: yes, there's not very good support for letting archive admins know when there are new packages in the backports binary NEW queues ready to be looked at, so your ping about it is helpful and I'm pushing them through now :)
[23:35] <jeromeg> slangasek: thank you very much !
[23:41] <hellboy195> is norsetto always absent on weekend?
[23:46] <RainCT> good night