[00:03] hi [00:31] is there any reason to prefer dput over dupload or vice versa? [01:08] evening [01:08] morning [01:27] hi folks [01:30] Heya sistpoty [01:30] hi bddebian [01:31] Is it too late to request syncs for Hardy? [01:31] bddebian: we're not yet in a feature freeze, so anything may still go in [01:32] at least until 14th, then FeatureFreeze applies [01:35] bi-daily package badgering: if any MOTU feels like reviewing my package, I'd appreciate it: http://revu.tauware.de/details.py?package=mixxx [01:35] :) [01:36] asantoni: give me a few minutes, then I'll take a look [01:36] thanks sistpoty! [01:37] asantoni: mixxx is already inthe repositories. Is this an new upstream, or just a patch? [01:37] Yes, new upstream [01:39] asantoni: The best way to get that approved and uploaded is to attach the diff.gz to a bug and subscribe ubuntu-universe-sponsors, rather than pushing to REVU. [01:39] asantoni: There are also some other bugs for that package (https://launchpad.net/ubuntu/+source/mixxx/+bugs): maybe some of them are fixed by your new upload? [01:39] Yes, most of those should be fixed [01:39] (if not all) [01:40] * persia seeks a second advocate for http://revu.ubuntuwire.com/details.py?package=whysynth as step 3 in the plan to enable gstreamer-midi for hardy [01:40] persia: What do I open the bug against? [01:40] asantoni: Would you mind testing, and adding (LP: #nnnnnn) in your changelog for the bugs that will be closed? [01:40] (mixxx in Launchpad? or the mixxx package in Launchpad?) [01:41] asantoni: The bug should be opened against the mixxx ubuntu package in launchpad. [01:41] persia: They were fixed in upstream... is that still relevant for the ubuntu changelog? [01:41] Ok, thanks [01:42] asantoni: Only in excerpted fashion, and to help identify when and how the bugs were fixed. You might add extra indented lines under the New Upstream Release indicating which specific things were fixed, and which bugs those close. [01:43] persia: ok... I'll try... This is rather awkward though, because we've fixed like 100 bugs that are in our SourceForge tracker [01:43] Also, mixxx in hardy is currently 1.6.0~beta1-1ubuntu2: it looks to me like your changelog lost sync with development at some point. Perhaps it's worth a check? [01:44] and we do packaging for Windows and OS X as well (so it adds up) [01:44] persia: I pushed the changes that were in that hardy version into upstream [01:44] persia: since you advocated extremetuxrace, I assume that you've checked the orig.tar.gz? (then I won't do the check again *g*) [01:45] sistpoty: Err. I'm guilty today. Let me check again... [01:45] sistpoty: Yep. orig.tar.gz is clean. [01:45] persia: heh, np... I'll just download the orig.tar again [01:45] ah thanks [01:45] * persia checked the last version, but forgot to doublecheck the md5sum for the updated version [01:45] ah crap, I can't attach the diff.gz, I'm at my parents for the weekend :/ [01:46] I've just linked to it [01:46] asantoni: Perhaps a different question: is there a newer version than 1.6.0 beta1 out? If not, we've that already in hardy, so perhaps you don't need to update? [01:46] persia: Yes, we just released beta2 [01:47] and we absolutely DO need the update - beta1 has some critical stability issues [01:47] (I really don't want to screw our users over) [01:47] asantoni: Completely understood. [01:47] thanks [01:47] does anyone know how I include a file with a space into debian/docs? [01:48] (I didn't even intend for beta1 to get into Universe. It was packaged by someone non-official in Debian, and got slurped up through that) [01:48] I tried \ before the space and 's around the name, both failed [01:48] Anyone have a some time to review the updated mixxx, take care of LP bug cleanup, and submit a diff.gz to help asantoni? [01:50] rhpot1991_laptop: though I'm no perl expert (dh_installdocs is perl), I guess just putting the name with spaces in there might eventually do it [01:51] tried that too actually [01:51] though you give me an idea [01:54] persia: so is something like this correct? http://pastebin.ca/898098 [01:54] and will Launchpad automatically close those bugs for me then? [01:56] asantoni: iirc you'll need a # before the bug number (as in LP: #number) [01:57] asantoni: if you build the source package (i.e. generate a changes file), the changes file should have s.th. like "launchpad-bugs-fixed: number, number, .." in there [01:57] asantoni: Looking at some of these bugs, it appears they were closed long ago. In general, I'd prefer something like "Updated playlist handling (LP: #122476)", but in this case, you might just want to ignore some of them (e.g. 75037 may not even be a bug in mixxx). [01:58] I feel like I may not be able to figure all of this out [01:59] In a perfect world, I just want to say "New upstream release" , and close the bugs that I know this fixes, lol [01:59] ok, so I'll look at the changes files though to make sure this changelog works [02:00] asantoni: Thanks for trying. If you get stuck, just ask here for someone to take over bug #190589 to get it in. [02:00] Launchpad bug 190589 in mixxx "New upstream release (in REVU)" [Undecided,New] https://launchpad.net/bugs/190589 [02:00] ok, thank you very much persia, I'll try my best [02:13] Right. Let's see if this only-somewhat-uuuuurgly multi-arch alsa-plugins builds right. [02:49] It's alive! It's _alive_! [02:50] hm? [02:50] self-modifying code? *g* [02:51] I can now build lib32asound2-plugins in a less than totally evil way. [02:51] excellent! [02:51] And if I had access to any of the other archs, it should build lib64asound2-plugins, too. [02:53] Oh, I suppose I should build it under Sid, too. [02:54] Pulseaudio support for wine is now mine! [02:54] RAOF: maybe ubuntuwire has an arch you could need? (not too sure for which arches we have servers, I only know of sparky, which shouldn't be used for building, because then revu goes down *g*) [02:55] * RAOF actually *looks* at debian/control. [02:56] So, I should be able to test the build at least; it'll build lib64foo on i386, powerpc sparc and s390 [02:59] * RAOF checks whether he's got an i386 sid build environment [03:04] asantoni: sorry for the delay, I'm just looking at the .diff.gz... seems like you dropped changelog entries from the current hardy version in debian/changelog [03:08] asantoni: also, please describe your changes in debian/changelog (e.g. what patches you dropped, what build-dependencies you updated etc.) [03:22] I think I've finally figured it out. I think MOTU generally has a better sense of humor than Debian. :-) [03:22] heh [03:22] I'm serious, it's kind of sad. [03:24] bddebian: btw.: why aren't you a DD yet, seeing so many qa or games uploads from you? [03:24] (then I could ask you for sponsoring debian uploads *g*) [03:24] heh [03:24] I dunno man, I'm starting to think I should withdraw my app [03:24] And go back strictly to Ubuntu [03:25] bddebian: No point withdrawing the application. Even if you focus on Ubuntu, DD can be useful. [03:26] strange enough, I'm even further below in the nm list than bddebian, and feel guilty, since I didn't do anything but bug forwarding since quite some time [03:26] I don't know, maybe it's because I'm some "evil American" or something, I just don't get the "culture". Everyone takes everything so damn seriously, yet pukes like are can spout nothing but useless drivel all day long.. [03:26] (maybe the caveats of FIFO *g*) [03:27] s/are/ari/ [03:28] heh, /me is reminded by some of Reinhard's postings to debian-devel, which are much less forgiving (dunno the right word) than to ubuntu mailing lists *g* [03:30] asantoni: can you run lintian on the resulting debs? should give you some hints on what still needs fixing [03:34] good evening. i would like to see if someone could gimme some help [03:34] I got up expecting some Ubuntu mail, and all I got were notifications of spam in my blog :( [03:34] sistpoty: Farther up the list how? [03:34] how to pack a package without a make file? [03:34] bddebian: https://nm.debian.org/nmlist.php [03:35] Legendario: Just build the way upstream builds [03:35] Legendario> What build system does it use? [03:36] sistpoty: Isn't that just alphabetical? [03:36] when, i don't know if i understood the question, but the tar.bz2 file the author offers has already a binary in it... [03:36] bddebian: doesn't seem like it... at least not to my known alphabet *g* [03:36] Well I never looked that closely :-) [03:37] heh [03:37] Legendario: It shouldn't, that's bad form. You should build the package from "source" [03:38] Of course you can just mv/cp the files around [03:38] bddebian, i know, but it only offer an rpm package and one like i've told you [03:39] bddebian, but when i ask pbuilder to build it, it says no make file was found. [03:39] Kick upstream :-) [03:40] Legendario: does it claim to be gpl? [03:40] bddebian, sure [03:40] http://checkgmail.sourceforge.net/#download [03:40] * Fujitsu notes that's already packaged. [03:40] checkgmail | 1.13-1ubuntu1 | http://archive.ubuntu.com hardy/universe Packages [03:40] checkgmail | 1.13-1ubuntu1 | http://archive.ubuntu.com hardy/universe Sources [03:41] Yeah, I thought that sounded familiar [03:41] Further, upstream is very active with https://launchpad.net/checkgmail [03:41] Err. Maybe not any more. Used to be, but that only has 1.12 and hardy has 1.13 [03:42] yeah, i want to make a 1.13 gutsy version to place on my PPA [03:42] Legendario: If it works in gutsy, why not just request a backport? [03:44] Heya LaserJock [03:44] persia, how is it? [03:44] hi LaserJock [03:44] !backports | Legendario [03:44] Legendario: If new updated Ubuntu packages are built for an application, then they may go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging [03:45] hi all [03:46] persia, it's because the actual 1.12 version on gutsy is not working anymore [03:47] hi | LaserJock [03:47] Legendario: That would be a bug, and likely sufficient for an SRU. Have you reported a bug? If not, please do so: this ought be fixed for everyone, rather than just in a PPA. [03:47] !sru [03:47] Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates [03:52] how do I find the standards-version via the commandline again for the control file? [03:54] firefly2442: zless /usr/share/doc/debian-policy/changelog.gz | head -1 | cut -f 2 -d'(' | cut -f 1 -d ')' [03:54] (assuming, you have an up to date hardy installed) [03:55] I'm in gutsy [03:56] firefly2442: then look at http://www.debian.org/doc/debian-policy/, version (at the bottom of the page) [03:57] thanks [03:59] sistpoty: apt-cache show debian-policy | grep Version: ? [03:59] LaserJock: heh, my command is much longer, and hence more geeky *g* [03:59] I'll give you that [04:00] persia, ok. thanks for the explanation. I got to understand all the stuff about the backports and sru. But one thing still intriges me: I have downloaded the orig.tar.bz2 file on from the hardy repository and it is exclaty the same one i have and it does not contain the source. I contais the same binary on it [04:00] how could it be packed? [04:02] Legendario: if it is gpl, then it must contain the sources (or include a document which points to the sources) [04:04] Legendario: it's a perl script, there is no difference between source and executable [04:07] squentin, so if i uncomment the perl line on the debian/rules script i should be able to package it? [04:09] Legendario: you just have to copy the perl file to its right place, dh_perl will just calculate perl dependencies, it won't install anything [04:10] how do I create these "postinst and prerm" from scratch? [04:11] squentin, what place would it supposed to be? [04:11] /usr/bin/ I think [04:13] Ah well this cold/flu is finally catching up to me, gnight folks [04:15] Legendario: btw, there is already a package in ubuntu, so you should start from it [04:17] squentin, i have downloaded it. Is that what you mean? === bmk789_ is now known as bmk789 [04:20] Legendario: well, the latest is already in hardy [04:22] squentin, well i know it now, and there is already a bug asking to backport it. [Bug #189795] [04:22] Launchpad bug 189795 in checkgmail "[Backport] CheckGmail 1.13-1ubuntu1 to Gutsy" [Undecided,New] https://launchpad.net/bugs/189795 [04:23] but now i am only interested on learning how to pack something that does not have a make file just like this package [04:23] well you can look at this package to see how it's done [04:24] Legendario: basically it's just a copy the files in debian/rules. however for some languages, there exist specific policies (e.g. python, perl) [04:25] Legendario: do you know of the scale of the changes required to fix Gutsy's version? [04:25] a make file is not magical, instead of calling the makefile, you just copy the needed files [04:25] how DARE you! [04:25] a makefile is magic! [04:25] 100% magic. [04:25] jdong, i guess the new 1.13 version corrects it [04:25] :) [04:25] automake is.... err.... that really subpar harry potter novel. [04:26] the 2nd one. [04:26] Legendario: well... yeah... but how big were teh changes that actually corrected it? [04:26] the package is simple, there is only a few file, only the perl file is important [04:26] Legendario: I'd like to consider it for the -updates repo if at all possible [04:27] this is something i can't tell you. But i consider yours a good idea [04:28] it doesn't work at all with the 0.12 version ? [04:28] 1.12 [04:29] squentin, no. it stopped to work about a month ago [04:30] sistpoty, but how does it go on the rules file itself? [04:30] squentin, it used to work very well until then [04:31] sounds like a good reason to put it in updates [04:31] Legendario: debian/rules is just a makefile, which has a few specific targets. basically, the binary target must ensure that a complete package falls out [04:32] Legendario: to do so, e.g. debhelper can be used (there are various dh_* calls, that make creating a .deb easier) [04:33] Legendario: usually you install everything that should go into the deb package in an install rule in there (and could do a cp there) [04:34] Legendario: which of course must be aligned to the debhelper calls, that build the binary (not too sure which dh_ call it is, but one expects all files to install under debian/ [04:34] (imo it was dh_installdeb) [04:35] sistpoty, what does imo mean...? [04:35] hm... where should I start... maybe we'll look at the current hardy package, ok? [04:36] imo=In my opinion === santiago-ve is now known as foursixnine [04:37] Legendario: if you look at debian/rules there, binary depends on binary-indep, which depends on install [04:38] Legendario: so install will basically install all files that should be part of the debian package inside debian/checkgmail (relative from the top source dir of the package) [04:39] Legendario: then later (in the binary-indep target), there are the debhelper commands, to generate a .deb from what's in debian/checkgmail [04:40] Legendario: there's even a cp command in install, to just put a file to the right directory [04:40] Legendario: for each debhelper (dh_*) command, you can look at the manpage what it does [04:44] Please review http://revu.tauware.de/details.py?package=sadms [04:45] sistpoty, is it too different if i try with the cdbs? [04:45] Legendario: cdbs will basically only have rules which call debhelper under the hood [04:46] Legendario: which hides some abstraction, but limits your flexibility [04:46] under the hood. heh i like that [04:46] Legendario: the problem here is, that a SRU should impose *minimal* changes [04:46] Legendario: so changing from debhelper to cdbs is a no go for an SRU [04:47] Aloha: That looks like an entire comprehensive collection of stuff. Might it not be a good idea to break it down into several binary packages? [04:48] persia, what do you mean? [04:48] Legendario: the best try for an sru, is to look which minimal changes are needed of the source, and to apply these... you should be able to explain every changed line [04:49] Aloha: There seem to be daemons, pam bits, guis, etc. Seems like a lot of different things in a single package. On the other hand, maybe that's the right way to do it (I'm not an expert when it comes to those things). [04:49] (otherwise it wouldn't be a valid sru, but maybe things changed nowadays) [04:49] No, it's still minimal changes preferred. [04:49] heh [04:49] persia, thats the way upstream put it together. [04:50] persia, they have the most odd build system [04:50] Aloha: The oddities of the build system, and the nature of the included docs is what made me think breaking it into a number of smaller binary packages (from one source package) might be best. === asac_ is now known as asac [04:52] sistpoty, i guess i am not the best person to tell u the reason "for every changed line" [04:53] i do no programing.... ;-( [04:54] i am just a computer enthusiastic who wants to contribute with the community by making some basic packaging and increasing his knowledge a little bit... [04:57] Legendario: there's still the option to request a backport... jdong should now the procedure ;) [04:58] but in this case of packaging scripts, i am complitely lost [04:58] sistpoty: well, I'd like for *someone* to try investigating it as a SRU first [04:58] sistpoty: at least figure out what upstream did exactly to fix the problem [04:58] sistpoty: considering the current package is basically USELESS, I think we can argue even for a partly invasive SRU. [04:58] where "invasive" refers to the package's own codebase of course [04:59] jdong: I guess motu-sru should decide on what's appropriate ;) [04:59] SRU should be minimal, but minimal to do the job may be large. [05:00] ScottK: agreed [05:00] On Thursday we SRU'ed clamav from 0.88.2 to 0.92 in Dapper because there was no other way. [05:00] err ... Friday [05:01] right. I'm curious about what the fix for this entails. It bugs me when the supported repo version of the package is entirely useless. [05:01] jdong: what package is this? [05:02] LaserJock: checkgmail [05:02] bug 189795 [05:02] Launchpad bug 189795 in checkgmail "[Backport] CheckGmail 1.13-1ubuntu1 to Gutsy" [Undecided,New] https://launchpad.net/bugs/189795 [05:02] classic gmail-changed-api-so-scraper-doesn't-work. [05:02] * sistpoty just wanted to express that I don't want to make a decision if a backport or sru is right *g* [05:02] I took a quick look at the diff, there is lot of small changes, most of them probably unrelated to the fix [05:04] sistpoty: so you're dragging me into this? :D [05:04] jdong: sure... or anyone else wanting to jump in :P [05:04] if it's a fairly clean patch I think an SRU would most likely be appropriate, if it's gonna be useless it's pretty low risk to attempt a fix [05:05] LaserJock: right, and I doubt anything that is involved with the fix can blow up any other chunk of universe either. [05:06] At this point, my thinking is, if checkgmail can't check gmail, it can't get much worse. [05:06] :-) [05:06] Is there some program to access Gmail directly without using POP3/IMAP? [05:06] (Apart from a web browser :p) [05:06] persia: whysynth rejected, sorry [05:07] * persia goes to investigate why, and considers fixing it directly [05:07] persia: changing source license in packaging [05:07] (didn't check further than that though) [05:08] sistpoty: Upstream doesn't want to release a new version right now, but has tracked down all the patch contributors and gotten them to agree to the PD dedication. Any suggestions? Without this, midi won't work in hardy again. [05:08] LucidFox: this thing I believe scrapes basically html gmail [05:09] LucidFox: but other than that, there is no other Gmail API publically published [05:09] persia: update debian/copyright with pointers instead, maybe even include mail messages in there [05:09] Ok, someone help me here [05:09] :( [05:09] sistpoty: Makes sense. I'll fix that. No other issues? [05:09] I've got a workflow problem with this DEB thing [05:09] jdong: I think it gets it from the atom feed. [05:09] asantoni: Where are you? [05:09] persia: as I wrote, I stop checking then.. but I can do a more thorough check if you want [05:10] persia: ah, ok, that sounds much more reasonable :) [05:10] We've got targets in our SCONS setup to build packages for every platform [05:10] (Windows, OS X, and Ubuntu) [05:10] every time we do a release, I update our Ubuntu package, which we host on our own site [05:10] sistpoty: If you would. I'll sort out the licensing, but I'm very interested in getting this in for hardy so that we can undisable the gstreamer-midi build. [05:10] so we have our own "debian" directory that sits in our source tree, which contains our own changelog [05:11] persia: sure, will do [05:11] sistpoty: Thanks. [05:11] persia: I won't do a complete license check then ;) [05:11] so now I'm trying to figure out what the best way to deal with having to merge the universe package's changelog with my own [05:12] all of the patches to our package in universe have been pushed upstream [05:12] sistpoty: I think the only issue is with the patches: I looked at the other files. Upstream shipped them without any licensing information. I'll review again, carefully, before uploading (or getting vemon to upload) a new candidate. [05:12] persia: thanks [05:12] but I guess it matters to you guys that the changelog be kept intact (I can understand that) [05:13] asantoni: imo your (upstream-wise) changelog and the ubuntu changelog are two different things... maybe a branch could help? [05:14] sistpoty: hmmm, maybe [05:14] asantoni: Officially, upstreams are encouraged not to host a debian/ directory. Of course, this can make it awkward to create Ubuntu packages external to the repositories. I'd suggest tracking a separate branch (as sistpoty suggests), and merging. Maybe pushing the packaging for mixxx into a Vcs could help. [05:14] persia: yeah, it's just too awkward [05:14] persia: What do you mean by pushing the packaging into a VCS? [05:14] (it's already part of our build system, but that's why we need to have our own debian directory) [05:15] the thing that really kills me is that people don't push their patches upstream to us [05:15] we don't have it nearly as bad as other projects though, so I should hold my tongue [05:15] i gotta go now guys. [05:16] asantoni: Hmm. I was suggesting moving the debian/ directory to somewhere non-upstream, making it accessible to Ubuntu developers (LP is good for this), and then sharing from this. For getting the patches back, it's a little harder. [05:17] asantoni: technically, it's actually that debian has created a fork, and ubuntu has created a fork of that fork. however debian realigns (rebases?) every file not under debian/* to the new upstream version.. and ubuntu tries to rebase everything to the new debian fork if possible [05:17] persia: any specific ideas for where this debian directory should go? I've never seen this problem addressed before, but it's making this impossible to streamline [05:17] (I think it'd be a great idea for you Ubuntu guys as well as our dev team to be able to modify it somewhere) [05:17] The general recommendation is to work with a maintainer to ensure that the latest versions are available. There could likely be better coordination between Ubuntu and Debian, but I'd suggest coordinating with the Debian maintainer to seek things up to date, and then syncing Ubuntu from Debian. [05:19] Does anyone have a good example of a Vcs managed package for asantoni to review as a model? [05:19] persia: Yes, I haven't been in contact with Free Ekanayaka (Debian) maintainer... I should though [05:19] I thought it was Paul Brossier. Likely my mistake. [05:19] it used to be [05:20] at some time in the past [05:20] but on Debian the package was unmaintained for at least the last two years [05:20] Free just kind of showed up out of the blue recently, and has never been in contact with us [05:20] Ah. The "used to be" is a common cause of the beginning of confusion. If Free is taking over, that's the best way to keep things up to date. Free tends to be very good about making things work for both Debian and Ubuntu. [05:21] Ok, I'll write him an email right now to try to sort this out [05:22] asantoni: Thanks a lot. If it takes a while, feel free to come back here, and we'll try to sort you. The goal is to find a process that works well in the future, but maybe this time shortcuts would not be inappropriate. [05:23] no, thank you persia - you MOTU have a generous amount of patience, and I appreciate your help. :) [05:30] persia: more comments to whysynth [05:30] sistpoty: Thank you. [05:30] np [05:31] persia: in general, it looks pretty good :) [05:31] sistpoty: SONAME is so that when gstreamer-midi gets built against it, we can track transitions sanely. Maybe it belongs in /usr/lib? [05:31] persia: it's a plugin for gstreamer, right? [05:32] sistpoty: whysynth is a DSSI plugin. gstreamer can build against it, so that gstreamer-midi calls out to whysynth to render sounds. [05:33] persia: does gstream link against it then? or will it dlopen it? [05:33] +er [05:33] * persia looks into the gstreamer-midi source to try to answer that [05:34] persia: if it will just dlopen (my guess for a plugin), /usr/lib/ should be right, (even if it has a SONAME) [05:35] otherwise (to link against it), there must be some headers to include (of course very ugly workarounds to define the headers -- basically what dlopen does exists) [05:38] * Hobbsee test out gweled [05:38] sistpoty: Nevermind. Thanks for making me check. I confused wildmidi with whysynth for some reason. It's dlopen(), but I need to package something else in a hurry :) [05:39] heh, /me just remembered a different dssi-plugin from very long ago which seemed to also get dlopen'ed *g* [05:39] yay, it works [05:40] Hobbsee: ? [05:41] Hobbsee: music as well? [05:41] persia: yeah [05:41] oh, cool... btw.: will there be a gstreamer-sid plugin as well (listening to 8bit sound the whole night) [05:42] :D [05:42] * persia cheers effie_jayx for clearing all the bugs from such a lonely package [05:42] gahhh, Free made the Debian package use our old icon :S [05:42] sistpoty: Not on my list of things to do by Wednesday. Feel free to add it if you have time :) [05:42] heh [05:42] asantoni: patches to the BTS are generally welcome. Upstream .desktop files even moreso. [05:43] heh, we do have an upstream .desktop file [05:43] which is even more confusing [05:44] asantoni: So the upstream .desktop file is being patched to use the old icon? Very odd. Maybe submitting a 32x32 xpm for the menu file would help. [05:44] persia: I think he patched the debian/mixxx.desktop [05:44] so it appears we have two upstream mixxx.desktop files, which neither of us noticed before [05:44] lol [05:45] * ScottK notes torque is now looking for a second advocate. [05:45] Ah. That's one of the arguments against upstream debian/ :) [05:45] haha [05:45] :) [05:45] point taken [05:45] any hints on how I should tell our rules file to use the mixxx.desktop file in our "src" directory? [05:46] * squentin wonders if someone will review/sponsor bug #156886 before the feature freeze (it's just a simple update) [05:46] Launchpad bug 156886 in libgtk2-trayicon-perl "Transparency not working with Gtk2::TrayIcon" [Low,Confirmed] https://launchpad.net/bugs/156886 [05:47] squentin: Without looking at the bug, that doesn't sound like something that needs to be done before FF. [05:47] asantoni: Just install it in /usr/share/applications from your normal build system, and remove it from debian/rules [05:47] persia: aha, we already install that there! :) [05:48] squentin: That's exactly the sort of bug which we try to address post-feature freeze. No rush for the deadline, and feel free to fix more like that later in the month and all through March. [05:48] so out it goes from the debian/rules [05:48] asantoni: You may also want to delete debian/mixxx.desktop to avoid future confusion. [05:49] ok, just though it would be easier to get in before the FF, it's basically an upgrade to the latest upstream version [05:49] will do [05:51] squentin: Ah. If that bug is solved by the new upstream, then yes, it is easier to get it in soon. The right groups are subscribed, so you've a good chance. [05:51] damn, danw is already breaking... [05:51] dawn even [05:52] * sistpoty is off to bed [05:52] gn8 everyone [05:52] * persia thought sistpoty was traveling to be up at this hour [05:52] good night! [05:53] persia: ok thanks [05:54] * ScottK advocates clipper (looking for #2) and heads to bed. [05:54] Is "diff.gz not identical after binary build and clean" a valid objection on REVU? [05:55] It's certainly an odd behaviour. It should be the same. Probably worth determining the cause: it may just be that the diff.gz on REVU is dirty, but the packaging is acceptable. [05:56] persia: torque and clipper are both packages that I think we want (even if they need a little cleanup after FF). Please have a look and see if you can manage to advocate either. [05:57] * ScottK going to bed really now. [05:57] ScottK: OK. Any chance you could look at libini4j-java and libnb-platform7-java? Last two pieces before netbeans can be pushed. [05:58] persia: Not tonight. Perhaps tomorrow or Monday. [05:58] ScottK: Thanks. [05:59] minghua: If you really want a versioned conflict between falconpl and falcon, wouldn't it be easier to just upload a patched version? [06:00] persia: He's not on right now.. [06:00] Good night. [06:00] ScottK: Yes, and hasn't been whilst sending email :) good night. [06:30] persia: as I'm working on updating all this debian directory stuff, it's becoming much more clear that having it in a separate repository that's accessible to package maintainers would save us a lot of hassle [06:31] asantoni: Check with Free, but I suspect http://svn.debian.org/wsvn/demudi is likely the right place for that. [06:33] persia: ah, I see... I wish this sort of stuff was communicated better (a fault of the process perhaps) [06:34] asantoni: Mostly a lack of documentation. FOSS tends to accumulate developers rather than UI specialists or documentation people :( [06:34] haha, that I cannot deny :) [06:34] I'll keep that in mind [06:36] asantoni: In this case, unless there is objection from one of the involved parties, I'd think the best workflow would be for your team to have access to the alioth SVN repo, and for Ubuntu to sync from Debian (and interested Ubuntu people to coordination with the Debian Multimedia Team to work in the same SVN). [06:36] persia: yes, I think that's reasonable [06:37] in the interest of getting Mixxx 1.6.0beta2 into universe before the freeze, I may have to forgo efforts to that end for a bit though [06:38] asantoni: Right. I'd suggest you first contact Free, and if you can get it there, we pull a sync. If not, maybe someone here can help you get it it. Try catching warp10 for the update, if nobody else. [06:39] ok, thanks for the tips [06:43] Good morning [06:44] warp10: Good morning. asantoni is here representing mixxx upstream, and looking for a bit of help integrating the latest release. Do you have some time to help with that? [06:44] (or am I confused by reading too many changelogs today?) [06:45] Heya persia! Sure, I have some time for asantoni's issue. [06:45] Hi, could a MOTU please have a look at my package http://revu.tauware.de/details.py?package=libtuxcap. It's ready for advocation, thanks! [06:46] warp10: I'm just trying to sort out and streamline our packaging process a bit more at the moment [06:46] I'm going to upload one more attempt at the mixxx package hopefully soon [06:47] asantoni: great! so you uploaded mixx on revu alread? [06:47] warp10: yes, twice [06:48] warp10: I've just fixed the things sistpoty pointed out in the comments [06:48] lintian (on my machine) says I botched one last thing though: [06:48] W: mixxx source: newer-standards-version 3.7.3 (current is 3.7.2) [06:49] but it takes about 30 mins to rebuild the package on my machine, and it's getting late (I need to sleep fairly soon) [06:50] asantoni: don't care too much of that warning. latest standards version is 3.7.3 and linda is not updated (lintian should not raise any warning about that) [06:50] warp10: ah, ok, perhaps this package will be good then (I'm uploading as we speak) [06:51] asantoni: if lintian and linda don't show anything else, and you addressed all sistpoty comments, looks like you are close to get an advocacy! :) [06:53] warp10: thank you, updated package is uploaded: http://revu.tauware.de/details.py?package=mixxx [06:53] (launchpad bug #190589) [06:53] Launchpad bug 190589 in mixxx "New upstream release (in REVU)" [Undecided,New] https://launchpad.net/bugs/190589 [06:54] asantoni: you should update the bug report on launchpad [06:54] warp10: the diff.gz? [06:54] asantoni: assign it to yourself, and set status to "in progress" [06:57] warp10: done, thanks [06:57] asantoni: great. Just the keep Launchpad up-to-date... [06:57] warp10: ok, will do [06:57] I need to head to bed now though [06:57] but the latest upload is there, if anyone has time to review it [06:58] thanks again for all of your hard work! [06:58] good night! [06:58] asantoni: Thank you for helping to improve Ubuntu! :) [06:59] what is the width limit for a manpage? [07:00] What causes cannot change ownership of `debian/readinglist/usr/share/doc/readinglist/changelog.Debian': Operation not permitted after dh_installchangelogs? [07:00] Using pbuilder [07:02] rhpot1991_laptop: should be 80. [07:02] figured so, thanks [07:15] Has anyone ever seen a problem with permissions on changelog.Debian? [07:20] Does anyone here have an {i386,PPC,sparc, s390} sid or hardy build environment and want to test building multiarch alsa-plugins? === foursixnine is now known as beholder-destroy === beholder-destroy is now known as beholder === beholder is now known as foursixnine [07:21] PPC64 is also testable! === imbrandon_ is now known as imbrandon [07:52] Anyone know what this is about? install: cannot change ownership of `debian/readinglist/usr/share/doc/readinglist/changelog.Debian': Operation not permitted. I found a thread on Google that mentioned the same problem, but no one replied. [07:53] method: Sounds like a problem with your local build system (pbuilder or whatever). [07:53] RAOF, yeah I'm using pbuilder [07:53] method: You'll need to provide more information for me to provide a more useful answer. [07:54]