[00:00] if there is a case where the depends are different between the debian and ubuntu version we keep the ubuntu versions right? [00:00] I would say only if necessary and if there are other changes [00:01] ok let me see [00:01] well, there doesn't need to be other changes [00:01] but only if necessary yes [00:02] I mean if there are other changes it would be OK. Otherwise, only if necessary. Does that make more sense? [00:02] more yes [00:03] but I wouldn't think we'd keep non-necessary changes in any case [00:03] + chmod 755 debian/rsh-server/usr/sbin/checkrhosts [00:03] essentially: "prefer the Debian packaging unless there's a compelling reason to use the Ubuntu delta, e.g., versioned dependency or specific package instead of virtual package, etc." [00:03] that is the only change [00:03] crimsun: ok [00:03] crimsun: Are you a DD? [00:03] bddebian: nope [00:04] really i have no idea how to test this without installing the package [00:04] since it is a depends issue and not a build depend issue [00:05] Do a simulation? [00:05] somerville32: simulation? [00:05] Yeah. IT goes through the installation without actually installing anything thing. [00:06] yeah but what about running it :P [00:06] joejaxx: thankfully there's /usr/share/doc/pbuilder/examples/execute_installtest.sh [00:06] (not to mention B92test-pkg in that same dir) [00:07] bug 76143 [00:07] Launchpad bug 76143 in netkit-rsh "missing dependency on update-inetd make it uninstallable on feisty" [Low,Fix released] https://launchpad.net/bugs/76143 [00:08] bug #45991 [00:08] Launchpad bug 45991 in netkit-rsh "/usr/sbin/checkrhosts misses execute permision" [Medium,Fix released] https://launchpad.net/bugs/45991 [00:08] hmm [00:08] that would be a suitable Ubuntu delta if it's not already fixed in the Debian packaging [00:09] crimsun: yeah nether are fixed in debian [00:09] Gawd I hate trying to get any help/advice in Debian :'-( [00:10] ? [00:10] my gosh, Yahoo actually expects people to be able to use their new webmail? [00:11] LaserJock: it's extremely heavy on JavaScript but seems to work tolerably [00:11] Anyone familiar with conquest? [00:11] most of the time I end up reverting to classic mail, though [00:11] it's completely unusable here :( [00:12] I don't know maybe webmail isn't the way to go until I get a new laptop [00:13] I could see that [00:14] bddebian: nope :\ [00:17] * Fujitsu wonders what is wrong with hosting your own mail and using a proper mail client, with webmail for when you're working remotely. [00:17] Fujitsu: amen. [00:17] Fujitsu: The thing thats wrong with hosting your own mail is when Telstra kills your line for a painful length of time. [00:17] whee, another azureus bug found.... [00:17] TheMuso: Ah, true. [00:18] jdong: Joy. [00:18] jdong: :P [00:18] is it a crime to put urgency=just-fscking-build-it-now? :) [00:18] lololol [00:18] the last round took like a week in queue :) [00:18] We're almost down to 1000 pending builds on i386! Not long to go now! [00:18] hahaha [00:18] how many of those are Openoffice? :) [00:19] It's sped up now too, since Soyuz likes this number of builds more. [00:19] jdong: Haha. [00:19] I'll work on a patch, then go back to starcraft then :) [00:19] Fujitsu: hosting my own mail where exactly? [00:19] :-) [00:19] LaserJock: Wherever. Home? [00:20] google and yahoo have the best uptime [00:21] so they're the best way to make sure I can get to my email [00:22] I've gone back and forth several times on what to do with email [00:22] and have never really figured out a good solution [00:22] * joejaxx is on a roll with the merges [00:22] :D [00:22] i just did the uml-utilities one [00:22] does setting urgency=medium actually do anything? [00:22] not in Ubuntu I don't think [00:22] jdong: Not in Soyuz. [00:22] now what do i have to put in these bug reports for merges? [00:23] joejaxx: well, a debdiff is good : ) [00:24] crimsun: :P i mean the bug content etc :P [00:24] maybe my ivman merge is still on lp [00:24] * joejaxx goes to look [00:24] * Fujitsu points to requestsponsor [00:24] ivman is still around? [00:24] jdong: yes [00:24] i use it :D [00:24] haha [00:24] Fujitsu: that is a script? [00:24] joejaxx: anyone else? ;-) [00:24] * joejaxx looks [00:24] jdong: all the fluxbuntu users :D [00:24] pfft, 80386s are still around. Of course ivman would be. : ) [00:24] joejaxx: ah, ok [00:24] What's wrong with ivman? [00:25] Fujitsu: i do not have a request sponsor script [00:25] Fujitsu: just reminds me of the old days when hal automounting was just around :) [00:25] is it in ubuntu-dev-tools? [00:25] * LaserJock has never heard of ivman [00:26] LaserJock: it is automounting for us without gnome :D [00:26] Hm, I'm sure we had a requestsponsor, but I can't see it anywhere. Maybe I was thinking of the argument to requestsync. [00:26] Fujitsu: I think so [00:26] ivman is what kubuntu uses also iirc [00:26] imbrandon: It's in universe, so I doubt it. [00:27] Fujitsu: but there is no application flag for merge for `requestsync` [00:27] :\ [00:27] at one point, Xubuntu used ivman [00:27] crimsun: they switched like 2 releases back [00:27] right, something along that timeline [00:27] <_16aR__> hello, I've got a problem on a compilation. Some object doesn't find members of its own class ... [00:27] imbrandon: doesn't KDE have its own thing that interfaces with hal for device insertion then uses pmount? [00:27] <_16aR__> here is the compile command : [00:27] <_16aR__> http://paste.ubuntu.com/1683/ [00:28] jdong, yes _now_ [00:28] <_16aR__> and here is an nm of an object [00:28] <_16aR__> http://paste.ubuntu.com/1681/ [00:28] <_16aR__> and here is one of the output : http://paste.ubuntu.com/1684/ [00:28] anyone have an example merge bug report? === _16aR__ is now known as _16aR_ [00:29] would a kind soul care to sponsor http://jdong.mit.edu/~jdong/motu/azureus_2.5.0.4-1ubuntu3.debdiff? [00:29] * jdong really hopes that's the last one.... [00:30] jdong: I'll look at it. [00:30] thanks [00:31] it's a trivial patch to the .desktop file [00:31] jdong: So I saw. What is %U? [00:31] Fujitsu: URL to file [00:31] which Azureus doesn't like... [00:32] Ah. [00:32] woohoo [00:32] flwm is my first package for hardy :D [00:32] 'grats! [00:32] crimsun: thanks :D [00:32] jdong: Do you have a bug number for that? [00:32] hmm, so NetworkManager has taken to pegging my CPU after reboot occasionally [00:32] https://launchpad.net/~joejaxx/+packages this is slowly getting bigger :D [00:33] Fujitsu: it's the last comment on bug 57875 [00:33] Launchpad bug 57875 in gutsy-backports "Azureus hangs or crashes showing splash screen at start" [Undecided,In progress] https://launchpad.net/bugs/57875 [00:33] vommenter didn't open new bug report [00:33] Ah, so not a bug on its own. [00:33] right [00:33] commenter* [00:33] OK, I'll upload shortly. [00:33] it would be so lovely if hibernate ever consistently worked ;-) [00:33] thanks muchly :) [00:33] LaserJock: I've heard a lot of good things about tuxonice [00:33] (I don't think I'll bother test-building, as I last built it a few days ago, and this doesn't look like it can do much to the build) [00:33] LaserJock: it will freeze my gnome session occasionally, and I normally have to force-reload dbus [00:33] how many packages do i need on that before i should go for motu :P [00:34] Fujitsu: testbuild already succeeded here ;-) [00:34] * jdong posts testing deb on bug report [00:34] crimsun: mine seems to have a new "bug" every few weeks [00:34] it's just so weird [00:34] joejaxx: it's not normally tied to number of source packages, per se, but rather continued involvement in the project over a sustained period [00:34] jdong: Uploaded. [00:35] crimsun: oh ok [00:35] :D [00:35] joejaxx: e.g., your work on Ubuntu Studio certainly is notable [00:35] Fujitsu: thanks muchly :) [00:35] No problem... now, I have an exam in 3 hours, so I'd best actually study for it. That's not going to happen, of course. [00:35] 'luck, Fujitsu [00:35] crimsun: yeah but that is not reflect in packages in universe :\ [00:35] Thanks crimsun. [00:35] reflected* [00:36] that is only ubuntustudio-meta [00:36] joejaxx: have you worked closely with Colin (cjwatson)? [00:36] yes [00:36] but not for packages :\ [00:36] you've also been around at UDSs [00:37] Fujitsu: good luck man! [00:37] (my recommendation is to work actively through the hardy cycle and then apply) [00:38] crimsun: ok [00:38] jdong: Thanks. [00:38] I agree with crimsun [00:38] * jdong puts MOTU work on his Hardy agenda too :) [00:38] a /major/ boon would be to work on 6.06 LTS -> 8.04 LTS upgrade testing [00:38] joejaxx: you're a smart guy, just spend some consistent time working on MOTU stuff and it shouldn't be any problem [00:38] LaserJock: ok :D [00:38] crimsun: i can do that [00:39] lol after doing that flwm merge i just realized i can do this bug :D bug 48340 [00:39] Launchpad bug 48340 in flwm "Does not create an option to log into an flwm session in GDM" [Medium,New] https://launchpad.net/bugs/48340 [00:39] there is no sessions file [00:40] sure, go for it [00:40] * cyberix feels slightly depressed because his deb-packet is starting to be perfect, while at the same time it is becomming clearer that no repository is willing to take it. [00:40] joejaxx: In my experience, when it's time to apply, a MOTU will harass you to apply. [00:40] cyberix: what is it? [00:40] Packaging great packages for myself doesn't really make sense. [00:40] cyberix: Because of licensing issues? [00:40] ScottK: :P i will keep that indicator in mind :D [00:40] No source available. [00:41] ? [00:41] Permissive license, but no source code available. [00:41] cyberix: eek, well, yeah, that's a major showstopper. What work has been invested for Ubuntu multiverse? [00:41] And it's PE. [00:41] PE? [00:41] Windows executable. [00:41] It is unclear, if Ubuntu is willing to expand Multiverse with nonessential non-free packages. [00:41] oh wow :\ [00:41] Progress Quest [00:41] cyberix: e.g., we have no source for Adobe Flash, but we use a script to download it [00:42] cyberix: we'd take it, if it's doable [00:42] (it -> tarball containing binary plugin) [00:42] http://progressquest.com/ [00:42] Right, but Adobe flash isn't distributable [00:42] I posted it to REVU earlier [00:43] But the entry was closed. [00:43] ScottK: right [00:43] that is a windows binary :\ [00:43] joejaxx: Yep, but it works fine. [00:43] via wine? [00:43] yep [00:45] hmm, do we have any sort of policy for that kind of thing? [00:45] it's an interesting thought [00:45] LaserJock: I'm not aware of any [00:45] LaserJock: We do not. [00:45] I've made some Ubuntu-integration for it. [00:46] If you wan't to beta test, you can try http://cs.helsinki.fi/u/twruottu/pq_6.2-0ubuntu1_all.deb [00:46] It _should_ work. [00:46] (it would be worthwhile to also post the urls for the source packaging) [00:47] I'll upload the new version to REVU [00:47] Please close it again, if it isn't ok [00:48] I don't really think we want multiverse to become a dumping ground for a lot of non-free Windows software. [00:48] cyberix: regarding the apparent wait time for inclusion, don't be discouraged. I believe a major factor is that Ubuntu simply doesn't have procedure in place for such inclusion. [00:48] Fujitsu: yeah :( [00:48] should this a subject at the next MOTU meeting? [00:48] Fujitsu: why not? [00:49] joejaxx: I think it would be a TB decision [00:49] I agree with crimsun. [00:49] crimsun: oh [00:49] hmm, I don't know why TB would be interested, but doesn't hurt [00:49] how do we go about that? [00:49] it would set precedent, I think [00:49] really? [00:50] only in that it's a Windows binary, I guess that might open up security issues [00:50] Have we (that is Ubuntu, not Debian) accepted binary-only unimportant stuff before? [00:50] sure [00:50] well, more importantly (I think), redistributability === nxvl_ is now known as nxvl [00:51] Fujitsu: have a luck at Multiverse :-) [00:51] dput done [00:51] And also, I don't like the idea of Wine having rdepends. [00:51] It's not the most stable of beasts, and generally has a blanket UVFe. [00:51] Will the entry unclose automagically, or should someone do something? [00:51] cyberix: The former. [00:52] might this be a MC question as well? [00:52] * ajmitch would prefer that multiverse be as small as possible [00:53] LaserJock: I don't think it really falls into MC's jurisdiction [00:53] * cyberix does understand the minimal multiverse argument [00:53] crimsun: I would think it would, at least in a hierarchical sense [00:53] ajmitch: Right, that's what persia and I said last night. [00:53] I was talking earlier about a new "Beerbuntu repository". [00:53] I personally would like to see any CC/TB issue go through the MC [00:54] But I think Progress Quest is a special case. [00:54] cyberix: Why? [00:54] Because it is more free than freeware [00:54] but I understand how that may not reflect the current understanding [00:54] LaserJock: no offense, but I think that would be unnecessary overhead [00:54] It allows you to do almost anything [00:54] cyberix: there is source though [00:54] It just doesn't ship with source code [00:54] cyberix: I fail to see the source. [00:54] So how can you do much? [00:54] Fujitsu: e.g. packaging [00:54] I'm not sure, if having a freeware repository makes sense [00:55] as most freeware may not allow packaging [00:55] crimsun: I suppose, but as TB/CC are supposed to be over MC then escalation would mean going to MC first, even if it were not in a "we need to make a judgement on this" thing [00:55] In my opinion, it doesn't belong in Ubuntu. [00:55] s/there\ is/there\ is\ not\ any/g [00:55] My proargument is Ubuntu integration. [00:55] But the TB has the final decision on that - they decide the purposes of the components. [00:55] not to stir ashes or anything, but it's similar to the KDE 4 snaps in universe bit IMO [00:56] And a proper bug channel for specific piece of software running inside Wine. [00:56] crimsun: which should have been a MC issue [00:56] Instead of pouring all bug reports into Wine-package [00:56] cyberix: why cannot people get wine and run it themselves? :) [00:56] i have to do that with Oregon Trail with dosbox [00:56] joejaxx: something similar could be said of virtually every package in Ubuntu ;-) [00:56] LaserJock: Except that MC has no jurisdiction over the main people, and are probably going to bend to Canonical requests. [00:56] and i would not want oregon trail in multiverse* [00:57] joejaxx: Ubuntu integration gives you easy installation and easy updates. [00:57] joejaxx: You'll neve have to know it is Windows software [00:57] cyberix: not for windows binaries :\ [00:57] cyberix: yeah that is bad [00:57] Fujitsu: the question was over Universe packages, which is the MC jurisdiction [00:57] :-D [00:58] joejaxx: Well it is not bad from the user experience perspective. [00:58] this is almost like shipping roms for an emulator we have (well not exactly) [00:58] joejaxx: fairly similar, yes [00:59] sudo apt-get install efp [00:59] cyberix: What is the integration you speak of, other than apt-getting? [00:59] is an example [00:59] if it's legal then there's no inherent reason not to [00:59] we can ship the emulator, but shipping the ROMs falls on a slippery slope [00:59] crimsun: yeap [00:59] Fujitsu: desktop-file, mime-type integration, icon, man page [00:59] Shipping freeware Windows binaries is a very slipper slope. There are a lot of them. [00:59] *slippery [01:00] * minghua agrees with Fujitsu. [01:00] Multiverse is a slippery slope [01:00] people maybe should've thought of that in the beginning ;-) [01:01] And never underestimate some develop's dislike of non-free software. [01:01] * joejaxx does not want Ubuntu to end up like Linspire lol [01:01] You risk losing developers if you decide opening multiverse to all kinds of closed "freeware". [01:02] now i forgot what i was going to do [01:02] ok right the flwm bug [01:02] IMO, multiverse is for stuff which is almost free (ie. we have source, but it isn't free enough for multiverse), stuff that is restricted in some jurisdictions, and important very non-free stuff like Adobe Flash. [01:02] http://revu.tauware.de/details.py?package=pq [01:02] And multiverse use should be minimised. [01:03] personally, cyberix, it would be worth investigating whether it can be offered via CNR [01:03] Fujitsu: ok, but that is stated nowhere [01:03] Fujitsu: things that would be a serious inconvenience to users if we didn't have them [01:03] 'The "multiverse" component contains software that is "not free"' [01:03] LaserJock: Right, we need a decision on that, which can only come from the TB. [01:03] crimsun: I have no interrest in that as I've never used CNR and probably never will. [01:03] ajmitch: Right, that's a better way of putting it. [01:03] And in the case of things like flash, I prefer a installer (i.e., pulling the non-free bits at install time) over a full package any day. [01:03] crimsun: But that might be just a sarcastic comment. [01:04] Btw [01:05] Please tell me, if I can improve pq package in someway. [01:05] Except for reverse-engineering it and producing the source code. [01:05] lol [01:05] On a different topic: what is the proper way to push a main package merge? Should I just wait patiently in the -main-sponsors queue, or should I hunt sponsors actively? [01:06] minghua: I waited a couple of days, then attacked Hobbsee about it. [01:06] minghua: it took a while for my packages to get through [01:06] so we have 434 source packages in Multiverse (gutsy), that seems like more than "serious inconvenience" [01:07] Fujitsu: Sounds fair, I'll wait for a while. [01:07] and there are still some that have not been uploaded since last release [01:07] LaserJock: A lot of that is from Debian. [01:07] minghua: which? [01:07] crimsun: scim-hangul, bug 155046. [01:07] Launchpad bug 155046 in scim-hangul "New upstream version 0.3.1 is available" [Wishlist,Confirmed] https://launchpad.net/bugs/155046 [01:07] Fujitsu: sure, I'm just saying we've never been picky before [01:08] but clearly we need to be clear on the purpose of Multiverse [01:13] Why would developers be upset if there was a repository with non-free stuff (ie. freeware)? [01:13] minghua: uploaded to hardy. [01:14] somerville32: ummm, because we're into FLOSS :-) [01:14] crimsun: Thanks! [01:14] somerville32: because they swore an oath to uphold the morality of Free Software... [01:14] pwnguin: hehe [01:14] soren, it is kind of like not providing support to people using Windows just because they use a non-free system? [01:14] Gah [01:14] Sorry soren, stupid auto-nick complete. [01:15] somerville32: we don't support Windows [01:15] we dont "support" things in universe/multiverse anyways :P [01:15] Right. [01:15] pwnguin: yes we do [01:15] LaserJock: Dental FLOSS for All! :D [01:15] LaserJock: the homepage disagrees [01:15] * LaserJock bangs his head against a wall [01:16] pwnguin: it is community supported [01:16] [01:16] lol [01:16] (which are quite misleading) [01:16] LaserJock: ... which sometimes (or for some packages) is non-existent (IMHO). [01:16] minghua: that's fine [01:17] I think the issue is pretty complex. [01:17] but it's just plain wrong to say that Universe is *not* supported [01:17] so its more of a heisenburg uncertainty support [01:17] FLOSS on one side, providing easy to install software to provide a better experience on the other. [01:17] where you dont know if the developers care or not until you look [01:17] I actually have been thinking for quite a while that we need a "galaxy" component, larger than main but smaller than universe. [01:18] what would it encompass? [01:18] minghua: What problem does that solve? [01:18] minghua: I know, but it's just too many components flying around === Zelu1 is now known as Zelut [01:18] i.e. a MOTU core set of packages [01:18] Stuff that we think is sane, and maintain fairly well? [01:18] presumably the set of universe packages that people will "maintain" [01:18] persia: So that users know which packages are better supported, and which ones are "completely on your own"? [01:18] as set of packages that MOTU commits to supporting [01:18] that'd have about 10 packages in it? [01:18] whatever support means [01:18] * TheMuso can't wait to get back into Universe work... Just as soon as he fully recovers from the flight. [01:19] TheMuso: yay! :D [01:19] 10 might be optimistic ;) [01:19] why don't we all just go to debian when that happens? :) [01:19] is anyone in MOTU on the security team? [01:19] ajmitch: lol :D [01:19] minghua: I suppose, but I suspect that it would just encourage people to not care more about the remainder of universe [01:19] pwnguin: which one [01:19] swat? [01:19] or core [01:19] pwnguin: The security team is made up of Canonical employees, and does main only. [01:19] pwnguin: we have a MOTU Swat team [01:19] (well +restricted) [01:19] Fujitsu: really? al Canonical? [01:19] *all [01:20] im aware that security is all done in main [01:20] persia: Well, can't be too much worse than current situation, if you pardon my pessimism. [01:20] i was wondering _if_ security was to be provided to some portion of MOTU [01:20] persia: concur, and I'm not sure an additional component of that sort would not place undue burden on the active MOTU. MOTU is mostly fluid IMO. [01:20] whether there was any actual experience in MOTU for it [01:20] minghua: I disagree, but don't see value in arguing about who might be motivated to do waht. [01:20] crimsun: That matches my thoughts well. [01:20] tonyyarusso: Yes, they have embargoes to keep and the like. [01:21] Fujitsu: what's that? [01:21] pwnguin: I don't agree that all security is done in main, what do you mean by that? [01:21] pwnguin: sure [01:21] motu swat [01:21] not that a volunteer couldn't maintain an embargo [01:21] persia: Now that I've raised it here, at least I know you and crimsun are against it, which is good to know. I was never sure about the idea myself. [01:21] ajmitch: Many do, for specialised cases. [01:21] pwnguin: universe/multiverse security, like SRU, is best-[community]effort [01:21] however there are restrictions for the security community on who's allowed on vendor notification lists [01:22] so any volunteer would need to be trusted & vouched for [01:22] * persia notes that "community" in terms of universe support often includes employees of various sponsoring firms [01:22] of course, that's the way things are meant to be [01:22] ajmitch: True. I was thinking of people who had a non-Ubuntu relation to those lists. [01:22] minghua: it's not so much that I disagree as much that I'm just not sure it would be a real change from status quo [01:22] since canonical is not meant to be the only player in town [01:22] Do most users even really understand where the software is coming from? [01:22] somerville32: hopefully not too much [01:23] as long as it's Ubuntu [01:23] * pwnguin hopes that users are aware of the upstream concept [01:23] another reason why it's tricky to stick random windows binaries in multiverse [01:23] pwnguin: lol [01:23] minghua: I think a real step toward an additional component with such guarantees would have to involve monetary compensation [and all of a sudden, Canonical would start to move toward what Red Hat did some years ago - and failed at IMO] [01:24] crimsun: You raise valid concerns. And it's definitely true that changes without significant perceivable gain should not happen. [01:24] rather than a component I'd rather see a priority list [01:24] or a priority set of packages [01:24] "we choose to ignore X,Y & Z before ignoring A, B & C: [01:25] we shouldn't waste too many resources messing around with packages that are often unused, obsolete, or just useless [01:25] Could someone clear the situation a bit by posting a new comment to REVU http://revu.tauware.de/details.py?package=pq [01:25] crimsun: Hmm. I never thought that way. My main thoughts is that I can give my non-geeky friends a pointer and say "only install stuff from these repos, and you should be fine, for now and for future upgrades." [01:25] Of course it will not be a solution [01:25] LaserJock: as frequently happens with unmet deps, FTBFS lists, etc [01:25] LaserJock: I don't really think that's ideal. Each person (or team) might set a priority list, but I doubt my priorities match others, and I enjoy trolling the rcbugs list, which is not generally priority packages. [01:25] But rather the process that will follow [01:25] persia: you're one of the few people who claims to use that list :) [01:26] crimsun: Right now I can only point main to them, and that is usually not enough. [01:26] persia: right, but I really don't care what you do ;-) [01:26] you can do whatever you like [01:26] minghua: playing devil's advocate, such a component would nearly be all of Ubuntu universe synced from Debian ;) [01:26] LaserJock: Right. You shouldn't care what I do, which is why I don't like the idea of generalised prioritisation. [01:26] why not? [01:26] Which goes back to the words LaserJock was against -- but I do tell my friends "universe is unsupported, you are on your own if you install stuff there." [01:26] * pwnguin wonders what percentage of MOTU-ers can write source patches for upstream. [01:26] ajmitch: Dktrkranz does quite a bit as well. [01:27] ive seen several people declare programming was not a nessecary trait for MOTU-ship [01:27] can or do? [01:27] can [01:27] pwnguin: would depend on the programming language I'd guess [01:27] pwnguin: I can & have done so [01:27] I don't think we have any MOTU who haven't done upstream patching at some point. [01:27] I don't think I can and never have [01:27] for code anyway [01:27] pwnguin: That's true, as long as one can read code well, knows the basic packaging utilities, and is very concientious [01:27] :) [01:27] ok, well, there's LaserJock. [01:27] I haven't done any java patching, of course [01:27] ajmitch: :P [01:28] but have done soe for C#, C, php & python [01:28] I think any MOTU should be at least familiar enough with a language [01:28] crimsun: Nah. I don't encourage those friends to use unstable. :-) [01:28] * Fujitsu has attacked Python, C, C++, Erlang. [01:28] (the last took a long time, and I didn't know the language prior, but...) === Frogzoo_ is now known as frogzoo [01:29] minghua: see, this is the issue [01:30] if Universe is less supportable than Debian (which is also community supported) then we have issues [01:30] we do have issues [01:30] It is implicitly less supportable. [01:30] No if, it's a fact that Ubuntu release's universe is less supportable than Debian stable. [01:30] It is much less maintained, we don't have people experienced in the maintenance of each package... [01:31] I would even say it's less supportable than testing. [01:31] LaserJock: Part of that is about process. We're not good at taking advantage of the work in Debian to maintain universe. We need more / better tools, and more people actually maintaining the release, rather than working on the next one. [01:31] Maybe on GNOME/KDE/XFCE/Multimedia main front it's quite supportable, but it pretty much fails everywhere else. [01:31] minghua: is vs should be is my point [01:32] whats the difference between maintaining a release and working on the next one? [01:32] pwnguin: SRUs [01:32] Universe should inherently be as supported as Debian [01:32] accountability, I think, is tied to compensation, which becomes a ... charged point. [01:32] I just can't see the difference [01:32] LaserJock: How? [01:32] from what i can tell, SRUs are practically discouraged [01:32] We have nobody. [01:32] LaserJock: I understand what you mean. In ajmitch's words: we do have issues. [01:32] LaserJock: people claiming responsibility for packages [01:32] pwnguin: I wouldn't say that [01:32] right, so should we not fix the issues rather than giving up? [01:32] pwnguin: That's not quite true, we're just not as motivated as we should be. SRUs are much more encouraged than Debian stable updates. [01:33] and RMs who *will* remove a package from an upcoming release if it's not up to scratch [01:33] LaserJock: How so? ~30 MOTUs vs. ~500 DD and maintainers? [01:33] ajmitch: I would certainly like that removal policy. [01:33] LaserJock: fixing the issues requires resources, and we've seen that the handful of MOTU are stretched tremendously [01:33] minghua: exactly! [01:33] * pwnguin doesnt like that policy [01:33] Fujitsu: We need a pocket for it, and we don't have one... [01:33] much of the software i use is not finished [01:33] it is a resource issue, not a policy issue or inherent issue [01:33] but usable [01:34] Fujitsu: it only works due to the stable/testing/unstable split [01:34] example: desmume [01:34] LaserJock: No, some policies have a effect on small (active) MOTU number, IMO. [01:34] We released Gutsy with a heap of libapache-* unmetdeps, because they might have become useful again in the future. [01:35] We need a way to blacklist packages from release, but I can't see how that would work. [01:35] minghua: but we have no policy that states that Universe is any less supported than Debian [01:35] Fujitsu: Right, so we should be following up with SRUs to get that cleaned up. [01:35] !roadmap [01:35] Sorry, I don't know anything about roadmap - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi [01:35] persia: SRU removals? I don't believe that to be possible. [01:35] _( [01:35] :( [01:35] LaserJock: we have no policy stating the level of support at all [01:35] ajmitch: sure we do [01:35] Fujitsu: No, SRUs to make the broken packages either work or be dummy packages [01:35] http://www.ubuntu.com/community/ubuntustory/components [01:35] apparently "community" is a level of support? [01:35] (same source, but don't install as much) [01:35] persia: They're not going to be made to work, and making them dummy packages is probably silly. [01:36] I have my theory about why MOTU, having a much more friendly atmosphere, fails to attract my contributors than Debian. But it's probably not the right time/place to talk about it. [01:36] minghua: because we don't scale at getting new people in [01:36] Fujitsu: Maybe. I don't like having anything that looks like it should work and just plain can't be installed. [01:36] LaserJock: that states what support won't be given :) [01:36] minghua: because we're technically incompetent? [01:36] persia: Is that any worse than having a package that doesn't do anything, where it did in other releases? [01:37] minghua: your contributors? [01:37] ajmitch: well, that's a typo ;-) [01:37] Fujitsu: Yes. With a dummy, there's a note in the changelog on upgrade. With unmetdeps, the user has to figure the problem out on their own. [01:38] persia: It would be better to remove them, wouldn't it? There's nothing to transition to, so no purpose for a dummy. [01:38] LaserJock: No. I tends to think it's a social issue than a technical issue. [01:38] joejaxx: Please rephrase, I don't understand. [01:38] minghua: 20:36 < minghua> I have my theory about why MOTU, having a much more friendly atmosphere, fails to attract my contributors than Debian. [01:38] * Fujitsu notes that Ubuntu would generally attract less technically-competent people, so... [01:38] Fujitsu: I thought you said we were keeping them because we expected them to work again in the future. I don't like to remove anything not being removed permanenty, because we don't have the infrastructure to handle that properly. [01:38] joejaxx: Oh. s/my/more/. [01:39] minghua: what did you mean by that? [01:39] oh [01:39] ok [01:39] persia: I can't see them becoming useful again, but we won't generally remove things unless they're removed from Debian or will not become useful again. [01:39] minghua: social as in being too friendly? [01:39] well obviously MOTU is in trouble because Canonical hires the qualified ones to work on core dev type stuff ;) [01:40] pwnguin: not often enough [01:40] The bugs about libapache-* have been sitting in Debian for about 6 months, and nothing has happened on most of them. [01:40] and the rest of us just drift away :) [01:40] ajmitch: :P [01:40] LaserJock: Not really, but related. However as I've said, it's not the right time/place for me to discuss it. [01:40] joejaxx: well I'm obviously not qualified :P [01:40] Fujitsu: If you think they should just be removed, I'm good for that: we don't have to wait for Debian. It's just in the case where there is a temporary uselessness that I'd like to keep a dummy around until we get it fixed. [01:40] ajmitch: bah :P [01:41] persia: The archive admins generally question that. [01:41] well back to merges :D [01:42] Fujitsu: They do, but tend to agree if the case is well presented. Do your research, present the documentation, and they will be gone. Just don't expect the archive-admins to be happy if they have to come back in the future. [01:42] * persia pokes joejaxx with mhwaveedit again [01:42] persia: i will take a look [01:43] :D [01:43] * ajmitch has no universe merges to do [01:43] ajmitch: You could upload new Debian revisions, and merge those :) [01:43] lol :D [01:44] so under what circumstances should one pursue an SRU? [01:44] would it not be better if grab-merge.sh created a directory with the name of the package and pulled everything to there? [01:45] pwnguin: easily understood, minimally invasive fix [01:46] pwnguin: i.e., someone in ubuntu-dev can eyeball and understand it and confirm that it fixes the issue [01:46] persia: there are not present conflicts for that package :\ [01:46] pwnguin: SRUs should be done if 1) the package is completely broken (doesn't install, FTBFS, cannot execute, etc), 2) there is a problem with a supported upgrade path, 3) There is an annoying and obvious bug that blocks user workflow or can cause data loss, for which a clear and small patch is the correct solution, and 4) you really, really, really want to. [01:46] joejaxx: Not really. Thats kinda how I work already, i.e create a dir of the sourfce package name, and dump contents in there. [01:46] joejaxx: Yep. It's a very easy merge. Don't forget to file the Debian bug about the .desktop. [01:46] TheMuso: yeap that is how i do it too [01:47] * Fujitsu notes that everybody is resigning from the IRC team these days. [01:47] Fujitsu: IRC is hard [01:48] i cant imagine how that set intersects with the available talent into significantly more SRUs [01:48] Fujitsu: from which team? [01:49] ajmitch: IRC ops. [01:49] ah, I should probably unsubscribe from there as well [01:49] pwnguin: Most cannot-install bugs and FTBFS bugs aren't that hard to fix: often just playing with dependencies. Most cannot start bugs are due to Debian/Ubuntu infrastructure differences, and not too hard to solve. Lots of them have solutions in Debian, or in the BTS. [01:50] hopefully liw's testing tools will make it easier to identify these? [01:50] im suprised it took so long, really [01:51] we were waiting for people to come along & tell us how we should have been doing it sooner [01:51] pwnguin: Maybe: other tools may also help. What it really needs is people who do the released work: some people shy from SRUs because they run development (which is usually broken in some way), and aren't prepared to test. [01:52] pwnguin: Running such tests takes a non-trivial amount of computing resources. [01:52] installing packages? [01:52] pwnguin: Yes, when installing 25,000 packages [01:52] pwnguin: you have a full mirror of universe & time to install/uninstall/purge every one? [01:53] * joejaxx is going to run lintian on all the package [01:53] :D [01:53] packages* [01:53] (and possible combinations to detect correct use of "conflicts") [01:53] cool, we've found ourselves some volunteers! [01:53] joejaxx: /me already does that. [01:53] joejaxx: Fujitsu does that twice a week. I forget the URL offhand, but I'll dig it up. [01:53] no, but in the scheme of building from source an install test seems like a drop in the bucket... [01:53] Fujitsu: :D [01:53] pwnguin: you think any of us build all of universe from source? [01:54] no [01:54] but LP does [01:54] no, it doesn't [01:54] we'd like it to [01:54] pwnguin: We only touch ~2000 packages out of ~14000. It's the other ~12,000 that need help [01:54] which parts of universe doesn't LP build? [01:54] it's more which parts doesn't it *re*build [01:54] pwnguin: Anything not uploaded during the current release cycle [01:54] pwnguin: You would need to do it fairly regularly. [01:54] pwnguin: None at all. [01:54] hmm, another logistical SRU question [01:54] since there are binary packages in there which date back to warty or hoary [01:54] jdong: Go! [01:55] heh [01:55] which don't install or build anymore [01:55] is it OK for a Gutsy SRU to roll back a package to Feisty version? :( (gtkpod-aac) [01:55] what happened is that someone blindly uploaded the new upstream release of gtkpod-aac without realizing our libmp4v2 is too old for this new release [01:55] jdong: Umm.. There was an API change involved there: I'm really not sure that's the best solution. [01:55] and gtkpod-aac in fact does not use AAC [01:55] persia: I'd expect feisty sources to compile on Gutsy with minimal changes, right? [01:56] persia: the only iffy part would be libgpod.... [01:56] Ugh. Not again. The person who upload that should be reprimanded IMHO. [01:56] jdong: I don't remember exactly. Ask LucidFox or StevenK (who did the transition). You can try. [01:56] minghua: oh this has been discussed? [01:56] afaik it wasn't me that broke stuff this time [01:56] ajmitch: Mostly from apt-get.org or other random repos. [01:56] jdong: No, just that I've seen the same thing happen on one of my Debian packages. [01:57] Fujitsu: No, there's also stuff from sid that hasn't been rebuilt for any supported release [01:57] minghua: Isn't that normally tepsipakki? [01:57] persia: anything that was imported as source, was built (or at least an attempt was made) [01:57] minghua: ah, ok [01:58] Fujitsu: I don't remember who it was in my case. But that was long ago. I was just hoping such things are not happening these days. [01:58] persia: well I'll just give a simple braindead prevu build a shot, and see what extent of changes are necessary to roll back. [01:58] ajmitch: Right, but we've sources from sid that haven't been rebuilt since warty/hoary [01:58] Apparently (and disappointingly) not so. [01:59] hi :D [01:59] ready for REVU day? [01:59] nxvl: lol [01:59] jdong: If you can find a (small) patch rather than a complete rollback, you'll probably have an easier time getting it introduced (but a rollback may be easier than a huge patch) [01:59] nxvl: It's been underway for 15 hours already! [02:00] persia: here comes in 3 hours :P [02:00] gos i hope this libx fixes X [02:00] god even [02:01] persia: does this look good to you? https://people.fluxbuntu.org/~joejaxx/ubuntu/merges/mhwaveedit_1.4.13-1ubuntu1.MERGE.debdiff.txt [02:02] i feel like getting anothe Sprite lol [02:02] get me one [02:02] What is the wiki page for details on how to get a sponsor for main? [02:02] joejaxx: your pancreas would hate you :) [02:02] persia: well the rollback idea failed miserably; now let's see if I can force gtkpod at gunpoint to use our libmp4v2 :) [02:03] joejaxx: Close. You'll want the Debian .po files to make the diff smaller (or to mention something in the changelog) [02:03] somerville32: I don't think there is a specific one for main, but the general page is quite detailed, and mentions both main and universe merges. [02:03] jdong: Good luck. I seem to remember the API being completely different, so you'll get to have some fun :) [02:03] somerville32: same as for universe, except subscribe ubuntu-main-sponsors [02:03] * joejaxx sends ajmitch a Sprite over the internet :D [02:04] persia: we want the debian translations? [02:04] persia: yay, lovely.... :) [02:04] joejaxx: We either want the debian translations or we want to mention the difference in the changelog. My swedish isn't up to taking a decision which. [02:05] oh ok [02:05] i guess we can keep the ubuntu ones [02:05] i will mention it in the changelog [02:05] joejaxx: Also, check the Russian: it looks like a codepage error. [02:06] is there way to force dch to write a dist you want? [02:06] -D [02:06] persia: pfft the new API is only used to do volume normalization headers on AAC [02:06] i thought there was a flag for that [02:06] persia: lemme see what I can do about that ;-) [02:06] crimsun: ah! yes thanks [02:06] jdong: Great. Thanks. [02:08] persia: hmm [02:08] jdong: is gutsy-backports open? [02:08] minghua: yep [02:09] jdong: Any authoritative procedure page? https://wiki.ubuntu.com/BackportRequestProcess looks outdated. [02:09] minghua: what do you need uploaded? [02:09] minghua: What's outdated about that page? [02:09] minghua: it's still correct, use the $distro-backports project on LP [02:09] crimsun: The scim-hangul you just uploaded. :-) There is a user requesting gutsy backport. [02:10] oh, right. [02:10] persia: what does the formatting for the translation files mean? [02:10] well, if you can't wait for it to be available in hardy, I could toss it into gutsy-backports manually. [02:10] persia: The "How to request a package to be backported" section doesn't mention gutsy at all. [02:10] * joejaxx has not dealt with po files before [02:10] joejaxx: I need a little context. [02:10] well for example [02:11] in my patch in the ru file [02:11] evening [02:11] it drops lines saying #~ [02:11] hello zul [02:11] hello zul [02:11] anyone know the status of X fix in hardy by chance? [02:12] hey ajmitch and joejaxx [02:12] joejaxx: I believe those to be comments [02:12] i hope they backport any fixes :( the open ati driver is messed up :( [02:12] gnomefreak: Waiting on compiles to see if that works. If not, there may be a poke later in the week. [02:12] crimsun: "well, if you can't wait for it to be available in hardy, I could toss it into gutsy-backports manually." Is that to me? [02:12] persia: to see if what works? [02:12] persia: what were you referencing when you said there was a issue with the russian po file? [02:13] minghua: yes [02:13] gnomefreak: X [02:13] crimsun: If yes -- I can wait, but I am completely new to this backport business. [02:13] persia: missing depends is all it is afaik [02:13] minghua: ok, then I recommend using the -backports project procedure [02:13] joejaxx: I'm not in the target environment, but I see strings like "[S] ðÒÏÔÑÇÉ×ÁÎÉÅ ×ÒÅÍÅÎÉ". If you see Cyrillic, everything is good. [02:14] gnomefreak: Right, but there's a huge build queue... [02:14] crimsun: I'm just trying to figure out if I should do it myself or ask the user who requested it to go through the procedure. [02:14] oh its been uploaded? [02:14] minghua: I'm pretty sure you would need to ack the non-dev backport request [02:14] crimsun: Sure, I'll follow the -backports project procedure. [02:14] gnomefreak: https://launchpad.net/ubuntu/hardy/+queue [02:14] * gnomefreak gonna have to assume its been tested prior to uploading ;) [02:14] persia: you are right [02:14] persia: i see ??????? [02:14] but in the debdiff they are not ?????? characters [02:14] I'll ack (I tested the backport), it's just the procedure is a bit unclear to me... [02:15] joejaxx: I don't imagine our Russian users will be most pleased by that. Most seem to be using Audacity for recording, but they might want to play with mhwaveedit too :) [02:15] joejaxx: What do you see in the debdiff? Ideally, it's all UTF-8, and properly marked as such. [02:16] +msgid "[B] Volume adjust/fade" [02:16] +msgstr "[B] ðÏÄÓÔÒÏÊËÁ ÇÒÏÍËÏÓÔÉ" [02:16] gah [02:16] is autogen.sh what turns configure.in -> configure? [02:16] it did not paste correctly [02:16] joejaxx: Yeah. That doesn't look ideal. [02:16] i see letters with accent marks on them [02:16] jdong: i think so [02:16] * ajmitch does not see utf-8 encoded characters there :) [02:17] and I've seen more than enough russian to say that's not it :) [02:17] * gnomefreak hasnt see an autogen.sh in a while [02:17] jdong: autoconf, auctually. [02:17] actually* [02:17] autogen.sh build package? [02:18] joejaxx: So, something is funny. You might want the Debian translations for now, and look at it later. Alternately, you could try to fix it now. Depends on if you are willing to set up a Russian locale, and try the program. [02:18] yeah i have not tried playing around with locales before [02:18] joejaxx: Essentially, I don't think we should be introducing broken translations, although I fully admit that not everything is well translated. [02:18] so drop all of them? [02:19] persia: you read it well enough to see that it's broken? [02:19] joejaxx: If you've an Ubuntu patch, and it's introducing a bug, it's better to take the Debian solution :) [02:19] ok [02:19] PO's encoding/charset is clearly noted in the PO file itself. It's not necessarily UTF-8. [02:19] ajmitch: I'm not on Ubuntu right now, so I can't test. I'm just guessing from the debdiff. [02:27] somerville32: what did you need? [02:29] joejaxx: If you're having trouble testing, and get stuck on the PO, stick your in-progress debdiff in a bug and subscribe me: I'll test it in ~ 9 hours. [02:30] persia: https://people.fluxbuntu.org/~joejaxx/ubuntu/merges/mhwaveedit_1.4.13-1ubuntu1.MERGE.debdiff.txt i dropped all of them [02:30] persia: ok [02:31] persia: I think I got it :) [02:31] persia: lemme build test before embarassing myself ;-) [02:31] joejaxx: I'm good for that: I don't see any changelog entries to explain the Ubuntu .po files anyway. [02:31] persia: ok [02:31] persia: yes that is why i thought it was weird [02:32] bddebian: You about? Do you happen to have any memory remaining about the mhwaveedit 1.4.7-2ubuntu1 merge? [02:32] I did it? [02:32] bddebian: Well, you uploaded my desktop file at least :) [02:32] Ah :-) [02:33] bddebian: Do you remember anything about fussing with .po ffiles? [02:33] Not that I recall but let me look locally [02:33] bddebian: Thanks. [02:34] joejaxx: We'll wait to hear back from bddebian, but I suspect your latest debdiff is the correct one (assuming your local testing is successful) [02:34] ok [02:35] Nuttin' here but your desktop file [02:36] bddebian: Great. That was my memory as well. [02:36] joejaxx: That's it then: the .po variation is just an undocumented artifact of history, likely related to changes upstream. [02:39] crimsun, ping [02:39] imbrandon: pong [02:40] heya i'm cleaning up some space / ports , do you still actively use that sid vm ? [02:40] imbrandon: nope [02:40] persia: Do you happen to know conquest? [02:40] cool, ok [02:40] bddebian: Only from the brief look a couple days ago: are you doing the fulll CDBS & quilt migration? [02:41] CDBS hell no, but I have debhelperized it [02:41] bddebian: coward :) [02:41] And I moved the libs so I need to test it [02:42] persia: ok then it looks good to go i guess :D [02:42] joejaxx: Excellent. Subscribe the sponsors queue, and someone will upload it. Thanks for taking care of that. [02:42] joejaxx: Also, if you'd file a Debian bug, it'd be great :) [02:43] persia: you are most welcome [02:43] persia: yeah i have to look up the docs on submitting a debian bug :D [02:43] WHOO! looks like it's accepting it..... [02:44] joejaxx: http://www.debian.org/Bugs/Reporting [02:44] persia: ok thanks [02:55] persia: care to sponsor the debdiff on bug 135168 into Hardy? [02:55] Launchpad bug 135168 in gnome-panel "apta" [Undecided,Invalid] https://launchpad.net/bugs/135168 [02:55] err [02:55] persia: care to sponsor the debdiff on bug 135178 into Hardy? [02:55] Launchpad bug 135178 in gtkpod-aac "[gutsy] gtkpod-aac does not live up to its name" [Undecided,Confirmed] https://launchpad.net/bugs/135178 [02:56] *that* looks more relevant :D [02:56] I've build-tested and iPod-tested the change [02:56] jdong: I don't have access to the tools for such sponsorship currently. How about subscribing the sponsors queue? [02:56] persia: ok, will do :) [02:57] jdong: Just to check: does hardy need any adjustment to match that? I like to avoid SRUs when the bug still exists in the development release. If there is something needed, I'd suggest adding the debdiff to the same bug, and nominating against both Gutsy and Hardy. [02:58] for some reason [02:58] these merges are becoming fun for me [02:58] lol [02:58] persia: the debdiff is to hardy, I'm preparing the Gutsy SRU for it right now [02:58] persia: doing both at the same time will avoid that kind of gutsy-ahead-of-hardy situation :) [02:58] jdong: Ah. I was just confused by the bug title :) [02:58] persia: the bug's old :) [02:59] ok, for SRU, I set version number to ubuntu1.1 or ubuntu1.1~prop1? [02:59] do we still do the ~proposed thing? [02:59] jdong: Absolutely. [02:59] ok, is there a preference between ~proposed1 and ~prop1? [02:59] Err. Set the version number to the version that will be in -updates. It gets uploaded to -proposed, and then sync'd. [03:00] persia: ah, ok, that's different than the last time I did it ages ago :) [03:00] e.g. -32ubuntu17.12 [03:01] Hmm, dh_installman doesn't compress the manpages? [03:02] bddebian: You want dh_compress [03:03] Well I have that but I am getting a warning that one of the manpages is not compressed, while the others are :-( [03:04] bddebian: That usually happens when 1) the manpage is (badly) compressed by something else, 2) the installation sequence is funny, or 3) one of the manpages is in the wrong directory. [03:05] bddebian: In which order are you calling dh_installman and dh_compress? [03:06] dh_installman -a [03:06] dh_link -a [03:06] dh_strip -a [03:06] dh_compress -a [03:06] OK. That eliminates 2). What about 1) and 3) ? [03:07] Well I don't know about 1, I think 3 is out [03:07] (alternately, do you have a binary independent package being built for which you aren't calling these?) [03:07] Yes but no man pages in the -data package [03:08] woohoo :D [03:08] https://people.fluxbuntu.org/~joejaxx/ubuntu/merges/rebuildd_0.2.2ubuntu1.MERGE.debdiff.txt [03:08] :D [03:08] another one [03:08] lol [03:08] persia: the -a option should rule out that possibility. [03:08] bddebian: Does upstream stick a manpage in /usr/share that ends up getting caught in the -data package by dh_install? It never hurts to stick a dh_compress -i in binary-indep [03:08] i think i should start filing bugs for them now lol [03:08] (unless there is arch:all packages involved) [03:08] persia: Shouldn't but I'll check [03:08] minghua: Right, except for arch:all conquest-data :) [03:09] joejaxx: In addition to filing bugs to claim the merges, please check for open bugs on the packages when merging: frequently one can add a couple little things during the merge to make the package even better. [03:09] persia: thanks for your help; nominated, attached the 2 debdiffs, and a testing package for the subscribers. And now we wait :D [03:10] persia: does that not make it confusing though? [03:10] jdong: Excellent. It's Sunday for a lot of people, so the queue might be slow, but it should be in fairly soon. [03:10] doing bug fixes to a merging from debian unstable changeset? [03:10] hello Amaranth [03:10] joejaxx: Not if you write the changelog properly: just clearly indicate what is a new change and what is a merge. Doing it at the same time saves space on the archives and reduces buildd churn. [03:11] persia: ok [03:11] hey [03:11] joejaxx: As an example, look at the mhwaveedit changelog again: for a couple of the merges there was a general cleanup. [03:11] (not that that package gets many bugs) [03:12] yeah :P [03:14] joejaxx: You should check the LP bugs for rebuildd :) [03:16] joejaxx: In particular, the *only* LP bug for rebuildd. [03:16] ahh the wonders of computing , the eeepc is on sale finaly [03:16] who wants to buy me one ? hehehe [03:17] RAOF: yeap already there :D [03:18] What the hell processes .conffiles? [03:18] RAOF: Are you planning a miro merge/sync? I was tempted by the xine-lib transition, but wanted to ping you first. [03:18] persia: Yes, I am. [03:18] bddebian: $ dh_ ... [03:19] persia: It's mostly done, just blocking on me actually testing on a Hardy system. [03:19] Although I'd like to see _just_ how small a delta I can get against Debian. [03:19] RAOF: OK. I'll leave it alone :) Please don't forget to update the xine-lib bug (as it won't show in the changelog) [03:20] persia: Right, thanks. [03:20] RAOF: sync isn't possible? I thought you were close a couple weeks ago. [03:20] persia: xulrunner! [03:20] bddebian: dpkg. But I'm not sure that's the answer you are looking for. [03:20] RAOF: Ah. Right. Pity that. [03:20] persia: We'd need to build against xulrunner-1.9 instead of xulrunner, at least. [03:21] Well conquest has a .conffiles file [03:21] And there are a few more debian/rules niggles I need to push on debian. [03:21] and it doesn't sound like debian will get xulrunner-1.9 anytime soon [03:21] And I'm installing /etc/foo in .install [03:21] Do we have xulrunner (not 1.9)? [03:21] And by the end of Hardy I hope to have no libxine dependency! [03:22] persia: Yes, but it doesn't work. [03:22] persia: and mozcorp really doesn't like it [03:22] * persia wonders why we don't just have xulrunner-1.9-0ubuntu1 [03:22] Errr.. xulrunner_1.9-0ubuntu1 [03:22] persia: Good question. Ask asac :) [03:22] err [03:22] 1.9~a8-0ubuntu2 [03:23] Amaranth: Right. [03:23] it's the xulrunner from firefox 3 alpha 8 [03:23] RAOF: that bug was fixed if you look at the changelogs :D [03:24] bddebian: If dpkg is processing .conffiles (as minghua said), then .conffiles should just end up in DEBIAN/ in the binary, so installing /etc in .install should be fine. The actual processing would take place at install time. [03:24] joejaxx: No, it wasn't. I fixed the FTBFS, but in a way that's now a *dash*-ism. [03:24] although it is ubuntu specific [03:24] RAOF: yes [03:24] that is why i said it was ubuntu specific :D [03:24] joejaxx: I thought the Debian maintainer had fixed it (using the actually portable printf), though? He hasn't yet? [03:24] joejaxx: Not even. Lots of Ubuntu people expect `debuild` to work in bash for a local build. [03:25] persia: I am not sure it's right to have a debian/conffiles (or debian/.conffiles) in source package, or if it requires special treatment in debian/rules. [03:25] bddebian: ^^^ for you, too. [03:25] persia: Those people are _wrong_ and deserved to be punished ;) [03:25] and I didn't think you could even _have_ a dashism [03:26] persia: That's still going to work, though, unless someone has gone to the effort of re-symlinking /bin/sh to bash? [03:26] Amaranth: Why? We often suggest that to users when asking for a local rebuild, etc. to test things. [03:27] RAOF: Does it? Hrm. I thought $SHELL might be exported from bash into make, and come out the other side, but I suppose you're more likely correct. [03:27] Amaranth: You can, by taking the behaviour specified in "man sh" as POSIX, rather than the more correct 'implementation defined'. [03:27] persia: Notice the ';) [03:27] RAOF: err [03:28] shouldn't they all follow 'man sh'? [03:28] Nope. [03:28] Amaranth: You're using "should" again :) [03:28] 'man sh' is not authorititive. [03:29] Much to my chagrin. [03:29] sh(1) man page is diverted to dash(1) if you use dash as /bin/sh. [03:29] otherwise it's linked to bash(1). [03:29] There is simply no man page for POSIX-sh AFAIK. [03:29] So RAOF was looking at dash explaining what _it_ does. :P [03:30] :( [03:32] joejaxx: Anyway, if you're going to do the rebuildd merge, can you fix the bug properly (with printf rather than echo)? [03:32] And then send that patch upstream to Debian? [03:39] I don't suppose any of you would have a chance to look at: http://www.bddebian.com/packages/debian/conquest/ ? [03:43] bddebian, wow Debian/hurd has no installer ? hehe [03:44] pfft :-) [03:46] imbrandon: does Debian/Hurd have a kernel? [03:46] LaserJock, apparently gnumach.gz :) [03:47] http://rubyforge.org/ is pretty cool [03:48] it'd be nice to have one of those for python [03:49] http://cheeseshop.python.org/pypi doesn't count? [03:50] I didn't think so, but maybe [03:51] I was thinking cheeseshop was more listing where rubyforge is more sourceforge-like [03:51] RAOF: sure [03:51] gah [03:51] lol [03:51] * joejaxx does not like being pulled into the submit a debian bug pool [03:52] I don't think cheeseshop has a sourceforge-like platform either. But I don't think it's very important. [03:52] Does CPAN have a sourceforge-like platform? [03:53] well, I think it's important if you're building projects rather than libraries [03:53] libraries don't tend to need screenshots and things like that, the bling ;-) [03:54] does that make sense? [03:54] man i'm so utterly bored with the day to day the last few weeks [03:54] amen brother [03:55] few weeks? [03:55] yea its slowly getting worse, what do yall do to over come boredom at the computer ? [03:55] Buy The Witcher ;-) [03:55] hehe [03:56] imbrandon: step away from the computer [03:56] ajmitch, i did that, no help really [03:56] find another hobby [03:56] hobby? what's that? [03:57] hehe [03:57] hrm maybe a new webapp or work on an existing one, i always like to do that [03:57] * imbrandon ponders [03:57] * LaserJock too [03:58] * joejaxx likes the word ponder [03:58] i do wonder something though, why do the people on ubuntuweblogs.org not just add them selfs to planet.u.c ? i mean i dont see any that arent ubuntu members yet [03:58] * joejaxx ponders submitting debian bugs [03:59] imbrandon: maybe they are not ubuntu members? :D [03:59] oh [03:59] maybe they do not know [03:59] * ajmitch ponders blogging & decides not to [03:59] I've given up on trying to figure out why people do what they do [03:59] what? Nobody's going to tell me about the next newest Nokia device? [04:00] I can't even figure out why I do what *I* do [04:00] jdong: the new one is nice [04:00] jdong: it has gps [04:00] or tell me how to roll back my Gutsy kernel to a tribe 2 kernel to let my macbook suspend? [04:00] that is crazy [04:00] LaserJock: I don't know either [04:00] * jdong glares at joejaxx :) [04:00] LaserJock, hahah me either [04:00] joejaxx: yes, and I'll read Planet Maemo for my Nokia drooling :) [04:00] * imbrandon is wishing for an eeepc [04:00] 400$ on newegg === bryce_ is now known as bryyce [04:01] imbrandon: it looks cool [04:01] joejaxx: I'll forward it to Debian if you really want. [04:01] imbrandon: I wish they would increase the formfactor a bit in order to get insane battery life though... [04:02] RAOF: no i need the experience [04:02] :D [04:02] imbrandon: Join me on the games team, it's "fun" ;-) [04:03] joejaxx: The big value in submitting the Debian bugs is that you get the satisfaction of syncing next time, and don't need to do a merge. [04:03] you know its a catch22 , i'd love to install and test and put diffrent devices through the ringer, specialy pda/mobile/sub-notebook computers but to get new ones from the mfg you have to already do that [04:03] persia: you mean the big value is that the next time you want to moan about Launchpad, you'll think twice? [04:03] hehe [04:04] jdong: Well, that helps, but the BTS isn't that bad. [04:04] persia: it's defintiely better than LP if manipulating the BTS is something that you have to do extremely often; but for occasional bugfiling the by-mail UI is a bit unintuitive/troublesome [04:05] jdong: Perhaps. I have a template that I copy in, and just fill out a couple fields and attach a (tested against Debian) patch. [04:06] persia: well once you have a template then yeah it's simple [04:06] yea the only thing worse than a email only BTS is a usenet only BTS [04:06] imbrandon: haha [04:06] BTS-over-azureus? :D [04:06] imbrandon: No. There are web forms that submit email to mail-to-news gateways... [04:06] crimsun: who normally does lts upgrade testing? [04:06] services imho should be avaible in as many forms as possible, especialy FL/OSS ones [04:07] imbrandon: is there any reason Debian doesn't provide a web-based UI? [04:07] jdong, no idea [04:07] I'll take Debian's BTS over sourceforge BTS any day. [04:07] no one has coded it ? [04:07] (even I haven't gotten familiar with Debian BTS) [04:08] bddebian: LOL [04:08] well thats where we differ in opnion i think, i refer to it as a BTS because thats what they claim it is, to me its just a database full of emails, nothing more [04:08] jdong: imbrandon: part of it has to do with quality-of-bug concerns. There's a group working on a front-end and a process to filter appropriately. [04:09] does anyone know who does lts {,upgrade} testing? [04:09] Debian BTS has a SOAP interface, in case anyone doesn't know that (and know what SOAP means). [04:09] joejaxx: This will be our second LTS, so there's no precedent. You're welcome to jump in and help. [04:09] minghua: NICE [04:09] And how is it hard to get familiar with Debian's BTS? It's just e-mail. [04:09] minghua: really!? [04:09] persia, bah thats just debian .... ummm whats the word for it ........ , not sure atm but point is there are TONS of BTS's with webui's infact debians is the only one i know of that dosent have one [04:09] persia: crimsun mentioned me taking it on [04:10] LaserJock: sure. [04:10] ...seems quite some people here don't know that... [04:10] minghua: I did a *very* little of SOAP and thought it was pretty cool [04:10] StevenK, its not the point of getting used to it, its the point i CANT do it another way if i choose [04:10] joejaxx: Excellent. I'm glad to hear it. Thanks. [04:10] I know there is a web interface for BTS in the works [04:10] http://wiki.debian.org/DebbugsSoapInterface [04:10] you can even search the BTS via LDAP [04:11] persia: i think i will create a lp group for it as well so we can get some centralized stuff going [04:12] ajmitch: if you want to spend eternity doing it ;-) [04:12] persia: or should i say organization [04:12] gah [04:12] joejaxx: That'd be great. You might also want to ping Dktrkranz who was looking at getting either piuparts or some pbuilder scripts to automate some of the testing. [04:12] persia: ok great [04:12] imbrandon: Okay, fine. Whagt do you want to do with a Debian bug that you can't? [04:13] file one via a webui, or update the status of one [04:13] imbrandon: Well, you can't, so cope. [04:13] should we perhaps get machine/hosting stuff figured out before we scatter stuff about? or not perhaps? [04:13] i touch email as little as possible [04:13] imbrandon: I've not filed a Debian bug not using a browser in years. It just requires the right front-end. [04:13] imbrandon: Changing the status is a very simple e-mail to control@bugs.d.o [04:14] imbrandon: I'm with you, I've got an allergy to BTS ;-) [04:14] imbrandon: Fine, it which case use the 'bts' command line tool and reportbug. [04:14] StevenK, i know how to , i mean via bugs.d.o when i'm looking over my bugs i cant change them easily [04:14] LaserJock: that eternity is why I decided not to use the LDAP interface for the rc bugs list [04:14] ajmitch: yes, I remember [04:15] that's really sweet though that they have it [04:15] imbrandon: Look in one of the little packages of debian developer scripts (I forget which one). There is a tool to modify/update the BTS from the command line. [04:15] that might be ok , as long as it hasent been modified for ubuntu like reportbug [04:15] Yes. It's in devscripts and it's called 'bts' [04:15] I mentioned it like two minutes ago. [04:16] * persia thanks StevenK for propping up my failing memory [04:16] that still requires me to go from looking the bugs over on the web then switching to console and doing what i need/want [04:16] not a very good workflow [04:16] is there any documentation on the REPORT file? I'm trying my best here but this is a lot of new information :) [04:16] * ajmitch notes that emacs integrates well with the BTS :) [04:16] imbrandon: Okay, in which you just whinging and I'll stop helping you. [04:16] imbrandon: You can also view the bugs from the command line :) [04:17] StevenK, no i mean really , i'm being serouious, if i'm over looking something cool, by all means, but i'm not whigning for the sake of it [04:17] imbrandon: bts has a "cache" command, too. [04:17] Zelut: Not really. The goal is to apply any relevant outstanding Ubuntu patches to the Debian package. If REPORT isn't helping, you might do well to look at the package differences directly. [04:17] Just learn the available tool. [04:18] you know it would be really nice since LP imports ( or did at one time ) debian bugs, it would interact back with them via that soap interfact [04:18] interface* [04:19] persia: as I understand there have been changes from the base in debian and ubuntu and it needs to be decided which will be used in this package? [04:19] persia: is it just a matter of removing lines >>>>> / <<<<< one way or the other? [04:20] Zelut: Mostly. The Ubuntu package is based off a previous Debian package. There have been updates in Debian, and the Ubuntu variations need to be reviewed to see if they are still relevant. At the conclusion, you seek a new Ubuntu package based off the new Debian package. [04:21] Zelut: blindly selecting one or the other from the <<<<<< / >>>>>>> lines may do the right thing, but it is nearly as likely to result in a package that neither matches the new Debian package nor includes all relevant Ubuntu variation. [04:21] and might even result in a sound thrashing ;-) [04:21] persia: I feel like what I'm missing here is some more experience with diff/patch [04:22] LaserJock: hey, I've got to start someplace.. I'm trying here :) [04:22] Zelut: Of course, if you understand your target goal, just removing the conflict lines may be the easiest way to generate the merge candidate: you want to first understand, and then plan a solution (for which MoM may be helpful) [04:22] Zelut: Ah. In that case, I'd recommend you look for some bugs, rather than merges, and follow https://wiki.ubuntu.com/MOTU/Contributing to build some experience. [04:23] I thought I'd try to start with something simple from merges.ubuntu.com [04:23] a good starting place is to look at all the the Ubuntu changelog entries [04:23] StevenK, ohhh `bts` looks nice [04:23] serouisly [04:23] I'm trying htop [04:23] Zelut: diff tools are great :D [04:23] persia: hi! [04:24] imbrandon: hi [04:24] Zelut: I think it's best to start with a couple bugs: merges require a fair understanding of both the diff tools and also the process by which the previous variation was created. [04:24] hello [04:24] hi nxvl [04:24] imbrandon: I have been using bts for about 12 months. It completly rocks. [04:24] grr [04:24] hth do you actually set yourself for mentoring? [04:25] joejaxx: To be mentored, or to mentor? [04:25] beg, bribe [04:25] +mentoring does not have any link to set yourself as a mentor [04:25] persia: on lp [04:25] sorry if i did not say that [04:26] right, we thought you meant MOTU mentoring [04:26] which is entirely separate [04:26] joejaxx: Everyone who belongs to a team is automatically a mentor. If you want to mentor bugs, report this on the bug page, and select the team most appropriate. [04:26] * joejaxx already has a MOTU mentor :D [04:26] just be glad I'm not your mentor [04:26] for the FTBFS bugs i need to use pbuilder to check if it builds, didn't i? [04:26] s/mentor/potential mentor/1 [04:26] ajmitch: lol why? [04:26] nxvl: yes [04:26] nxvl: Or sbuild or a private buildd, or something, but basically, yes. [04:26] nxvl: that is the only way to know if it builds :D [04:26] joejaxx: because I'd have to find all sorts of weird & wonderful bugs for you to fix [04:27] ajmitch: LOL! [04:27] my attitude would be push until breaking point [04:27] mm i need to build my pbuilder system [04:27] hence why I'm not a mentor [04:27] * nxvl search the scripts [04:28] ajmitch: :P [04:28] my mentor is LaserJock :D [04:28] * LaserJock hides [04:29] * bddebian looks for a mentor [04:29] bddebian: I'll be your mentor :-) [04:29] bddebian: You can't have a mentor. [04:29] (well, maybe excepting Laserjock) [04:29] bddebian: stop pouting and get to work!!! *Whip* [04:29] lol [04:29] LaserJock: Cool thanks. Now, help me fix this conquest ;-P [04:30] bddebian: heah man, mentoring == fixing all your crap games ;-) [04:30] != [04:30] lol [04:30] bddebian: mentor me, pls [04:30] phew, that could have been disasterous [04:30] Sure it does.. :-) [04:30] ajmitch: Pfft, I couldn't even begin to touch your l33t sk1llZ [04:30] has anybody actually used the "mentor" feature on LP? [04:30] bddebian: I'm no deity [04:31] LaserJock: I have a few times, and generally found it attracts someone to fix it within a reasonably short period of time. It just requires me being willing to provide pointers to all the necessary guides, hints at the solution, and review of the results. [04:32] persia: but it did seem to work? [04:32] LaserJock: In what sense? [04:33] as in, people wanted to be mentored [04:33] I wondered if it would actually attract anyone who could fix the bug [04:34] LaserJock: Yes. I haven't offered any new bugs for mentoring in a while, but in the spring a number of the people who are now active contributors were starting out, and hit my +mentoring bugs [04:34] cool [04:34] LaserJock: Only offer mentoring for bugs you could fix, but are too lazy / busy to fix right now. [04:34] heh [04:35] that'll give me oh ... 0 [04:35] (or it's just not important, like grammar errors in the manpage or the .desktop not validating, etc.) [04:35] LaserJock: You could fix a spelling error, no? [04:35] thanks to my trusty spellchecker ;-) [04:35] (the mentoring part would be about getting the person in touch with upstream, and getting the patch applied there) [04:35] packaging bugs I'm usually ok with [04:36] LaserJock: Just mentor all the bugs tagged "packaging" then :) [04:37] probably not [04:37] my response time is really bad nowadays [04:37] which was the apt command to download all build dependencies for a package? i can't find it on packaging guide [04:38] apt-get build-dep foo [04:38] I keep saying I'll do something and somebody ends up getting to it before me :/ [04:38] apt-get build-dep blah [04:38] thnx [04:38] :D [04:38] doh i forgot the password to my router [04:38] LaserJock: That's excellent: you're providing guidance and direction. [04:38] * imbrandon grumbles [04:38] imbrandon: telnet port 1? [04:39] telnet and ssh are disabled [04:39] hrm [04:39] magical reset port? [04:40] jdong, then it will reset all my settings too , i'm trying to avoid that if possibly, but probably the only choice [04:40] jdong: For certain brands and models in the past. I don't think anything modern actually exposes that anymore. [04:40] persia: ah, I meant the physical one [04:40] imbrandon: think really really hard >:| [04:40] persia: most routers should still have that 5-second static-ip TFTP window :) [04:40] persia, its just a old fon thats reflashed [04:41] imbrandon: do I envision you downloading some HTTP basic auth brute forcers? :) [04:41] with dd-wrt [04:41] imbrandon: You and I obviously have different definitions of "old" [04:41] jdong, nah, it only is a bridge to one client computer on wireless, i could just reset it if need be [04:42] persia, well in this case the first wireless ap i had :) so old to me [04:42] see, this is why strong passwords are a denial-of-service and data loss vulnerability ;-) [04:42] imbrandon: next time just write it on a sticky note and stick it on it [04:42] lol [04:42] jdong: Right. Everyone should use cryptographic tokens. [04:42] LaserJock: put it on the underside. nobody would look there. [04:42] persia: yes [04:42] persia: and smart card [04:42] biometrics [04:42] and hardware level encryption [04:43] jdong: yeah, that's what I do :-) [04:43] sticky note underneath the laptop [04:43] * persia avoids biometrics: there are enough motives for people to poke out my eye without inviting more [04:43] lol [04:43] LaserJock: I just use the Windows XP license key printed on the barcode :) [04:43] persia: lol [04:43] jdong: oh, thats good [04:46] * LaserJock out [04:46] night everybody [04:47] Gnight LaserJock [04:47] LaserJock: Goodnight :D [04:58] i'm getting a strange error [04:59] pbuilder says: E: Couldn't find package j2sdk1.4 but if i try to install it on my systems [04:59] it download [04:59] downloads* [04:59] nxvl: Does pbuilder have multiverse enabled? [05:00] persia: checking [05:00] nop [05:00] how do i enable it? [05:00] nxvl: No idea. I've never used pbuilder :) [05:00] /////// [05:00] jajja [05:00] ok [05:01] * nxvl searchs [05:11] added multiverse and universe :D [05:18] ok other than a bash script is there a little tool to scan a subnet for used ip's ? [05:19] imbrandon: using nmap¡ [05:19] ? [05:19] imbrandon: nmap can be handy... [05:19] nmap will only scan a single ip right ? [05:19] imbrandon: nop [05:19] imbrandon: Well, depends on what you pass it. I think it traps 0.0.0.0/0, but that's about it. [05:20] imbrandon: you can do "nmap 192.168.5.16 192.168.5.18" and he will scan the 2 ip's or the ones you past [05:20] or you can do 192.168.5.0/24 or whatever you want [05:20] nmap is magica [05:20] magical [05:20] can i do like nmap 192.168.1.0/24 ? [05:20] kk [05:20] I think that would be 3 ips. [05:21] imbrandon: yep [05:21] Oh not. Never mind. [05:21] imbrandon: nmap is magic [05:22] why the whois are so slowly [05:22] hell of a lot better than ... [05:22] minghua: I suspect you're thinking of 192.168.5.16-18 (if I remember the range syntax properly) [05:22] #!/bin/bash [05:22] for ((i=1;i<=254;i+=1)); do [05:22] echo $i [05:22] ping -c 1 192.168.1.$i|grep ttl [05:22] heh [05:22] done [05:22] imbrandon: what are you exactly doing [05:22] imbrandon: for that you can ping the broadcast [05:22] just looking for all the ip's responding to ping on my subnet [05:23] imbrandon: ping the broadcast [05:23] persia: Yeah, that's what I was thinking. (No idea about the correct grammar, though) [05:24] imbrandon: ping 192.168.1.255 -b [05:24] 192.168.1.0/24 worked thanks [05:24] ok [05:24] nxvl: Not every stack implementation replies to broadcast pings. [05:24] persia: mmm that's true [05:25] sometimes i wonder what the hell am i doing on the office on sunday at 00:25 o'clock [05:26] i need to be less workaholic [05:40] bye all [05:51] woot, back into the router :) [05:51] ~ # uname -a [05:51] Linux fonbox 2.6.22.1 #43 Sat Jul 28 17:53:50 CEST 2007 mips unknown [05:51] ~ # [05:51] imbrandon: That's lenny? [05:51] nah, dd-wrt [05:51] on a fon [05:52] not sure i could put lenny on it without some major hacking, it only has 8mb flash [05:53] Ah. That's tight. [05:54] might be kinda funny to setup a mips pbuilder though [05:54] lol [05:54] imbrandon: In 8mb?, or does it have a USB port? [05:55] imbrandon: good luck building OOo on it ;) [05:55] persia, well i would do some nfs mounting for more storage [05:55] white: Why? Would it not just take an extra long time (assuming the ability to add disk, and use that disk for swap) [05:55] white, lol [05:56] persia: doesn't it take several days to build OOo on mips? [05:56] well considering the fon is only 200mhz it would be quite slow. [05:56] imbrandon: Hmm... Swap to NFS too, or is there a surprising amount of RAM? [05:56] white: I think it's longer for MIPS... [05:56] nah 8mb ram 8 mb flash [05:57] iirc , i'll have to check [05:57] free [05:57] Mem: 13524 12264 1260 0 1348 [05:57] Swap: 0 0 0 [05:57] * joejaxx plots doing a mips port of ubuntu [05:57] i could do it [05:57] i have the hardware [05:57] joejaxx: Could I convince you to do ARM first? [05:57] arm [05:57] ftw [05:58] persia: i have arm machines but they are all mobile [05:58] i've been looking for some good arm hardware for a long time [05:58] ie it would take forever to build main [05:58] desktop/server arm [05:58] Fujitsu, you here? [05:58] actually [05:59] white: last build: 20071022-1016 through 20071022-1040, which makes me think that there's something odd about OO.o for mips [05:59] i could use my nokia 770 it would just take a while to compile [06:00] joejaxx: Isn't that a 624MHz machine? Shouldn't be too bad... [06:00] (three or four weeks) [06:00] persia: 252 MHz :P [06:00] persia: that would take a long time [06:00] :D [06:01] i could buy three or four more and cluster them [06:01] joejaxx: Really? Hmmm... I have a spare 400 laying around, but don't really know how to start the bootstrap. [06:01] 400? [06:01] 400mhz arm? [06:01] wow [06:01] oh [06:01] 400Mhz [06:01] nice [06:02] joejaxx: PXA255 400MHz [06:02] :D [06:02] so xscale [06:02] arent there some chineese desktop arm boxen ? [06:02] wth i forgot i had a ipaq [06:02] let me look up the specs [06:02] imbrandon: They go up to around 800MHz these days, and nVidia has a couple 1Ghz chips in the lab... [06:02] Chinese arm boxes? I only heard MIPS ones. [06:03] joejaxx, just send me all your old stuff you "forgot" about :) [06:03] * persia thinks China likes MIPS [06:03] ahh maybe it was mips [06:03] imbrandon: lol [06:04] Gnight folks [06:04] imbrandon: For ARM, you need to look at Taiwan, Japan, Korea, Finland, Sweden, and the UK really. [06:05] grr wth is my ipaq [06:05] NIght bddebian. Good luck with conquest. [06:07] lol my ipaq is only 206MHz [06:07] :D [06:08] ok fun stuff [06:09] i love my ipaq [06:09] :D [06:09] joejaxx: If you can get a basic bootstrap going on your ipaQ to be a buildd, I'll volunteer to dig up my Z760 as a buildd for the -mobile seed. [06:09] persia: ok [06:09] :) [06:10] i need to get a 100Mbps ethernet card for it [06:10] then i can get it a static [06:10] joejaxx: Can the bus handle that? My Z760 doesn't get any benefit for more than 10 [06:10] can someone ack 135492 [06:10] ? [06:10] bug 135492 [06:10] ubotu poke [06:11] hmm [06:11] Launchpad bug 135492 in libitpp "Update to latest version in Ubuntu" [Wishlist,Confirmed] https://launchpad.net/bugs/135492 [06:11] Sorry, I don't know anything about poke - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi [06:11] tuxmaniac: https://launchpad.net/ubuntu/+source/libitpp/ makes me think that bug doesn't have much value. [06:12] persia, value as in? [06:12] persia, its used by several students in some premier institutions in India [06:13] tuxmaniac: As in, we have 3.99.3.1-2 in hardy, so the bug doesn't do anything useful. Further, We don't need sync bugs for packages without Ubuntu variation prior to Hardy, and lastly, please use the sponsorship queues to request approval. [06:14] persia, aah ok. Sorry for the trouble [06:15] tuxmaniac: No problem. It's a valid user request , and the bug needed attention. The best way to handle it would have been to check the URL I provided, notice that Hardy already had it, and close the bug with a nice comment saying that it will be included in hardy. [06:15] persia, ok [06:15] thanks [06:15] persia: i do not know that is why i need to get one [06:15] persia: :) [06:16] tuxmaniac: No, thank you for noticing the bug, and trying to get it fixed :) [06:16] :) [06:19] i need to wipe it [06:19] i am reflashing it now [06:19] joejaxx: Just to make sure, this is a spare machine, and you're using the 770 for normal stuff, right? [06:19] yeap [06:19] persia, close as in "Fix Rleased" right? [06:20] tuxmaniac: Yep (I've already done it for this bug) [06:20] the ipaq will work great in this case as they have CF slots [06:20] aah thanks [06:20] i have not come across sd card ethernet cards lol [06:21] joejaxx: They have the silly drop-down to expose the wires and touch them to the cable-head trick. Very fragile. [06:21] yeah [06:22] the cf ones are more robust [06:22] * persia wishes more handhelds still came with CF slots [06:22] * joejaxx does too [06:24] * joejaxx has an ipaq with and expansion sleeve with an extra battery + wlan card :D [06:24] superm1: I'm here now (sorry, was in an exam) [06:24] Fujitsu, ah hi [06:24] Fujitsu, i wanted to talk to you about mplayer 1.0~rc2, I started to get it packaged into bzr and clean up a bunch of stuff and then realized you were marked on a bug for it in progress [06:24] superm1: Ah, yes, I should probably get around to finishing that. [06:24] Fujitsu, so hopefully your not too far invested in? [06:25] I've not done much. [06:25] Fujitsu, i'm fairly close with it and am pushing to a new hardy bzr branch right now [06:25] Fujitsu, okay, you mind if i nab it then? [06:25] superm1: Shouldn't it go into trunk? [06:25] Fujitsu, well the way i looked there [06:25] i put the new 1.0~rc2 into upstream-ubuntu [06:25] branch [06:25] Yep, that's right. [06:26] and then i did a 2 way merge from the gutsy and upstream-ubuntu [06:26] Is there a separate gutsy branch? [06:26] well the "ubuntu" one was the gutsy one, and since there was a feisty one already, i figured might as well start a third for hardy [06:26] well i am going to retire for the evening [06:26] The feisty branch only exists for security updates. [06:26] * joejaxx will file those merge bug reports tomorrow [06:26] Hardy should be just using ubuntu. [06:27] or i guess later today it is [06:27] Goodnight All [06:27] Fujitsu, well wouldn't it be the same situation for the gutsy one, that it would be for security updates too then? [06:27] joejaxx: Good night. [06:27] superm1: We haven't had any security updates yet, but yes. [06:27] ( so it makes sense to have a third hardy one ) [06:27] Renaming ubuntu-hardy to ubuntu is probably best. [06:27] superm1: Wouldn't you want to name the gutsy-stable branch "gutsy", and maintain trunk in "ubuntu"? [06:27] yeah i'll do that after it finishes pushing [06:27] its a rather large push [06:27] persia: That's what I thought. [06:28] Yeah, takes a number of hours. [06:28] well i'm on a uni connection right now and using bzr+ssh, so hopefully it will be decently fast [06:28] We can branch ubuntu-hardy when hardy releases, rather than branching trunk off a release branch each time. [06:28] well assuming there are no new versions like this time around [06:29] i branched from ubuntu-gutsy, and then merged upstream-ubuntu [06:29] Ah, we normally branch ubuntu- from trunk upon 's release, the merge upstream-ubuntu into ubutnu. [06:30] Your way should work, i think. [06:30] Might just need to be careful about people who have existing local copies. [06:30] (that's another reason not renaming trunk is good) [06:30] oh good point. [06:30] i see what you mean [06:31] well from this point forward i'll make sure to keep it that way [06:31] With the way bzr works, it should be safe to rename the new branch back to ubuntu. [06:31] Thanks. [06:31] (also, please assign the branch back to ~ubuntu-dev when you're done) [06:31] of course [07:38] hi! [07:38] I'd like a review on the following package please : http://revu.tauware.de/details.py?upid=539 [07:39] * nand_ wonders if a day include all the timezones... [07:40] nand_: Yes. REVU day includes all the timezones, and is intended to be 49 hours long. Some of our more active REVUers are currently still recovering from travel from UDS, so we're a little understaffed this time: next week we hope to be in better shape. [07:41] persia: hehe ok! [07:42] superm1: Are you finished with mplayer? I might modify a couple of configure options if you're yet to upload. [07:43] * nand_ doesn't want what a 49-hour day of work might be! [07:44] s/want/want to know/ [07:44] Don't think that way. Think about 73-hour weekends. :-) [07:44] Fujitsu, i will be as long as this test build i'm doing right now [07:44] nand_: Nobody does the entire day at once: there are shifts taken. [07:44] Fujitsu, i've had to adjust a lot of configure options already [07:45] minghua: and a 24-hour night :) [07:45] Fujitsu, because the autodetection works whereas hardcoding --enable-XYZ doesn't work [07:45] persia: I know, yeah. [07:45] ps. [07:45] Oops. [07:45] (as of this version) [07:45] superm1: ^^ [07:45] Yeah, i saw that in the Debian package. [07:46] Fujitsu: Ah. I thought you were responding to my untyped thought that you had likely sat for an exam and felt like reviewing things :) [07:46] Well, yes, I probably will review something tonight, as I don't have another exam for a couple of days. [07:46] nand_: I can't comment now, but is there anything in TODO.TXT you think is interesting for end-users? [07:47] persia: TODO is a very precise roadmap of the features upstream plan [07:47] persia: might be interesting [07:47] superm1: I'm thinking we should probably disable joystick support, particularly with the prevalence of motion sensors in laptops, and the general uselessness of joystick control. [07:48] nand_: I completely agree, and believe it to be very interesting for developers, I'm just not sure it's worth distributing to end-users. If you think it is, that's fine [07:49] Fujitsu: What does joystick support break? I have a mini-keyboard with extra function keys that uses the joystick driver, and I wouldn't be surprised if there was other, similar, hardware. [07:49] persia, i've got a hdaps sensor in my thinkpad [07:49] Yeah. [07:49] that it gets very very annoying [07:49] Fujitsu, i agree, there [07:49] We've had a couple of bugs about mplayer doing strange things on MacBooks. [07:49] The problem is that they appear as joysticks, and..... yes. [07:50] Is there any way to disable by default in a config file, and still compile in support for those that may want it? [07:50] persia: We can, yes. [07:50] persia, hm perhaps that is the better solution [07:50] But I'm not sure how well our config-file mangling works at the moment. [07:50] I haven't looked into that much. [07:50] well it worked for the screensaver fix that i put in during gutsy [07:50] OK, that sounds good. [07:51] do you know the config option off hand? [07:51] to disable joysticks [07:51] * pwnguin scrambles to read backlog [07:51] superm1: It's in the bug on MacBooks, I'll get a number in a sec. [07:51] disable joystick in what? [07:51] persia: Well, that's a good question. What is generally done concerning upstream plans? [07:51] pwnguin: mplayer, and only in the config file, so you can turn it on if you want. [07:51] Bug #119630 [07:51] Launchpad bug 119630 in mplayer "spurious keyboard input on intel macbook to blobwars and mplayer (dup-of: 75925)" [Undecided,New] https://launchpad.net/bugs/119630 [07:51] Launchpad bug 75925 in mplayer "[edgy] Disable joystick by default" [Wishlist,Confirmed] https://launchpad.net/bugs/75925 [07:52] nand_: Usually just left in the source package. Anyone looking at the source will see it, but most users don't need it. [07:52] go nuts [07:52] Fujitsu, okay thanks i'll add that in [07:52] persia: ok. [07:52] in a perfect world totem would actually inhibit dpms [07:53] Fujitsu: I'd argue that 119630 for blobwars was user error, but the the mplayer side is more annoying. [07:53] (and render softsubs accurately) [07:53] persia: The bug is against mplayer, so.. [07:53] Fujitsu: Good. I wasn't planning on turning off joystick support for a platform game :) [07:54] persia: Haha. [07:54] persia: just remembered: I have this comment on REVU : 6) the ike-qtgui package doesn’t ship the upstream changelog . Since i was shipping TODO.txt and README.txt, i guess it was referring to the todo. [07:55] nand_: That's sort of the inverse of a changelog. Users like to have upstream changelogs because changelog.Debian doesn't contain much information beyond "new upstream version", and some people want to see if their pet issues were adjusted, etc. [07:56] * Fujitsu gets mildly unhappy when packages don't have changelogs. [07:56] Fujitsu: How about when upstream doesn't produce one, and the VCS log doesn't have comments :) [07:56] persia: in fact, TODO.txt is both a changelog and a todo list. So i should let it be. [07:56] * persia looks again [07:56] persia: Then the upstream probably shouldn't be trusted anyway. [07:57] Fujitsu: I'm inclined to agree, but I could find some examples... [07:57] persia: In that case, I would say packager should persuade upstream release manager to include "vcs log" output as changelog in releases. [07:57] 'morning all! :) [07:57] hey, is ~ a shell expansion for homedir? [07:57] pwnguin: For some definitions of "shell", including dash and bash [07:58] so definately not something fopen("~/.foo/bar") would handle correctly [07:58] pwnguin: Right. [07:58] nanap [07:58] uh sry [07:58] surely someone's envisoned a "correct" way to do that [07:59] pwnguin: query the user information from the system [07:59] pwnguin, typically an env variable like HOME [08:00] superm1: As long as it's unix, there's a better way... I'll dig it up. [08:01] this has been in revu since march and got some review before revu went down in august [08:01] http://revu.tauware.de/details.py?package=sdlmame [08:01] could anyone help me to get it finally in the repositories? thanx! :) [08:02] persia: well, it may or may not be unix. one could probably check passwd [08:02] pwnguin: getent, please. [08:03] Fujitsu: naturally. [08:03] Fujitsu: Thank you. [08:04] * nand_ goes take a short 4-hours nap before starting his 48-hours day [08:04] Yay, less than 1000 builds to go on i386. [08:04] * persia stops looking at ike, after determining that TODO should be installed with dh_changelogs instead of dh_installdocs, and looks at something else. [08:05] persia: Ah! [08:05] * nand_ puts it on his todo list. [08:05] persia: thanks for looking into it. [08:06] nand_: No problem. If you finish your long day (or get a break) before the end of REVU day, be sure to ask for another look: I think you're getting real close. [08:07] persia: sure. [08:07] nand_: Also, you might want to look into make variables: there's a much easier way to do all the manual cleaning. [08:08] persia: true enough, it's a bit messy here. [08:08] wallyweek: I can't comment on REVU, but I've few notes: firstly that you probably want to pass whatsnew.txtx and whatsnew_0120u1.txt to dh_installchangelogs [08:09] persia: Why can't you comment? Don't have your key and can't remember the password? [08:09] Fujitsu: got it in one :) [08:10] The password can be changed easily. [08:10] Fujitsu: From the web interface, without the key, and without the old one? That sounds like manual tweaking, which isn't worth it when I can't run lintian, linda, desktop-file-validate, or suspicious-source anyway. [08:11] persia: With one line on a shell on sparky. [08:12] Fujitsu: Right. manual tweaking. No worries: since I can't do a proper review, I'd rather not leave a comment implying I can (as long as the uploader is around) [08:12] OK. [08:12] persia: ok [08:13] persia: here, i'll give your p/w back to you, if you like [08:13] That's true, we can actually retrieve passwords too. [08:14] No, I'm fine, and I'd rather be an example for others who don't have REVU comment rights, and want to comment on packages. REVU day is about everyone: not my ability to log in. [08:14] persia: what's the email that you use to log onto revu with? [08:14] persia: true, but i'm here now, so :) [08:14] Hobbsee: i.wont@tell.you :P [08:14] dont make me search the DB :) [08:15] Hobbsee: Really, I'm fine with my password, and don't need to be able to log in. [08:15] oh well, OK [08:15] * Hobbsee logs out [08:15] gah, was going to clear stuff out first [08:15] * persia thanks Fujitsu and Hobbsee for their willingness to fix things [08:16] * Fujitsu thanks the relaxed permissions on sparky. [08:16] wallyweek: This looks like a repack, but there's not a get-orig-source in debian/rules, so it's hard to verify your repack work. Also, please add a watch file so we can see if there is a new upstream version for the next release. [08:16] Fujitsu: is libqalculate on the revu interface? [08:16] Hobbsee: Looking. [08:16] er, web interface? [08:17] Yes, right near the bottom. [08:17] Hobbsee: http://revu.tauware.de/details.py?package=libqalculate [08:17] ah, good [08:17] * Hobbsee wtf's? [08:17] What an old email address. [08:17] Hobbsee: Why? [08:17] just looking at other stuf here [08:17] Changed-By: Matt T. Proud [08:17] we have a googler [08:17] Nice. [08:18] Which package? [08:18] I thought we had about a dozen of those [08:18] it really is him, too [08:19] wallyweek: I don't believe you need to include the man directiories in every dirs file: dh_installman should generate those (someone correct me if I'm wrong) [08:20] persia: what did you have in mind with the make variables? [08:20] nand_: At a quick glance it appears you were manually iterating over a set: make can automate this though interative execution of dynamic rules. [08:21] appears not to be on irc, either. [08:21] the guy has 2 keys, and didnt use either of them to sign his package [08:22] nand_: So, if you define a variable to contain strings of all the filename classes you want to clean up, and then you can define a virtual rule that can take the name of any of those classes, and perform the appropriate deletions based on the rule name. Then you make your clean rule depend on the expanded variable, and it all works. [08:23] persia: hmm... I think i see. [08:23] wallyweek: The only other thing I see from a quick glance is that you're linking to the mame man page, but you don't conflict with other mame packages: I suspect you either want to conflict, or use the alternatives system. [08:24] nand_: Look for an example for compiling. Usually some list is defined, and then $(LIST).o: $(LIST).c is given as a rule (check the manual for syntax), which rule defines how to compile one file. Then, all: $(LIST) is defined, so make all will call the rule for each item in list... [08:25] The same thing also works in debian/rules, although it's less frequently required. [08:25] persia: Ah ok I see! [08:25] err. all: $(LIST).o [08:25] nand_: Just really check the manual. My syntax is very likely wrong. [08:25] persia: from first to last: is get-orig-source a rules target? isn't enough to state repackagin in changelog/copyright? [08:26] wallyweek: Please implement get-orig-source. [08:26] wallyweek: Only stating it is policy compliant, but providing a debian/rules target means we don't have to trust you to see it is correct. (and users don't need to trust us that we checked it) [08:26] persia: manpages go in different binary packages. Should I list them all as dh_installman arguments? [08:27] persia: mame is a symlink for frotends compatibiliy... I can remove it as well [08:27] wallyweek: packagename.manpages does the right thing. I just don't think you need to define the manpage directories in package.dirs [08:28] wallyweek: I'm not sure you want to remove it, so much as investigate the other mame packages, and follow their practices (either conflict against other providers of the symlink and provide a meta-package, or use the alternatives system) [08:30] persia: right, I'm going to edit files and be back in a while :) [08:30] wallyweek: Great. Thanks. [08:43] persia, Fujitsu: checking the sdlmame site, there's no older source archive online :( [08:44] please post some suggestion... thanks! :) [08:44] wallyweek: Is the current archive available? [08:44] persia: they've released 120u2, and deleted 120u1 [08:45] and dev cycle is a new release each week :( [08:45] they're driving me mad :p [08:45] wallyweek: so we should expect 120u3 next week? [08:45] yes... it usually is up on tuesday [08:46] Fujitsu: What do you think? I'm not sure how it would work unless the wayback machine is being agressivev. [08:47] Headache inducing upstream. [08:47] :) [08:47] Hm... attack upstream until they do something sane. [08:47] Deleting old sources is silly and makes things difficult. [08:47] Fujitsu, okay uploaded mplayer. whew that was a much uglier merge than i expected :) [08:47] wallyweek: Do you think you might be able to convince them to pick a version that you could distribute in Ubuntu and leave the archive up for a while? [08:47] nope [08:47] :( [08:48] superm1: Yep, that's why I didn't finish it quickly. [08:48] superm1: Thanks. [08:48] wallyweek: Do upstream sign their releases? [08:48] their chiefly interest is to make sdlmame available for source building only :( [08:48] (if yes, a mirror with all releases probably will do) [08:48] wallyweek: I'm really not sure then. We generally try to avoid repacks without get-orig-source, as it makes it annoying to update it for a newer release. [08:48] Fujitsu, i started it on the last day of UDS when there weren't any interesting sessions left, did some on the plane ride back, and then the rest tonight. It was overall fun to do :) [08:48] no prob [08:49] wallyweek: Do they not consider sdlmame to be stable enough yet? [08:49] minghua: no, AFAIK [08:49] okay well i'm going to get to bed now. g'night [08:49] Upstream can go to hell, IMHO. :-P [08:49] wallyweek: Do they have a public VCS repository? [08:50] good night superm1 [08:50] persia: it's not a public one [08:51] persia: and I've got no auth even to see it [08:51] wallyweek: Well, we can help you to get the package perfect, but it's going to be an uphill struggle to get it into the archives with upstream being that uncooperative. [08:51] Not.... public.... ew. [08:51] Why isn't it public? [08:52] Are they trying to be as non-free as possible while being free? [08:52] fujitsu: I don't know :( [08:52] Fujitsu: s3kr1+ g4mrz d4+4 [08:52] fujitsu: possibly yes ;) [08:52] persia: Aha. [08:53] secret gamrs data? Is that what persia saying? [08:53] I presume so. [08:53] I daren't attempt to look at that abomination much. [08:53] minghua: Well, sort of. I'm putting it in funny characters to make a sarcastic point. [08:53] What does gamrs mean then... [08:53] minghua: Secret gamers data (sort of) [08:54] * persia can read 1337, but has trouble typing it [08:54] "gamers data" is still parser error to me. [08:54] or "gamers' data". [08:54] minghua: Secret data only available to the gamers who are hacking the code [08:55] Ah. By gamers you mean developers. [08:55] minghua: Specifically not. developers who write open source software do so in open repositories [08:55] fujitsu, persia: the code *is* accessible, the VCS repository is not... [08:55] Anyway, I maintain my idea that upstream can go to hell. [08:56] lol [08:56] I think they've been flooded with patches so they decided to make it not accessible by everyone [08:56] wallyweek: There's only a weekly snapshot. That means that 1) we have to download every week if we want to know what they did, an 2) people with patches can't check what upstream is doing to make sure the patch is compatible with the current efforts. [08:57] persia: right, I understand that [08:57] wallyweek: 2) isn't terrible, and there's good software that uses that model, and 1) isn't destructive, but the combination is useless. [08:58] persia: ok, I'll see what I can do to convince upstreamers to keep older sources at least [08:59] could this be enough? [08:59] I mean: some kind of "freeze" [08:59] wallyweek: If they keep a mirror of all the snapshots (maybe space intensive, but shouldn't use much bandwidth), and you can make a get-orig-source that works, that problem goes away, and we're likely down to lintian and licensing. [09:00] Or do what every other upstream on the planet does, and keep sources around. [09:00] Indefinitely. [09:00] wallyweek: Not a freeze, just when they add a new one, don't delete the old one. [09:02] persia, fujitsu: devel cycle consists of unstable and stable releases [09:02] wallyweek: Do they leave the "stable" releases around forever? [09:02] should I ask for a full archive or would the stable releases be enough? [09:02] no [09:03] they keep until next stable release (each month, normally) [09:03] wallyweek: stable is enough, as long as you're packaging a stable. That's a better candidate for inclusion anyway. [09:03] ok [09:03] (and they should keep them around forever) [09:04] * persia wonders if REVU is as much a club with which to beat upstreams as a mechanism for including software in Ubuntu [09:04] ok, I'll see what I can do... I have to hold for this meanwhile :( [09:05] btw, I also have another couple of packages in revu... may we carry on with them? [09:05] http://revu.tauware.de/details.py?package=btpd [09:05] http://revu.tauware.de/details.py?package=shorten [09:05] thanks :p [09:06] wallyweek: I have to get back to other things for a couple hours, but someone else might be able to review... [09:10] Hi : I do believe its package Review day! Can someone (an MOTU) review may package on REVU - it currently has 0 reviews - http://revu.tauware.de/details.py?upid=541 [09:13] persia: ok, thanks for you help, anyway! :) [09:19] StevenHarperUK: I'm not reviewing right now, but just wanted to check on point 3, as I haven't reviewed the backscroll. Are you disregarding get-orig-source because you've switched to a real release instead of an SVN checkout? [09:22] persia : I am on a real release now yes [09:23] persia: it that enough? [09:23] persia: *is [09:23] StevenHarperUK: OK. Great. I still like get-orig-source, but there's no requirement to have it for a real release. I'll take another look if it's still at 0 reviews when I again am reviewing. [09:24] persia: thanks, I plan to get as many reviews / revisions as it takes today :p [09:24] StevenHarperUK: Great. There's about 25:30 left in REVU day, so you've a good chance. [09:26] * Hobbsee thinks persia is bad at maths. [09:26] * persia hunts a calendar [09:28] * persia points at http://www.worldtimezone.com/time/wtzresult.php?CiID=42124 to justify the 25:30 figure [09:28] Hobbsee: Kiribati to Niue :) [09:31] morning everyone [09:33] persia: i thought you were advocating a 49 hour revu day before [09:34] Hobbsee: Ah. Yes, I was. It appears that the introduction / removal of daylight savings time has shortened that to 48 hours for the next few months :( [09:34] awww [09:34] Damn :( [09:35] Hobbsee: It's hard to justify it's Monday when there isn't anywhere on the globe where it is monday. I'd appreciate it if you could buy an island, declare sovreignity, and claim some more time zones. [09:35] true :) [09:36] that would be fun :) [09:36] declare metric time! [09:36] pwnguin: Yes! [09:36] * ajmitch shudders to think of Hobbsee as dictator [09:36] * Hobbsee dictates that ajmitch GET REVIEWING! [09:36] can't [09:36] * persia points out there are three reviews without responses pending [09:36] ajmitch: yes you can. [09:37] that would require me to have some confidence in my abilities to review properly [09:38] ajmitch: You could at least run linda and lintian for people, and comment about the style of files in debian/ [09:40] ajmitch: you're a DD. get to it. [09:40] for now [09:40] you're quitting that too? [09:40] Anyone having a look at easycrypt - http://revu.tauware.de/details.py?upid=541 [09:41] StevenHarperUK: Even though we encourage regular advertisment during REVU day, please keep it to only once every few hours unless you've made a new upload. [09:45] less than a thousand builds left in the sync? [09:45] might be time to look into my pet packages [09:50] pwnguin: That's i386-only :( [09:50] pwnguin: Still 3928 for hppa (and only 3 for lpia) [09:51] Actually, shouldn't there be none for lpia? Why isn't anything building? Hrm. [09:52] persia: Because the queue-builder sucks. [09:52] Fujitsu: Ah. Right. I keep forgetting. [09:54] is i386-only different than i386? [09:54] pwnguin: No. i386 runs with -A [10:02] Grr. It is a 49 hour day. It started an hour before I changed the topic because there are lots of timezones in Kitibati. "Kiritimati to Alofi" [10:39] Can anyone tell me how can I fix a bug using my PPA. I mean I know the fix, I have created a patch and I will upload the package to my PPA. But should I put the ~ppa1 in version in the latest changelog entry? [10:43] Can anyone have a look at my packages? [10:43] http://revu.tauware.de/details.py?package=btpd [10:43] http://revu.tauware.de/details.py?package=shorten [10:43] thanks :) [10:51] jdong: thanks for caring about gtkpod-aac :) [10:52] success [10:53] soulfu is now packaged [10:53] yay [10:53] Can anyone tell me how can I fix a bug using my PPA. I mean I know the fix, I have created a patch and I will upload the package to my PPA. But should I put the ~ppa1 in version in the latest changelog entry? [10:54] bedtime now. i guess i'll upload to revu in the mornin [10:54] I request a review of my package ike please : http://revu.tauware.de/details.py?package=ike . Thanks! [10:55] im sure theres tons of errors i've made [11:01] wallyweek: I'm transmitting a comment I got on my package : In the control file, homepage should now be put on its field (cf http://wiki.debian.org/DeveloperNews) [11:03] nand_: I missed that. Thanks! :) [11:03] slytherin: yes, it's better to have a PPA-specific version so that the PPA version doesn't interfere with versions from the main archive. [11:04] broonie: Ok. I have just uploaded a package to my PPA that fixes a problem (generic menu icon) in 'tagtool'. Now what is next step? [11:17] Hi : I do believe its package Review day! Can someone (an MOTU) review may package on REVU - it currently has 0 reviews - http://revu.tauware.de/details.py?upid=541 [11:22] StevenHarperUK: Just a note : According to http://wiki.debian.org/DeveloperNews, I believe the homepage field should be put on the source area, and not the package area. [11:25] StevenHarperUK: Please fix what nand_ said. I'm looking over it now. [11:27] Ok ill do that now [11:28] StevenHarperUK: Couple of other issues that I'll add a comment about in a sec. [11:28] Fujitsu: Great [11:28] fujitsu: definitely yes: "put it in the new "Homepage" field in the source stanza" [11:29] Fujitsu [11:29] Fujitsu: Shall I wait for your other before I rebuild [11:29] StevenHarperUK: Yes please. [11:29] I won't be more than another couple of minutes. [11:30] Hi all! [11:30] warp10: hi [11:45] StevenHarperUK: Commented. [11:46] Fujitsu: ta [11:47] Fujitsu: the TrueCrypt packaging : there fussy about re-distribution [11:48] Fujitsu: Hopefully in the future, I will get clearence to package and then make it a dependancy [11:48] StevenHarperUK: OK, I see there are easily-installed binary packages there. It's probably OK. [11:48] Fujitsu: ok ta [11:48] Fujitsu: I am on to them so I can get it into a proper package then I can make it a dependancy... [11:49] StevenHarperUK: Does their fussiness include a requirement to use a browser? Can you grab something with wget or curl, and stuff it in the right place? [11:49] persia: It's a .deb... that sounds evil. [11:50] Like Fijitsu says its a deb [11:50] Fujitsu: Hrm. True. [11:50] I wouldn't want to automate it [11:50] When I get the OK to package it will be better [11:50] but it is very simple [11:50] I have users using it from my PPA without complaint [11:51] StevenHarperUK: Also, there is a space before the python build-dependency. [11:51] Trivial, but it'd be nice to fix it. [11:51] TheMuso: is it you who added the comment about audacious-plugins on DaD? [11:53] Fujitsu: done [11:53] StevenHarperUK: Thanks. [11:59] is the buildd backlog visible somewhere? Someone mentioned that it's ~1000 packages for i386 [12:00] tepsipakki: https://launchpad.net/ubuntu/hardy/+builds has everything, https://launchpad.net/ubuntu/hardy/i386/+builds has just i386. [12:00] You can use the filter there. [12:00] tepsipakki: It was 3000 a couple of weeks ago, so it shouldn't be too long. [12:00] Fujitsu: oh, indeed :) [12:01] tepsipakki: You can also play with the i386 to check any arch... [12:02] people have complained about X dep-breakage on hardy, but until all drivers are (re-)built there's no point uploading xorg-metapackage [12:02] tepsipakki: They've all built, as far as I know. [12:02] since the ABI's have changed [12:02] They still seem to be providing -1.0. [12:03] Fujitsu: well, I still see a bunch of video-drivers on MoM [12:03] they are supposed to be synced, so I'd like to be sure before complaining about it :) [12:03] tepsipakki: I suspect they might have rebuilt before the new xserver-xorg did. [12:03] cyberix: I've added a comment to pq with my thoughts. As discussed ~12 hours ago, the decision will likely be taken external to MOTU, but I shan't archive it again: the packaging looks rather clean now. [12:03] Fujitsu: aww [12:03] * Fujitsu checks the logs. [12:03] Because they definitely still provide -1.0. [12:03] Which is wrong. [12:03] hmm, actually they shouldn't build [12:04] but only some video-drivers were synced [12:04] Ah. [12:04] Which? [12:04] I need to check [12:05] -mga for instance [12:06] Ah, that's -2. [12:06] so not built yet [12:06] ogh [12:06] *oh [12:06] -mga built, -intel, -ati haven't... /me checks others. [12:06] you meant the provides, not package revision (which is -3 :) [12:06] Oh, sorry. [12:06] intel and ati needs merging [12:07] but I uploaded intel since that's a candidate for gutsy SRU [12:07] * Fujitsu is waiting on -intel [12:07] And I happened to be dealing with -ati earlier tonight, so that was the second one I checked. [12:07] I had 46 packages on the sync-list ;) [12:08] Fujitsu: all Changes done & tested : uploading now.. I'll msg you again when its up [12:08] and maybe some of those weren't synced [12:08] StevenHarperUK: Thanks, I'll look shortly. [12:09] StevenHarperUK: You'd do better to advertise for general review for each new upload, rather than poking specific people (even though they may be willing) [12:16] Fujitsu, I'm chasing a FTBFS on netcdf, which is under MOTU-Science attention. Can I proceed? [12:17] Fujitsu: Its there with comment - http://revu.tauware.de/details.py?upid=543 [12:17] StevenHarperUK: Yep, looking now. [12:18] DktrKranz: Of course. We (well, I) don't bite. [12:18] We try to take care of them, but that doesn't mean we have an exclusive lock. [12:18] Fujitsu, of course not, but I don't want to steal something you may be interested in :) [12:21] DktrKranz: Bit busy with exams and stuff to chase much now. [12:22] ok. I'll publish a debdiff soon and subscribe u-u-s for sponsorship. thanks [12:23] StevenHarperUK: Looking good. [12:23] nand_: ike commented [12:23] persia: thanks! [12:23] nand_: Looks like a bit of a copyright mess with upstream (unless I misunderstand) [12:24] persia: I remember having discussed about it with upstream... /me will look at it [12:25] nand_: If you've been discussing it, and think you have a solution, it may be worth discussing. I haven't looked at the copyright policy in a while, but my memory is that every file should have a note. [12:26] persia: btw, here with my version of desktop-file-validate, it is validated. Can you tell me what your version tells? [12:26] nand_: "Encoding" is deprecated is the one I remember. Which version of desktop-file-validate are you using? [12:27] StevenHarperUK: The package is now technically clean in my eyes, but some of the description is a bit iffy. [12:30] persia: ok i give up :p What is the package providing desktop-file-validate === apachelogger_ is now known as apachelogger [12:30] nand_: desktop-file-utils [12:30] * nand_ notes that the man page of desktop-file is wrong [12:31] nand_: Please submit a patch: upstream is very responsive [12:32] persia: version 0.13 [12:32] persia: on my todo list too. [12:33] Fujitsu: the description has to be user friendly - the guide http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-desc-basics seems to match what I have done, do you have any suggestions to make it less iffy? [12:36] nand_: WIth desktop-file-utils 0.13-0ubuntu3, desktop-file-validate debian/ike.desktop gives me "ike.desktop: warning: key "Encoding" in group "Desktop Entry" is deprecated". Are you not seeing the same? This might be a larger bug. [12:36] persia: this is my exact version. [12:36] * nand_ checks again [12:38] persia: No i'm definitely using the same version, and I don't have any output. Any command line parameters? [12:38] nand_: none. Which architecure are you using? [12:38] i386 [12:39] * persia seeks a volunteer with a gutsy/i386 system to run desktop-file-validate against http://revu.tauware.de/revu1-incoming/ike-0711051330/ike-2.0.2/debian/ike.desktop [12:39] Fujitsu: if its technically clean can you comment on it please [12:39] StevenHarperUK: See PM. [12:39] persia: you suspect a architecture bug? [12:40] persia: I'll do so (on hardy, but the package hasn't changed AFAIK) [12:40] persia: may I send you in pm the comment of upstream concerning copyright [12:40] nand_: I'm amd64. Sometimes behaviour is different, so it's a handy thing to check. [12:40] Fujitsu: Thanks, and no, it's the same version. [12:40] I get the Encoding warning, as I have for months. [12:40] nand_: Sure. [12:41] but then why did I not get this warning? [12:41] nand_: It's just you then. You may want to reinstall desktop-file-utils to see if that helps. [12:41] persia: I'll give it a try. [12:43] wallyweek: shorten commented [12:44] * Fujitsu ponders attacking REVU to comment via POST. [12:45] persia: oops. I think I have forgotten to register. [12:45] nand_: register? [12:45] persia: log in with nickserv. [12:46] persia: anonymous pm are forbidden [12:46] nand_: Ah. That makes it hard to message me. How about a pastebin? [12:46] !pastebin | nand_ [12:46] nand_: pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic) [12:46] persia: ok :) [12:48] nand_: If upstream is reviewing the code to add the copyright headers, that's a good thing. We won't be able to upload to the archive until it's done, but the rest of the package is almost there. If upstream is actually quick about it, I suspect ike will get in next time (especially if you keep fixing all the packaging stuffin the meantime) [12:49] persia: Ok i'll forward that. In fact I think upstream has forgotten about that... [12:50] nand_: Just keep bugging them. Because this will be an LTS, you've a decent size stick (it'll be two or three years before your app can get on Ubuntu servers if you don't do it soon) [12:51] persia: right :) [12:52] persia: Btw when is the next revu freeze? [12:52] (upstream may want to get a later revision in) [12:52] nand_: Not entirely decided, but likely February, although it'd be ideal to get it in by December 14th for best testing. [12:54] Hobbsee: Around? Can you fix sparky's time up? [12:54] * persia is amused by "The program 'les' is currently not installed. You can install it by typing: sudo apt-get install atm-tools" [12:55] Fujitsu: time up? [12:55] Hobbsee: It is saying it's 31 past the hour. [12:55] Which I doubt. [12:55] ...interesting [12:55] * white waves [12:55] Hi white. [12:56] do you know that feeling, when you should study for an exam (which is in two days), but you just can't? [12:57] but after wednesday holidays start :) [12:57] white: Oh, I do. I have one in two days, and am not studying :P [12:57] Fujitsu: there we are :) [12:57] Hobbsee: Thanks. [12:58] Might be nice to install ntp on there, but that is probably best discussed with siretart. [12:59] Fujitsu: sorry? [12:59] siretart: sparky's time drifts. [13:00] damn [13:00] It was 25 minutes out just now. [13:00] Fujitsu: I won't get to it today, please check with sistpoty or Hobbsee, they both have root [13:00] I was wondering why uploads weren't appearing at */10. [13:00] Hobbsee: Install ntp kthxbye. [13:00] Mon Nov 5 14:00:41 CET 2007 [13:01] hmmm. time seems okay right now [13:01] siretart: I just got Hobbsee to fix the time manually. [13:01] ok. thanks! [13:01] Fujitsu: ntp installed, kthxbye. [13:01] Hobbsee: Thanks. [13:01] siretart: it appears to think that ntp.ubuntu.com is not a valid server, or something. [13:01] Hobbsee: please use 'faui45.informatik.uni-erlangen.de' as ntp server [13:01] Fujitsu: all i did was use the ntpserver of the uni that it's in [13:01] if that doesn't work, try faui40.informatik.uni-erlangen.de [13:01] Hobbsee: That's ntpdate, not ntp. [13:01] siretart: hm, i used something close to that [13:02] oh, piont, i thought one was from teh other [13:02] it might be very well possible that some ports are firewalled [13:02] ntpdate runs once, doesn't keep things synced. [13:02] wallyweek: btpd commented [13:03] Educational institutions seem to have a habit of blocking NTP outbound. [13:04] Would anyone with a powerpc be willing to run a test build of http://revu.tauware.de/details.py?package=sdlmame ? It's requested in the comments, but I'm not sure how widely that is seen. [13:05] Fujitsu: lecturers are never on time, so they do not want the students to look at the time of the clients and then appear for the lectures on time [13:05] white: Good theory. [13:06] i could make a statistic of my favourite lecturer, she always is at least ten minutes late :) [13:06] * Fujitsu wonders if mangling the times of a couple of REVU uploads to make them actually appear in chronological order is plausible. [13:06] * persia wonders why chronology is important for REVU [13:07] persia: Observe http://revu.tauware.de/details.py?upid=545 [13:07] That is the latest upload. [13:07] Yet two appear after it, as sparky was behind. [13:07] any hint on an automatic way to retrive a upload from revu and automaticaly set it up (dget only download) ? (just lazy) [13:08] nand_: dget -x [13:08] Fujitsu: Ah. Then, I'd say it's worth it for anything uploaded in the last two hours. [13:08] azeem: thanks! [13:08] ... if that is what you mean by "set it up" [13:08] persia: desktop-file package reinstalled, still nothing. BUT if I download if with wget, then I got your warning. [13:09] weird... [13:09] nand_: Download which with wget? [13:09] persia: sorry. "If I download my uploaded source package with dget" [13:10] it looks like it's on REVU side. [13:10] * nand_ checks the md5 [13:10] nand_: Ah, so it's clean locally, but the REVU version is ugly? That's frustrating. You'll want to make sure it's really clean for your next upload (I'd wait a couple hours due to the REVU time change). [13:11] persia: oh wait. [13:11] Looking for an Advocation for Easy Crypt : I already have 1 advocation : http://revu.tauware.de/details.py?upid=545 - please note its the 14:00 upload, the time chnage on REVU has put them out of order [13:13] persia: Sorry for the waste of time. That's the problem when working simultaneously on two machines... :/ I'm on feisty for the build, I have checked on the gutsy one :/ [13:15] nand_: That explains it. Encoding didn't become deprecated until gutsy [13:17] StevenHarperUK: There's still no upstream changelog: is uncorrectible? [13:17] ^this [13:41] happy revu day everybody [13:43] hi norsetto [13:44] morning [13:44] proppy: salut, how is it with juce? [13:44] hi zul [13:46] hi norsetto [13:46] persia: thanks! :) [13:47] what would one recommand instead of mv to rename a file on the rule file considering that dh_install doesn't rename? [13:48] *what would one recommand to use to rename a file in the rule file (more clear) [13:48] nand_: install -m 644 (or whatever) works, but it's not the prettiest solution [13:49] persia: ok thanks. [13:49] norsetto: studying debhelper while @home [13:49] proppy: dh_gconf ? [13:49] norsetto: it's not really my mother tongue, but It's interesting to learn :) [13:49] norsetto: I'm sure I will enjoy reading debian/rules of package after that [13:50] proppy: don't tell me that japanese its easier .... [13:52] hiya jono [13:52] norsetto: Actually yes, since I don't have a dhelper native gf :) [13:52] norsetto: got my mail about dh_icons? [13:53] norsetto: please keep discussing it with Peter on the cdbs bug to get a solution there :) [13:54] white: which bug number? [13:54] Fujitsu: ffs. keep the server online will ya ;-) [13:55] Nafallo: Getting there, getting there. [13:55] :-) [13:58] persia: The ChangeLog is in there [13:58] norsetto: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432851 [13:58] Debian bug 432851 in cdbs "cdbs: Please add support for dh_icons" [Wishlist,Open] [13:59] StevenHarperUK: why can't linda find it: i7ll dig some more [13:59] heya Hobbsee [13:59] persia: it gets installed to : usr/share/easycrypt/ChangeLog [14:00] persia: if you check it in the included files when you double click the DEB [14:00] StevenHarperUK: Eek, I missed that, sorry. It should be in /usr/share/doc [14:00] /usr/share/doc/easycrypt, that is. [14:01] Fujitsu: sorry what do you mean - its correct or not? [14:01] StevenHarperUK: I missed that you'd done it wrong. [14:01] The changelog needs to be in /usr/share/doc/easycrypt. [14:02] white: actually I sympatise with Peter, dh_icons should not be called by default by cdbs [14:02] Do I manually stick it there using easycrypt.install? [14:02] Fujitsu: ^^^ [14:02] dh_installchangelogs should do it, I think. [14:02] Or whatever it is. [14:02] I haven't made a new package in quite a while. [14:03] Fujitsu: That is right , does it go in this section (binary-install/easycrypt::) [14:04] norsetto: well then i have to tag my bug wontfix [14:04] white: as you wish, we have dh_icons in any case in Ubuntu [14:05] StevenHarperUK: CDBS stuff isn't one of my strong points. [14:05] norsetto: Isn't that done by gnome.mk? [14:05] well calling dh_icons (and later on whatever is used for other desktops) would have the same effect, than calling it from cdbs [14:05] Fujitsu: qt packages do not use gnome.mk [14:05] Fujitsu: indeed, also by kde.mk and xfce.mk [14:05] norsetto: Right. [14:05] Fujitsu: my point would be to use it in debhelper.mk [14:06] although i agree with peter that dh_icons needs to be adjusted [14:07] * persia would like to see dh_desktop called whenever there is a .desktop in /usr/share/applications now that the MIME issue is fixedf [14:08] persia: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=439717 [14:08] Debian bug 439717 in cdbs "cdbs: run dh_desktop if there's a debian/package.desktop file" [Normal,Open] [14:08] white: Thanks :) [14:08] white: the point is that calling it by default would mean calling it also when its not needed [14:08] white: not many packages have a need to register their icons, so I think its fair to leave it to the packager [14:09] well if there is no icon installed, then imho dh_icons should detect that and not add anything [14:09] * persia ponders submitting patches to debhelper to actually have a chance of closing that bug [14:11] Can anyone help: I have placed dh_installchangelogs ChangeLog in my rules, but its not placing the ChangeLog file into /usr/share/doc/easycrypt/ [14:11] persia: fixing it in debhelper and cdbs would imho be the right approach and bring the most benefit to all the packages [14:11] and less effort for future releases [14:12] white: I think debhelper has to go first. dh_icons needs to use a find test, and dh_desktop should actually install them [14:12] yes [14:12] and dh_desktop could document what the call actually does :) [14:13] white: Well, it calls update-desktop-database iff there is a MIME type defined in the desktop file in the postinst. Most of the time it's a nop currently. [14:14] * persia puts dh_desktop firmly in the TODO list, albeit not very close to the top [14:15] This is in the Build output [14:15] dh_installchangelogs -peasycrypt ./ChangeLog [14:15] no errors after it [14:15] This in the Included files : usr/share/doc/easycrypt/changelog.Debian.gz [14:15] is that right? [14:15] in the deb [14:16] changelog.Debian.gz is debian/changelog, so no. [14:16] StevenHarperUK: You want /usr/share/doc/easycrypt/changelog.gz [14:16] thats there too [14:16] Both are there [14:16] StevenHarperUK: If that's there then your dh_changelogs call is working. Is linda happy on your binary now? [14:16] ill check now [14:17] Yes it passes ill re-upload now [14:20] StevenHarperUK: That's a neat idea: sticking releases into the svn trunk :) === KC8TAD is now known as rrittenhouse [14:25] persia: Thanks [14:26] persia: its my own Idea we use SVN @ work [14:26] StevenHarperUK: I've stuck a comment on the 14:00 upload, but I don't know enough about python packaging to be sure it's correct. [14:27] persia: I have had python packager look at it before, they were happy [14:27] persia: It looks fine to me, and I've dealt with a fair bit of Python stuff. [14:28] Fujitsu: Most things seem to use site-packages, and the wrapper changing directories seems odd to me, but I just don't know enough to know if these are problems or not. [14:28] persia: The modules are private, so it should be OK. [14:28] * Fujitsu checks the policy. [14:30] They're private, so /usr/share/easycrypt is OK. [14:30] wallyweek: I've added a comment to sdlmame also: skipping most of what was discussed earlier, but just for a record of review, and incuding some of the automated test output. [14:31] persia: Its re-uplaoded now http://revu.tauware.de/details.py?upid=546 [14:32] Fujitsu: can you re-check it pls : http://revu.tauware.de/details.py?upid=546 [14:32] StevenHarperUK: advocated [14:32] StevenHarperUK: too bad you didn't wait another 10 minutes :) [14:32] StevenHarperUK: Looking. [14:32] Fujitsu: Thanks [14:35] Are there any uploaders currently waiting for a review? [14:35] StevenHarperUK, persia: easycrypt advocated. [14:35] Woohooo : big thanks to all you very helpful MOTU's [14:35] StevenHarperUK: Be warned, NEW is fairly slow for the next few weeks, you may not hear back from an archive admin for a while. [14:36] persia: Do you want to upload it, or shall I? [14:36] (being as much as a month) [14:36] * Hobbsee can promise a quick turn around :P [14:36] Fujitsu: either's good. [14:36] Hobbsee: Haha. [14:36] * Fujitsu uploads, then sleeps. [14:36] No problem, I can wait: users are using my PPA atm [14:36] Hobbsee: You're going to review the license? [14:36] persia: nope. but i can be damn quick with the "reject" button. [14:36] heh [14:37] persia: thanks once again! :) [14:39] wallyweek: Do you have any more, or did they all get commented? [14:39] persia: just go thru them all on REVU :) [14:40] Hobbsee: I've hit quite a few, but I give preference for people who actually show up to REVU day (and really ought to be working on my linda patch anyway) [14:40] heh [14:41] StevenHarperUK: Uploaded and archived. [14:43] * Fujitsu now heads to bed. [14:43] good night Fujitsu === _czessi is now known as Czessi [14:43] Night persia. [14:47] persia: you know, i'm thinking that we really should be like debian in making people putting in new packages commit to maintainingthem. [14:47] as in, others permitted to hijack, but they needed ot make sure it's up to date [14:48] persia: so they can rot in universe? [14:48] Hobbsee: I really don't think we should be like that. I do think that we should require every new package to have a watch file, and have something check the watch files, and add that to the merge list for each release. [14:48] zul: ENOCONTEXT [14:48] persia: that's another way. the advantage of debian is that they actually care about the package that they're uploading, at least somewhat, so are somewhat motivated to update it. [14:49] Sir sir! I'm stuck! :) [14:49] oh noes! [14:49] * Hobbsee pulls knights out of his hole [14:49] Hobbsee: The main blocker to getting rid of wxwindows2.4 is three Debian maintainers who don't fit that criterion [14:49] persia: was meaning generally, not that in particular [14:49] but yes [14:49] (well, actually there are a couple more, but we've been able to work around them) [14:50] The app I'm trying to package has a few .sh scripts and lintian doesn't like this. How do I get rid of the extensions? I tried messing with the Makefile but obviously didn't mess with the right thing. I suspect these .in files have something to do with it? [14:50] persia: if new packages have no maintainer then they will rot [14:51] Hobbsee: The thing is that there is a promise to maintain, but that doesn't translate into maintenance. I firmly believe in teams: as long as we have the systems to make sure they are up to date, getting new people to pull new upstreams for random leaves seems safer to be than getting new people to process merges. [14:51] Hobbsee, : Thanks! but it wasn't 'hole' stuck. It was school kid, homework type stuck :) [14:51] zul: I think that assumes a level of apathy I don't think that all MOTUs exhibit. [14:51] persia: true, but the team doesnt tend to care, and cant track it anyway :) [14:51] but yes, being able to train it might persuade some people [14:52] knights: Ask a question, and you'll get an answer. Make a comment, and someone will comment. [14:52] Hello all [14:52] Hello norsetto persia Hobbsee and everyone else [14:52] :-) [14:52] persia: not complaining, just one of the limitations of text comms init? [14:52] Hobbsee: We should have the latter solved in hardy, and the former just requires encouragement, support, and for all the bitter people to stop whining :) [14:52] hey huats [14:52] easy to get the wrong idea === huats_ is now known as huats [14:53] knights: yep :) [14:54] persia: any idea how i'd go about changing these 3 .sh files to extensionless files [14:54] What files will I need to modify? [14:54] knights: Umm. In what context? [14:55] I think they're generated from .in files, does that sound right? [14:55] knights: It's certainly possible: I need more context. [14:59] persia: No, I was wrong, the 3 .sh files are included in the original source tar [14:59] persia: Any chance I could pastebin the Makefile for you to look at? [15:00] I think thats what you'd need to see? [15:00] knights: OK. So you're packaging this software, and upstream includes some random shell snippets and you want to strip the extensions and stuff them in /usr/bin? [15:00] yes [15:01] knights: install -m 755 source target usually does a nice job. Not so pretty, but it works. You could also rename them in the source directory, and then install them with dh_install. [15:01] I'm wondering if I'll need to edit moe than just the makefile [15:01] knights: You can just edit debian/rules. [15:03] 'install -m 755 source target' where? [15:04] knights: in the install rule [15:04] install rule is a file where? (sorry, this is my first package) [15:05] knights: Ah. It being your first package is important context: it sets the verbose flag :) [15:06] knights: Essentially, dh_install cannot change file names when installing files. As most packages use either CDBS or debhelper, and therefore relay on dh_install to do the work, this makes it tricky when files need to be renamed. [15:06] Oh right the 'install' section with devian/rules is what you mean! [15:07] within debian/rules [15:07] There are three options available to address this, as follows: 1) If you are already patching the upstream Makefile (and you should only do this if you really must), you can change the name in the upstream Makefile install rule. [15:07] 2) Otherwise, you want to use the "install" command to manually install the files in the install rule in debian/rules [15:08] option 2 please persia! :) [15:08] 3) Some people get extra fancy and write make tricks to rename the files in the debian/rules build rule, and then use dh_install to install them. This should only be attempted if you have a strong understanding of make [15:09] knights: Does that provide enough info, or do you need more [15:09] Ohh no! No fancy tricks for me yet! [15:09] persia: I''m justabout to see if I can do option 2 now [15:11] This package I'm doing was already mostly packaged for DEbian, it just needed to be cleaned up and a few things added/ changed [15:11] In the rules install section it already has this line [15:11] install: DH_OPTIONS= [15:11] This is the line I'm editing then? [15:12] knights: pastebin your rules, and I'll tell you: I'm not sure from that [15:12] In fact its got 2 install sections, which seems odd [15:12] ok [15:13] http://pastebin.ca/762252 [15:15] knights: Yeah. lines 42 and 43 look very suspicious to me. I'd suggest you review the make manual to make sure that's legal (I think it's not). I'd add the install calls after line 51 [15:17] Thanks persia! [15:17] let me try.. === mdomsch_ is now known as mdomsch [15:19] morning mdomsch [15:20] Hobbsee: wanna play hearts? :> [15:20] h4x0r7h11: why? [15:20] heh [15:20] * h4x0r7h11 shrugs. Was browsing the PPA earlier. [15:20] ahhh [15:22] h4x0r7h11: it should actually work now, too [15:23] Hobbsee: cool [15:23] Heya gang [15:23] See, ya don't have to be stalking someone to find out things about them. ;D [15:24] * Hobbsee is not someone [15:24] * Hobbsee is a green alien. [15:24] Some girl I know thought it was really cool that I knew like ... half her entire life a week after meeting her, without talking to her much o_o [15:24] persia: OK, so if I have a file script.sh in the base of my apps source dir (ie one level up from the debian dir) that want to go to /usr/bin/script I'd add a command like this to that section of rules: [15:25] dh_install -Xscript.sh /usr/bin/script [15:25] ? [15:26] knights: No. dh_install can't rename things. You need to use the "install" command. It's a little confusing to put the install command in the install rule to install things, but `man install` will help. [15:26] You can rename in the .install file with dh_install can't you? [15:26] bddebian: If you can, it's new [15:26] * persia looks [15:26] Hmm [15:28] greetings Hobbsee [15:29] bddebian: I don't feel up to digging through the perl right now, but the man page says you can't [15:29] Doesn't look like I'd need any fancy option so would [15:29] h4x0r7h11: that's creepy [15:29] install script.sh /usr/bin/script [15:29] do the trick dya tink? [15:31] suppose I'll just have to try it eh [15:31] hey mdomsch [15:31] knights: I prefer `install -m 755 script $(DESTDIR)/usr/bin/script`, but basically [15:31] tepsipakki: no problem :) Just want to see it working again after several people were whining about it :) [15:32] Ah yes! Thanks persia! [15:33] jdong: I hijacked your hardy gtkpod-aac for no dpatch comment. Please fix it for gutsy while waiting for the buildds [15:34] persia: ah, good point, didn't realize dpatches had comments :) [15:34] persia: I believe you for some reason I was just thinking you could === _jason is now known as jrib [15:36] bddebian: Yep. I've spent hours on that issue more than once :) [15:36] jdong: Did you read your dpatch? [15:37] persia: When is the meeting going to be? I'm referring my points and I'll add that as a comment too. [15:37] persia: only the payload... [15:38] cyberix: No idea, I don't even know if one is scheduled. I was just reviewing all the REVU requests from the backlog, and didn't want to archive yours again as you'd put it back up, but did want to say I didn't think it belonged in Ubuntu. [15:39] persia: Yep. I think it is good to be visible as it has raised lots of discussion [15:39] persia: I still don't think you're completely wrong. [15:40] jdong: The payload is the important part :) [15:40] I just think the policies are lacking a process for such packages. [15:40] cyberix: One thing I don't really understand is why wine-doors is the wrong place. They seem to have a lot of the same wrapper stuff you created. [15:41] Hi bddebian [15:43] jdong: I haven't used it myself for quite some time since I reripped my albums and transcoded as mp3's. Banshee is good enough for me now (and what I hear, will be even better soon) :) [15:43] Heya geser [15:44] tepsipakki: My apologies: I didn't notice until uploading that you were the maintainer. I hope you don't mind the patch. [15:44] persia: of course not [15:44] is it possible to "orphan" a package?-) [15:44] * persia is still ashamed for not checking on a claimed package [15:45] tepsipakki: Yep. Just upload with Maintainer: Ubuntu MOTU Developers [15:45] tepsipakki: ah, ok, my primary usecase for gtkpod-aac is transferring videos onto my iPod, for which I don't have a choice of which container to use :) [15:45] persia: ok, I can do that later :) [15:45] persia: gutsy debdiff revised and reattached :) [15:46] jdong: OK. Despite the positive gutsy report, since I don't have equipment to verify, I'd like to wait for a hardy success report before pushing gutsy-proposed. Perhaps you can draft someone? [15:46] persia: I had no luck with adding the install command: [15:46] install: cannot create regular file `/usr/bin/xdtv_makedvd': Permission denied [15:46] knights: No? What happened? [15:47] knights: is $(DESTDIR) defined? [15:47] persia: once it builds I'll give it a shot -- gtkpod is quite simple to test even from a pbuilder chroot :) [15:47] persia 15:39: sorry, I had to go out and collect my daughter from school :) [15:47] install -m 755 xdtv_makedvd.sh /usr/bin/xdtv_makedvd [15:47] knights: You're not allowed to install to the build system. You need to install to the temporary directory for the package. [15:47] persia: I have one more: http://revu.tauware.de/details.py?package=sdlmame-cheat [15:48] I updated btpd [15:48] now I'm working on shorten [15:48] wallyweek: Unfortunately it's now late enough here that I don't trust myself to do a good job on either of those :( [15:48] wallyweek: Perhaps you could find another reviewer (doesn't need to be MOTU, just needs to know packaging, and share comments)? [15:48] no problem. You've been of *great* help... thank you very much for your efforts! :) [15:49] persia: So do you think removing DESTDIR will solve this? [15:49] I'm probably don't have that defined [15:49] persia: sure! hope to hear you again next time! :) [15:50] knights: "install -m 755 xdtv_makedvd.sh /usr/bin/xdtv_makedvd" is trying to install to "/usr/bin/". If you got that when using $(DESTDIR) than $(DESTDIR) isn't defined in your makefile. [15:50] wallyweek: You can get a lot of my comments from running linda and lintian on your binary packages :) [15:50] OK, I'll try it again with no DESTDIR [15:50] knights: How will that help? [15:51] knights: does your makefile respect DESTDIR? [15:51] * knights confused [15:51] keescook: try make DESTDIR=/tmp install [15:51] err wrong person [15:52] (I think that's the order, maybe DESTDIR= goes at the end) [15:52] if install isn't trying to put things in /tmp, then you have a makefile that ignores DESTDIR :) [15:52] jdong: How will that help? [15:52] persia: oh is he already trying a prefix and it's ignoring it? [15:53] jdong: We're trying to rename some files while installing them during a package build. [15:53] persia: ah, ok [15:53] knights: OK. Do you understand about make variables. [15:53] persia: My makeflile has lots of DESTDIRs in it [15:53] I know what an env var is [15:53] knights: Which makefile, ./Makefile or ./debian/rules ? [15:54] ./Makefile [15:54] knights: make variables aren't quite environment variables [15:54] knights: I thought we decided not to modify ./Makefile, and were adjusting debian/rules. [15:54] Sorry- misunderstood your question [15:54] which question? [15:54] I've not made any mods to upstream Makefile [15:55] I thought you were asking if thatr Makefile comntained DESTDIRs [15:55] sorry about typos [15:56] Right. So, you've a line like "install -m 755 xdtv_makedvd.sh $(DESTDIR)/usr/bin/xdtv_makedvd" in debian rules? [15:56] I added the install commands to rules [15:56] yes, 3 lines like that for the 3 .sh files [15:57] OK. And you get "install: cannot create regular file `/usr/bin/xdtv_makedvd': Permission denied" as an error message? [15:57] And the build log shows "install -m 755 xdtv_makedvd.sh /usr/bin/xdtv_makedvd"? [15:57] yes [15:57] build log? [15:57] The output of your build process [15:58] /usr/bin/install -c -m 755 xdtv_makedvd.sh /home/knights/src/xdtv_2.4.1cvs3/debian/tmp/usr/bin [15:58] persia: just one short question, please... :p comment about hyphens in manpages means I should escape them with a slash, right? [15:59] is the build log output [15:59] wallyweek: Well, it depends on whether you mean hyphen or minus. \- is minus and \(hy is hyphen. [15:59] knights: From where did you get that line? [15:59] persia: unfortunately they are the same on my keyboard :( [16:00] I presume the 'build log' is whats dumped to the terminal as output from debuild, no? [16:00] options are preceded by minus sign IIRC [16:00] wallyweek: That's true for everyone's keyboard, which is why we write '\-' and '\(hy' in manpages instead of '-' [16:01] knights: Yes, the debuild output may be considered a build log (it also dumps it all in a file in the parent directory for later reference). [16:01] persia: ok, I'll sort it out with a good translation tool... thanks :) [16:02] I mean a dictionary, of course... [16:02] Well, build log says its trying to put it in /home/knights/src/xdtv_2.4.1cvs3/debian/tmp/usr/bin and we just wanted /usr/bin [16:02] knights: If your buildlog is reporting "/usr/bin/install -c -m 755 xdtv_makedvd.sh /home/knights/src/xdtv_2.4.1cvs3/debian/tmp/usr/bin" then I don't understand why you see "install: cannot create regular file `/usr/bin/xdtv_makedvd': Permission denied". It should be installing to "/home/knights/src/xdtv_2.4.1cvs3/debian/tmp/usr/bin/" [16:03] wallyweek: If you run lintian on your binary package, it should tell you which manpages to read [16:03] If I remove these install commands it builds fine as a non-root user [16:03] but lintian complains about the .sh files of course [16:04] knights, Maybe you should try pbuilder? [16:04] knights: No, we don't want /usr/bin: we want /home/knights/src/xdtv_2.4.1cvs3/debian/tmp/usr/bin, so that the package can be made from home/knights/src/xdtv_2.4.1cvs3/debian/tmp and install it on the target system /usr/bin [16:04] somerville32: That won't help in this case, although it's a good general suggestion. [16:04] ok persia [16:05] knights: So, if you have the install commands, and stick it in $(CURDIR)/debian/tmp/usr/bin, does install complain about a permission error? [16:06] CUDIR? typo? [16:06] CURDIR, even :) [16:06] DESTDIR? [16:06] * persia wonders if bytes are being dropped somewhere [16:06] $(CURDIR) [16:07] Err, Rather $(CURDIR)/debian/tmp/usr/bin, which is $(DESTDIR)/usr/bin [16:07] Sorry persia, I don't understand 'if you have the install commands, and stick it in' [16:08] You want me to copy /usr/bin/install to there? [16:08] knights: Sorry: I'm tired. If you add the install commands to debian/rules, and install the script.sh files to /home/..../tmp/usr/bin/script, do you get an error? [16:10] Could someone who knows python better than I please tell me what kind of data structure http://paste.ubuntu-nl.org/43416/ is building, and whether I can add a third level? [16:15] persia: http://pastebin.ca/762317 [16:15] Thats the tail of my build log === _czessi is now known as Czessi [16:16] knights: Right. it reports "install -m 755 xdtv_makedvd.sh /usr/bin/xdtv_makedvd". We want it to report "install -m 755 xdtv_makedvd.sh /home/knights/src/xdtv_2.4.1cvs3/debian/tmp/usr/bin/xdtv_makedvd". Now, let's look at your rules file. [16:16] ok [16:17] http://pastebin.ca/762320 [16:18] knights: Right. Now we had hoped that $(DESTDIR) would expand to "/home/knights/src/xdtv_2.4.1cvs3/debian/tmp", but it doesn't seem to be doing that. [16:18] knights: Does that make sense as to why you would encounter that error? [16:19] What is it expanding to? [16:19] The wrong thing obviously [16:20] knights: Let's look at the input and output again. In debian/rules we have "install -m 755 xdtv_makedvd.sh $(DESTDIR)/usr/bin/xdtv_makedvd", and in the build output we have "install -m 755 xdtv_makedvd.sh /usr/bin/xdtv_makedvd". What is $(DESTDIR) [16:20] ? [16:21] DESTDIR isn't defined [16:22] knights: Exactly. [16:22] :() [16:22] OK- thanks. I'll get rid and see how it goes [16:22] knights: How does removing it help? [16:23] So I need to define destdir in rules? [16:24] knights: Or maybe there is another variable you can use [16:25] Do I replace my install DESTDIR with CURDIR? [16:25] DESTDIRs [16:25] knights: What is $(CURDIR)? [16:26] You got me! [16:28] knights: OK. http://doc.ubuntu.com/ubuntu/packagingguide/C/ch04s02.html isn't an ideal document, but it can help to answer that question. [16:31] ScottK: hello [16:32] So CURDIR is kinda equivalent to . [16:32] What is the command to restart package installation when it has been interrupted? [16:32] its the build dirs . [16:32] knights: Right. [16:32] cool :) [16:33] So, we need to put the right things in the install calls. There are two choices, either to define DESTDIR or to use CURDIR in the calls directly [16:40] * persia grumbles about formalisation of data structures in python making recursion annoying === Ng_ is now known as Ng [16:40] persia: but what gets me is that my rules file already said [16:40] $(MAKE) install DESTDIR=$(CURDIR)/debian/tmp [16:41] is that line incorrect? [16:42] knights: That's a use/mention distinction. In "$(MAKE) install DESTDIR=$(CURDIR)/debian/tmp", you are calling the program whose name is stored in the MAKE variable with two arguments, "install" and "DESTDIR=$(CURDIR)/debian/tmp", after expanding $(CURDIR) to the value of CURDIR. [16:42] This second argument sets DESTDIR for the target makefile (./Makefile), in which $(DESTDIR) may then be used freely. [16:43] This has nothing to do with the value of DESTDIR in debian/rules [16:44] Compare with a shell script: if your shell script includes the line "aptitude install apt=0.31" this doesn't set the value of $apt to "0.31" [16:44] ok I kinda get that [16:45] knights: I'll suggest that http://www.gnu.org/software/make/manual/make.html is worth reading, but I suspect you're very close to a solution for your current problem. [16:46] I'd like to think so! [16:47] * persia loses to the inconvenience of python data structures and files a bug without a patch [16:48] I can see that if I'm to get into packaging or programming reading that would be a must [16:51] Grr... There's already been a bug for 3 months. [16:51] persia: bug number? [16:51] joejaxx: debian bug #434989 [16:51] Debian bug 434989 in linda "linda: please adopt new menu policy" [Important,Open] http://bugs.debian.org/434989 [16:52] * joejaxx looks [16:53] joejaxx: The data is stored as tuples in a dictionary, which is fine when there are two levels. The new model allows one, two, or three levels, depending on context, and I'm having difficulty handling mixed tuples and dictionaries, which is probably due to my poor understanding of python data structures. [16:53] oh [16:53] its written in python lol [16:53] joejaxx: Any suggestions? [16:53] Hey Joe! [16:54] * joejaxx does not take a look [16:54] persia: i do not know python [16:54] knights: hi [16:54] Seems to be a fair bit of buzz over fluxbuntu [16:54] joejaxx: Ah. Too bad. Thanks anyway. [16:54] persia: you are most welcome [16:54] Even though its not out yet :) [16:54] knights: maybe :) [16:55] yeah i do not know what that is about :P [16:55] joejaxx: The RC booted fine for you then? [16:55] knights: of course lol [16:56] we had practically the entire channel test it before release [16:56] i need to look at isolinux [16:57] good [16:57] dunno why my machines didn't like it then - I checked the MD5 and burned it twice so... === apachelogger_ is now known as apachelogger [16:59] persia: Only thing I can think of now is doing a [16:59] install -m 755 xdtv_makedvd.sh $(CURDIR)/debian/tmp/usr/bin/xdtv_makedvd [16:59] in the install but that'd only be good for building if anything right? [17:00] Is it that I'm missing a -c option? [17:01] knights: Isn't it that you want to build the package? So something that works for building would be ideal, no? [17:01] I suppose you're right :) [17:01] knights: Also, `man install`: -c is ignored :) [17:01] * persia sleeps [17:01] Well, really I want to shut up lintian - the package build np [17:01] Good Night persia :) [17:02] Gnight persia [17:02] Night persia! [17:02] Night persia [17:02] Thanks for the help persia! === bear__ is now known as bear [17:45] is anyone working on updating wxwidgets2.8 to 2.8.6? [17:55] for merge bug reports, for the changelog that is shown, should that be the debian changelog or the one with the ubuntu modification on it as well [17:55] ? [17:57] I'm pretty sure both, joejaxx [18:05] wth lol [18:05] i just got a timeout error on lp [18:07] wth? :\ [18:07] it keeps happening [18:07] You don't use lp too often than :P [18:09] joejaxx: can you give me the link for the page you get timeout? [18:09] its the file a bug package for ubuntu :P [18:09] ok [18:10] joejaxx, Let the people in launchpad know the OOPs number [18:10] doko: ping [18:10] nxvl: you probably want to leave a message with that ping :) [18:10] nxvl: just ask [18:11] my homepage works [18:11] doko: i'm having a problem building freemind (LP Bug #126537) [18:11] Launchpad bug 126537 in freemind "FTBFS" [Undecided,Confirmed] https://launchpad.net/bugs/126537 [18:11] and as far as i have seen it seems to be that the ncurses dialog from j2re1.4 it's now showed [18:12] is there anyway to make it accept the license or show the dialog for building it? [18:12] no, not on the buildds. did you try to build it with icedtea? [18:13] joejaxx: first is a good practice to see if he's there :D [18:13] nop, trying... [18:16] doko: i meant to ask you, why does icetea not lable itself in firefox as 1.7 well it might but also lables parts of java 1.4, i dont have GUI atm so i cant look but i did set up icedtea in alternatives [18:17] gnomefreak: EPARSEERROR [18:17] icedtea is version 1.7 right? [18:17] pre 1.7 [18:17] I have a prob with a package that has a few .sh files- I need to drop the .sh extension and so persia recommended I use the install command in my rules file to copy them- I can do that but this doesn't prevent the Makefile copying the .sh files over too. Persia recommended I try to avoid modifying the Makefile though and that I coukd do this through rules with install [18:17] are you allowed to unionfs a mountpoint on top of itself? [18:17] or do you have to specify a different path? [18:18] doko: the long list in firefox for java maybe 20 items, most say version 1.4 even after setting icedtea in update-alternatives [18:18] doko: once hardy is fixed if its still like that i will file a bug on it [18:19] surely I've just got to adjust the makefile? Or can I delete files using rules and rm or something? [18:20] icedtea- arrgh! People should know better than to name packages after food, drink etc. I really want some Iced tea now! :) === x-spec-t is now known as Spec [18:36] 77[A[B[A[A[B[D[A [18:37] jdong: lol ? === nicolai__ is now known as Kopfgeldjaeger [18:45] bug #44806 [18:45] Launchpad bug 44806 in gwave "No .desktop file" [Low,Fix released] https://launchpad.net/bugs/44806 [18:45] ok nice [18:47] joejaxx: silly control characters :) [18:50] if you have a desktop file in debian/ dh_desktop should automatically pull that right? no need for install ? [18:50] gnomefreak: it says it's handles 1.4 as well. what's wrong with it? [18:52] nothing i expected to see only 1.7 or atleast most of it since sun-java6-plugin adds 1.6 to most of the list if not all [18:55] good afternoon bryce_ [18:55] hi gnomefreak [19:20] persia: REVU-system said segfault ;-) [19:20] persia: Too much stuff exception [19:20] persia: http://cs.helsinki.fi/u/twruottu/blog/#packagingprogressquestforubuntu [19:21] There is my writing about case pq. [19:21] Is persia core-dev? === mathiaz_ is now known as mathiaz [19:45] keescook: i have found the same as you, it must be a pida bug [19:55] nxvl: cool; glad we tracked that down. [20:10] bad things to do before a diff: dos2unix *.c [20:11] I'm sure diff can ignore that [20:11] unix2dos *.c ? [20:20] pwnguin: why not something like diff -Naur --exclude="*.C" [20:22] what would that do? [20:23] the whole point is to patch C files === lamalex_ is now known as lamalex === michele78 is now known as __michele77 [20:30] fortunately theres unix2dos [20:31] 4MB diff down to 24kb [20:37] persia: what was the other merge that you want me to do? [20:39] persia: nevermind it was ecasound [20:40] good evening all! [20:42] I need agent Moulder... why pointing firefox to http://rbelmont.mameworld.info/sdlmame0120u1.zip it downloads the package, [20:42] while wget http://rbelmont.mameworld.info/sdlmame0120u1.zip doesn't work?! :( [20:53] because that is not actualy a zip file, its a html file with a javascript function to download the real zip, but more to the point this is not a suport channel [20:57] imbrandon: thanks :) I asked here because comment on my package asked to implement the get-orig-source [20:57] I never saw something like that! [21:00] actualy it looks like some strange 302 redirect to google.com [21:00] weird hosting [21:00] http://web-sniffer.net/?url=http%3A%2F%2Frbelmont.mameworld.info%2Fsdlmame0120u1.zip&submit=Submit&http=1.1&gzip=yes&type=GET&ua=Mozilla%2F5.0+%28X11%3B+U%3B+Linux+i686%3B+en%3B+rv%3A1.8.1.8%29+Gecko%2F20071022+Epiphany%2F2.20+Firefox%2F2.0.0.8+Web-Sniffer%2F1.0.24 [21:02] imbrandon: I must admit I'm not so skilled with the web... :( [21:03] I'm getting this error `W: xdtv: setuid-binary usr/bin/xdtv_v4l-conf 4755 root/root` from my new deb off lintian as my prog contains a v4l config tool which needs root. How do I flag for this? [21:03] np , honestly i would ask whom ever is the host for that file to put it elsewhere [21:04] or shall I just wap a chmod in my rules install? [21:08] imbrandon: they have no interest in the site itself, it's barely a snapshot distribution page === tmarble_ is now known as tmarble [21:08] I asked for an archive of older source to download from, and I've been told that files remain in the same place [21:08] but with no direct link to them [21:10] I understand their view: the devel cycle is really fast (a snapshot a week) and site is not their main target === hellboy195 is now known as orcalefan === orcalefan is now known as oraclefan === oraclefan is now known as hellboy195 [21:14] Any cdbs wizards around? [21:14] mok0: I wouldn't call myself a wizard, but whats your problem? [21:15] I'll see if I can help. [21:15] I need to install a program suid to root, but the cdbs rules change it to 755 [21:16] I've tried to make a rule binary/foo:: but it doesnt solve the problem [21:17] mok0: I think what is happening, is that dh_fixperms gets called and fixes that up. I kinow dh_fixperms can be given a list of exludes, but I don't know how that translates to cdbs variables, without having a look myself. [21:18] * joejaxx wishes he did not have to know about cdbs to become a motu :\ [21:18] TheMuso: I figured it was dh_fixperms doing it, but I have not seen that you can tell it to do things [21:19] * mok0 thinks cdbs is an aquirede taste... [21:19] mok0: Yeah in the manpage for dh_fixperms it explains what you can do, but as I said, I don't know how that translates to cdbs. [21:19] hmm, I now find a target binary-predeb (called just before creating .deb) [21:20] it might work... [21:20] mok0: try the variable DEB_FIXPERMS_EXCLUDE [21:20] slangasek: Thanks, I thought there would be something like that, but currently couldn't be bothered looking. :p [21:20] slangasek: Ah! I'll check the docs [21:20] (found by reading the text of /usr/share/cdbs/1/rules/debhelper.mk; the ultimate anti-endorsement for cdbs) [21:21] lol [21:21] :-D [21:21] hehe [21:21] down with cdbs! [21:21] * joejaxx runs [21:26] james_w: is it possible to use "bzr import-dsc --snapshot" for Ubuntu (like snapshots.) for debian? [21:34] DEB_FIXPERMS_EXCLUDE works great! Megathanx! [21:35] blueyed: does ubuntu have a snapshots? [21:36] james_w: not that I know.. I thought you would know. But it's ok. I'm finding my way with dget currently. [21:37] Unfortunately the .dsc on https://edge.launchpad.net/ubuntu/+source/db4.4/4.4.20-8.1ubuntu3 is not dget-able AFAICS. (different paths in URL) [21:39] ummm just wget them all 3 and dpkg-source -x *.dsc [21:41] blueyed: is there an index listing the versions available anywhere? [21:41] could anyone here please explain how I do a lintian override for a file that needs to be installed setuid in my deb? [21:42] imbrandon: I actually drag them into the konsole and let kfmclient copy them. Still not ideal. [21:43] james_w: not that I know of. The above "per release" pages seem to be the best available (for old versions). [21:44] blueyed: yeah, launchpad.net doesn't make it easy to do this. [21:45] I would suggest wgetting all files, and then run "bzr import-dsc *.dsc". [21:48] Who is going to take to TB the discussion that my pq package raised? [21:48] Should I do it myself? [21:49] I was hoping the request could containt a link to my blog. [21:51] cyberix: why? [21:52] Because I took sometime to write about the case in detail [21:52] http://cs.helsinki.fi/u/twruottu/blog/#packagingprogressquestforubuntu [21:53] and I was told yesterday that only TB can decide what to do with the case and similar cases in future (in case you asked about taking it to TB) [21:55] joejaxx: . === apachelogger_ is now known as apachelogger [22:10] I bumped into the program YADA today. Is anyone using it? Sounds pretty useful === rrittenhouse is now known as KC8TAD [22:11] mok0: Stay away!!! [22:11] mok0: it's discouraged [22:11] mok0: if you want to know how bad it is, talk to StevenK. [22:11] I'm curious... [22:11] :) [22:11] Or more to the poit, watch StevenK and others rant and rave about how shocking it is. [22:11] Hehe. OK [22:11] is it worse than checkinstall? :P [22:12] * norsetto still has nightmares after he stumbled with yada [22:13] gahhhhhh [22:13] I like the idea of having just one file to edit though... [22:13] mok0: Um, if you do, take a look at rpm spec files. [22:14] why does &fail(launchpad); on the day i am trying to do merges :( [22:14] TheMuso: I have. [22:14] little quiz: I'm using the feisty xserver-xorg video driver, the feisty wireless driver, don't have compiz, removed strigi after 20 sec, can I be considered to be on gutsy? [22:14] norsetto: ? [22:14] I just finished a package with 9 subpackages, and it's a nightmare keeping track of all those little files... [22:15] norsetto: what does lsb release say? [22:16] mok0: IMO its much easier managing several files, than one big file. [22:16] joejaxx: ok, call me guisty then [22:18] TheMuso: It's not bad, but I hail emacs when writing .install files... ;-) [22:19] lintian question [22:19] E: soulfu source: not-binnmuable-any-depends-any soulfu -> soulfu-data [22:20] translation into english? === Spec is now known as x-spec-t [22:20] pwnguin, Use the information flag [22:20] norsetto: What's your version of libc6? [22:20] lintian -i [22:21] mok0: let me check, I just saw an upgrade [22:21] pwnguin: You're using binary:version when you likely wanted source:version [22:21] mok0: 2.6.1-1ubuntu1 [22:21] no im not [22:21] norsetto: That makes it gutsy [22:21] in fact, -info suggests the opposite is trie [22:21] true [22:22] norsetto: feisty has glibc vers. 2.5 [22:22] mok0: Ah, I see; thanks for the help [22:22] pwnguin: opposite, as in binary:version is preferred? [22:23] apparently [22:25] pwnguin: Aha! arch:any -> arch:any should be ${source:Version}, and arch:any -> arch:all should be ${source:Version}. My apologies for the confusion. [22:25] Err... arch:any -> arch:any should be${binary:Version}, and arch:any -> arch:all should be ${source:Version}. [22:39] man [22:40] you wanna talk about scaring people about packaging, just paste that line [22:40] * pwnguin goes back and reads the difference between any and all [22:40] ahhh, I remember those days [22:41] any gets compiled on all arches seperately, all just compiles once for all arches, like bash scripts [22:41] "what the heck?!?! any and all is the same thing" [22:41] heya LaserJock [22:41] all lies [22:42] heh [22:42] mmmm red koolaid [22:42] what's wrong with my lintian [22:42] E: soulfu_1.5.2-1_source.changes: bad-distribution-in-changes-file gutsy [22:42] 11:42:33 up 475 days, 19:35, 37 users, load average: 0.21, 0.21, 0.22 [22:42] almost rollover time [22:43] time to update the kernel? [22:43] ajmitch, what box is that? [22:43] pwnguin, old lintian ? [22:43] imbrandon: i dont think so... [22:43] imbrandon: a debian box [22:44] 17:44:24 up 300 days, 7:34, 12 users, load average: 0.03, 0.04, 0.06 [22:44] :D [22:44] ajmitch: theres an entire site dedicated to uptime records. sort of like a highscore list =/ [22:44] when i saw that i pointed out that it wouldnt be hard to modify the answer via /proc/kmem [22:45] pwnguin: haha write a kernel module that supports writeable /proc/uptime? :D [22:45] jdong: well, not that advanced [22:45] jdong: lol [22:45] jdong: write a kernel module that kprints the address of the variable [22:45] if I submit a patch like that on lkml, what do you think will happen? :D [22:45] then use /proc/ to write to the memory address [22:45] people will sigh & say 'not again' [22:45] supporting setting an epoch to bootup time :D [22:45] or just modify the copy/paste [22:46] imbrandon: *gasp*! [22:46] uptime: 1 million days! [22:46] http://revu.tauware.de/details.py?package=libqalculate ...any comments? [22:46] apparently the guy who thought it was easy / funny enough to try wound up with negative uptimes [22:46] jdong: lol you are crazy lol [22:47] joejaxx: haha that's my reputation around here, isn't it? :) [22:47] speaking of reboots, i'll brb [22:48] he still hasnt released the source because he doesn't want to be the guy who broke uptime.org for good [22:48] jdong: lol [22:49] hmm, the uptime on my home machine is 22 days [22:49] so much for being a server [22:49] speaking of source release... I've got a quick GPL-ish question. [22:49] joumetal: which is the bug# for the transition for the rdepends (or is no transition required?) [22:50] Let's say I'm writing a media encoder frontend that is going to use a GPL'd backend, like say ffmpeg (for the moment assume it's totally GPL) [22:50] the way I understand it, if I choose to link against it as a library and call its API to do the encoding, I am obligated to release both my app and my ffmpeg sources under the GPL. [22:51] however, if my app launches the ffmpeg executable externally, then I am not obligated to open-source my application. [22:51] unless the ffmpeg is unmodified [22:51] (1) Is this accurate [22:51] jdong: yes, generally [22:51] (2) Is this right? [22:51] jdong: why not use gstreamer? [22:51] Burgundavia: it's a totally hypothetical question [22:51] ahh, ok [22:51] Burgundavia: I have no plans to write a closed source media encoder ;-) [22:51] jdong: FSF would say no and no but in reality it is Yes and maybe [22:51] jdong, yes thats correct [22:52] in that case, yes, you are correct [22:52] In this case, other than a technicality, I see nothing different between the two approaches when it comes to the big picture that I am using an open source backend. [22:52] it confuses me why they would be treated differently? [22:52] pwnguin: Just as a last note before I stop refreshing my knowledge of dependencies, always use >= ${source:Version} (never '=') for arch:all depends on arch:any [22:52] some applications don't expose certain things publicy [22:53] also, some things are libraries, not applications [22:53] jdong: I guess it sort of depends on what you think of as a "work" [22:53] persia do you mean bug 133336 or bug 102328? (rdepends?) [22:53] Launchpad bug 133336 in libqalculate "New upstream version" [Wishlist,Confirmed] https://launchpad.net/bugs/133336 [22:53] Launchpad bug 102328 in qalculate-gtk "New upstream release available" [Wishlist,Confirmed] https://launchpad.net/bugs/102328 [22:53] persia: this is a any depends on all [22:53] Burgundavia: then, can't I write an open-source bridging wrapper between my closed-source app and a GPL library, to expose a callable binary and proceed to profit? [22:53] jdong: source compatibility: as long as you call externally, you don't care about the source, just the behaviour. If you call internally, you also care about the implementation. [22:53] the game depends on its music, levels etc. [22:53] jdong: a good way to think about it is standing on someones shoulders vs standing next to them [22:53] pwnguin: Right. Just wanted to mention for completeness :) [22:53] jdong, The answer really does depend on who you ask. [22:53] jdong: no, because the shim library would become gpl [22:54] jdong, yes you can, look at all the windows mencoder front ends [22:54] gstreamer is a great example of this [22:54] Burgundavia, shim executable [22:54] persia: well, then for completeness' sake, when i change "any" to "i386", does that change anything? [22:54] Burgundavia: yes, but the shim library could just be that, a skeletal bridge that still allows my app to be closed source [22:54] Burgundavia: IMO it sounds like circumventing the GPL by technicality again.... [22:54] but you couldn't like the shim library with closed object [22:54] link [22:54] jdong: all law can be worked around [22:55] pwnguin: no, but if the shim library was a shim binary..... I can popen() to it. [22:55] liba is gpl, write a gpl app to make a cli interface to it, then a closed front end [22:55] pwnguin: No. An arbitrary list of specific architecutures is considered to be equivalent to arch: any, but be a workaround for hardware issues [22:55] Where is mom? [22:55] imbrandon: yeah, arguably you can build a setup like that for most GPL'd apps that would circumvent the GPL [22:55] well, this is more a workaround for crappy source [22:55] somerville32: merges.ubuntu.com [22:55] imbrandon: is it considered legal? [22:56] littered with sizeof(int) == sizeof(int*) assumptions [22:56] pwnguin: Just patch it then. [22:56] heh [22:56] jdong, well iirc the gpl hasnet ever been tested in court, but yes it is "legal" [22:56] g'night all [22:56] pwnguin: No, really: lots of people use 64bits these days [22:56] imbrandon: are there any plans to address cheap circumventions like that? [22:57] not really [22:57] persia: then any of them are welcome to write the patch [22:57] breaking that would break a lot of other stuff [22:57] not really [22:57] persia: i expect a couple thousand lines of patches there [22:57] the reality is that the most interesting bits people want to use in closed source stuff are libraries you cannot make into applications [22:58] pwnguin: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=04_wx-strings.diff;att=1;bug=427853 [22:58] Burgundavia: ok, interesting. thanks for the insight. [22:59] persia: is there a point to that? [22:59] pwnguin: Patch size. Go for it! [22:59] persia: i am done with merging for today :D [22:59] joejaxx: Thanks for your help. [23:00] * somerville32 does some merges. [23:00] persia: it also adds a build-dep [23:01] persia: there are 9 i did today [23:02] joejaxx: You'll get in your own list :) [23:02] pwnguin: Fixing 64-bit adds a build-dep? [23:02] persia: ? lol [23:02] persia: that patch did [23:02] persia: [23:03] pwnguin: Same headers package as other includes, but that's not important. I was talking about patch size. [23:03] persia: my own list? [23:04] joejaxx: http://ubuntu.joejaxx.org/ [23:04] oh hahaha [23:04] persia: well, when you add in context lines, it's probably around five to thousand in length... [23:04] i have no where near over 100 uploads [23:04] oh wait [23:04] nevermind it is the beginning of the cycle [23:04] :D [23:05] joejaxx: 9 is a big number right now :) [23:05] yea 13 makes te list :) [23:05] * joejaxx searches for some more merges [23:05] persia: personally, the effort vs reward isn't there for me to write it. its possible someone else does, and they're welcome to submit patches. i recall someone on the upstream forum stating they took a look at it [23:05] joejaxx: merge thinkfinger [23:05] pwnguin: If someone else is looking at it, then that's fine. Just remember that amd64 is one of the supported architectures, so we need a good reason not to support it. [23:06] pwnguin: i do not see that on the list [23:07] im not sure what happened [23:07] oh [23:07] sorry [23:07] it'd be a sync [23:07] terminology ftl [23:07] persia: well, if upstream can't be bothered to care, im not sure I want to start caring... [23:08] ponders upgrading to hardy [23:08] i am definitely going to screenshot the top ten uploaders if i make it :D [23:08] imbrandon, I just added hardy as a deb-src [23:08] persia: it was painful enough just to get it to BUILD on i386 linux [23:09] I figured downloading it's binaries would be a scary ride at this point [23:09] persia: Do you follow the MOTU Council list? [23:12] Hey everyone, Genpo has been updated and is up for review. http://revu.tauware.de/details.py?package=genpo Thanks :) [23:13] joejaxx, how often does your top 10 uploaders thing update? [23:14] superm1_: i update it everyday [23:14] or almost everyday [23:14] joejaxx, ook [23:14] cron ? hehe [23:14] imbrandon: i put it on a cron before and it broken [23:14] broke* [23:15] i never put it back [23:16] joejaxx: Where can we see that 10 uploaders thingie? [23:16] mok0: ubuntu.joejaxx.org [23:16] ScottK2: Yes. [23:16] Why am I getting: [23:16] gpg: [stdin]: clearsign failed: secret key not available [23:16] at the end of debuild? [23:17] gpg --list-secret-keys prints my key OK [23:17] knights: The last entry in the changelog doesn't match any of the identities for any of the secret keys on your keyring [23:17] Thanks persia! [23:22] persia: Thats not the case. I take it you mean the top/most recent entry in debian/changelog? That perfectly matches my gpg key name ans e-mail [23:24] http://pastebin.ca/762867 [23:25] That's my changelog [23:25] knights: In that case, you probably have a comment as part of the identity in your key, and forgot to put the comment in the changelog. [23:26] knights: Is "allcoms@gmail.com" defined in your gpg key? [23:27] good idea never post email addresses in email formoat [23:27] Oh! You're right! I put a comment in too! [23:27] ;) [23:27] gnomefreak: lol [23:27] gnomefreak: why not? [23:27] spam [23:27] lots of spam [23:28] umm, it's going to be indexed by google anyway [23:28] gnomefreak: Don't you have a spamfilter? [23:28] these are public channels [23:28] !offtopic [23:28] #ubuntu is the Ubuntu support channel, #ubuntu+1 supports the development version of Ubuntu and #ubuntu-offtopic is for random chatter. Welcome! [23:28] mok0: a few but isnt it nicer when you dont have to worry [23:28] gnomefreak: as soon as it's uploaded it's more "available" than these channels [23:28] this is a developer channel, please take all off-topic stuff to the correct channel [23:28] kthxbye :p [23:28] nixternal: lol [23:28] nixternal: that was random :P [23:28] nixternal: I think your !offtopic is the only offtopic ;-) [23:29] So basically I've now got to scrap my gpg key, get a new one and re-register with launchpad have I?? [23:29] imbrandon: where the heck are you at? you are the !offtopic officer [23:29] LaserJock: i didnt know once uploaded they were googlible(may not be a word) [23:29] nixternal: lol [23:29] knights: Or just add a comment to the changelog... [23:29] gnomefreak: Google for your email address. [23:29] Note several results for each upload you have ever made. [23:29] gnomefreak: sure [23:30] mok0: Did you get your merging questions answered? [23:30] knights: just add an email to your key [23:30] LaserJock: will in a sec [23:30] ScottK2: mmmm... yeah, sorta [23:30] knights: you can have more than 1 address per gpg key [23:30] crap cant google [23:30] gnomefreak: googling my email address give 1,430 results [23:30] mok0: Let me know what you need help with and I'll get glad to assist in getting you going. [23:31] I figure I have to file a bug report and attach a debdiff...' [23:31] well i could be too much trouble in links2/lynx [23:31] Does my comment go inbetween my name and e-mail address in the last changelog entry? [23:31] comment? [23:31] knights: name (comment) [23:31] ScottK2: Thx. Did you see my email about kaksi? [23:31] * gnomefreak lost [23:31] lol [23:32] Fujitsu: So the comment goes in brackets right? [23:32] I mean parentheses [23:32] or whatever you want to call () [23:32] mok0: I did. As long as there's a verbatim copy of the license in the tarball and the intent of upstream is clear, the archive should accept a package that's missing GPL headers in a few files. [23:32] LaserJock: i only get maybe 50 [23:32] knights: Yes. [23:32] cool- thanks! [23:32] mok0: So it's really up to you if you want to continue with it or not. [23:32] * mok0 checks to look [23:33] erm, my comment happens to be a .org e-mail. Is that ok? [23:33] omg it does show uploaded packages [23:33] sorry, web address [23:33] ty LaserJock [23:34] ScottK2: There is a COPYING file, but the comments I got from various reviewers was about the missing GPL clauses in some of the source files [23:34] my comment is a web address- is that OK still? [23:34] ScottK2: Anyways, if upstream is not active, it is perhaps not reasonable to include the program in Ubuntu [23:35] gnomefreak: Of course. === asac_ is now known as asac [23:35] Changelogs, -changes mails... [23:35] Fujitsu: yeah that [23:35] Bugs with changelog-closes-bugs comments... [23:35] (that last one will be fixed soon) [23:36] sorry im trying to get blood taken and talking to someone in my lug [23:36] mok0: They'll take it, but I suspect you're right if it's not maintained. You might ask LaserJock for an opinion. He does a lot of science stuff. [23:36] I take it that somebody synced a lot of new stuff from Debian. [23:38] ScottK2: Is there a "go" for new software upload for reviewing? [23:40] mok0: Yes. Today is the first REVU day of the Hardy cycle. [23:40] ScottK2: Cool! [23:41] Fujitsu, i tried to close as many bugs as i could find for mplayer that were supposed to be resolved by 1.0~rc2, but i'm sure i missed a few. since your more familiar with the bug list, when you get a chance can you double check if there are any others that stood out [23:41] superm1_: So I noticed. [23:41] I'll have a look now. [23:42] ScottK2: I've been working to package Torque (formerly OpenPBS) -- a very cool job submission system but it's licensed under a weird license. I am wondering if it could go into Multiverse [23:42] mok0: what are the terms of the license? [23:43] Well it's open source with some restrictions [23:44] mok0: Can you link to the license, please? [23:44] Fujitsu: Hang on, I'll pastebin it [23:44] mok0: Thanks. [23:45] http://paste.ubuntu-nl.org/43478/ [23:46] Registration? Ew. [23:46] Fujitsu: Yup [23:46] That's multiverse, if that. [23:47] Fujitsu: What are the conditions for multiverse? [23:47] Hm, does the second point imply that you may only redistribute it to those who will use it for non-commercial purposes, or that you will only redistribute it non-commercially? [23:47] mok0: Basically if we have the source but it's not quite free enough. Non-commercial, or whatever. [23:47] mok0: this is not meant to be a complete list of conditions: must be redistributable [23:48] Except it says points one and two don't apply anymore. [23:48] This software was developed for NCSA under a contract. [23:48] ScottK2: Ah, true. [23:48] It is not even called OpenPBS anymore... :-) [23:49] ScottK2: What do you think about paragraph 6? [23:49] That's essentially clause 4 of the old 4 clause BSD [23:49] That looks non-free like 4-clause BSD. [23:49] Yeah. [23:49] It's not non-free, just non-GPL [23:49] Otherwise (as long as 1&2 don't actually apply) it looks OK. [23:50] must be redistributable, must not impose conditions on other software, must not discriminate against endevors, that sort of stuff. some people also feel it should be limited to things that are very nearly open source [23:50] Like I said: the license is weird :-) [23:50] I think it's free and fine for Universe. It just can't be combined with GPL code. [23:50] ScottK2: Even with the advertising clause? [23:50] the advertising clause is free, just annoying [23:50] Debian accepts stuff with that [23:50] OK, universe it is, then. [23:51] I really wish people would use standard licenses. [23:51] Fujitsu: Really? You think? [23:51] debsign failed again because I don't have pinentry installed [23:51] mok0: Yes. They key thing is points 1 and 2 are non-operative, so it's essentially just 4 clause bsd [23:51] what package contains this? [23:51] This is a complicated package, I can submit it to revu.. ? [23:51] !find debsign [23:51] knights: What are you running [23:51] mok0: Go ahead. [23:52] gutsy [23:52] Oh, pinentry, not debsign, oops. [23:52] File debsign found in devscripts, zsh, zsh-beta [23:52] Fujitsu, my personal favorite is the WTFPL [23:52] imbrandon: Heh, yes. [23:52] Fujitsu: ok will do [23:52] knights: Feisty/Gutsy and Ubuntu/Kubuntu? [23:52] Fujitsu, and its dfsg free too :) http://sam.zoy.org/wtfpl/ [23:53] knights: It shouldn't be needed. It'll be pinentry-qt or pinentry-gtk2. [23:53] imbrandon: lololololo [23:54] Actually, this box is ubuntu studio. I installed pinentry-gtk and its on now [23:54] heh, there's an old demoscene invite that comes with a very similar license [23:54] joejaxx, sounds funny but its an honest to goodness lic approved to be dfsg and written by a former dpl iirc [23:54] vip2 [23:55] http://www.sesse.net/vip2-linux/ [23:55] Successfully uploaded packages. To revu. Enjoy ;-) [23:57] mok0, : what? [23:57] imbrandon: Can you please point sparky's ntpd at a local uni server? [23:57] It has drifted by 20 seconds in the past 12 hours. [23:58] Fujitsu, how about pool.de.ntp.org ? [23:58] imbrandon: NTP outbound is blocked. [23:58] faui45.informatik.uni-erlangen.de [23:58] i dont know if there is one localy [23:58] That should work. [23:58] k [23:58] give me a sec