[00:00] <joejaxx> if there is a case where the depends are different between the debian and ubuntu version we keep the ubuntu versions right?
[00:00] <bddebian> I would say only if necessary and if there are other changes
[00:01] <joejaxx> ok let me see
[00:01] <LaserJock> well, there doesn't need to be other changes
[00:01] <LaserJock> but only if necessary yes
[00:02] <bddebian> I mean if there are other changes it would be OK.  Otherwise, only if necessary.  Does that make more sense?
[00:02] <LaserJock> more yes
[00:03] <LaserJock> but I wouldn't think we'd keep non-necessary changes in any case
[00:03] <joejaxx> +       chmod 755 debian/rsh-server/usr/sbin/checkrhosts
[00:03] <crimsun> 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] <joejaxx> that is the only change
[00:03] <joejaxx> crimsun: ok
[00:03] <bddebian> crimsun: Are you a DD?
[00:03] <crimsun> bddebian: nope
[00:04] <joejaxx> really i have no idea how to test this without installing the package
[00:04] <joejaxx> since it is a depends issue and not a build depend issue
[00:05] <somerville32> Do a simulation?
[00:05] <joejaxx> somerville32: simulation?
[00:05] <somerville32> Yeah. IT goes through the installation without actually installing anything thing.
[00:06] <joejaxx> yeah but what about running it :P
[00:06] <crimsun> joejaxx: thankfully there's /usr/share/doc/pbuilder/examples/execute_installtest.sh
[00:06] <crimsun> (not to mention B92test-pkg in that same dir)
[00:07] <joejaxx> bug 76143
[00:07] <ubotu> 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] <joejaxx> bug #45991
[00:08] <ubotu> Launchpad bug 45991 in netkit-rsh "/usr/sbin/checkrhosts misses execute permision" [Medium,Fix released] https://launchpad.net/bugs/45991
[00:08] <joejaxx> hmm
[00:08] <crimsun> that would be a suitable Ubuntu delta if it's not already fixed in the Debian packaging
[00:09] <joejaxx> crimsun: yeah nether are fixed in debian
[00:09] <bddebian> Gawd I hate trying to get any help/advice in Debian :'-(
[00:10] <crimsun> ?
[00:10] <LaserJock> my gosh, Yahoo actually expects people to be able to use their new webmail?
[00:11] <crimsun> LaserJock: it's extremely heavy on JavaScript but seems to work tolerably
[00:11] <bddebian> Anyone familiar with conquest?
[00:11] <crimsun> most of the time I end up reverting to classic mail, though
[00:11] <LaserJock> it's completely unusable here :(
[00:12] <LaserJock> I don't know maybe webmail isn't the way to go until I get a new laptop
[00:13] <crimsun> I could see that
[00:14] <joejaxx> 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] <jdong> Fujitsu: amen.
[00:17] <TheMuso> Fujitsu: The thing thats wrong with hosting your own mail is when Telstra kills your line for a painful length of time.
[00:17] <jdong> whee, another azureus bug found....
[00:17] <Fujitsu> TheMuso: Ah, true.
[00:18] <Fujitsu> jdong: Joy.
[00:18] <joejaxx> jdong: :P
[00:18] <jdong> is it a crime to put urgency=just-fscking-build-it-now? :)
[00:18] <joejaxx> lololol
[00:18] <jdong> the last round took like a week in queue :)
[00:18] <Fujitsu> We're almost down to 1000 pending builds on i386! Not long to go now!
[00:18] <jdong> hahaha
[00:18] <jdong> how many of those are Openoffice? :)
[00:19] <Fujitsu> It's sped up now too, since Soyuz likes this number of builds more.
[00:19] <Fujitsu> jdong: Haha.
[00:19] <jdong> I'll work on a patch, then go back to starcraft then :)
[00:19] <LaserJock> Fujitsu: hosting my own mail where exactly?
[00:19] <LaserJock> :-)
[00:19] <Fujitsu> LaserJock: Wherever. Home?
[00:20] <LaserJock> google and yahoo have the best uptime
[00:21] <LaserJock> so they're the best way to make sure I can get to my email
[00:22] <LaserJock> I've gone back and forth several times on what to do with email
[00:22] <LaserJock> and have never really figured out a good solution
[00:22]  * joejaxx is on a roll with the merges
[00:22] <joejaxx> :D
[00:22] <joejaxx> i just did the uml-utilities one
[00:22] <jdong> does setting urgency=medium actually do anything?
[00:22] <LaserJock> not in Ubuntu I don't think
[00:22] <Fujitsu> jdong: Not in Soyuz.
[00:22] <joejaxx> now what do i have to put in these bug reports for merges?
[00:23] <crimsun> joejaxx: well, a debdiff is good : )
[00:24] <joejaxx> crimsun: :P i mean the bug content etc :P
[00:24] <joejaxx> maybe my ivman merge is still on lp
[00:24]  * joejaxx goes to look
[00:24]  * Fujitsu points to requestsponsor
[00:24] <jdong> ivman is still around?
[00:24] <joejaxx> jdong: yes
[00:24] <joejaxx> i use it :D
[00:24] <jdong> haha
[00:24] <joejaxx> Fujitsu: that is a script?
[00:24] <jdong> joejaxx: anyone else? ;-)
[00:24]  * joejaxx looks
[00:24] <joejaxx> jdong: all the fluxbuntu users :D
[00:24] <crimsun> pfft, 80386s are still around.  Of course ivman would be.  : )
[00:24] <jdong> joejaxx: ah, ok
[00:24] <Fujitsu> What's wrong with ivman?
[00:25] <joejaxx> Fujitsu: i do not have a request sponsor script
[00:25] <jdong> Fujitsu: just reminds me of the old days when hal automounting was just around :)
[00:25] <joejaxx> is it in ubuntu-dev-tools?
[00:25]  * LaserJock has never heard of ivman
[00:26] <joejaxx> LaserJock: it is automounting for us without gnome :D
[00:26] <Fujitsu> 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] <LaserJock> Fujitsu: I think so
[00:26] <imbrandon> ivman is what kubuntu uses also iirc
[00:26] <Fujitsu> imbrandon: It's in universe, so I doubt it.
[00:27] <joejaxx> Fujitsu: but there is no application flag for merge for `requestsync`
[00:27] <joejaxx> :\
[00:27] <crimsun> at one point, Xubuntu used ivman
[00:27] <jdong> crimsun: they switched like 2 releases back
[00:27] <crimsun> 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] <jdong> 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] <imbrandon> 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] <joejaxx> anyone have an example merge bug report?
[00:29] <jdong> would a kind soul care to sponsor http://jdong.mit.edu/~jdong/motu/azureus_<IP_ADDRESS>-1ubuntu3.debdiff?
[00:29]  * jdong really hopes that's the last one....
[00:30] <Fujitsu> jdong: I'll look at it.
[00:30] <jdong> thanks
[00:31] <jdong> it's a trivial patch to the .desktop file
[00:31] <Fujitsu> jdong: So I saw. What is %U?
[00:31] <jdong> Fujitsu: URL to file
[00:31] <jdong> which Azureus doesn't like...
[00:32] <Fujitsu> Ah.
[00:32] <joejaxx> woohoo
[00:32] <joejaxx> flwm is my first package for hardy :D
[00:32] <crimsun> 'grats!
[00:32] <joejaxx> crimsun: thanks :D
[00:32] <Fujitsu> jdong: Do you have a bug number for that?
[00:32] <LaserJock> hmm, so NetworkManager has taken to pegging my CPU after reboot occasionally
[00:32] <joejaxx> https://launchpad.net/~joejaxx/+packages this is slowly getting bigger :D
[00:33] <jdong> Fujitsu: it's the last comment on bug 57875
[00:33] <ubotu> 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] <jdong> vommenter didn't open new bug report
[00:33] <Fujitsu> Ah, so not a bug on its own.
[00:33] <jdong> right
[00:33] <jdong> commenter*
[00:33] <Fujitsu> OK, I'll upload shortly.
[00:33] <LaserJock> it would be so lovely if hibernate ever consistently worked ;-)
[00:33] <jdong> thanks muchly :)
[00:33] <jdong> LaserJock: I've heard a lot of good things about tuxonice
[00:33] <Fujitsu> (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] <crimsun> LaserJock: it will freeze my gnome session occasionally, and I normally have to force-reload dbus
[00:33] <joejaxx> how many packages do i need on that before i should go for motu :P
[00:34] <jdong> Fujitsu: testbuild already succeeded here ;-)
[00:34]  * jdong posts testing deb on bug report
[00:34] <LaserJock> crimsun: mine seems to have a new "bug" every few weeks
[00:34] <LaserJock> it's just so weird
[00:34] <crimsun> 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] <Fujitsu> jdong: Uploaded.
[00:35] <joejaxx> crimsun: oh ok
[00:35] <joejaxx> :D
[00:35] <crimsun> joejaxx: e.g., your work on Ubuntu Studio certainly is notable
[00:35] <jdong> Fujitsu: thanks muchly :)
[00:35] <Fujitsu> 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] <crimsun> 'luck, Fujitsu
[00:35] <joejaxx> crimsun: yeah but that is not reflect in packages in universe :\
[00:35] <Fujitsu> Thanks crimsun.
[00:35] <joejaxx> reflected*
[00:36] <joejaxx> that is only ubuntustudio-meta
[00:36] <crimsun> joejaxx: have you worked closely with Colin (cjwatson)?
[00:36] <joejaxx> yes
[00:36] <joejaxx> but not for packages :\
[00:36] <LaserJock> you've also been around at UDSs
[00:37] <jdong> Fujitsu: good luck man!
[00:37] <crimsun> (my recommendation is to work actively through the hardy cycle and then apply)
[00:38] <joejaxx> crimsun: ok
[00:38] <Fujitsu> jdong: Thanks.
[00:38] <LaserJock> I agree with crimsun
[00:38]  * jdong puts MOTU work on his Hardy agenda too :)
[00:38] <crimsun> a /major/ boon would be to work on 6.06 LTS -> 8.04 LTS upgrade testing
[00:38] <LaserJock> joejaxx: you're a smart guy, just spend some consistent time working on MOTU stuff and it shouldn't be any problem
[00:38] <joejaxx> LaserJock: ok :D
[00:38] <joejaxx> crimsun: i can do that
[00:39] <joejaxx> lol after doing that flwm merge i just realized i can do this bug :D bug 48340
[00:39] <ubotu> 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] <joejaxx> there is no sessions file
[00:40] <crimsun> 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] <ScottK> joejaxx: In my experience, when it's time to apply, a MOTU will harass you to apply.
[00:40] <LaserJock> cyberix: what is it?
[00:40] <cyberix> Packaging great packages for myself doesn't really make sense.
[00:40] <ScottK> cyberix: Because of licensing issues?
[00:40] <joejaxx> ScottK: :P i will keep that indicator in mind :D
[00:40] <cyberix> No source available.
[00:41] <LaserJock> ?
[00:41] <cyberix> Permissive license, but no source code available.
[00:41] <crimsun> cyberix: eek, well, yeah, that's a major showstopper.  What work has been invested for Ubuntu multiverse?
[00:41] <Fujitsu> And it's PE.
[00:41] <ScottK> PE?
[00:41] <Fujitsu> Windows executable.
[00:41] <cyberix> It is unclear, if Ubuntu is willing to expand Multiverse with nonessential non-free packages.
[00:41] <joejaxx> oh wow :\
[00:41] <cyberix> Progress Quest
[00:41] <crimsun> cyberix: e.g., we have no source for Adobe Flash, but we use a script to download it
[00:42] <LaserJock> cyberix: we'd take it, if it's doable
[00:42] <crimsun> (it -> tarball containing binary plugin)
[00:42] <cyberix> http://progressquest.com/
[00:42] <ScottK> Right, but Adobe flash isn't distributable
[00:42] <cyberix> I posted it to REVU earlier
[00:43] <cyberix> But the entry was closed.
[00:43] <crimsun> ScottK: right
[00:43] <joejaxx> that is a windows binary :\
[00:43] <cyberix> joejaxx: Yep, but it works fine.
[00:43] <crimsun> via wine?
[00:43] <cyberix> yep
[00:45] <LaserJock> hmm, do we have any sort of policy for that kind of thing?
[00:45] <LaserJock> it's an interesting thought
[00:45] <crimsun> LaserJock: I'm not aware of any
[00:45] <Fujitsu> LaserJock: We do not.
[00:45] <cyberix> I've made some Ubuntu-integration for it.
[00:46] <cyberix> If you wan't to beta test, you can try http://cs.helsinki.fi/u/twruottu/pq_6.2-0ubuntu1_all.deb
[00:46] <cyberix> It _should_ work.
[00:46] <crimsun> (it would be worthwhile to also post the urls for the source packaging)
[00:47] <cyberix> I'll upload the new version to REVU
[00:47] <cyberix> Please close it again, if it isn't ok
[00:48] <Fujitsu> I don't really think we want multiverse to become a dumping ground for a lot of non-free Windows software.
[00:48] <crimsun> 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] <joejaxx> Fujitsu: yeah :(
[00:48] <joejaxx> should this a subject at the next MOTU meeting?
[00:48] <LaserJock> Fujitsu: why not?
[00:49] <crimsun> joejaxx: I think it would be a TB decision
[00:49] <Fujitsu> I agree with crimsun.
[00:49] <joejaxx> crimsun: oh
[00:49] <LaserJock> hmm, I don't know why TB would be interested, but doesn't hurt
[00:49] <joejaxx> how do we go about that?
[00:49] <crimsun> it would set precedent, I think
[00:49] <LaserJock> really?
[00:50] <LaserJock> only in that it's a Windows binary, I guess that might open up security issues
[00:50] <Fujitsu> Have we (that is Ubuntu, not Debian) accepted binary-only unimportant stuff before?
[00:50] <LaserJock> sure
[00:50] <crimsun> well, more importantly (I think), redistributability
[00:51] <LaserJock> Fujitsu: have a luck at Multiverse :-)
[00:51] <cyberix> dput done
[00:51] <Fujitsu> And also, I don't like the idea of Wine having rdepends.
[00:51] <Fujitsu> It's not the most stable of beasts, and generally has a blanket UVFe.
[00:51] <cyberix> Will the entry unclose automagically, or should someone do something?
[00:51] <Fujitsu> cyberix: The former.
[00:52] <LaserJock> might this be a MC question as well?
[00:52]  * ajmitch would prefer that multiverse be as small as possible
[00:53] <crimsun> LaserJock: I don't think it really falls into MC's jurisdiction
[00:53]  * cyberix does understand the minimal multiverse argument
[00:53] <LaserJock> crimsun: I would think it would, at least in a hierarchical sense
[00:53] <Fujitsu> ajmitch: Right, that's what persia and I said last night.
[00:53] <cyberix> I was talking earlier about a new "Beerbuntu repository".
[00:53] <LaserJock> I personally would like to see any CC/TB issue go through the MC
[00:54] <cyberix> But I think Progress Quest is a special case.
[00:54] <Fujitsu> cyberix: Why?
[00:54] <cyberix> Because it is more free than freeware
[00:54] <LaserJock> but I understand how that may not reflect the current understanding
[00:54] <crimsun> LaserJock: no offense, but I think that would be unnecessary overhead
[00:54] <cyberix> It allows you to do almost anything
[00:54] <joejaxx> cyberix: there is source though
[00:54] <cyberix> It just doesn't ship with source code
[00:54] <Fujitsu> cyberix: I fail to see the source.
[00:54] <Fujitsu> So how can you do much?
[00:54] <cyberix> Fujitsu: e.g. packaging
[00:54] <cyberix> I'm not sure, if having a freeware repository makes sense
[00:55] <cyberix> as most freeware may not allow packaging
[00:55] <LaserJock> 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] <Fujitsu> In my opinion, it doesn't belong in Ubuntu.
[00:55] <joejaxx> s/there\ is/there\ is\ not\ any/g
[00:55] <cyberix> My proargument is Ubuntu integration.
[00:55] <Fujitsu> But the TB has the final decision on that - they decide the purposes of the components.
[00:55] <crimsun> not to stir ashes or anything, but it's similar to the KDE 4 snaps in universe bit IMO
[00:56] <cyberix> And a proper bug channel for specific piece of software running inside Wine.
[00:56] <LaserJock> crimsun: which should have been a MC issue
[00:56] <cyberix> Instead of pouring all bug reports into Wine-package
[00:56] <joejaxx> cyberix: why cannot people get wine and run it themselves? :)
[00:56] <joejaxx> i have to do that with Oregon Trail with dosbox
[00:56] <LaserJock> joejaxx: something similar could be said of virtually every package in Ubuntu ;-)
[00:56] <Fujitsu> LaserJock: Except that MC has no jurisdiction over the main people, and are probably going to bend to Canonical requests.
[00:56] <joejaxx> and i would not want oregon trail in multiverse*
[00:57] <cyberix> joejaxx: Ubuntu integration gives you easy installation and easy updates.
[00:57] <cyberix> joejaxx: You'll neve have to know it is Windows software
[00:57] <joejaxx> cyberix: not for windows binaries :\
[00:57] <joejaxx> cyberix: yeah that is bad
[00:57] <LaserJock> Fujitsu: the question was over Universe packages, which is the MC jurisdiction
[00:57] <cyberix> :-D
[00:58] <cyberix> joejaxx: Well it is not bad from the user experience perspective.
[00:58] <joejaxx> this is almost like shipping roms for an emulator we have (well not exactly)
[00:58] <crimsun> joejaxx: fairly similar, yes
[00:59] <cyberix> sudo apt-get install efp
[00:59] <Fujitsu> cyberix: What is the integration you speak of, other than apt-getting?
[00:59] <cyberix> is an example
[00:59] <LaserJock> if it's legal then there's no inherent reason not to
[00:59] <crimsun> we can ship the emulator, but shipping the ROMs falls on a slippery slope
[00:59] <joejaxx> crimsun: yeap
[00:59] <cyberix> Fujitsu: desktop-file, mime-type integration, icon, man page
[00:59] <Fujitsu> Shipping freeware Windows binaries is a very slipper slope. There are a lot of them.
[00:59] <Fujitsu> *slippery
[01:00]  * minghua agrees with Fujitsu.
[01:00] <LaserJock> Multiverse is a slippery slope
[01:00] <LaserJock> people maybe should've thought of that in the beginning ;-)
[01:01] <minghua> 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] <minghua> You risk losing developers if you decide opening multiverse to all kinds of closed "freeware".
[01:02] <joejaxx> now i forgot what i was going to do
[01:02] <joejaxx> ok right the flwm bug
[01:02] <Fujitsu> 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] <cyberix> http://revu.tauware.de/details.py?package=pq
[01:02] <Fujitsu> And multiverse use should be minimised.
[01:03] <crimsun> personally, cyberix, it would be worth investigating whether it can be offered via CNR
[01:03] <LaserJock> Fujitsu: ok, but that is stated nowhere
[01:03] <ajmitch> Fujitsu: things that would be a serious inconvenience to users if we didn't have them
[01:03] <LaserJock> 'The "multiverse" component contains software that is "not free"'
[01:03] <Fujitsu> LaserJock: Right, we need a decision on that, which can only come from the TB.
[01:03] <cyberix> crimsun: I have no interrest in that as I've never used CNR and probably never will.
[01:03] <Fujitsu> ajmitch: Right, that's a better way of putting it.
[01:03] <minghua> 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] <cyberix> crimsun: But that might be just a sarcastic comment.
[01:04] <cyberix> Btw
[01:05] <cyberix> Please tell me, if I can improve pq package in someway.
[01:05] <cyberix> Except for reverse-engineering it and producing the source code.
[01:05] <joejaxx> lol
[01:05] <minghua> 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] <Fujitsu> minghua: I waited a couple of days, then attacked Hobbsee about it.
[01:06] <joejaxx> minghua: it took a while for my packages to get through
[01:06] <LaserJock> so we have 434 source packages in Multiverse (gutsy), that seems like more than "serious inconvenience"
[01:07] <minghua> Fujitsu: Sounds fair, I'll wait for a while.
[01:07] <joejaxx> and there are still some that have not been uploaded since last release
[01:07] <Fujitsu> LaserJock: A lot of that is from Debian.
[01:07] <crimsun> minghua: which?
[01:07] <minghua> crimsun: scim-hangul, bug 155046.
[01:07] <ubotu> Launchpad bug 155046 in scim-hangul "New upstream version 0.3.1 is available" [Wishlist,Confirmed] https://launchpad.net/bugs/155046
[01:07] <LaserJock> Fujitsu: sure, I'm just saying we've never been picky before
[01:08] <LaserJock> but clearly we need to be clear on the purpose of Multiverse
[01:13] <somerville32> Why would developers be upset if there was a repository with non-free stuff (ie. freeware)?
[01:13] <crimsun> minghua: uploaded to hardy.
[01:14] <LaserJock> somerville32: ummm, because we're into FLOSS :-)
[01:14] <minghua> crimsun: Thanks!
[01:14] <pwnguin> somerville32: because they swore an oath to uphold the morality of Free Software...
[01:14] <LaserJock> pwnguin: hehe
[01:14] <somerville32> soren, it is kind of like not providing support to people using Windows just because they use a non-free system?
[01:14] <somerville32> Gah
[01:14] <somerville32> Sorry soren, stupid auto-nick complete.
[01:15] <LaserJock> somerville32: we don't support Windows
[01:15] <pwnguin> we dont "support" things in universe/multiverse anyways :P
[01:15] <somerville32> Right.
[01:15] <LaserJock> pwnguin: yes we do
[01:15] <joejaxx> LaserJock: Dental FLOSS for All! :D
[01:15] <pwnguin> LaserJock: the homepage disagrees
[01:15]  * LaserJock bangs his head against a wall
[01:16] <LaserJock> pwnguin: it is community supported
[01:16] <crimsun> <cue sources.list comments>
[01:16] <joejaxx> lol
[01:16] <crimsun> (which are quite misleading)
[01:16] <minghua> LaserJock: ... which sometimes (or for some packages) is non-existent (IMHO).
[01:16] <LaserJock> minghua: that's fine
[01:17] <somerville32> I think the issue is pretty complex.
[01:17] <LaserJock> but it's just plain wrong to say that Universe is *not* supported
[01:17] <pwnguin> so its more of a heisenburg uncertainty support
[01:17] <somerville32> FLOSS on one side, providing easy to install software to provide a better experience on the other.
[01:17] <pwnguin> where you dont know if the developers care or not until you look
[01:17] <minghua> I actually have been thinking for quite a while that we need a "galaxy" component, larger than main but smaller than universe.
[01:18] <crimsun> what would it encompass?
[01:18] <persia> minghua: What problem does that solve?
[01:18] <LaserJock> minghua: I know, but it's just too many components flying around
[01:18] <LaserJock> i.e. a MOTU core set of packages
[01:18] <Fujitsu> Stuff that we think is sane, and maintain fairly well?
[01:18] <pwnguin> presumably the set of universe packages that people will "maintain"
[01:18] <minghua> persia: So that users know which packages are better supported, and which ones are "completely on your own"?
[01:18] <LaserJock> as set of packages that MOTU commits to supporting
[01:18] <ajmitch> that'd have about 10 packages in it?
[01:18] <pwnguin> 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] <joejaxx> TheMuso: yay! :D
[01:19] <crimsun> 10 might be optimistic ;)
[01:19] <ajmitch> why don't we all just go to debian when that happens? :)
[01:19] <pwnguin> is anyone in MOTU on the security team?
[01:19] <joejaxx> ajmitch: lol :D
[01:19] <persia> minghua: I suppose, but I suspect that it would just encourage people to not care more about the remainder of universe
[01:19] <joejaxx> pwnguin: which one
[01:19] <joejaxx> swat?
[01:19] <joejaxx> or core
[01:19] <Fujitsu> pwnguin: The security team is made up of Canonical employees, and does main only.
[01:19] <LaserJock> pwnguin: we have a MOTU Swat team
[01:19] <Fujitsu> (well +restricted)
[01:19] <tonyyarusso> Fujitsu: really?  al Canonical?
[01:19] <tonyyarusso> *all
[01:20] <pwnguin> im aware that security is all done in main
[01:20] <minghua> persia: Well, can't be too much worse than current situation, if you pardon my pessimism.
[01:20] <pwnguin> i was wondering _if_ security was to be provided to some portion of MOTU
[01:20] <crimsun> 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] <pwnguin> whether there was any actual experience in MOTU for it
[01:20] <persia> minghua: I disagree, but don't see value in arguing about who might be motivated to do waht.
[01:20] <persia> crimsun: That matches my thoughts well.
[01:20] <Fujitsu> tonyyarusso: Yes, they have embargoes to keep and the like.
[01:21] <tonyyarusso> Fujitsu: what's that?
[01:21] <LaserJock> pwnguin: I don't agree that all security is done in main, what do you mean by that?
[01:21] <joejaxx> pwnguin: sure
[01:21] <joejaxx> motu swat
[01:21] <ajmitch> not that a volunteer couldn't maintain an embargo
[01:21] <minghua> 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] <persia> ajmitch: Many do, for specialised cases.
[01:21] <crimsun> pwnguin: universe/multiverse security, like SRU, is best-[community]effort
[01:21] <ajmitch> however there are restrictions for the security community on who's allowed on vendor notification lists
[01:22] <ajmitch> 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] <ajmitch> of course, that's the way things are meant to be
[01:22] <persia> ajmitch: True.  I was thinking of people who had a non-Ubuntu relation to those lists.
[01:22] <crimsun> 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] <ajmitch> since canonical is not meant to be the only player in town
[01:22] <somerville32> Do most users even really understand where the software is coming from?
[01:22] <LaserJock> somerville32: hopefully not too much
[01:23] <LaserJock> as long as it's Ubuntu
[01:23]  * pwnguin hopes that users are aware of the upstream concept
[01:23] <ajmitch> another reason why it's tricky to stick random windows binaries in multiverse
[01:23] <LaserJock> pwnguin: lol
[01:23] <crimsun> 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] <minghua> crimsun: You raise valid concerns.  And it's definitely true that changes without significant perceivable gain should not happen.
[01:24] <LaserJock> rather than a component I'd rather see a priority list
[01:24] <LaserJock> or a priority set of packages
[01:24] <ajmitch> "we choose to ignore X,Y & Z before ignoring A, B & C:
[01:25] <LaserJock> we shouldn't waste too many resources messing around with packages that are often unused, obsolete, or just useless
[01:25] <cyberix> Could someone clear the situation a bit by posting a new comment to REVU http://revu.tauware.de/details.py?package=pq
[01:25] <minghua> 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] <cyberix> Of course it will not be a solution
[01:25] <ajmitch> LaserJock: as frequently happens with unmet deps, FTBFS lists, etc
[01:25] <persia> 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] <cyberix> But rather the process that will follow
[01:25] <ajmitch> persia: you're one of the few people who claims to use that list :)
[01:26] <minghua> crimsun: Right now I can only point main to them, and that is usually not enough.
[01:26] <LaserJock> persia: right, but I really don't care what you do ;-)
[01:26] <LaserJock> you can do whatever you like
[01:26] <crimsun> minghua: playing devil's advocate, such a component would nearly be all of Ubuntu universe synced from Debian ;)
[01:26] <persia> LaserJock: Right.  You shouldn't care what I do, which is why I don't like the idea of generalised prioritisation.
[01:26] <LaserJock> why not?
[01:26] <minghua> 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] <persia> ajmitch: Dktrkranz does quite a bit as well.
[01:27] <pwnguin> ive seen several people declare programming was not a nessecary trait for MOTU-ship
[01:27] <crimsun> can or do?
[01:27] <pwnguin> can
[01:27] <LaserJock> pwnguin: would depend on the programming language I'd guess
[01:27] <ajmitch> pwnguin: I can & have done so
[01:27] <crimsun> I don't think we have any MOTU who haven't done upstream patching at some point.
[01:27] <LaserJock> I don't think I can and never have
[01:27] <LaserJock> for code anyway
[01:27] <persia> pwnguin: That's true, as long as one can read code well, knows the basic packaging utilities, and is very concientious
[01:27] <joejaxx> :)
[01:27] <crimsun> ok, well, there's LaserJock.
[01:27] <ajmitch> I haven't done any java patching, of course
[01:27] <joejaxx> ajmitch: :P
[01:28] <ajmitch> but have done soe for C#, C, php & python
[01:28] <ajmitch> I think any MOTU should be at least familiar enough with a language
[01:28] <minghua> crimsun: Nah.  I don't encourage those friends to use unstable. :-)
[01:28]  * Fujitsu has attacked Python, C, C++, Erlang.
[01:28] <Fujitsu> (the last took a long time, and I didn't know the language prior, but...)
[01:29] <LaserJock> minghua: see, this is the issue
[01:30] <LaserJock> if Universe is less supportable than Debian (which is also community supported) then we have issues
[01:30] <ajmitch> we do have issues
[01:30] <Fujitsu> It is implicitly less supportable.
[01:30] <minghua> No if, it's a fact that Ubuntu release's universe is less supportable than Debian stable.
[01:30] <Fujitsu> It is much less maintained, we don't have people experienced in the maintenance of each package...
[01:31] <minghua> I would even say it's less supportable than testing.
[01:31] <persia> 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] <minghua> Maybe on GNOME/KDE/XFCE/Multimedia main front it's quite supportable, but it pretty much fails everywhere else.
[01:31] <LaserJock> minghua: is vs should be is my point
[01:32] <pwnguin> whats the difference between maintaining a release and working on the next one?
[01:32] <persia> pwnguin: SRUs
[01:32] <LaserJock> Universe should inherently be as supported as Debian
[01:32] <crimsun> accountability, I think, is tied to compensation, which becomes a ... charged point.
[01:32] <LaserJock> I just can't see the difference
[01:32] <Fujitsu> LaserJock: How?
[01:32] <pwnguin> from what i can tell, SRUs are practically discouraged
[01:32] <Fujitsu> We have nobody.
[01:32] <minghua> LaserJock: I understand what you mean.  In ajmitch's words: we do have issues.
[01:32] <ajmitch> LaserJock: people claiming responsibility for packages
[01:32] <crimsun> pwnguin: I wouldn't say that
[01:32] <LaserJock> right, so should we not fix the issues rather than giving up?
[01:32] <persia> 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] <ajmitch> and RMs who *will* remove a package from an upcoming release if it's not up to scratch
[01:33] <minghua> LaserJock: How so?  ~30 MOTUs vs. ~500 DD and maintainers?
[01:33] <Fujitsu> ajmitch: I would certainly like that removal policy.
[01:33] <crimsun> LaserJock: fixing the issues requires resources, and we've seen that the handful of MOTU are stretched tremendously
[01:33] <LaserJock> minghua: exactly!
[01:33]  * pwnguin doesnt like that policy
[01:33] <persia> Fujitsu: We need a pocket for it, and we don't have one...
[01:33] <pwnguin> much of the software i use is not finished
[01:33] <LaserJock> it is a resource issue, not a policy issue or inherent issue
[01:33] <pwnguin> but usable
[01:34] <ajmitch> Fujitsu: it only works due to the stable/testing/unstable split
[01:34] <pwnguin> example: desmume
[01:34] <minghua> LaserJock: No, some policies have a effect on small (active) MOTU number, IMO.
[01:34] <Fujitsu> We released Gutsy with a heap of libapache-* unmetdeps, because they might have become useful again in the future.
[01:35] <Fujitsu> We need a way to blacklist packages from release, but I can't see how that would work.
[01:35] <LaserJock> minghua: but we have no policy that states that Universe is any less supported than Debian
[01:35] <persia> Fujitsu: Right, so we should be following up with SRUs to get that cleaned up.
[01:35] <nxvl> !roadmap
[01:35] <ubotu> Sorry, I don't know anything about roadmap - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[01:35] <Fujitsu> persia: SRU removals? I don't believe that to be possible.
[01:35] <nxvl> _(
[01:35] <nxvl> :(
[01:35] <ajmitch> LaserJock: we have no policy stating the level of support at all
[01:35] <LaserJock> ajmitch: sure we do
[01:35] <persia> Fujitsu: No, SRUs to make the broken packages either work or be dummy packages
[01:35] <LaserJock> http://www.ubuntu.com/community/ubuntustory/components
[01:35] <pwnguin> apparently "community" is a level of support?
[01:35] <persia> (same source, but don't install as much)
[01:35] <Fujitsu> persia: They're not going to be made to work, and making them dummy packages is probably silly.
[01:36] <minghua> 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] <ajmitch> minghua: because we don't scale at getting new people in
[01:36] <persia> Fujitsu: Maybe.  I don't like having anything that looks like it should work and just plain can't be installed.
[01:36] <ajmitch> LaserJock: that states what support won't be given :)
[01:36] <LaserJock> minghua: because we're technically incompetent?
[01:36] <Fujitsu> persia: Is that any worse than having a package that doesn't do anything, where it did in other releases?
[01:37] <joejaxx> minghua: your contributors?
[01:37] <LaserJock> ajmitch: well, that's a typo ;-)
[01:37] <persia> 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] <Fujitsu> 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] <minghua> LaserJock: No.  I tends to think it's a social issue than a technical issue.
[01:38] <minghua> joejaxx: Please rephrase, I don't understand.
[01:38] <joejaxx> 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] <persia> 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] <minghua> joejaxx: Oh. s/my/more/.
[01:39] <joejaxx> minghua: what did you mean by that?
[01:39] <joejaxx> oh
[01:39] <joejaxx> ok
[01:39] <Fujitsu> 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] <LaserJock> minghua: social as in being too friendly?
[01:39] <pwnguin> well obviously MOTU is in trouble because Canonical hires the qualified ones to work on core dev type stuff ;)
[01:40] <LaserJock> pwnguin: not often enough
[01:40] <Fujitsu> The bugs about libapache-* have been sitting in Debian for about 6 months, and nothing has happened on most of them.
[01:40] <ajmitch> and the rest of us just drift away :)
[01:40] <joejaxx> ajmitch: :P
[01:40] <minghua> LaserJock: Not really, but related.  However as I've said, it's not the right time/place for me to discuss it.
[01:40] <ajmitch> joejaxx: well I'm obviously not qualified :P
[01:40] <persia> 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] <joejaxx> ajmitch: bah :P
[01:41] <Fujitsu> persia: The archive admins generally question that.
[01:41] <joejaxx> well back to merges :D
[01:42] <persia> 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] <joejaxx> persia: i will take a look
[01:43] <joejaxx> :D
[01:43]  * ajmitch has no universe merges to do
[01:43] <persia> ajmitch: You could upload new Debian revisions, and merge those :)
[01:43] <joejaxx> lol :D
[01:44] <pwnguin> so under what circumstances should one pursue an SRU?
[01:44] <joejaxx> 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] <crimsun> pwnguin: easily understood, minimally invasive fix
[01:46] <crimsun> pwnguin: i.e., someone in ubuntu-dev can eyeball and understand it and confirm that it fixes the issue
[01:46] <joejaxx> persia: there are not present conflicts for that package :\
[01:46] <persia> 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] <TheMuso> 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] <persia> joejaxx: Yep.  It's a very easy merge.  Don't forget to file the Debian bug about the .desktop.
[01:46] <joejaxx> 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] <persia> Fujitsu: IRC is hard
[01:48] <pwnguin> i cant imagine how that set intersects with the available talent into significantly more SRUs
[01:48] <ajmitch> Fujitsu: from which team?
[01:49] <Fujitsu> ajmitch: IRC ops.
[01:49] <ajmitch> ah, I should probably unsubscribe from there as well
[01:49] <persia> 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] <pwnguin> hopefully liw's testing tools will make it easier to identify these?
[01:50] <pwnguin> im suprised it took so long, really
[01:51] <ajmitch> we were waiting for people to come along & tell us how we should have been doing it sooner
[01:51] <persia> 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] <Fujitsu> pwnguin: Running such tests takes a non-trivial amount of computing resources.
[01:52] <pwnguin> installing packages?
[01:52] <persia> pwnguin: Yes, when installing 25,000 packages
[01:52] <ajmitch> 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] <joejaxx> :D
[01:53] <joejaxx> packages*
[01:53] <persia> (and possible combinations to detect correct use of "conflicts")
[01:53] <ajmitch> cool, we've found ourselves some volunteers!
[01:53] <Fujitsu> joejaxx: /me already does that.
[01:53] <persia> joejaxx: Fujitsu does that twice a week.  I forget the URL offhand, but I'll dig it up.
[01:53] <pwnguin> no, but in the scheme of building from source an install test seems like a drop in the bucket...
[01:53] <joejaxx> Fujitsu: :D
[01:53] <ajmitch> pwnguin: you think any of us build all of universe from source?
[01:54] <pwnguin> no
[01:54] <pwnguin> but LP does
[01:54] <ajmitch> no, it doesn't
[01:54] <ajmitch> we'd like it to
[01:54] <persia> pwnguin: We only touch ~2000 packages out of ~14000.  It's the other ~12,000 that need help
[01:54] <pwnguin> which parts of universe doesn't LP build?
[01:54] <ajmitch> it's more which parts doesn't it *re*build
[01:54] <persia> pwnguin: Anything not uploaded during the current release cycle
[01:54] <Fujitsu> pwnguin: You would need to do it fairly regularly.
[01:54] <Fujitsu> pwnguin: None at all.
[01:54] <jdong> hmm, another logistical SRU question
[01:54] <ajmitch> since there are binary packages in there which date back to warty or hoary
[01:54] <persia> jdong: Go!
[01:55] <pwnguin> heh
[01:55] <ajmitch> which don't install or build anymore
[01:55] <jdong> is it OK for a Gutsy SRU to roll back a package to Feisty version? :( (gtkpod-aac)
[01:55] <jdong> 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] <persia> jdong: Umm..  There was an API change involved there: I'm really not sure that's the best solution.
[01:55] <jdong> and gtkpod-aac in fact does not use AAC
[01:55] <jdong> persia: I'd expect feisty sources to compile on Gutsy with minimal changes, right?
[01:56] <jdong> persia: the only iffy part would be libgpod....
[01:56] <minghua> Ugh.  Not again.  The person who upload that should be reprimanded IMHO.
[01:56] <persia> jdong: I don't remember exactly.  Ask LucidFox or StevenK (who did the transition).  You can try.
[01:56] <jdong> minghua: oh this has been discussed?
[01:56] <ajmitch> afaik it wasn't me that broke stuff this time
[01:56] <Fujitsu> ajmitch: Mostly from apt-get.org or other random repos.
[01:56] <minghua> jdong: No, just that I've seen the same thing happen on one of my Debian packages.
[01:57] <persia> Fujitsu: No, there's also stuff from sid that hasn't been rebuilt for any supported release
[01:57] <Fujitsu> minghua: Isn't that normally tepsipakki?
[01:57] <ajmitch> persia: anything that was imported as source, was built (or at least an attempt was made)
[01:57] <jdong> minghua: ah, ok
[01:58] <minghua> 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] <jdong> 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] <persia> ajmitch: Right, but we've sources from sid that haven't been rebuilt since warty/hoary
[01:58] <minghua> Apparently (and disappointingly) not so.
[01:59] <nxvl> hi :D
[01:59] <nxvl> ready for REVU day?
[01:59] <joejaxx> nxvl: lol
[01:59] <persia> 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] <persia> nxvl: It's been underway for 15 hours already!
[02:00] <nxvl> persia: here comes in 3 hours :P
[02:00] <gnomefreak> gos i hope this libx fixes X
[02:00] <gnomefreak> god even
[02:01] <joejaxx> persia: does this look good to you? https://people.fluxbuntu.org/~joejaxx/ubuntu/merges/mhwaveedit_1.4.13-1ubuntu1.MERGE.debdiff.txt
[02:02] <joejaxx> i feel like getting anothe Sprite lol
[02:02] <ajmitch> get me one
[02:02] <somerville32> What is the wiki page for details on how to get a sponsor for main?
[02:02] <jdong> joejaxx: your pancreas would hate you :)
[02:02] <jdong> persia: well the rollback idea failed miserably; now let's see if I can force gtkpod at gunpoint to use our libmp4v2 :)
[02:03] <persia> joejaxx: Close.  You'll want the Debian .po files to make the diff smaller (or to mention something in the changelog)
[02:03] <minghua> 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] <persia> jdong: Good luck.  I seem to remember the API being completely different, so you'll get to have some fun :)
[02:03] <ajmitch> somerville32: same as for universe, except subscribe ubuntu-main-sponsors
[02:03]  * joejaxx sends ajmitch a Sprite over the internet :D
[02:04] <joejaxx> persia: we want the debian translations?
[02:04] <jdong> persia: yay, lovely.... :)
[02:04] <persia> 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] <joejaxx> oh ok
[02:05] <joejaxx> i guess we can keep the ubuntu ones
[02:05] <joejaxx> i will mention it in the changelog
[02:05] <persia> joejaxx: Also, check the Russian: it looks like a codepage error.
[02:06] <joejaxx> is there way to force dch to write a dist you want?
[02:06] <crimsun> -D
[02:06] <jdong> persia: pfft the new API is only used to do volume normalization headers on AAC
[02:06] <joejaxx> i thought there was a flag for that
[02:06] <jdong> persia: lemme see what I can do about that ;-)
[02:06] <joejaxx> crimsun: ah! yes thanks
[02:06] <persia> jdong: Great.  Thanks.
[02:08] <joejaxx> persia: hmm
[02:08] <minghua> jdong: is gutsy-backports open?
[02:08] <jdong> minghua: yep
[02:09] <minghua> jdong: Any authoritative procedure page?  https://wiki.ubuntu.com/BackportRequestProcess looks outdated.
[02:09] <crimsun> minghua: what do you need uploaded?
[02:09] <persia> minghua: What's outdated about that page?
[02:09] <jdong> minghua: it's still correct, use the $distro-backports project on LP
[02:09] <minghua> crimsun: The scim-hangul you just uploaded. :-)  There is a user requesting gutsy backport.
[02:10] <crimsun> oh, right.
[02:10] <joejaxx> persia: what does the formatting for the translation files mean?
[02:10] <crimsun> well, if you can't wait for it to be available in hardy, I could toss it into gutsy-backports manually.
[02:10] <minghua> 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] <persia> joejaxx: I need a little context.
[02:10] <joejaxx> well for example
[02:11] <joejaxx> in my patch in the ru file
[02:11] <zul> evening
[02:11] <joejaxx> it drops lines saying #~
[02:11] <ajmitch> hello zul
[02:11] <joejaxx> hello zul
[02:11] <gnomefreak> anyone know the status of X fix in hardy by chance?
[02:12] <zul> hey ajmitch and joejaxx
[02:12] <persia> joejaxx: I believe those to be comments
[02:12] <joejaxx> i hope they backport any fixes :( the open ati driver is messed up :(
[02:12] <persia> gnomefreak: Waiting on compiles to see if that works.  If not, there may be a poke later in the week.
[02:12] <minghua> 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] <gnomefreak> persia: to see if what works?
[02:12] <joejaxx> persia: what were you referencing when you said there was a issue with the russian po file?
[02:13] <crimsun> minghua: yes
[02:13] <persia> gnomefreak: X
[02:13] <minghua> crimsun: If yes -- I can wait, but I am completely new to this backport business.
[02:13] <gnomefreak> persia: missing depends is all it is afaik
[02:13] <crimsun> minghua: ok, then I recommend using the -backports project procedure
[02:13] <persia> joejaxx: I'm not in the target environment, but I see strings like "[S] ðÒÏÔÑÇÉ×ÁÎÉÅ ×ÒÅÍÅÎÉ".  If you see Cyrillic, everything is good.
[02:14] <persia> gnomefreak: Right, but there's a huge build queue...
[02:14] <minghua> 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] <gnomefreak> oh its been uploaded?
[02:14] <crimsun> minghua: I'm pretty sure you would need to ack the non-dev backport request
[02:14] <minghua> crimsun: Sure, I'll follow the -backports project procedure.
[02:14] <persia> gnomefreak: https://launchpad.net/ubuntu/hardy/+queue
[02:14]  * gnomefreak gonna have to assume its been tested prior to uploading ;)
[02:14] <joejaxx> persia: you are right
[02:14] <joejaxx> persia: i see ???????
[02:14] <joejaxx> but in the debdiff they are not ?????? characters
[02:14] <minghua> I'll ack (I tested the backport), it's just the procedure is a bit unclear to me...
[02:15] <persia> 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] <persia> joejaxx: What do you see in the debdiff?  Ideally, it's all UTF-8, and properly marked as such.
[02:16] <joejaxx> +msgid "[B] Volume adjust/fade"
[02:16] <joejaxx> +msgstr "[B] ðÏÄÓÔÒÏÊËÁ ÇÒÏÍËÏÓÔÉ"
[02:16] <joejaxx> gah
[02:16] <jdong> is autogen.sh what turns configure.in -> configure?
[02:16] <joejaxx> it did not paste correctly
[02:16] <persia> joejaxx: Yeah.  That doesn't look ideal.
[02:16] <joejaxx> i see letters with accent marks on them
[02:16] <gnomefreak> jdong: i think so
[02:16]  * ajmitch does not see utf-8 encoded characters there :)
[02:17] <ajmitch> 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] <crimsun> jdong: autoconf, auctually.
[02:17] <crimsun> actually*
[02:17] <gnomefreak> autogen.sh build package?
[02:18] <persia> 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] <joejaxx> yeah i have not tried playing around with locales before
[02:18] <persia> joejaxx: Essentially, I don't think we should be introducing broken translations, although I fully admit that not everything is well translated.
[02:18] <joejaxx> so drop all of them?
[02:19] <ajmitch> persia: you read it well enough to see that it's broken?
[02:19] <persia> joejaxx: If you've an Ubuntu patch, and it's introducing a bug, it's better to take the Debian solution :)
[02:19] <joejaxx> ok
[02:19] <minghua> PO's encoding/charset is clearly noted in the PO file itself.  It's not necessarily UTF-8.
[02:19] <persia> ajmitch: I'm not on Ubuntu right now, so I can't test.  I'm just guessing from the debdiff.
[02:27] <crimsun> somerville32: what did you need?
[02:29] <persia> 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] <joejaxx> persia: https://people.fluxbuntu.org/~joejaxx/ubuntu/merges/mhwaveedit_1.4.13-1ubuntu1.MERGE.debdiff.txt i dropped all of them
[02:30] <joejaxx> persia: ok
[02:31] <jdong> persia: I think I got it :)
[02:31] <jdong> persia: lemme build test before embarassing myself ;-)
[02:31] <persia> joejaxx: I'm good for that: I don't see any changelog entries to explain the Ubuntu .po files anyway.
[02:31] <joejaxx> persia: ok
[02:31] <joejaxx> persia: yes that is why i thought it was weird
[02:32] <persia> bddebian: You about?  Do you happen to have any memory remaining about the mhwaveedit 1.4.7-2ubuntu1 merge?
[02:32] <bddebian> I did it?
[02:32] <persia> bddebian: Well, you uploaded my desktop file at least :)
[02:32] <bddebian> Ah :-)
[02:33] <persia> bddebian: Do you remember anything about fussing with .po ffiles?
[02:33] <bddebian> Not that I recall but let me look locally
[02:33] <persia> bddebian: Thanks.
[02:34] <persia> 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] <joejaxx> ok
[02:35] <bddebian> Nuttin' here but your desktop file
[02:36] <persia> bddebian: Great.  That was my memory as well.
[02:36] <persia> joejaxx: That's it then: the .po variation is just an undocumented artifact of history, likely related to changes upstream.
[02:39] <imbrandon> crimsun, ping
[02:39] <crimsun> imbrandon: pong
[02:40] <imbrandon> heya i'm cleaning up some space / ports , do you still actively use that sid vm ?
[02:40] <crimsun> imbrandon: nope
[02:40] <bddebian> persia: Do you happen to know conquest?
[02:40] <imbrandon> cool, ok
[02:40] <persia> bddebian: Only from the brief look a couple days ago: are you doing the fulll CDBS & quilt migration?
[02:41] <bddebian> CDBS hell no, but I have debhelperized it
[02:41] <persia> bddebian: coward :)
[02:41] <bddebian> And I moved the libs so I need to test it
[02:42] <joejaxx> persia: ok then it looks good to go i guess :D
[02:42] <persia> joejaxx: Excellent.  Subscribe the sponsors queue, and someone will upload it.  Thanks for taking care of that.
[02:42] <persia> joejaxx: Also, if you'd file a Debian bug, it'd be great :)
[02:43] <joejaxx> persia: you are most welcome
[02:43] <joejaxx> persia: yeah i have to look up the docs on submitting a debian bug :D
[02:43] <jdong> WHOO! looks like it's accepting it.....
[02:44] <persia> joejaxx: http://www.debian.org/Bugs/Reporting
[02:44] <joejaxx> persia: ok thanks
[02:55] <jdong> persia: care to sponsor the debdiff on bug 135168 into Hardy?
[02:55] <ubotu> Launchpad bug 135168 in gnome-panel "apta" [Undecided,Invalid] https://launchpad.net/bugs/135168
[02:55] <jdong> err
[02:55] <jdong> persia: care to sponsor the debdiff on bug 135178 into Hardy?
[02:55] <ubotu> 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] <jdong> *that* looks more relevant :D
[02:56] <jdong> I've build-tested and iPod-tested the change
[02:56] <persia> jdong: I don't have access to the tools for such sponsorship currently.  How about subscribing the sponsors queue?
[02:56] <jdong> persia: ok, will do :)
[02:57] <persia> 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] <joejaxx> for some reason
[02:58] <joejaxx> these merges are becoming fun for me
[02:58] <joejaxx> lol
[02:58] <jdong> persia: the debdiff is to hardy, I'm preparing the Gutsy SRU for it right now
[02:58] <jdong> persia: doing both at the same time will avoid that kind of gutsy-ahead-of-hardy situation :)
[02:58] <persia> jdong: Ah.  I was just confused by the bug title :)
[02:58] <jdong> persia: the bug's old :)
[02:59] <jdong> ok, for SRU, I set version number to ubuntu1.1 or ubuntu1.1~prop1?
[02:59] <jdong> do we still do the ~proposed thing?
[02:59] <persia> jdong: Absolutely.
[02:59] <jdong> ok, is there a preference between ~proposed1 and ~prop1?
[02:59] <persia> Err.  Set the version number to the version that will be in -updates.  It gets uploaded to -proposed, and then sync'd.
[03:00] <jdong> persia: ah, ok, that's different than the last time I did it ages ago :)
[03:00] <persia> e.g. -32ubuntu17.12
[03:01] <bddebian> Hmm, dh_installman doesn't compress the manpages?
[03:02] <persia> bddebian: You want dh_compress
[03:03] <bddebian> Well I have that but I am getting a warning that one of the manpages is not compressed, while the others are :-(
[03:04] <persia> 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] <minghua> bddebian: In which order are you calling dh_installman and dh_compress?
[03:06] <bddebian>         dh_installman -a
[03:06] <bddebian>         dh_link -a
[03:06] <bddebian>         dh_strip -a
[03:06] <bddebian>         dh_compress -a
[03:06] <persia> OK.  That eliminates 2).  What about 1) and 3) ?
[03:07] <bddebian> Well I don't know about 1, I think 3 is out
[03:07] <persia> (alternately, do you have a binary independent package being built for which you aren't calling these?)
[03:07] <bddebian> Yes but no man pages in the -data package
[03:08] <joejaxx> woohoo :D
[03:08] <joejaxx> https://people.fluxbuntu.org/~joejaxx/ubuntu/merges/rebuildd_0.2.2ubuntu1.MERGE.debdiff.txt
[03:08] <joejaxx> :D
[03:08] <joejaxx> another one
[03:08] <joejaxx> lol
[03:08] <minghua> persia: the -a option should rule out that possibility.
[03:08] <persia> 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] <joejaxx> i think i should start filing bugs for them now lol
[03:08] <minghua> (unless there is arch:all packages involved)
[03:08] <bddebian> persia: Shouldn't but I'll check
[03:08] <persia> minghua: Right, except for arch:all conquest-data :)
[03:09] <persia> 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] <jdong> persia: thanks for your help; nominated, attached the 2 debdiffs, and a testing package for the subscribers. And now we wait :D
[03:10] <joejaxx> persia: does that not make it confusing though?
[03:10] <persia> 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] <joejaxx> doing bug fixes to a merging from debian unstable changeset?
[03:10] <joejaxx> hello Amaranth
[03:10] <persia> 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] <joejaxx> persia: ok
[03:11] <Amaranth> hey
[03:11] <persia> joejaxx: As an example, look at the mhwaveedit changelog again: for a couple of the merges there was a general cleanup.
[03:11] <persia> (not that that package gets many bugs)
[03:12] <joejaxx> yeah :P
[03:14] <RAOF> joejaxx: You should check the LP bugs for rebuildd :)
[03:16] <RAOF> joejaxx: In particular, the *only* LP bug for rebuildd.
[03:16] <imbrandon> ahh the wonders of computing , the eeepc is on sale finaly
[03:16] <imbrandon> who wants to buy me one ? hehehe
[03:17] <joejaxx> RAOF: yeap already there :D
[03:18] <bddebian> What the hell processes <package>.conffiles?
[03:18] <persia> RAOF: Are you planning a miro merge/sync?  I was tempted by the xine-lib transition, but wanted to ping you first.
[03:18] <RAOF> persia: Yes, I am.
[03:18] <persia> bddebian: $ dh_<TAB> ...
[03:19] <RAOF> persia: It's mostly done, just blocking on me actually testing on a Hardy system.
[03:19] <RAOF> Although I'd like to see _just_ how small a delta I can get against Debian.
[03:19] <persia> 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] <RAOF> persia: Right, thanks.
[03:20] <persia> RAOF: sync isn't possible?  I thought you were close a couple weeks ago.
[03:20] <RAOF> persia: xulrunner!
[03:20] <minghua> bddebian: dpkg.  But I'm not sure that's the answer you are looking for.
[03:20] <persia> RAOF: Ah.  Right.  Pity that.
[03:20] <RAOF> persia: We'd need to build against xulrunner-1.9 instead of xulrunner, at least.
[03:21] <bddebian> Well conquest has a .conffiles file
[03:21] <RAOF> And there are a few more debian/rules niggles I need to push on debian.
[03:21] <Amaranth> and it doesn't sound like debian will get xulrunner-1.9 anytime soon
[03:21] <bddebian> And I'm installing /etc/foo in .install
[03:21] <persia> Do we have xulrunner (not 1.9)?
[03:21] <RAOF> And by the end of Hardy I hope to have no libxine dependency!
[03:22] <RAOF> persia: Yes, but it doesn't work.
[03:22] <Amaranth> persia: and mozcorp really doesn't like it
[03:22]  * persia wonders why we don't just have xulrunner-1.9-0ubuntu1
[03:22] <persia> Errr..  xulrunner_1.9-0ubuntu1
[03:22] <RAOF> persia: Good question.  Ask asac :)
[03:22] <Amaranth> err
[03:22] <Amaranth> 1.9~a8-0ubuntu2
[03:23] <persia> Amaranth: Right.
[03:23] <Amaranth> it's the xulrunner from firefox 3 alpha 8
[03:23] <joejaxx> RAOF: that bug was fixed if you look at the changelogs :D
[03:24] <persia> 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] <RAOF> joejaxx: No, it wasn't.  I fixed the FTBFS, but in a way that's now a *dash*-ism.
[03:24] <joejaxx> although it is ubuntu specific
[03:24] <joejaxx> RAOF: yes
[03:24] <joejaxx> that is why i said it was ubuntu specific :D
[03:24] <RAOF> joejaxx: I thought the Debian maintainer had fixed it (using the actually portable printf), though?  He hasn't yet?
[03:24] <persia> joejaxx: Not even.  Lots of Ubuntu people expect `debuild` to work in bash for a local build.
[03:25] <minghua> persia: I am not sure it's right to have a debian/conffiles (or debian/<package>.conffiles) in source package, or if it requires special treatment in debian/rules.
[03:25] <minghua> bddebian: ^^^ for you, too.
[03:25] <Amaranth> persia: Those people are _wrong_ and deserved to be punished ;)
[03:25] <Amaranth> and I didn't think you could even _have_ a dashism
[03:26] <RAOF> persia: That's still going to work, though, unless someone has gone to the effort of re-symlinking /bin/sh to bash?
[03:26] <persia> Amaranth: Why?  We often suggest that to users when asking for a local rebuild, etc. to test things.
[03:27] <persia> 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] <RAOF> Amaranth: You can, by taking the behaviour specified in "man sh" as POSIX, rather than the more correct 'implementation defined'.
[03:27] <Amaranth> persia: Notice the ';)
[03:27] <Amaranth> RAOF: err
[03:28] <Amaranth> shouldn't they all follow 'man sh'?
[03:28] <RAOF>  Nope.
[03:28] <persia> Amaranth: You're using "should" again :)
[03:28] <RAOF> 'man sh' is not authorititive.
[03:29] <RAOF> Much to my chagrin.
[03:29] <minghua> sh(1) man page is diverted to dash(1) if you use dash as /bin/sh.
[03:29] <minghua> otherwise it's linked to bash(1).
[03:29] <minghua> There is simply no man page for POSIX-sh AFAIK.
[03:29] <Amaranth> So RAOF was looking at dash explaining what _it_ does. :P
[03:30] <RAOF> :(
[03:32] <RAOF> joejaxx: Anyway, if you're going to do the rebuildd merge, can you fix the bug properly (with printf rather than echo)?
[03:32] <RAOF> And then send that patch upstream to Debian?
[03:39] <bddebian> I don't suppose any of you would have a chance to look at: http://www.bddebian.com/packages/debian/conquest/ ?
[03:43] <imbrandon> bddebian, wow Debian/hurd has no installer ? hehe
[03:44] <bddebian> pfft :-)
[03:46] <LaserJock> imbrandon: does Debian/Hurd have a kernel?
[03:46] <imbrandon> LaserJock, apparently gnumach.gz :)
[03:47] <LaserJock> http://rubyforge.org/ is pretty cool
[03:48] <LaserJock> it'd be nice to have one of those for python
[03:49] <minghua> http://cheeseshop.python.org/pypi doesn't count?
[03:50] <LaserJock> I didn't think so, but maybe
[03:51] <LaserJock> I was thinking cheeseshop was more listing where rubyforge is more sourceforge-like
[03:51] <joejaxx> RAOF: sure
[03:51] <joejaxx> gah
[03:51] <joejaxx> lol
[03:51]  * joejaxx does not like being pulled into the submit a debian bug pool
[03:52] <minghua> I don't think cheeseshop has a sourceforge-like platform either.  But I don't think it's very important.
[03:52] <minghua> Does CPAN have a sourceforge-like platform?
[03:53] <LaserJock> well, I think it's important if you're building projects rather than libraries
[03:53] <LaserJock> libraries don't tend to need screenshots and things like that, the bling ;-)
[03:54] <LaserJock> does that make sense?
[03:54] <imbrandon> man i'm so utterly bored with the day to day the last few weeks
[03:54] <bddebian> amen brother
[03:55] <LaserJock> few weeks?
[03:55] <imbrandon> yea its slowly getting worse, what do yall do to over come boredom at the computer ?
[03:55] <bddebian> Buy The Witcher ;-)
[03:55] <imbrandon> hehe
[03:56] <ajmitch> imbrandon: step away from the computer
[03:56] <imbrandon> ajmitch, i did that, no help really
[03:56] <ajmitch> find another hobby
[03:56] <LaserJock> hobby? what's that?
[03:57] <imbrandon> hehe
[03:57] <imbrandon> 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] <imbrandon> 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] <joejaxx> imbrandon: maybe they are not ubuntu members? :D
[03:59] <joejaxx> oh
[03:59] <joejaxx> maybe they do not know
[03:59]  * ajmitch ponders blogging & decides not to
[03:59] <LaserJock> I've given up on trying to figure out why people do what they do
[03:59] <jdong> what? Nobody's going to tell me about the next newest Nokia device?
[04:00] <LaserJock> I can't even figure out why I do what *I* do
[04:00] <joejaxx> jdong: the new one is nice
[04:00] <joejaxx> jdong: it has gps
[04:00] <jdong> or tell me how to roll back my Gutsy kernel to a tribe 2 kernel to let my macbook suspend?
[04:00] <joejaxx> that is crazy
[04:00] <ajmitch> LaserJock: I don't know either
[04:00]  * jdong glares at joejaxx :)
[04:00] <imbrandon> LaserJock, hahah me either
[04:00] <jdong> joejaxx: yes, and I'll read Planet Maemo for my Nokia drooling :)
[04:00]  * imbrandon is wishing for an eeepc
[04:00] <imbrandon> 400$ on newegg
[04:01] <jdong> imbrandon: it looks cool
[04:01] <RAOF> joejaxx: I'll forward it to Debian if you really want.
[04:01] <jdong> imbrandon: I wish they would increase the formfactor a bit in order to get insane battery life though...
[04:02] <joejaxx> RAOF: no i need the experience
[04:02] <joejaxx> :D
[04:02] <bddebian> imbrandon: Join me on the games team, it's "fun" ;-)
[04:03] <persia> 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] <imbrandon> 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] <jdong> persia: you mean the big value is that the next time you want to moan about Launchpad, you'll think twice?
[04:03] <bddebian> hehe
[04:04] <persia> jdong: Well, that helps, but the BTS isn't that bad.
[04:04] <jdong> 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] <persia> 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] <jdong> persia: well once you have a template then yeah it's simple
[04:06] <imbrandon> yea the only thing worse than a email only BTS is a usenet only BTS
[04:06] <jdong> imbrandon: haha
[04:06] <jdong> BTS-over-azureus? :D
[04:06] <persia> imbrandon: No.  There are web forms that submit email to mail-to-news gateways...
[04:06] <joejaxx> crimsun: who normally does lts upgrade testing?
[04:06] <imbrandon> services imho should be avaible in as many forms as possible, especialy FL/OSS ones
[04:07] <jdong> imbrandon: is there any reason Debian doesn't provide a web-based UI?
[04:07] <imbrandon> jdong, no idea
[04:07] <minghua> I'll take Debian's BTS over sourceforge BTS any day.
[04:07] <imbrandon> no one has coded it ?
[04:07] <minghua> (even I haven't gotten familiar with Debian BTS)
[04:08] <joejaxx> bddebian: LOL
[04:08] <imbrandon> 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] <persia> 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] <joejaxx> does anyone know who does lts {,upgrade} testing?
[04:09] <minghua> Debian BTS has a SOAP interface, in case anyone doesn't know that (and know what SOAP means).
[04:09] <persia> joejaxx: This will be our second LTS, so there's no precedent.  You're welcome to jump in and help.
[04:09] <joejaxx> minghua: NICE
[04:09] <StevenK> And how is it hard to get familiar with Debian's BTS? It's just e-mail.
[04:09] <LaserJock> minghua: really!?
[04:09] <imbrandon> 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] <joejaxx> persia: crimsun mentioned me taking it on
[04:10] <minghua> LaserJock: sure.
[04:10] <minghua> ...seems quite some people here don't know that...
[04:10] <LaserJock> minghua: I did a *very* little of SOAP and thought it was pretty cool
[04:10] <imbrandon> StevenK, its not the point of getting used to it, its the point i CANT do it another way if i choose
[04:10] <persia> joejaxx: Excellent.  I'm glad to hear it.  Thanks.
[04:10] <LaserJock> I know there is a web interface for BTS in the works
[04:10] <minghua> http://wiki.debian.org/DebbugsSoapInterface
[04:10] <ajmitch> you can even search the BTS via LDAP
[04:11] <joejaxx> persia: i think i will create a lp group for it as well so we can get some centralized stuff going
[04:12] <LaserJock> ajmitch: if you want to spend eternity doing it ;-)
[04:12] <joejaxx> persia: or should i say organization
[04:12] <joejaxx> gah
[04:12] <persia> 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] <joejaxx> persia: ok great
[04:12] <StevenK> imbrandon: Okay, fine. Whagt do you want to do with a Debian bug that you can't?
[04:13] <imbrandon> file one via a webui, or update the status of one
[04:13] <StevenK> imbrandon: Well, you can't, so cope.
[04:13] <LaserJock> should we perhaps get machine/hosting stuff figured out before we scatter stuff about? or not perhaps?
[04:13] <imbrandon> i touch email as little as possible
[04:13] <persia> imbrandon: I've not filed a Debian bug not using a browser in years.  It just requires the right front-end.
[04:13] <StevenK> imbrandon: Changing the status is a very simple e-mail to<EMAIL_ADDRESS>[04:14] <LaserJock> imbrandon: I'm with you, I've got an allergy to BTS ;-)
[04:14] <StevenK> imbrandon: Fine, it which case use the 'bts' command line tool and reportbug.
[04:14] <imbrandon> 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] <ajmitch> LaserJock: that eternity is why I decided not to use the LDAP interface for the rc bugs list
[04:14] <LaserJock> ajmitch: yes, I remember
[04:15] <LaserJock> that's really sweet though that they have it
[04:15] <persia> 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] <imbrandon> that might be ok , as long as it hasent been modified for ubuntu like reportbug
[04:15] <StevenK> Yes. It's in devscripts and it's called 'bts'
[04:15] <StevenK> I mentioned it like two minutes ago.
[04:16]  * persia thanks StevenK for propping up my failing memory
[04:16] <imbrandon> 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] <imbrandon> not a very good workflow
[04:16] <Zelut> 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] <StevenK> imbrandon: Okay, in which you just whinging and I'll stop helping you.
[04:16] <persia> imbrandon: You can also view the bugs from the command line :)
[04:17] <imbrandon> 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] <minghua> imbrandon: bts has a "cache" command, too.
[04:17] <persia> 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] <minghua> Just learn the available tool.
[04:18] <imbrandon> 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] <imbrandon> interface*
[04:19] <Zelut> 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] <Zelut> persia: is it just a matter of removing lines >>>>> / <<<<< one way or the other?
[04:20] <persia> 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] <persia> 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] <LaserJock> and might even result in a sound thrashing ;-)
[04:21] <Zelut> persia: I feel like what I'm missing here is some more experience with diff/patch
[04:22] <Zelut> LaserJock: hey, I've got to start someplace.. I'm trying here :)
[04:22] <persia> 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] <persia> 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] <Zelut> I thought I'd try to start with something simple from merges.ubuntu.com
[04:23] <LaserJock> a good starting place is to look at all the the Ubuntu changelog entries
[04:23] <imbrandon> StevenK, ohhh `bts` looks nice
[04:23] <imbrandon> serouisly
[04:23] <Zelut> I'm trying htop
[04:23] <nxvl> Zelut: diff tools are great :D
[04:23] <nxvl> persia: hi!
[04:24] <nxvl> imbrandon: hi
[04:24] <persia> 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] <imbrandon> hello
[04:24] <persia> hi nxvl
[04:24] <StevenK> imbrandon: I have been using bts for about 12 months. It completly rocks.
[04:24] <joejaxx> grr
[04:24] <joejaxx> hth do you actually set yourself for mentoring?
[04:25] <persia> joejaxx: To be mentored, or to mentor?
[04:25] <ajmitch> beg, bribe
[04:25] <joejaxx> +mentoring does not have any link to set yourself as a mentor
[04:25] <joejaxx> persia: on lp
[04:25] <joejaxx> sorry if i did not say that
[04:26] <ajmitch> right, we thought you meant MOTU mentoring
[04:26] <ajmitch> which is entirely separate
[04:26] <persia> 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] <ajmitch> just be glad I'm not your mentor
[04:26] <nxvl> for the FTBFS bugs i need to use pbuilder to check if it builds, didn't i?
[04:26] <persia> s/mentor/potential mentor/1
[04:26] <joejaxx> ajmitch: lol why?
[04:26] <joejaxx> nxvl: yes
[04:26] <persia> nxvl: Or sbuild or a private buildd, or something, but basically, yes.
[04:26] <joejaxx> nxvl: that is the only way to know if it builds :D
[04:26] <ajmitch> joejaxx: because I'd have to find all sorts of weird & wonderful bugs for you to fix
[04:27] <joejaxx> ajmitch: LOL!
[04:27] <ajmitch> my attitude would be push until breaking point
[04:27] <nxvl> mm i need to build my pbuilder system
[04:27] <ajmitch> hence why I'm not a mentor
[04:27]  * nxvl search the scripts
[04:28] <joejaxx> ajmitch: :P
[04:28] <joejaxx> my mentor is LaserJock :D
[04:28]  * LaserJock hides
[04:29]  * bddebian looks for a mentor
[04:29] <LaserJock> bddebian: I'll be your mentor :-)
[04:29] <persia> bddebian: You can't have a mentor.
[04:29] <persia> (well, maybe excepting Laserjock)
[04:29] <LaserJock> bddebian: stop pouting and get to work!!! *Whip*
[04:29] <joejaxx> lol
[04:29] <bddebian> LaserJock: Cool thanks.    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] <LaserJock> persia: but it did seem to work?
[04:32] <persia> LaserJock: In what sense?
[04:33] <LaserJock> as in, people wanted to be mentored
[04:33] <LaserJock> I wondered if it would actually attract anyone who could fix the bug
[04:34] <persia> 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] <LaserJock> cool
[04:34] <persia> LaserJock: Only offer mentoring for bugs you could fix, but are too lazy / busy to fix right now.
[04:34] <LaserJock> heh
[04:35] <LaserJock> that'll give me oh ... 0
[04:35] <persia> (or it's just not important, like grammar errors in the manpage or the .desktop not validating, etc.)
[04:35] <persia> LaserJock: You could fix a spelling error, no?
[04:35] <LaserJock> thanks to my trusty spellchecker ;-)
[04:35] <persia> (the mentoring part would be about getting the person in touch with upstream, and getting the patch applied there)
[04:35] <LaserJock> packaging bugs I'm usually ok with
[04:36] <persia> LaserJock: Just mentor all the bugs tagged "packaging" then :)
[04:37] <LaserJock> probably not
[04:37] <LaserJock> my response time is really bad nowadays
[04:37] <nxvl> which was the apt command to download all build dependencies for a package? i can't find it on packaging guide
[04:38] <bddebian> apt-get build-dep foo
[04:38] <LaserJock> I keep saying I'll do something and somebody ends up getting to it before me :/
[04:38] <imbrandon> apt-get build-dep blah
[04:38] <nxvl> thnx
[04:38] <nxvl> :D
[04:38] <imbrandon> doh i forgot the password to my router
[04:38] <persia> LaserJock: That's excellent: you're providing guidance and direction.
[04:38]  * imbrandon grumbles
[04:38] <persia> imbrandon: telnet port 1?
[04:39] <imbrandon> telnet and ssh are disabled
[04:39] <imbrandon> hrm
[04:39] <jdong> magical reset port?
[04:40] <imbrandon> jdong, then it will reset all my settings too , i'm trying to avoid that if possibly, but probably the only choice
[04:40] <persia> jdong: For certain brands and models in the past.  I don't think anything modern actually exposes that anymore.
[04:40] <jdong> persia: ah,  I meant the physical one
[04:40] <LaserJock> imbrandon: think really really hard >:|
[04:40] <jdong> persia: most routers should still have that 5-second static-ip TFTP window :)
[04:40] <imbrandon> persia, its just a old fon thats reflashed
[04:41] <jdong> imbrandon: do I envision you downloading some HTTP basic auth brute forcers? :)
[04:41] <imbrandon> with dd-wrt
[04:41] <persia> imbrandon: You and I obviously have different definitions of "old"
[04:41] <imbrandon> jdong, nah, it only is a bridge to one client computer on wireless, i could just reset it if need be
[04:42] <imbrandon> persia, well  in this case the first wireless ap i had :) so old to me
[04:42] <jdong> see, this is why strong passwords are a denial-of-service and data loss vulnerability ;-)
[04:42] <LaserJock> imbrandon: next time just write it on a sticky note and stick it on it
[04:42] <imbrandon> lol
[04:42] <persia> jdong: Right.  Everyone should use cryptographic tokens.
[04:42] <jdong> LaserJock: put it on the underside. nobody would look there.
[04:42] <joejaxx> persia: yes
[04:42] <joejaxx> persia: and smart card
[04:42] <joejaxx> biometrics
[04:42] <joejaxx> and hardware level encryption
[04:43] <LaserJock> jdong: yeah, that's what I do :-)
[04:43] <LaserJock> 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] <imbrandon> lol
[04:43] <jdong> LaserJock: I just use the Windows XP license key printed on the barcode :)
[04:43] <joejaxx> persia: lol
[04:43] <LaserJock> jdong: oh, thats good
[04:46]  * LaserJock out
[04:46] <LaserJock> night everybody
[04:47] <bddebian> Gnight LaserJock
[04:47] <joejaxx> LaserJock: Goodnight :D
[04:58] <nxvl> i'm getting a strange error
[04:59] <nxvl> pbuilder says: E: Couldn't find package j2sdk1.4 but if i try to install it on my systems
[04:59] <nxvl> it download
[04:59] <nxvl> downloads*
[04:59] <persia> nxvl: Does pbuilder have multiverse enabled?
[05:00] <nxvl> persia: checking
[05:00] <nxvl> nop
[05:00] <nxvl> how do i enable it?
[05:00] <persia> nxvl: No idea.  I've never used pbuilder :)
[05:00] <StevenK> ///////
[05:00] <nxvl> jajja
[05:00] <nxvl> ok
[05:01]  * nxvl searchs
[05:11] <nxvl> added multiverse and universe :D
[05:18] <imbrandon> ok other than a bash script is there a little tool to scan a subnet for used ip's ?
[05:19] <nxvl> imbrandon: using nmap¡
[05:19] <nxvl> ?
[05:19] <persia> imbrandon: nmap can be handy...
[05:19] <imbrandon> nmap will only scan a single ip right ?
[05:19] <nxvl> imbrandon: nop
[05:19] <persia> imbrandon: Well, depends on what you pass it.  I think it traps <IP_ADDRESS>/0, but that's about it.
[05:20] <nxvl> imbrandon: you can do "nmap <IP_ADDRESS> <IP_ADDRESS>" and he will scan the 2 ip's or the ones you past
[05:20] <nxvl> or you can do <IP_ADDRESS>/24 or whatever you want
[05:20] <nxvl> nmap is magica
[05:20] <nxvl> magical
[05:20] <imbrandon> can i do like nmap <IP_ADDRESS>/24 ?
[05:20] <imbrandon> kk
[05:20] <minghua> I think that would be 3 ips.
[05:21] <nxvl> imbrandon: yep
[05:21] <minghua> Oh not.  Never mind.
[05:21] <nxvl> imbrandon: nmap is magic
[05:22] <nxvl> why the whois are so slowly
[05:22] <imbrandon> hell of a lot better than ...
[05:22] <persia> minghua: I suspect you're thinking of <IP_ADDRESS>-18 (if I remember the range syntax properly)
[05:22] <imbrandon> #!/bin/bash
[05:22] <imbrandon> for ((i=1;i<=254;i+=1)); do
[05:22] <imbrandon> echo $i
[05:22] <imbrandon> ping -c 1 192.168.1.$i|grep ttl
[05:22] <persia> heh
[05:22] <imbrandon> done
[05:22] <nxvl> imbrandon: what are you exactly doing
[05:22] <nxvl> imbrandon: for that you can ping the broadcast
[05:22] <imbrandon> just looking for all the ip's responding to ping on my subnet
[05:23] <nxvl> imbrandon: ping the broadcast
[05:23] <minghua> persia: Yeah, that's what I was thinking.  (No idea about the correct grammar, though)
[05:24] <nxvl> imbrandon: ping <IP_ADDRESS> -b
[05:24] <imbrandon> <IP_ADDRESS>/24 worked thanks
[05:24] <nxvl> ok
[05:24] <persia> nxvl: Not every stack implementation replies to broadcast pings.
[05:24] <nxvl> persia: mmm that's true
[05:25] <nxvl> sometimes i wonder what the hell am i doing on the office on sunday  at 00:25 o'clock
[05:26] <nxvl> i need to be less workaholic
[05:40] <nxvl> bye all
[05:51] <imbrandon> woot, back into the router :)
[05:51] <imbrandon> ~ # uname -a
[05:51] <imbrandon> Linux fonbox <IP_ADDRESS> #43 Sat Jul 28 17:53:50 CEST 2007 mips unknown
[05:51] <imbrandon> ~ #
[05:51] <persia> imbrandon: That's lenny?
[05:51] <imbrandon> nah, dd-wrt
[05:51] <imbrandon> on a fon
[05:52] <imbrandon> not sure i could put lenny on it without some major hacking, it only has 8mb flash
[05:53] <persia> Ah.  That's tight.
[05:54] <imbrandon> might be kinda funny to setup a mips pbuilder though
[05:54] <imbrandon> lol
[05:54] <persia> imbrandon: In 8mb?, or does it have a USB port?
[05:55] <white> imbrandon: good luck building OOo on it ;)
[05:55] <imbrandon> persia, well i would do some nfs mounting for more storage
[05:55] <persia> 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] <imbrandon> white, lol
[05:56] <white> persia: doesn't it take several days to build OOo on mips?
[05:56] <imbrandon> well considering the fon is only 200mhz it would be quite slow.
[05:56] <persia> imbrandon: Hmm...  Swap to NFS too, or is there a surprising amount of RAM?
[05:56] <persia> white: I think it's longer for MIPS...
[05:56] <imbrandon> nah 8mb ram 8 mb flash
[05:57] <imbrandon> iirc , i'll have to check
[05:57] <imbrandon> free
[05:57] <imbrandon>   Mem:        13524        12264         1260            0         1348
[05:57] <imbrandon>  Swap:            0            0            0
[05:57]  * joejaxx plots doing a mips port of ubuntu
[05:57] <joejaxx> i could do it
[05:57] <joejaxx> i have the hardware
[05:57] <persia> joejaxx: Could I convince you to do ARM first?
[05:57] <imbrandon> arm
[05:57] <imbrandon> ftw
[05:58] <joejaxx> persia: i have arm machines but they are all mobile
[05:58] <imbrandon> i've been looking for some good arm hardware for a long time
[05:58] <joejaxx> ie it would take forever to build main
[05:58] <imbrandon> desktop/server arm
[05:58] <superm1> Fujitsu, you here?
[05:58] <joejaxx> actually
[05:59] <persia> white: last build: 20071022-1016 through 20071022-1040, which makes me think that there's something odd about OO.o for mips
[05:59] <joejaxx> i could use my nokia 770 it would just take a while to compile
[06:00] <persia> joejaxx: Isn't that a 624MHz machine?  Shouldn't be too bad...
[06:00] <persia> (three or four weeks)
[06:00] <joejaxx> persia: 252 MHz :P
[06:00] <joejaxx> persia: that would take a long time
[06:00] <joejaxx> :D
[06:01] <joejaxx> i could buy three or four more and cluster them
[06:01] <persia> joejaxx: Really?  Hmmm...  I have a spare 400 laying around, but don't really know how to start the bootstrap.
[06:01] <joejaxx> 400?
[06:01] <imbrandon> 400mhz arm?
[06:01] <imbrandon> wow
[06:01] <joejaxx> oh
[06:01] <joejaxx> 400Mhz
[06:01] <joejaxx> nice
[06:02] <persia> joejaxx: PXA255 400MHz
[06:02] <joejaxx> :D
[06:02] <joejaxx> so xscale
[06:02] <imbrandon> arent there some chineese desktop arm boxen ?
[06:02] <joejaxx> wth i forgot i had a ipaq
[06:02] <joejaxx> let me look up the specs
[06:02] <persia> imbrandon: They go up to around 800MHz these days, and nVidia has a couple 1Ghz chips in the lab...
[06:02] <minghua> Chinese arm boxes?  I only heard MIPS ones.
[06:03] <imbrandon> joejaxx, just send me all your old stuff you "forgot" about :)
[06:03]  * persia thinks China likes MIPS
[06:03] <imbrandon> ahh maybe it was mips
[06:03] <joejaxx> imbrandon: lol
[06:04] <bddebian> Gnight folks
[06:04] <persia> imbrandon: For ARM, you need to look at Taiwan, Japan, Korea, Finland, Sweden, and the UK really.
[06:05] <joejaxx> grr wth is my ipaq
[06:05] <persia> NIght bddebian.  Good luck with conquest.
[06:07] <joejaxx> lol my ipaq is only 206MHz
[06:07] <joejaxx> :D
[06:08] <joejaxx> ok fun stuff
[06:09] <joejaxx> i love my ipaq
[06:09] <joejaxx> :D
[06:09] <persia> 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] <joejaxx> persia: ok
[06:09] <joejaxx> :)
[06:10] <joejaxx> i need to get a 100Mbps ethernet card for it
[06:10] <joejaxx> then i can get it a static
[06:10] <persia> joejaxx: Can the bus handle that?  My Z760 doesn't get any benefit for more than 10
[06:10] <tuxmaniac> can someone ack 135492
[06:10] <tuxmaniac> ?
[06:10] <joejaxx> bug 135492
[06:10] <joejaxx> ubotu poke
[06:11] <joejaxx> hmm
[06:11] <ubotu> Launchpad bug 135492 in libitpp "Update to latest version in Ubuntu" [Wishlist,Confirmed] https://launchpad.net/bugs/135492
[06:11] <ubotu> Sorry, I don't know anything about poke - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[06:11] <persia> tuxmaniac: https://launchpad.net/ubuntu/+source/libitpp/ makes me think that bug doesn't have much value.
[06:12] <tuxmaniac> persia, value as in?
[06:12] <tuxmaniac> persia, its used by several students in some premier institutions in India
[06:13] <persia> tuxmaniac: As in, we have <IP_ADDRESS>-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] <tuxmaniac> persia, aah ok. Sorry for the trouble
[06:15] <persia> 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] <tuxmaniac> persia, ok
[06:15] <tuxmaniac> thanks
[06:15] <joejaxx> persia: i do not know that is why i need to get one
[06:15] <joejaxx> persia: :)
[06:16] <persia> tuxmaniac: No, thank you for noticing the bug, and trying to get it fixed :)
[06:16] <tuxmaniac> :)
[06:19] <joejaxx> i need to wipe it
[06:19] <joejaxx> i am reflashing it now
[06:19] <persia> joejaxx: Just to make sure, this is a spare machine, and you're using the 770 for normal stuff, right?
[06:19] <joejaxx> yeap
[06:19] <tuxmaniac> persia, close as in "Fix Rleased" right?
[06:20] <persia> tuxmaniac: Yep (I've already done it for this bug)
[06:20] <joejaxx> the ipaq will work great in this case as they have CF slots
[06:20] <tuxmaniac> aah thanks
[06:20] <joejaxx> i have not come across sd card ethernet cards lol
[06:21] <persia> joejaxx: They have the silly drop-down to expose the wires and touch them to the cable-head trick.  Very fragile.
[06:21] <joejaxx> yeah
[06:22] <joejaxx> 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] <Fujitsu> superm1: I'm here now (sorry, was in an exam)
[06:24] <superm1> Fujitsu, ah hi
[06:24] <superm1> 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] <Fujitsu> superm1: Ah, yes, I should probably get around to finishing that.
[06:24] <superm1> Fujitsu, so hopefully your not too far invested in?
[06:25] <Fujitsu> I've not done much.
[06:25] <superm1> Fujitsu, i'm fairly close with it and am pushing to a new hardy bzr branch right now
[06:25] <superm1> Fujitsu, okay, you mind if i nab it then?
[06:25] <Fujitsu> superm1: Shouldn't it go into trunk?
[06:25] <superm1> Fujitsu, well the way i looked there
[06:25] <superm1> i put the new 1.0~rc2 into upstream-ubuntu
[06:25] <superm1> branch
[06:25] <Fujitsu> Yep, that's right.
[06:26] <superm1> and then i did a 2 way merge from the gutsy and upstream-ubuntu
[06:26] <Fujitsu> Is there a separate gutsy branch?
[06:26] <superm1> 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] <joejaxx> well i am going to retire for the evening
[06:26] <Fujitsu> The feisty branch only exists for security updates.
[06:26]  * joejaxx will file those merge bug reports tomorrow
[06:26] <Fujitsu> Hardy should be just using ubuntu.
[06:27] <joejaxx> or i guess later today it is
[06:27] <joejaxx> Goodnight All
[06:27] <superm1> Fujitsu, well wouldn't it be the same situation for the gutsy one, that it would be for security updates too then?
[06:27] <persia> joejaxx: Good night.
[06:27] <Fujitsu> superm1: We haven't had any security updates yet, but yes.
[06:27] <superm1> ( so it makes sense to have a third hardy one )
[06:27] <Fujitsu> Renaming ubuntu-hardy to ubuntu is probably best.
[06:27] <persia> superm1: Wouldn't you want to name the gutsy-stable branch "gutsy", and maintain trunk in "ubuntu"?
[06:27] <superm1> yeah i'll do that after it finishes pushing
[06:27] <superm1> its a rather large push
[06:27] <Fujitsu> persia: That's what I thought.
[06:28] <Fujitsu> Yeah, takes a number of hours.
[06:28] <superm1> well i'm on a uni connection right now and using bzr+ssh, so hopefully it will be decently fast
[06:28] <Fujitsu> We can branch ubuntu-hardy when hardy releases, rather than branching trunk off a release branch each time.
[06:28] <superm1> well assuming there are no new versions like this time around
[06:29] <superm1> i branched from ubuntu-gutsy, and then merged upstream-ubuntu
[06:29] <Fujitsu> Ah, we normally branch ubuntu-<release> from trunk upon <release>'s release, the merge upstream-ubuntu into ubutnu.
[06:30] <Fujitsu> Your way should work, i think.
[06:30] <Fujitsu> Might just need to be careful about people who have existing local copies.
[06:30] <Fujitsu> (that's another reason not renaming trunk is good)
[06:30] <superm1> oh good point.
[06:30] <superm1> i see what you mean
[06:31] <superm1> well from this point forward i'll make sure to keep it that way
[06:31] <Fujitsu> With the way bzr works, it should be safe to rename the new branch back to ubuntu.
[06:31] <Fujitsu> Thanks.
[06:31] <Fujitsu> (also, please assign the branch back to ~ubuntu-dev when you're done)
[06:31] <superm1> of course
[07:38] <nand_> hi!
[07:38] <nand_> 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] <persia> 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] <nand_> persia: hehe ok!
[07:42] <Fujitsu> 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] <nand_> s/want/want to know/
[07:44] <minghua> Don't think that way.  Think about 73-hour weekends. :-)
[07:44] <superm1> Fujitsu, i will be as long as this test build i'm doing right now
[07:44] <persia> nand_: Nobody does the entire day at once: there are shifts taken.
[07:44] <superm1> Fujitsu, i've had to adjust a lot of configure options already
[07:45] <nand_> minghua: and a 24-hour night :)
[07:45] <superm1> Fujitsu, because the autodetection works whereas hardcoding --enable-XYZ doesn't work
[07:45] <Fujitsu> persia: I know, yeah.
[07:45] <Fujitsu> ps.
[07:45] <Fujitsu> Oops.
[07:45] <superm1> (as of this version)
[07:45] <Fujitsu> superm1: ^^
[07:45] <Fujitsu> Yeah, i saw that in the Debian package.
[07:46] <persia> 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] <Fujitsu> Well, yes, I probably will review something tonight, as I don't have another exam for a couple of days.
[07:46] <persia> nand_: I can't comment now, but is there anything in TODO.TXT you think is interesting for end-users?
[07:47] <nand_> persia: TODO is a very precise roadmap of the features upstream plan
[07:47] <nand_> persia: might be interesting
[07:47] <Fujitsu> 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] <persia> 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] <persia> 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] <superm1> persia, i've got a hdaps sensor in my thinkpad
[07:49] <Fujitsu> Yeah.
[07:49] <superm1> that it gets very very annoying
[07:49] <superm1> Fujitsu, i agree, there
[07:49] <Fujitsu> We've had a couple of bugs about mplayer doing strange things on MacBooks.
[07:49] <Fujitsu> The problem is that they appear as joysticks, and..... yes.
[07:50] <persia> 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] <Fujitsu> persia: We can, yes.
[07:50] <superm1> persia, hm perhaps that is the better solution
[07:50] <Fujitsu> But I'm not sure how well our config-file mangling works at the moment.
[07:50] <Fujitsu> I haven't looked into that much.
[07:50] <superm1> well it worked for the screensaver fix that i put in during gutsy
[07:50] <Fujitsu> OK, that sounds good.
[07:51] <superm1> do you know the config option off hand?
[07:51] <superm1> to disable joysticks
[07:51]  * pwnguin scrambles to read backlog
[07:51] <Fujitsu> superm1: It's in the bug on MacBooks, I'll get a number in a sec.
[07:51] <pwnguin> disable joystick in what?
[07:51] <nand_> persia: Well, that's a good question. What is generally done concerning upstream plans?
[07:51] <persia> pwnguin: mplayer, and only in the config file, so you can turn it on if you want.
[07:51] <Fujitsu> Bug #119630
[07:51] <ubotu> 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] <ubotu> Launchpad bug 75925 in mplayer "[edgy] Disable joystick by default" [Wishlist,Confirmed] https://launchpad.net/bugs/75925
[07:52] <persia> 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] <pwnguin> go nuts
[07:52] <superm1> Fujitsu, okay thanks i'll add that in
[07:52] <nand_> persia: ok.
[07:52] <pwnguin> in a perfect world totem would actually inhibit dpms
[07:53] <persia> Fujitsu: I'd argue that 119630 for blobwars was user error, but the the mplayer side is more annoying.
[07:53] <pwnguin> (and render softsubs accurately)
[07:53] <Fujitsu> persia: The bug is against mplayer, so..
[07:53] <persia> Fujitsu: Good.  I wasn't planning on turning off joystick support for a platform game :)
[07:54] <Fujitsu> persia: Haha.
[07:54] <nand_> 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] <persia> 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] <persia> Fujitsu: How about when upstream doesn't produce one, and the VCS log doesn't have comments :)
[07:56] <nand_> 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] <Fujitsu> persia: Then the upstream probably shouldn't be trusted anyway.
[07:57] <persia> Fujitsu: I'm inclined to agree, but I could find some examples...
[07:57] <minghua> persia: In that case, I would say packager should persuade upstream release manager to include "vcs log" output as changelog in releases.
[07:57] <wallyweek> 'morning all! :)
[07:57] <pwnguin> hey, is ~ a shell expansion for homedir?
[07:57] <persia> pwnguin: For some definitions of "shell", including dash and bash
[07:58] <pwnguin> so definately not something fopen("~/.foo/bar") would handle correctly
[07:58] <persia> pwnguin: Right.
[07:58] <nand_> nanap
[07:58] <nand_> uh sry
[07:58] <pwnguin> surely someone's envisoned a "correct" way to do that
[07:59] <persia> pwnguin: query the user information from the system
[07:59] <superm1> pwnguin, typically an env variable like HOME
[08:00] <persia> superm1: As long as it's unix, there's a better way...  I'll dig it up.
[08:01] <wallyweek> this has been in revu since march and got some review before revu went down in august
[08:01] <wallyweek> http://revu.tauware.de/details.py?package=sdlmame
[08:01] <wallyweek> could anyone help me to get it finally in the repositories? thanx! :)
[08:02] <pwnguin> persia: well, it may or may not be unix. one could probably check passwd
[08:02] <Fujitsu> pwnguin: getent, please.
[08:03] <pwnguin> Fujitsu: naturally.
[08:03] <persia> Fujitsu: Thank you.
[08:04]  * nand_ goes take a short 4-hours nap before starting his 48-hours day
[08:04] <Fujitsu> 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] <nand_> persia: Ah!
[08:05]  * nand_ puts it on his todo list.
[08:05] <nand_> persia: thanks for looking into it.
[08:06] <persia> 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] <nand_> persia: sure.
[08:07] <persia> nand_: Also, you might want to look into make variables: there's a much easier way to do all the manual cleaning.
[08:08] <nand_> persia: true enough, it's a bit messy here.
[08:08] <persia> 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] <Fujitsu> persia: Why can't you comment? Don't have your key and can't remember the password?
[08:09] <persia> Fujitsu: got it in one :)
[08:10] <Fujitsu> The password can be changed easily.
[08:10] <persia> 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] <Fujitsu> persia: With one line on  a shell on sparky.
[08:12] <persia> 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] <Fujitsu> OK.
[08:12] <wallyweek> persia: ok
[08:13] <Hobbsee> persia: here, i'll give your p/w back to you, if you like
[08:13] <Fujitsu> That's true, we can actually retrieve passwords too.
[08:14] <persia> 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] <Hobbsee> persia: what's the email that you use to log onto revu with?
[08:14] <Hobbsee> persia: true, but i'm here now, so :)
[08:14] <persia> Hobbsee<EMAIL_ADDRESS>:P
[08:14] <Hobbsee> dont make me search the DB :)
[08:15] <persia> Hobbsee: Really, I'm fine with my password, and don't need to be able to log in.
[08:15] <Hobbsee> oh well, OK
[08:15]  * Hobbsee logs out
[08:15] <Hobbsee> 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] <persia> 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] <Hobbsee> Fujitsu: is libqalculate on the revu interface?
[08:16] <Fujitsu> Hobbsee: Looking.
[08:16] <Hobbsee> er, web interface?
[08:17] <Fujitsu> Yes, right near the bottom.
[08:17] <persia> Hobbsee: http://revu.tauware.de/details.py?package=libqalculate
[08:17] <Hobbsee> ah, good
[08:17]  * Hobbsee wtf's?
[08:17] <Fujitsu> What an old email address.
[08:17] <Fujitsu> Hobbsee: Why?
[08:17] <Hobbsee> just looking at other stuf here
[08:17] <Hobbsee> Changed-By: Matt T. Proud<EMAIL_ADDRESS>[08:17] <Hobbsee> we have a googler
[08:17] <Fujitsu> Nice.
[08:18] <Fujitsu> Which package?
[08:18] <persia> I thought we had about a dozen of those
[08:18] <Hobbsee> it really is him, too
[08:19] <persia> 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] <nand_> persia: what did you have in mind with the make variables?
[08:20] <persia> 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] <Hobbsee> appears not to be on irc, either.
[08:21] <Hobbsee> the guy has 2 keys, and didnt use either of them to sign his package
[08:22] <persia> 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] <nand_> persia: hmm... I think i see.
[08:23] <persia> 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] <persia> 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] <persia> The same thing also works in debian/rules, although it's less frequently required.
[08:25] <nand_> persia: Ah ok I see!
[08:25] <persia> err.  all: $(LIST).o
[08:25] <persia> nand_: Just really check the manual.  My syntax is very likely wrong.
[08:25] <wallyweek> persia: from first to last: is get-orig-source a rules target? isn't enough to state repackagin in changelog/copyright?
[08:26] <Fujitsu> wallyweek: Please implement get-orig-source.
[08:26] <persia> 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] <wallyweek> persia: manpages go in different binary packages. Should I list them all as dh_installman arguments?
[08:27] <wallyweek> persia: mame is a symlink for frotends compatibiliy... I can remove it as well
[08:27] <persia> wallyweek: packagename.manpages does the right thing.  I just don't think you need to define the manpage directories in package.dirs
[08:28] <persia> 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] <wallyweek> persia: right, I'm going to edit files and be back in a while :)
[08:30] <persia> wallyweek: Great.  Thanks.
[08:43] <wallyweek> persia, Fujitsu: checking the sdlmame site, there's no older source archive online :(
[08:44] <wallyweek> please post some suggestion... thanks! :)
[08:44] <persia> wallyweek: Is the current archive available?
[08:44] <wallyweek> persia: they've released 120u2, and deleted 120u1
[08:45] <wallyweek> and dev cycle is a new release each week :(
[08:45] <wallyweek> they're driving me mad :p
[08:45] <persia> wallyweek: so we should expect 120u3 next week?
[08:45] <wallyweek> yes... it usually is up on tuesday
[08:46] <persia> Fujitsu: What do you think?  I'm not sure how it would work unless the wayback machine is being agressivev.
[08:47] <minghua> Headache inducing upstream.
[08:47] <wallyweek> :)
[08:47] <Fujitsu> Hm... attack upstream until they do something sane.
[08:47] <Fujitsu> Deleting old sources is silly and makes things difficult.
[08:47] <superm1> Fujitsu, okay uploaded mplayer.  whew that was a much uglier merge than i expected :)
[08:47] <persia> 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] <wallyweek> nope
[08:47] <wallyweek> :(
[08:48] <Fujitsu> superm1: Yep, that's why I didn't finish it quickly.
[08:48] <Fujitsu> superm1: Thanks.
[08:48] <minghua> wallyweek: Do upstream sign their releases?
[08:48] <wallyweek> their chiefly interest is to make sdlmame available for source building only :(
[08:48] <minghua> (if yes, a mirror with all releases probably will do)
[08:48] <persia> 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] <superm1> 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] <superm1> no prob
[08:49] <persia> wallyweek: Do they not consider sdlmame to be stable enough yet?
[08:49] <wallyweek> minghua: no, AFAIK
[08:49] <superm1> okay well i'm going to get to bed now.  g'night
[08:49] <minghua> Upstream can go to hell, IMHO.  :-P
[08:49] <persia> wallyweek: Do they have a public VCS repository?
[08:50] <persia> good night superm1
[08:50] <wallyweek> persia: it's not a public one
[08:51] <wallyweek> persia: and I've got no auth even to see it
[08:51] <persia> 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] <Fujitsu> Not.... public.... ew.
[08:51] <Fujitsu> Why isn't it public?
[08:52] <Fujitsu> Are they trying to be as non-free as possible while being free?
[08:52] <wallyweek> fujitsu: I don't know :(
[08:52] <persia> Fujitsu: s3kr1+ g4mrz d4+4
[08:52] <wallyweek> fujitsu: possibly yes ;)
[08:52] <Fujitsu> persia: Aha.
[08:53] <minghua> secret gamrs data?  Is that what persia saying?
[08:53] <Fujitsu> I presume so.
[08:53] <Fujitsu> I daren't attempt to look at that abomination much.
[08:53] <persia> minghua: Well, sort of.  I'm putting it in funny characters to make a sarcastic point.
[08:53] <minghua> What does gamrs mean then...
[08:53] <persia> minghua: Secret gamers data (sort of)
[08:54]  * persia can read 1337, but has trouble typing it
[08:54] <minghua> "gamers data" is still parser error to me.
[08:54] <minghua> or "gamers' data".
[08:54] <persia> minghua: Secret data only available to the gamers who are hacking the code
[08:55] <minghua> Ah.  By gamers you mean developers.
[08:55] <persia> minghua: Specifically not.  developers who write open source software do so in open repositories
[08:55] <wallyweek> fujitsu, persia: the code *is* accessible, the VCS repository is not...
[08:55] <minghua> Anyway, I maintain my idea that upstream can go to hell.
[08:56] <xstasi> lol
[08:56] <wallyweek> I think they've been flooded with patches so they decided to make it not accessible by everyone
[08:56] <persia> 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] <wallyweek> persia: right, I understand that
[08:57] <persia> 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] <wallyweek> persia: ok, I'll see what I can do to convince upstreamers to keep older sources at least
[08:59] <wallyweek> could this be enough?
[08:59] <wallyweek> I mean: some kind of "freeze"
[08:59] <persia> 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] <Fujitsu> Or do what every other upstream on the planet does, and keep sources around.
[09:00] <Fujitsu> Indefinitely.
[09:00] <persia> wallyweek: Not a freeze, just when they add a new one, don't delete the old one.
[09:02] <wallyweek> persia, fujitsu: devel cycle consists of unstable and stable releases
[09:02] <persia> wallyweek: Do they leave the "stable" releases around forever?
[09:02] <wallyweek> should I ask for a full archive or would the stable releases be enough?
[09:02] <wallyweek> no
[09:03] <wallyweek> they keep until next stable release (each month, normally)
[09:03] <persia> wallyweek: stable is enough, as long as you're packaging a stable.  That's a better candidate for inclusion anyway.
[09:03] <wallyweek> ok
[09:03] <persia> (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] <wallyweek> ok, I'll see what I can do... I have to hold for this meanwhile :(
[09:05] <wallyweek> btw, I also have another couple of packages in revu... may we carry on with them?
[09:05] <wallyweek> http://revu.tauware.de/details.py?package=btpd
[09:05] <wallyweek> http://revu.tauware.de/details.py?package=shorten
[09:05] <wallyweek> thanks :p
[09:06] <persia> wallyweek: I have to get back to other things for a couple hours, but someone else might be able to review...
[09:10] <StevenHarperUK> 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] <wallyweek> persia: ok, thanks for you help, anyway! :)
[09:19] <persia> 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] <StevenHarperUK> persia : I am on a real release now yes
[09:23] <StevenHarperUK> persia: it that enough?
[09:23] <StevenHarperUK> persia: *is
[09:23] <persia> 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] <StevenHarperUK> persia: thanks, I plan to get as many reviews / revisions as it takes today :p
[09:24] <persia> 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] <persia> Hobbsee: Kiribati to Niue :)
[09:31] <huats> morning everyone
[09:33] <Hobbsee> persia: i thought you were advocating a 49 hour revu day before
[09:34] <persia> 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] <Hobbsee> awww
[09:34] <Fujitsu> Damn :(
[09:35] <persia> 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] <Hobbsee> true :)
[09:36] <Hobbsee> that would be fun :)
[09:36] <pwnguin> declare metric time!
[09:36] <Fujitsu> pwnguin: Yes!
[09:36]  * ajmitch shudders to think of Hobbsee as dictator
[09:36]  * Hobbsee dictates that ajmitch GET REVIEWING!
[09:36] <ajmitch> can't
[09:36]  * persia points out there are three reviews without responses pending
[09:36] <Hobbsee> ajmitch: yes you can.
[09:37] <ajmitch> that would require me to have some confidence in my abilities to review properly
[09:38] <persia> ajmitch: You could at least run linda and lintian for people, and comment about the style of files in debian/
[09:40] <Hobbsee> ajmitch: you're a DD.  get to it.
[09:40] <ajmitch> for now
[09:40] <Hobbsee> you're quitting that too?
[09:40] <StevenHarperUK> Anyone having a look at easycrypt - http://revu.tauware.de/details.py?upid=541
[09:41] <persia> 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] <pwnguin> less than a thousand builds left in the sync?
[09:45] <pwnguin> might be time to look into my pet packages
[09:50] <Fujitsu> pwnguin: That's i386-only :(
[09:50] <persia> pwnguin: Still 3928 for hppa (and only 3 for lpia)
[09:51] <persia> Actually, shouldn't there be none for lpia?  Why isn't anything building?    Right.  I keep forgetting.
[09:54] <pwnguin> is i386-only different than i386?
[09:54] <persia> pwnguin: No.  i386 runs with -A
[10:02] <persia> 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] <slytherin> 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] <wallyweek> Can anyone have a look at my packages?
[10:43] <wallyweek> http://revu.tauware.de/details.py?package=btpd
[10:43] <wallyweek> http://revu.tauware.de/details.py?package=shorten
[10:43] <wallyweek> thanks :)
[10:51] <tepsipakki> jdong: thanks for caring about gtkpod-aac :)
[10:52] <pwnguin> success
[10:53] <pwnguin> soulfu is now packaged
[10:53] <ajmitch> yay
[10:53] <slytherin> 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] <pwnguin> bedtime now. i guess i'll upload to revu in the mornin
[10:54] <nand_> I request a review of my package ike please : http://revu.tauware.de/details.py?package=ike  . Thanks!
[10:55] <pwnguin> im sure theres tons of errors i've made
[11:01] <nand_> 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] <wallyweek> nand_: I missed that. Thanks! :)
[11:03] <broonie> 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] <slytherin> 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] <StevenHarperUK>  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] <nand_> 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] <Fujitsu> StevenHarperUK: Please fix what nand_ said. I'm looking over it now.
[11:27] <StevenHarperUK> Ok ill do that now
[11:28] <Fujitsu> StevenHarperUK: Couple of other issues that I'll add a comment about in a sec.
[11:28] <StevenHarperUK> Fujitsu: Great
[11:28] <wallyweek> fujitsu: definitely yes: "put it in the new "Homepage" field in the source stanza"
[11:29] <StevenHarperUK> Fujitsu
[11:29] <StevenHarperUK> Fujitsu: Shall I wait for  your other before I rebuild
[11:29] <Fujitsu> StevenHarperUK: Yes please.
[11:29] <Fujitsu> I won't be more than another couple of minutes.
[11:30] <warp10> Hi all!
[11:30] <StevenHarperUK> warp10: hi
[11:45] <Fujitsu> StevenHarperUK: Commented.
[11:46] <StevenHarperUK> Fujitsu: ta
[11:47] <StevenHarperUK> Fujitsu: the TrueCrypt packaging : there fussy about re-distribution
[11:48] <StevenHarperUK> Fujitsu: Hopefully in the future, I will get clearence to package and then make it a dependancy
[11:48] <Fujitsu> StevenHarperUK: OK, I see there are easily-installed binary packages there. It's probably OK.
[11:48] <StevenHarperUK> Fujitsu: ok ta
[11:48] <StevenHarperUK> Fujitsu: I am on to them so I can get it into a proper package then I can make it a dependancy...
[11:49] <persia> 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] <Fujitsu> persia: It's a .deb... that sounds evil.
[11:50] <StevenHarperUK> Like Fijitsu says its a deb
[11:50] <persia> Fujitsu: Hrm.  True.
[11:50] <StevenHarperUK> I wouldn't want to automate it
[11:50] <StevenHarperUK> When I get the OK to package it will be better
[11:50] <StevenHarperUK> but it is very simple
[11:50] <StevenHarperUK> I have users using it from my PPA without complaint
[11:51] <Fujitsu> StevenHarperUK: Also, there is a space before the python build-dependency.
[11:51] <Fujitsu> Trivial, but it'd be nice to fix it.
[11:51] <Adri2000> TheMuso: is it you who added the comment about audacious-plugins on DaD?
[11:53] <StevenHarperUK> Fujitsu: done
[11:53] <Fujitsu> StevenHarperUK: Thanks.
[11:59] <tepsipakki> is the buildd backlog visible somewhere? Someone mentioned that it's ~1000 packages for i386
[12:00] <Fujitsu> tepsipakki: https://launchpad.net/ubuntu/hardy/+builds has everything, https://launchpad.net/ubuntu/hardy/i386/+builds has just i386.
[12:00] <Fujitsu> You can use the filter there.
[12:00] <Fujitsu> tepsipakki: It was 3000 a couple of weeks ago, so it shouldn't be too long.
[12:00] <tepsipakki> Fujitsu: oh, indeed :)
[12:01] <persia> tepsipakki: You can also play with the i386 to check any arch...
[12:02] <tepsipakki> 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] <Fujitsu> tepsipakki: They've all built, as far as I know.
[12:02] <tepsipakki> since the ABI's have changed
[12:02] <Fujitsu> They still seem to be providing -1.0.
[12:03] <tepsipakki> Fujitsu: well, I still see a bunch of video-drivers on MoM
[12:03] <tepsipakki> they are supposed to be synced, so I'd like to be sure before complaining about it :)
[12:03] <Fujitsu> tepsipakki: I suspect they might have rebuilt before the new xserver-xorg did.
[12:03] <persia> 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] <tepsipakki> Fujitsu: aww
[12:03]  * Fujitsu checks the logs.
[12:03] <Fujitsu> Because they definitely still provide -1.0.
[12:03] <Fujitsu> Which is wrong.
[12:03] <tepsipakki> hmm, actually they shouldn't build
[12:04] <tepsipakki> but only some video-drivers were synced
[12:04] <Fujitsu> Ah.
[12:04] <Fujitsu> Which?
[12:04] <tepsipakki> I need to check
[12:05] <tepsipakki> -mga for instance
[12:06] <Fujitsu> Ah, that's -2.
[12:06] <tepsipakki> so not built yet
[12:06] <tepsipakki> ogh
[12:06] <tepsipakki> *oh
[12:06] <Fujitsu> -mga built, -intel, -ati haven't... /me checks others.
[12:06] <tepsipakki> you meant the provides, not package revision (which is -3 :)
[12:06] <Fujitsu> Oh, sorry.
[12:06] <tepsipakki> intel and ati needs merging
[12:07] <tepsipakki> but I uploaded intel since that's a candidate for gutsy SRU
[12:07]  * Fujitsu is waiting on -intel
[12:07] <Fujitsu> And I happened to be dealing with -ati earlier tonight, so that was the second one I checked.
[12:07] <tepsipakki> I had 46 packages on the sync-list ;)
[12:08] <StevenHarperUK> Fujitsu: all Changes done & tested : uploading now.. I'll msg you again when its up
[12:08] <tepsipakki> and maybe some of those weren't synced
[12:08] <Fujitsu> StevenHarperUK: Thanks, I'll look shortly.
[12:09] <persia> 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] <DktrKranz> Fujitsu, I'm chasing a FTBFS on netcdf, which is under MOTU-Science attention. Can I proceed?
[12:17] <StevenHarperUK> Fujitsu: Its there with comment - http://revu.tauware.de/details.py?upid=543
[12:17] <Fujitsu> StevenHarperUK: Yep, looking now.
[12:18] <Fujitsu> DktrKranz: Of course. We (well, I) don't bite.
[12:18] <Fujitsu> We try to take care of them, but that doesn't mean we have an exclusive lock.
[12:18] <DktrKranz> Fujitsu, of course not, but I don't want to steal something you may be interested in :)
[12:21] <Fujitsu> DktrKranz: Bit busy with exams and stuff to chase much now.
[12:22] <DktrKranz> ok. I'll publish a debdiff soon and subscribe u-u-s for sponsorship. thanks
[12:23] <Fujitsu> StevenHarperUK: Looking good.
[12:23] <persia> nand_: ike commented
[12:23] <nand_> persia: thanks!
[12:23] <persia> nand_: Looks like a bit of a copyright mess with upstream (unless I misunderstand)
[12:24] <nand_> persia: I remember having discussed about it with upstream... /me will look at it
[12:25] <persia> 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] <nand_> persia: btw, here with my version of desktop-file-validate, it is validated. Can you tell me what your version tells?
[12:26] <persia> nand_: "Encoding" is deprecated is the one I remember.  Which version of desktop-file-validate are you using?
[12:27] <Fujitsu> StevenHarperUK: The package is now technically clean in my eyes, but some of the description is a bit iffy.
[12:30] <nand_> persia: ok i give up :p What is the package providing desktop-file-validate
[12:30] <persia> nand_: desktop-file-utils
[12:30]  * nand_ notes that the man page of desktop-file is wrong
[12:31] <persia> nand_: Please submit a patch: upstream is very responsive
[12:32] <nand_> persia: version 0.13
[12:32] <nand_> persia: on my todo list too.
[12:33] <StevenHarperUK> 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?