[00:10] 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] sistpoty: looks like Edgy shipped with an unstable release (1.1.8), but I don't know of such situation [00:22] pochu: ok [00:25] 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] (assuming FFe approval) [00:26] persia: we are already in sync ;) [00:27] persia: and Rhonda uploads the same day the wesnoth team makes a new release (he contributes upstream I think) [00:27] pochu: That's why I ask. I was hoping Ubuntu wouldn't be in advance when the release happens :) [00:27] persia: any hints, to ack or rej the FFe? [00:27] and the Maintainer is a wesnoth developer iirc [00:28] 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] (oh, and 1.3.18 is an RC, although this is not clear from the versioning) [00:28] that's in the bug report :) [00:29] 13 development releases, 3 beta releases and one RC so far [00:29] 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] and the changes in the RC are really small === wolfger_ is now known as wolfger === _stefan_ is now known as sistpoty [00:44] 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] pochu: slomo: Thanks! That's a great step forward towards having MIDI work. [00:54] persia: thanks to you for packaging wildmidi ;) [00:54] persia: did you see the TODO in the changelog? ;-) [00:54] pochu: Actually, slomo deserves more credit than I: I just wrapped upstream in CDBS. [00:55] persia: you both deserve it, and you both have it [00:56] 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] persia: and you ITP'ed it and are the maintainer, which is great too [00:56] ScottK: is there any reason bug 184614 is set fix committed? [00:56] 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] persia: perhaps "grep x-bzip ext/bz2/gstbz2dec.c" is helpful [00:59] does anyone know this make error: [build-stamp] Error 2 ? [01:00] Legendario: that by itself doesn't tell you what the error was [01:00] 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] 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] 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] pochu: Or am I looking at a much more invasive and general issue than that implied by your TODO? [01:03] here it is the whole thing: http://paste.ubuntu-nl.org/57009/ [01:04] 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] persia, which folder are the kernel modules installed? [01:06] /lib/modules/$(uname -r) [01:06] Legendario: Typically /lib/modules/`uname -r` (or, used in a makefile, "/lib/modules/$(shell uname -r)/") [01:07] persia: no, you may be right. I didn't know midi was used for other things than midi sound files [01:09] 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] persia: oh, that's... really new to me :) [01:10] 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] 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] persia, let's see if this solves it [01:13] 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] persia, got the same error... do u have the any idea? [01:17] i am trying to pack this package: http://wiki.mediati.org/R5u870#Compiling [01:19] 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] ah... gnome feels so wrong *g* [01:20] sistpoty: :) [01:21] * sistpoty is still having troubles with gnome *g* [01:21] ls [01:23] :) [01:23] 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] jdong: I didn't set it that way. [01:24] ScottK: ok thanks, that's all I needed to know. [01:24] ScottK: btw what do you think about maintainer field, -backports vs -motu? [01:24] I personally don't care either way at this point [01:25] I'd say backports, particularly for a Main backport, but I wouldn't remunge it if it's already munged once. [01:25] ScottK: ok, then I think jeromeg's debdiff for brasero is good for sponsorship [01:26] K [01:27] ScottK: any particular status or process you'd like me to follow to communicate source-change backports? [01:27] V3nd3tt4: why do you want to edit the description? [01:27] jdong: Just subscribe me on the bugs I guess. [01:27] ScottK: sounds good :) [01:29] 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] 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] V3nd3tt4: then yes, you need to update debian/control{.in} and rebuild the package [01:30] pochu: thanks for your reply and sorry for my english and newbie question :P [01:30] persia: I closed it since we now have midi support... feel free to reopen it if you think it's an RFS [01:31] RFS? [01:31] err, RFP [01:31] ScottK: for source-change backports, would you like an existing ubuntu motu maintainer: field to be mangled, or left as-is? [01:31] (I'm leaning towards left as-is) [01:31] 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] lol [01:31] 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] pochu: of course [01:33] persia: hmm, I guess a 'clone' feature in Launchpad would be useful in this case [01:35] 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] heh [01:45] 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] ScottK: that would be hard to implement ;) [01:47] * ScottK wants. [01:47] Implementation details are left to the programmers. [01:49] 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] 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] What does J, K and L stand for? :) [01:51] pochu: intrepid+2, +2, and +3. [01:51] s/2/1/1 [01:51] persia: sound generation suite, as in something similar to Jokosher? [01:51] ah, ok [01:51] 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] 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] 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] heh, and it still won't help me play my keyboard w.o. practice *g* [01:56] 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] hi persia :) [02:02] * ScottK2 tries out the new send an attachment via email to LP feature ... [02:12] 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] https://help.ubuntu.com/community/UbuntuBackports#head-ef8cfa47259137092769be75f623d52e8f9ab352 [02:14] 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] 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] 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] 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] 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] ScottK2: What'd it eat? [02:19] jdong: I see your point. debian/changelog needs to have enough info to be sensible on it's own. [02:20] Fujitsu: The text of the file I attached is in the main bug, not attached. [02:20] That sounds ugly. [02:20] Yeah. Certainly violates the principal of least suprise. [02:21] Probably the approved design. [02:21] Probably. [02:21] Which bug? [02:21] so I couldn't attach a png icon by mail? [02:21] Excuse me if I'm a little grumpy about LP bugs. [02:22] 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] sistpoty: Lots of LP bits check MIME type. image/png likely wouldn't be pulled as text. [02:24] persia: Why would it pull any attachments in at all? [02:24] Stunningly bad design. [02:24] I wouldn't make any assumptions at all about it not sucking in a particular way. [02:25] Is the list of blacklisted attachments available anywhere? I can't find it. [02:25] 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] (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] Ah, it lists three categories on UsingMaloneEmail, but doesn't exactly say how they're determine. [02:26] 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] 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] Heya bddebian [02:28] persia: It'd be particularly nice if stuff like this was public pre-release, as it can't be tested on ege. [02:28] *edge [02:28] My d key is failing :( [02:28] 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] Well I've not had any trouble in a long time with any that were not developed in Redmond. [02:29] 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] I like Outlook's attachments. [02:29] TNEF FTW. [02:30] Heya gang [02:30] Hi ScottK [02:30] This one could have easily been tested on dogfood. [02:31] Does dogfood email? [02:31] Or accept email? [02:31] I can't imagine a more basic thing to test with this new feature. [02:31] Dunno, but it's the test site, right? [02:31] dogfood is largely for Soyuz testing, anyway. [02:31] Ah [02:31] 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] hi bddebian [02:31] Fujitsu: neither dogfood nor staging worked for me in feisty. I haven't tested since. [02:32] I know staging doesn't. [02:32] 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] Heya sistpoty [02:32] 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] 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] demo might, but it uses the prouction codebase. [02:32] persia: Did you see that survex got "fixed" in Debian though? [02:32] if i try to build with new.dsc working fine [02:32] and compile fine, but debdiff dont work [02:32] 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] 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] some idea? [02:32] 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] persia, some idea? :) [02:32] And yes, I saw your note about survex: brightened my whole day. [02:33] How do I stop the generated maintainer scripts from running ldconfig? [02:33] pochu: If it's just bugfix it doesn't need an ack. [02:33] ScottK2: actually, I must admit, that I'm quite ok with LP recently... imho, it was much worse earlier [02:33] ScottK2: it's for main :) [02:33] Ah [02:33] pochu: I'm not touching Main stuff that starts with a G. I know nothing near enough about it. [02:33] bddebian: Why don't you want to run ldconfig? [02:33] ScottK2: hehe [02:34] why debdiff introduce to my result.debdiff debian translation indtroduced? [02:34] persia: W: muine: postinst-has-useless-call-to-ldconfig [02:34] ScottK2: ok no worries. [02:34] 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] bddebian: Ah. Yes. I suspect you want the buildlog with DH_VERBOSE := 1 [02:35] (in other words, I don't know) [02:36] 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] sistpoty: This one I find their response inexplicable. https://bugs.launchpad.net/malone/+bug/137448 [02:36] Launchpad bug 137448 in malone "New UI is confusing and counter inuitive for changing affected package" [High,Confirmed] [02:36] 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] 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] It was faster and cleaner and generally more usable. [02:37] ScottK2: Was the content-disposition set properly on the bug you filed? [02:38] Fujitsu: What do you mean? [02:38] ScottK: The RFC822 header Content-Disposition: in your mail [02:38] ScottK2: LP is only meant to take the attachment as an attachment if it's not Content-Disposition: inline, but attachment. [02:39] Oh, I have the newpki patch on my local windows box [02:39] Content-Disposition: attachment; filename="diffstat.txt" [02:39] 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] ScottK2: OK, so it is YALPB. [02:39] Fujitsu: Yes it way [02:39] bddebian: It's the copy from your windows box that I was having trouble applying :( [02:40] persia: I know but at least I have it :-) [02:40] bddebian: It's also in the BTS :) [02:40] Oh, I actually remembered to submit it didn't I.. Heh [02:40] 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] WHOO it didn't FTBFS this time :) [02:42] jdong: Ship it. [02:42] (wow check out that confidence in my voice) [02:42] 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] jdong: If you haven't go look up what wikipedia says PPA stands for. [02:46] 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] ScottK2: amd64/i386/ppc are all fine, hppa FTBFS'es on half of the planet anyway... [02:48] Dep wait for IA64. [02:49] jdong: I commented in the bug. Please comment back. [02:53] ScottK2: btw, thanks for your excellent work at motu-release. I guess we might have lost control w.o. you by now! [02:53] what is the logic behind man pages numbers? [02:54] which number belogns to what [02:54] 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] nxvl: man man [02:54] ScottK2: well, I must admit that I've been procrastinating at work *g* [02:54] ;-) [02:54] ScottK2: there is explained? thnx [02:54] nxvl: Yes [02:56] ScottK2, one question: i was try to merge firebird2.0 and pbuilted fine, but debdiff include stupid .po* changes imported by debian [02:56] clean method to clean debdiff ? [02:56] good night everyone [02:56] good night sistpoty [02:57] ScottK2, http://thc.emanuele-gentili.com/~emgent/security_fix/a.debdiff [02:57] emgent: Generally you can edit those out of the debdiff, but it depends. [02:57] * ScottK2 looks [02:57] this is a debdiff, but include debian .po* [02:58] changelog: http://rafb.net/p/tAV6eo67.html [02:58] if i try to build with .dsc working fine (i have .deb) [02:58] but debdiff it's not cleaned. [02:59] some idea? [02:59] Edit the debdiff. [02:59] That's what I've always done. [03:00] i'm think to use filterdiff -x '*\.po*' a.debdiff > b.debdiff [03:00] Should work. [03:00] ok thanks [03:00] * ScottK2 just uses vim, but you pick your tools [03:00] heheh sure! [03:00] :P [03:02] ScottK; I'd encourage you to look at editdiff as a vim wrapper: it can help with the line number calculations, etc. [03:02] persia: Thanks. [03:02] In this particular case it's removing complete files from the diff, so it's pretty easy. [03:03] 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] HA! victory is mine. [03:06] I did get it to work :) [03:06] now I await victims^Wtesters [03:10] persia, ehehe [03:18] done i have two upload on hold :P [03:41] persia: I'm re-doing the patch by hand now. If it still doesn't work, I'm done.. :-( [03:43] 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] Yeah, I have no idea why it doesn't apply.. :-( [03:43] persia: Oh if you get bored I have a game debugging issue for you ;-P [03:45] 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] persia: I packaged up the new attal and finally got rpath to work but it keeps segfaulting on me :-( [03:49] bddebian: Excellent. That's the point I can actually find something. Is the new version in SVN? [03:50] persia: yes and also on mentors I think [03:52] 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] Sweet, thanks man [03:54] Any suggestions on a test case to crash it? [03:54] Start it. ;-) [03:54] omg impossible... [03:54] Actually I think as soon as I tried to open a scenario it barfed [03:55] if i pbuilt .dsc work fine, if i try to apply debdiff cleaned faild. [03:55] uhm.. [03:55] bddebian: That sounds like it won't be hard :) [03:57] how do I go about building a package for both gutsy and hardy? [03:57] into my ppa [03:58] jetsaredim: #launchpad is the place for PPA questions. [04:02] ScottK, problem persist [04:02] if i use new-ubuntu.dsc for build work fine, but debdiff give error on apply. [04:02] but i dont saw the problem, strange.. [04:03] emgent: Did you remove all the po files from the debdiff? [04:05] yep [04:05] http://launchpadlibrarian.net/12160087/hardy_firebird2.0_2.0.3.12981.ds1-5ubuntu1.debdiff [04:06] it's cleaned, same change by hand in firebird2.0 directory [04:06] but i pbuilt ubuntu-new.dsc work fine [04:06] if i try to apply this debdiff give me an error [04:06] very strage. [04:07] i worked on more merges but i dont saw this strage situation.. [04:08] if i dont solve this night, i will as to pitti monday [04:08] ScottK, you have some idea? [04:10] i think tht if someone upload by .changes there isnt problem [04:10] it's debdiff the true problem. [04:11] emgent: Why are the patches your debian/changelog says you removed in the debdiff? [04:11] it's conflict [04:11] i just remove coflict in debian/patches/series [04:12] according to keescook and Luca Falavigna [04:12] but i dont delete .patch [04:13] if you saw changelog explain well, edit is only in debian/patches/series [04:13] + * debian/patches/series [04:13] + - removed ubuntu-port-hppa.patch FTBFS and disable. [04:13] + - removed ubuntu-port-ia64.patch FTBFS and disable. [04:15] emgent@flybox:~/Ubuntu/Merges/firebird2.0$ ls /var/cache/pbuilder/result |grep firebird2.0 [04:15] firebird2.0_2.0.3.12981.ds1-5ubuntu1.diff.gz [04:15] firebird2.0_2.0.3.12981.ds1-5ubuntu1.dsc [04:15] firebird2.0_2.0.3.12981.ds1-5ubuntu1_i386.changes [04:15] firebird2.0_2.0.3.12981.ds1.orig.tar.gz [04:15] firebird2.0-classic_2.0.3.12981.ds1-5ubuntu1_i386.deb [04:15] firebird2.0-common_2.0.3.12981.ds1-5ubuntu1_i386.deb [04:15] firebird2.0-dev_2.0.3.12981.ds1-5ubuntu1_all.deb [04:15] firebird2.0-doc_2.0.3.12981.ds1-5ubuntu1_all.deb [04:15] firebird2.0-examples_2.0.3.12981.ds1-5ubuntu1_all.deb [04:15] firebird2.0-super_2.0.3.12981.ds1-5ubuntu1_i386.deb [04:15] emgent@flybox:~/Ubuntu/Merges/firebird2.0$ [04:15] (sorry for little flood) [04:18] i try to build it in my PPA [04:18] (too) [04:20] Accepted: [04:20] OK: firebird2.0_2.0.3.12981.ds1.orig.tar.gz [04:20] OK: firebird2.0_2.0.3.12981.ds1-5ubuntu1.diff.gz [04:20] OK: firebird2.0_2.0.3.12981.ds1-5ubuntu1.dsc [04:20] -> Component: main Section: misc [04:22] ScottK, some good idea? :P [04:23] Then your changelog is confusing me. I thought it meant you'd removed them. [04:24] removed conflict [04:24] in debian/patches/series [04:25] if you have little bit time try to merge firebird2.0 [04:25] i used grab_merge.sh [04:26] it's all ok when solve conflicts but debdiff that result isnt clean and dont work. [04:32] 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] persia, sure i saw that [04:33] anyway it's late (5.33 am) [04:33] i will work on this later :P === \sh is now known as \sh_away [04:46] persia, in PPA builted fine amd64 i386 lpia (saw mail now) :P [05:17] i want to try making debdiffs, but cant seem to find a good way to find 'bitesized' bugs, any help? [05:22] kdub: Have you tried searching for the bitesize tag? [05:23] i think my problem is that i dont know how to look for tags... :-[ [05:23] kdub: They should show on the left from https://bugs.launchpad.net/ubuntu/+bugs [05:24] ah. there we go thanks persia [05:27] * jdong grumbles about mono's svn taking 8 minutes to log [05:48] 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] Probably the QA team now that I think about it more. :) [06:56] Good morning! [08:18] Good morning. [08:30] Hi! [08:30] I'm trying to build a package, using "debuild -b" [08:30] but always fails stating: secret key not found. [08:31] I managed doing: debuild -b -k [08:31] is that ok ? [08:31] ERROR: http://paste.ubuntu.com/4914/ [08:32] 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] 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] I've updated the env variables: DEBEMAIL & DEBFULLNAME. [08:33] How do i update GPG Key to match UID ? [08:33] phoenix24: Do you have a comment for the matching identity on the GPG key? [08:34] Yes! comment => (phoenix24) [08:35] persia: what shall I reset it to ? [08:36] phoenix24: I think it's Name (comment), but I'm momentarily forgetting the appropriate gpg call to extract it. [08:37] gpg --edit-key ; adduid; add a new UID that includes just your name and email with no comment [08:38] That works too :) [08:39] Hah. Yes. It's `gpg --list-public-keys ` to find out what you have to match. [08:40] running `gpg --list-public-keys : gives uid Chaitanya Sharma (phoenix24) [08:41] 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] Works absolutely fine! [08:43] thanks persia slangasek !! === jscinoz is now known as OMGOMGOMGWTFKEKE === OMGOMGOMGWTFKEKE is now known as jscinoz [09:22] While doing a => bzr commit -m "* enable sh build.sh to build the .xpi" debian/rules [09:22] ERROR : bzr: ERROR: Path(s) are not versioned: debian/rules [09:23] phoenix24: bzr add debian/rules [09:24] Fujitsu, Does this commit to the Upstream ? or my local bzr repo ? [09:30] hi, is there a chance, that someone reviews http://revu.tauware.de/details.py?package=gnome-lirc-properties - despite the feature freeze? [09:31] a modern UI for configuring LIRC powered remote controls should be quite useful for Hardy - imho [09:31] https://code.fluendo.com/remotecontrol/trac/browser/trunk/help/C/figures [10:04] phoenix24: if you do bzr add and bzr commit -m .... then your local repo [10:05] joejaxx: thanks! [10:05] 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] kndgkdjfn [10:05] ok [10:05] s/hee\ than/then/g [10:06] phoenix24: you are most welcome [10:07] oy [10:27] How are tests supposed to be packaged? I'm seeing a variety of current practices. [10:28] db-keen: What sort of test? [10:31] persia: tests for a specific package [10:33] 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] phoenix24: it was cut off [10:34] bah [10:34] persia: * [10:34] persia: Tests to see if the user has a given piece of knowledge as part of an e [10:34] joejaxx: That's OK. The remainder may safely be deduced :) [10:34] btw good morning persia :D [10:34] persia: lol ;) [10:35] mostly code correctness [10:35] my apologies for being so vague [10:36] 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] 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] Err. autopkgtest. Sorry :) [10:40] gm persia! [10:40] 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] Launchpad bug 163603 in axiom "FTBFS: axiom_20050901-9ubuntu1 on hardy/i386" [Medium,Confirmed] https://launchpad.net/bugs/163603 [10:40] Launchpad bug 193649 in axiom "Merge axiom 20050901-10 from Debian(Unstable)" [Undecided,New] https://launchpad.net/bugs/193649 [10:41] 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] 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] 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] 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] 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] hellboy195: Sorry. Misread them. Does 193649 also fix 163603? [10:44] thanks for your help [10:45] 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] 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] 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] 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] 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] hellboy195: Ah. What did you discover when you were looking for code.o in the build tree? [10:50] 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] 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]