[00:00] ah, ok, that might be more difficult to do then. i think flashplugin just uses wget [00:08] it should be different than using wget as long as it prints just to stdout and doesn't do any fancy stuff (like a ncurses interface or such) [00:10] the questioning should be better done with debconf and only the result of it passed directly to the updater to not break non-interactive updates [00:16] I also want to use this script as normal application [00:16] so the user can update the game data with it [00:45] hm, can't I just execute the updater in xterm or something [00:45] I can expect that X is installed, can't I? [01:08] Hello, I'm not sure this is the correct channel to ask but: I'm editing https://wiki.ubuntu.com/Halsectomy Can I add gnome-pilot to the table ? [01:52] Hello? [01:53] is anyone here? [01:53] !give drdr ask [01:53] Sorry, I don't know anything about give drdr ask [01:54] oops [01:54] !ask | drdr [01:54] drdr: Please don't ask to ask a question, simply ask the question (all on ONE line, so others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) [01:54] Anyone know when firefox 3.5 will be pushed as a update to the netbook spin? [01:57] fta: ^^ [04:46] Is the Library General Public License forward compatible with the Lesser General Public License? [04:53] stochastic: same thing [05:12] I keep getting debian-changelog-file-is-a-symlink from lintian, I've deleted the changelog and created a new one but it still didn't get rid of the warning :/ [05:13] binarymutant: This is almost certainly OK. [05:13] cool ty ScottK :D [05:14] If it's a multi-binary package and the package depends on the one that ships the symlink it's OK. [05:14] any MOTU able to look at stompserver, merb and chef on REVU? [05:15] ScottK, awesome, it is multi-binary === johe__ is now known as johe === Guest76973 is now known as santiago-ve [06:39] good morning [06:43] Good morning Daniel :-) [06:44] can reportbug work with debian's bts too? [06:44] binarymutant, yes: reportbug --bts=debian [06:44] hey fabrice_sp! [06:44] fabrice_sp, ty :D [06:49] dholbach, what do you mean with "if you fix this for Karmic, I'm happy to ACK it" in bug #416262. Should I upload a new version in Debian with the translations and re-ask for the sync? Or do you mean having the po files in a temporary way in debian directory? [06:49] Launchpad bug 416262 in aptoncd "Sync aptoncd 0.1.98+bzr110-1 (universe) from Debian unstable (main)." [Wishlist,New] https://launchpad.net/bugs/416262 [06:49] just a sec [06:50] it'd be nice to have translations back and investigate where they went [06:50] * RoAkSoAx off to bed, bye all [06:53] dholbach, upstream lost them. I can upload them again to the upstream repository (I have 'upstream' powers for aptoncd :-) ), and update debian then [06:53] fabrice_sp: that'd be sweet! [06:53] here we go then :-) Thanks [07:11] Hello dholbach. [07:12] hey iulian! [07:24] Would a kind motu with a spare second or two be able to REVU http://revu.ubuntuwire.com/p/xjadeo [07:35] This package has received two advocations http://revu.ubuntuwire.com/p/a2jmidid but they were on separate uploads, do I need them on the same upload for it to get pushed through? [07:37] ^^ james_w I think you may need to re-advocate if that's what's stopping it. [07:53] stochastic: yes, you need to get a second advocate. [07:58] don't you mean third ;) [08:00] stochastic: only if james_w is unavailable to advocate, i suppose. [08:20] does anyone here know about python distutls? [08:20] mine keeps installing to /usr/local/local [08:20] cannot for the life of me figure out why [09:03] lamalex: pass --install-layout=deb to setup.py install call [09:14] Hello, how usable is wine1.2 ? [09:17] stochastic: stefanlsd uploaded [09:20] james_w, okay, I just haven't seen it appear here yet: https://launchpad.net/ubuntu/+source/a2jmidid and it was still listed in the new packages page on revu [09:21] it's in the NEW queue [09:22] I don't follow. Maybe I'm still too NEW [09:23] stochastic, new source packages go into the NEW queue for approval by an archive admin [09:23] stochastic, then new binary packages go back into NEW [09:24] okay, and where does feature freeze play on this? will that package be accepted? [09:26] yeah [09:26] unless it is rejected, in which case you may have to ask motu-release nicely to allow you to upload after Feature Freeze [09:27] okay. thanks for the clarification. [09:31] bdrung_, if you have a second, I've re-uploaded (with all earlier discussed changes) xjadeo to revu. But I can't for the life of me figure out how to get rid of the executable-not-ELF-or-script lintian warning. [09:45] stochastic, i'm not seeing it [09:45] qjadeo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped [09:45] xjadeo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped [09:45] xjinfo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped [09:45] xjremote: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped [09:46] directhex my lintian reports ./usr/share/qjadeo/locale/qjadeo_fr.qm to be the culprit [09:47] but as I browse through the source tree I can't find any place where the qjadeo_fr file becomes executable [09:47] hm, it IS executable isn't it [09:48] directhex, it's probably from either the makefile or the debian/rules file (the debian folder is shipped from upstream so I didn't write debian/rules from scratch) === dholbach_ is now known as dholbach [10:17] dholbach: good morning. got time for a quick pm? [10:18] jussi01: yep === Guest77631 is now known as Zic [11:35] <\sh> siretart: pingeling you got the mail from mrfai? [11:46] \sh: yes, I did [11:46] <\sh> siretart: would you like to review my comment...and eventually make a comment, too? :) [11:56] stochastic: why do you run "test -f configure || ./autogen.sh" in the clean target? [12:00] i would guess that it's to autogen so that configure exists inside the source package, which is not a good idea [12:03] that's why i asked. clean is for cleaning, not for creating :) [12:32] any DD around, who could sponsor me an upgrade of min12xxw (preferred from svn - svn://svn.debian.org/svn/collab-maint/ext-maint/min12xxw/trunk/)? === ripps_ is now known as ripps [13:15] james_w: there? need to discuss something abuot cobertura package that you rejected last week. [13:15] hi [13:17] james_w: Even after remocing the DTDs in xhtml folder there are still some DTDs etc/dtds/coverage*.dtd which do not have license header. Is that acceptable? [13:17] possibly [13:18] were they written for this project? [13:18] juli_: Can you please answer james_w's question? [13:21] james_w, I think so but I didn't check it with authors [13:30] it that's the case then it moves them to a slightly (un)clearer license state [13:35] james_w, I'll contact them. But what about the package? I need it for the rest netbeans staff [13:35] packaging request.. would it be possible to package 64 bit packages for lighnting and enigmail working on TB3 :) [13:35] juli_: I can't say without looking really [13:36] I expect that it would be ok, but can't be sure [13:36] I suggest you upload again [13:36] james_w, ok, thank you. [13:37] ghostcube: Is such a version available i.e. the one which works with TB3? [13:37] yes [13:37] slytherin, could you, please upload again. I will see what can I do about coverage*.dtd in the meantime [13:37] juli_: Ok. Let me test build it. [13:37] slytherin, ok. Thank you [13:38] ghostcube: but there is no TB3 in repository. Why would anyone want to package an extension for it? [13:39] there is an ppa daily i havent known there is no universe package oO [13:40] havent searched i thought with ff3.5 there was tb3 too [13:40] ghostcube: TB3 has not been released yet. [13:40] oh ok .. [13:41] btw its a must have :D === rmcbride_ is now known as rmcbride4 === rmcbride4 is now known as rmcbride [13:55] jtimberman: hey, does merb need the embedded gems? [14:03] juli_: uploaded cobertura. it is now at the mercy of archive admins. :-) [14:04] slytherin, thanks! I'm writing a letter to cobertura developers about the license) [14:08] james_w: what gem is embedded?? [14:09] gem? [14:09] there's about 20 of them :-) [14:09] james_w: oh, stuff in the specs? [14:09] one second [14:10] ./merb-core/spec/public/core_ext/fixtures/gems/gems/ [14:10] ./merb-core/spec10/public/webrat/test_app/gems/gems/ [14:13] james_w: its not included in the resulting package. [14:13] still [14:14] it was fine for debian, merb was uploaded to NEW. [14:15] but i was told that it probably wouldn't get into an archive in time to make karmic feature freeze, hence packaging for universe as well. [14:16] and it wasn't a blocking issue in earlier reviews. [14:21] jtimberman: 'NEW' is not equal to 'ACCEPTED'. :-) [14:23] sorry, plumber arrived [14:26] slytherin: sure, and Debian ruby packaging also does not include the source package. [14:27] jtimberman: at the least not all the gems are covered by the same license as the main code, and that is not documented in debian/copyright [14:31] james_w: so you want me to repackage the source tarball? [14:32] I think so, though I've no idea what they are there for [14:35] they're there for doing spec tests on the source. [14:36] even if things aren't in the final package, their distributability needs to be certain for them to be on the ubuntu archive [14:37] Perhaps this is why Debian doesn't include the original source tarball in the packaging. [14:43] juli_: those files look very much like they are written for the project, so would be covered by the dominant license. Therefore I have accepted the package. Clarifying the situation with upstream would still be appreciated. [14:44] where should removal of the source gems be mentioned? [14:47] james_w: should i note those were removed in README.source, or README.Debian ? [14:47] see debian policy [14:47] it's debian/copyright [14:47] and README.source I guess [14:47] plus the version number should change [14:52] Does anyone know of an example package that generates debian/*.install etc files at source build time? [14:53] Surely you'd just call install manually instead? [14:56] james_w: http://paste.ubuntu.com/258692/ adding that to README.source, with the gems dirs removed, that good? [14:57] probably [14:57] I didn't review the whole package [14:57] you need to document it in debian/copyright as well, and change the version number as I said [14:58] as in a new dch entry, or modify the ubuntu version, 1ubuntu1 [14:58] the upstream version number [14:58] so that it is clear the tarball has changed [14:59] i dont know what you mean [15:00] as in bump from merb-1.0.12 to merb-1.0.13 or something? [15:01] i don't think upstream isn't going to remove those gems from the source tarball, they're included on purpose for the spec tests. === AlanB` is now known as AlanB [15:08] jtimberman: no, merb-1.0.12+dfsg [15:08] so that it is clear that it is a modified tarball, and not the one that upstream calls 1.0.12 [15:09] james_w: do i just change the name of the orig.tar.gz, or update the changelog? [15:09] both [15:10] ok [15:11] in changelog, merb (1.0.12+dfsg-0ubuntu1) ? [15:14] yep [15:18] uploaded to revu. [15:18] james_w, thank you! I wrote a message to cobertura-devel. I hope they clarify the situation. [15:18] thanks juli_ === dyfet` is now known as dyfet [15:22] Heya gang [15:22] hi bddebian [15:23] Heya sistpoty|work [16:02] james_w, cobertura developer said coverage* files are under W3C license (the same: http://changelogs.ubuntu.com/changelogs/pool/main/w/w3c-dtd-xhtml/w3c-dtd-xhtml_1.1-5ubuntu1/w3c-dtd-xhtml.copyright). They will add these info for next release. Should I update copyright file now and reupload? [16:03] yes please [16:03] if they can make that explicit in the headers of their next release that would be great as well === cprov is now known as cprov-lunch [16:04] I'd be happy to sponsor that change [16:04] james_w, thank you:) I'll update copyright and upload an updated version to REVU [16:05] just a debdiff would do [16:05] or even a diff for that file and proposed changelog entry :-) [16:06] should I create a bug in LP? [16:06] I suppose yes:) I'll do this today [16:08] no need really [16:08] if you just pass the changes to me I can sponsor straight away [16:08] a bug is fine though [16:09] james_w: can you take another look at merb please? i uploaded w/ new orig.tar.gz [16:12] sorry, I've got to do something else today [16:12] I've already spent most of my day on archive-admin stuff [16:14] jtimberman: you uploaded to REVU? [16:14] james_w: i did [16:14] I can upload that to NEW for you [16:15] james_w: :-D [16:15] link please? [16:15] http://revu.ubuntuwire.com/details.py?upid=6771 [16:15] or, http://revu.ubuntuwire.com/p/merb [16:47] DktrKranz: my distutils doesn't appear to have that option [16:57] james_w, I created a bug and attache diff files for copyright and changelog there: https://bugs.launchpad.net/ubuntu/+source/cobertura/+bug/418181 [16:57] Launchpad bug 418181 in cobertura "cobertura copyright doesn't contain license for coverage* files" [Undecided,New] [17:16] lamalex: sounds strange, which release are you running? [17:16] DktrKranz: jaunty [17:16] james_w: I also fixed blocking issue with license in stompserver, which had 2 advocates: http://revu.ubuntuwire.com/p/stompserver [17:16] er [17:16] karmic [17:18] DktrKranz: i think part of the problem is that I dont understand distutils at all [17:19] lamalex: so it should definitely support it. how do you call setup.py? [17:20] DktrKranz: sudo python setup.py --instal-layout=deb install [17:21] it should be "sudo python setup.py install --install-layout=deb" [17:22] DktrKranz: do I pass the same flag for bdist? [17:23] --install-layout is common for install only [17:24] hmm how do I generate the correctly layed out tar.gz [17:24] ah, it's dsist [17:24] s/dsist/sdist [17:32] DktrKranz: ?! NEVER SUGGEST TO "sudo pytohn setup.py install" or ez_instal something!!! I will break other parts of the system [17:33] if someone wants to test something, he should use some kind of sandbox (like virtualenv) === cprov-lunch is now known as cprov === davroman1ak is now known as davromaniak === cody-somerville_ is now known as cody-somerville [18:19] fabrice_sp: ping [18:22] slytherin, pong [18:22] Chef just needs one more advocate, who wants to be the lucky MOTU? :-D http://revu.ubuntuwire.com/p/chef [18:22] fabrice_sp: do you plan to file sync request for doxia and doxia-site-tools? [18:23] slytherin, not yet. I was planning to get them built, for the moment [18:25] fabrice_sp: Ok. I am updating my pbuilder. It will take me an hour to get doxia built. If you are done before that then please let me know. [18:27] slytherin, I can go with doxia-site-tools first [18:28] it has build-dep on libdoxia-java [18:29] oh [18:47] slytherin, doxia build depends on plexus-containers and plexus-containers needs the latest version of libgoogle... [18:48] so where are you stuck at? [18:48] compiling plexus-containers, without libgoogle [18:50] have to go. bbl [18:50] plexus-containers sound like something from star trek [19:05] back [19:05] highvoltage, it's almost as complex as the Enterprise :-) [19:07] fabrice_sp: :) [19:07] fabrice_sp: so libgoogle is one of those few libraries which will need to be modified to have complete maven stack right? [19:08] slytherin, yes: it's also blocking the 'plugin' path [19:08] maven-plugin-tools-java [19:08] fabrice_sp: have you discussed this already with ttx by any chance? [19:09] yes, and it's a no go :-/ [19:09] ttx is more of the opinion to let maven and plexus as-is [19:09] Then he is probably using google-* libraries as build dep for some other work. [19:13] I didn't specifically spoke about libgoogle, but his last email is more this way (do not touch non plexus lib) [19:18] fabrice_sp: reply to that mail and add details about the libraries that 'must' be modified. Let's see what he says. [19:18] kirkland: thanks for your comments on Chef :) [19:19] jtimberman: debian-changelog-file-is-a-symlink - I've seen that one often - but I have no clue how to fix these [19:19] jtimberman: sure, i just advocated [19:19] kirkland: ^^ [19:19] mathiaz: hmm, i've never seen that one before [19:19] mathiaz: let me have a look [19:19] kirkland: it seems to be something from cdbs [19:19] slytherin, ok. As I will be on holidays beginning tomorrow, I won't be able to follow up on that until post-FFE. [19:20] ok [19:20] mathiaz: fwiw, i did advocate, packaging looks good [19:20] it's one of Ubuntu's cdbs features to symlink identical files [19:20] ah, space savings [19:20] It does not need fixing [19:20] geser: that makes lintian unhappy [19:20] kirkland: thanks! [19:20] mathiaz: i don't use cdbs very much, which is why i haven't seen it [19:20] It is warning, not error. [19:20] there's an element of danger in using magic. [19:21] :) [19:22] slytherin: https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews#Tips says Package should be lintian clean [19:22] slytherin: lintian clean means error free or warning free? [19:22] kirkland: do you look for lintian warnings as an AA? [19:23] mathiaz: yes, but warnings are not necessarily blockers [19:23] kirkland: you're an AA? [19:23] Ideally it means free from errors as well as warnings. But in this case lintian is not updated to ignore a warning caused by a feature. [19:23] kirkland: lintian errors are though? [19:23] mathiaz: bonus points for lintian overrides (with inline comments as to why they may be safely ignored) [19:24] mathiaz: yeah, i generally require lintian overrides (with comments) for lintian errors [19:24] mathiaz: where comments provide an acceptable explanation [19:24] jtimberman: y [19:24] kirkland: mathiaz got me to put that in for chef-server ;) [19:24] as you probably saw. [19:24] jtimberman: right [19:25] mathiaz: honestly, most of my AA work is ensuring that debian/copyrights is comprehensive and correct [19:26] kirkland: right - are you also looking at the debian/ directory in general (as an AA)? [19:26] mathiaz: and mostly trusting that the uploading/advocating MOTUs did a good job with the packaging checks [19:26] mathiaz: only lightly; see my last statement ^ [19:26] mathiaz: so i did the REVU with MOTU hat on, not AA hat [19:26] kirkland: ok :) [19:27] mathiaz: as for debian/copyrights, I read/digest that [19:27] kirkland: and you MOTU hat covers more things than your AA hat? [19:27] mathiaz: i consider my MOTU hat to cover packaging technical details [19:28] kirkland, mathiaz and it was a good reminder to discuss the lintian override, now we have an upstream ticket to use system-provided jquery if it exists. [19:28] mathiaz: which any MOTU, I think, should be able to cover [19:28] mathiaz: and as an AA, we put a lot of trust in MOTUs [19:29] mathiaz: for stuff like package syncs, we have to "trust" that the MOTU ack'ing the package sync has done a good job reviewing "why" the diffs can be dropped from the package [19:29] mathiaz: because we might have to process a hundred of those per day, and can't look at every one of those [19:30] * mathiaz nods [19:30] mathiaz: if a MOTU ack'd that, it's on him/her ;-) [19:30] mathiaz: as for the licensing ... [19:30] mathiaz: run "licensecheck -r ." from the package source tree [19:30] mathiaz: i see chef is Apache license [19:31] mathiaz: so I'll start with "licensecheck -r . | grep -v Apache" [19:31] mathiaz: looking for anything licensed differently [19:31] kirkland: right - what do you do about Unknown - no copyright files? [19:31] mathiaz: for instance, maybe some GPL code slipped into here [19:32] mathiaz: i try to make sure those are clearly covered otherwise [19:32] kirkland: such as with the debian/copyright mentioning those filepaths [19:32] mathiaz: and when possible, I ask upstream to ensure that they have proper copyrights in their files, and provide them the list of files missing copyright/license headers [19:33] mathiaz: usually projects are willing/able to get that into a future release [19:33] jtimberman: right; sometimes it's a matter of a whole section (subdir) being licensed/copyrighted and mentioning that in debian/copyrights [19:35] kirkland: gotcha. ran into a bit of that with merb earlier today. merb's spec tests include some gems, and some of those are available as packages but the upstream isn't going to worry about which platform they're on for testing. [19:35] so they can't rely on say libfoo-ruby is installed to do a test. [20:19] superm1: would you like to act as motu-release delegate for mythbuntu again, or do you have someone else you'd like to recommend for the position? [20:20] sistpoty, yeah should be able to. i sponsor everything within our small team anyway :) [20:20] excellent, thanks superm1 [20:24] does anyone know what happens when there's a name conflict between packages from different sources? [20:24] fta: would you like to act as motu-release delegate for the mozilla team this feature freeze again (together with asac, if he agrees)? [20:25] lamalex: If the two don't do the same thing, one has to be renamed. [20:25] lamalex: it's not coinstallable? (and you'd need to declare conflicts: otherpackage in both) [20:25] sistpoty: they dont conflict [20:26] ScottK: but what /happens/. does apt just pick on arbitrarily to be used? [20:26] sistpoty: conflicts are only appropriate if they are alternative implementations of the same functionality. [20:26] sistpoty, sure [20:26] lamalex: First one installed wins. [20:26] Second one will get an install failure. [20:26] ScottK: and before installation? [20:26] That's why one needs to be renamed. [20:26] ScottK: the one with higher versionsnumber wins xD [20:27] sebner: Nope. [20:27] aptitutde search package [20:27] who gets shown [20:27] both? [20:27] ScottK: why not? [20:27] thanks fta [20:27] Ah. [20:27] I was talking about file name conflicts, not package names. [20:27] Sorry. [20:27] sebner is likely correct. [20:27] np [20:27] he, /me is well [20:27] * sebner ^5 sistpoty [20:28] lamalex: Only the binary with the higher version number will exist in the archive. [20:30] luisbg: up for ubuntustudio delegation for motu-release for karmic again together with _MMA_? [20:31] sistpoty, yes [20:31] ScottK: thanks [20:31] luisbg: excellent, thanks. can you also ask _MMA_ if he agrees? [20:31] sistpoty, will do and will let you know [20:31] thanks a lot luisbg [20:31] he is a little bit hard to contact now but still possible :) [20:31] heh === nixternal_ is now known as nixternal [21:17] burnout. is when you answer to a user-request wine on a devel list and get tangled into a support thread. [21:18] Modern Support: http://xkcd.com/627/ [21:18] No, I don't do that. [21:21] luisbg: btw.: read the mail about the request for audacity standing FFe? (https://lists.ubuntu.com/archives/ubuntu-motu/2009-August/006079.html) / I also cross-replied to ubuntu-studio-devel [21:59] fta, ping [22:01] ghostcube, no contentless ping please [22:01] fta, ping http://bugzilla.songbirdnest.com/show_bug.cgi?id=17683 :) [22:01] sorry [22:01] bugzilla.songbirdnest.com bug 17683 in UI "Ui Media View not showing anything" [Major,Unconfirmed] [22:03] does anyone use reportbug with gmail? It didn't send the mail for me :/ [22:03] ghostcube, no idea [22:04] i think it is an songbird bug or a missing lib maybe [22:11] fta, got it the problem is somehow a mising german loalisation [22:11] *c [22:38] bdrung_ I've lost that last command you suggested I run, can you repost? [22:39] stochastic: run debuild twice [22:40] stochastic: and you will see, that the second run failes, because the clean target do not remove all generated files. you have to remove them in the clean target with "rm -f file1 file2" or "rm -rf dir1 dir2" [22:41] james_w: You are ubuntu top contributor ;-) [22:41] it's a lie! [22:41] https://edge.launchpad.net/debian/+topcontributors [22:41] * xnox lol [22:42] When people start using Distributed Development will Karma even out? [22:42] That's Debian, not Ubuntu. [22:42] don't take karma as a proxy for worth :-) [22:42] stochastic: and why do you run "test -f configure || ./autogen.sh"? [22:42] in the clean target? === fta_ is now known as fta [22:43] xnox: somewhat, though it may take some time [22:43] bdrung_, I don't know why that's there, I inherited the debian packaging from upstream and am cleaning it up [22:43] james_w: I'm just jealous =) I was evaluating my chances for UniverseContributor and tried to weight my Ubuntu Karma to find this bob =) [22:43] s/bob/bomb [22:43] xnox: LP might subtract a large lump off me or something, as it's not at all fair [22:43] heh [22:43] stochastic: then remove this line [22:44] at least you now probably feel like poker tournament winner with a huge stake =) [22:46] james_w: anyhow by submitting Karmic recipes for daily-debs I was hoping to get nightly bzr for Karmic.... Will you update cron-jobs or however jw+dailydebs works [22:47] ah, Dmitrijs! [22:47] thanks [22:47] I'll do that now, thanks for the reminder [22:47] if you remove the 190000 from the bazaar branches of james_w, there will be only 451 karma points left [22:48] bdrung_ I think the removal of xjadeo.desktop isn't happening, but that sill doesn't fix the elf binary warning... [22:48] james_w: your welcome =) scratching my itch really I've just moved to karmic and I can't live without my daily treats [22:49] feel free to send me any more packages you want added [22:49] well within reason ;-) [22:49] there must be something wrong with the karma points. i am listed as "top contributer", too. really strange. [22:49] james_w: I kind of trying to run my own as well ~crosswire-daily for my Debian/Ubuntu Packaging team of Crosswire stuff. [22:50] nice [22:50] what's crosswire? [22:50] stochastic: it complains about xjadeo-0.4.7/src/qt-gui/qjadeo_fr.qm [22:51] stochastic: you should remove this file on clean [22:51] james_w: I didn't know before I've signed up =) It's bible study library & front-ends + actual texts of hundreds of bibles/commentries etc. [22:52] a long the lines of making Ubuntu interesting without the internetz [22:52] ah, ok [22:53] Hello. Is this a good place to look for someone who would accept to maintain the ubuntu package of an upstream project ? [22:53] xnox: if you need a helping hand for packaging Xiphos, feel free to contact me. [22:53] james_w: really didn't know how to get involved with Ubuntu/Debian and there was a team being formed in January so I joined =) Resurected from horrible QA state 2 packages in Debian and Ubuntu =) [22:54] bdrung_: I'm proud maintainer of Xiphos =) Hope it's in good shape in Karmic now [22:54] bdrung_: can you sponsor a fix though? I've forgot a "Provides:" in the latest version in Ubuntu [22:55] (the package in question is exaile, which losts its maintainer for ubuntu) [22:55] bdrung_: lp:~dmitrij.ledkov/ubuntu/karmic/xiphos/fix-upgrades [22:55] xnox: not yet, in 3 day is my motu application :) [22:56] Aha =) well I wish you good luck [22:56] I'm noone yet. And I'm thinking whether I can make it into Contributors [22:57] xnox: being a contributor is the first step (you become ubuntu member and gain a nice email address) [22:58] xnox: i found a bug in your debian package :) [22:58] bdrung_: I'm listening =) [22:58] xnox: it's a native package [22:58] but it shouldn't be native [23:00] * xnox checking [23:01] bdrung_: how is 3.1.1-1 in Debian or the proposed fix 3.1.1-1ubuntu1 native? [23:01] * xnox is confused [23:01] the package in debian sid [23:01] 3.1.1-1 [23:03] You are right! How did that happen [23:04] * xnox need to bash Debian Sponsor for mingling with my package!!! [23:05] it was the sponsors fault? [23:05] bdrung_, I've added qjadeo_fr.qm to the files removed in clean, but lintian still gives me the elf-binary error [23:06] stochastic: that are different issues :) [23:06] bdrung_: thanks a lot =) [23:06] xnox: np [23:06] xnox: i will have a look at the package. let me see if i find more issues ;) [23:08] bdrung_: the previous DD who maintained it had tarball inside tarball so it was all native to him [23:08] And now I'm out-of sync with and the checksums will be different [23:08] crap [23:08] stochastic: the convert and install command should be moved to the install target (you see the correlation?) [23:09] xnox: tarballs inside tarballs are ugly [23:10] stochastic: after all the install command you could put a chmod 644 command for the qjadeo_fr.qm file [23:10] stochastic: the "$(MAKE) distclean" command should come before the "rm" commands [23:11] bdrung_, so the binary-indep: build install target should be empty? [23:11] stochastic: yes [23:11] stochastic: i don't know why you have a "rm -f" command in the binary-indep target [23:13] bdrung_, I believe it's because the convert command creates a temporary copy of those files, then it's copied to the right place, then the temporary files are removed [23:13] ok [23:14] stochastic: the convert command _could_ put the resulting files directly into the right place. [23:14] bdrung_, yes that would seem cleaner [23:14] stochastic: after running debuild twice, run "zcat ../xjadeo_0.4.7-0ubuntu1.diff.gz |diffstat" and you will see that there are some files not cleaned [23:15] bdrung_ I don't understand what you mean by "run debuild twice" I've run it many times [23:17] stochastic: run debuild twice means, that you run it at least two times. [23:17] the diffstat command list all files in the diff file. in the diff file should only be the files of the debian/ directory [23:20] stochastic: http://paste.ubuntu.com/258969/ this fixes the copyright lintian warning [23:21] I thought you mentioned we could safely ignore that warning [23:22] * stochastic changes it anyway [23:22] the zcat |diffstat command only returns files in the debian directory for me [23:22] (if you don't mind me asking: is there an easy way to get lintian to *always* warn on changes outside of debian/, not only if it detects a patch system, which iirc is its default behavior?) [23:23] stochastic: ok, maybe i need your updates [23:23] bdrung_, uploading to revu right now [23:24] oops, forgot to debuild after that copyright file change [23:24] mzz: don't know. i normally use the zcat diff.gz | diffstat command [23:24] next upload will include the copyright file changes [23:24] mzz: if you want everthing from lintian, run "lintian -iIE --pedantic ..." [23:24] bdrung_: sure, and that's a good habit anyway, I guess (since it'll also warn you about oddities inside debian/) [23:25] the diffstat, that is :) I haven't tried lintian in full pedantic mode yet... [23:25] mzz: some pedantic warnings are usefull [23:26] * mzz is beginning to get the hang of things, has managed to create a ppa with a few basic packages, might figure out how to get those in either debian or ubuntu proper in the future [23:27] mzz: new ones? [23:27] mostly backports [23:27] well, backports or fairly trivial version bumps [23:29] ok [23:29] so far my experience has been that it's not exactly hard, but that there are a great many layers of tools calling each other, with multiple choices on some of the layers, and I don't understand all the layers yet. [23:30] mzz: i know the feeling. [23:30] it will go away some day :) [23:30] (things like python-support versus python-central, pbuilder versus sbuild versus probably other things I haven't encountered yet, but also on a user level apt-get vs aptitude vs synaptic, which don't seem to be using exactly the same "marks" database) [23:30] bdrung_, I get no lintian warnings on that latest upload. Do you see any issues left? [23:31] stochastic: is the upload already on http://revu.ubuntuwire.com/p/xjadeo [23:31] * mzz shall stop distracting you now :) [23:31] the last upload date is 23:48 [23:32] mzz: no problem. i am doing more thing parallel. [23:32] bdrung_, oh, looks like that upload was rejected [23:32] this is generally the case on irc :) [23:33] mzz: yes. [23:35] stochastic: the revu page seams to be not up to date [23:37] mzz: it's good to have a choice, but on the beginning it could be confusing. sometimes you use more than one of them (e.g. i use apt-get and synaptic) [23:38] bdrung_, okay revu is up to date now [23:42] stochastic: the second run of debuild failed. the patch could not applied. "1 out of 1 hunk FAILED -- saving rejects to file src/qt-gui/qjadeo.cpp.rej" [23:43] bdrung_ how are you getting these errors? [23:44] what options are you running debuild with? [23:44] is it in a pbuilder environment? [23:45] stochastic: run this: http://paste.ubuntu.com/258979/ [23:46] stochastic: no, you cannot reproduce it with pbuilder, because pbuilder do not rely on the clean target [23:48] bdrung_, but for that I need to manually install the build deps? [23:49] stochastic: yes [23:49] ugh, is there any way to do that without clogging my system up? [23:51] stochastic: setting up a virtual machine :) [23:51] stochastic: after playing around with a lot of pacakges a removed all -dev packages and then did an autoremove =) [23:52] "Developers spring cleaning" [23:52] xnox: i clean them once in a half year with reinstalling the current release. ;) [23:52] bdrung_: Ahh that's what you call install party =) [23:52] xnox: yes [23:53] xnox: but sometimes i install in between [23:53] last time was when i bought an ssd. [23:53] =) me too I've just upgraded to karmic alpha [23:53] the complete installation needs less than 10 minutes [23:54] karmic is on my previous hdd and in a vm [23:54] what about / etc? [23:54] and /var/cache/ [23:54] bdrung_, my apt-get doesn't want to install any of the last four dependencies because of broken sub dependencies, but pbuilder finds these just fine [23:55] bdrung_ could you just pastebin the diffstat so I can see the result of the debuilds? [23:55] stochastic: strange [23:56] stochastic: http://paste.ubuntu.com/258982/ [23:57] xnox: for /etc i have some scripts / patches that are making the required changes [23:57] xnox: but /var/cache? [23:57] ok /var/cache/pbuilder [23:58] and /var/cache/apt-cacher-ng [23:58] ~30 GB [23:58] xnox: i rebuilt them. that is not the problem. (i have mirrored jaunty and karmic with apt-mirror) [23:58] how much does that take space? [23:58] i have one pc without internet access [23:59] 44,8 GiB [23:59] ok not that bad [23:59] one distribution would use 22 - 25 GiB