[00:10]  * TheMuso grumbles at there being no Contents-$arch.gz for hardy
[00:10] <TheMuso> on any mirror.
[00:17] <geser> TheMuso: afaik the Contents file isn't generated yet for hardy but I don't remember why
[00:18] <TheMuso> geser: I can see its not being generated... I guess another soyuz bug.
[00:19] <LaserJock> seems like that always happens for the devel release
[00:57]  * persia notes that Contents.gz is intentionally not provided at the beginning of a release cycle due to the expected massive changes, but that post-DIF it likely ought be enabled, and someone may have forgotten.
[00:58] <LaserJock> ah, that makes sense
[01:03] <LaserJock> Fujitsu: wow, there's now an octave3.0 package
[01:03] <Fujitsu> LaserJock: There is.
[01:03] <Fujitsu> And we didn't sync it because it broke the upgrade path, IIRC.
[01:03] <LaserJock> oh? how so?
[01:03]  * Hobbsee waves
[01:03] <persia> LaserJock: Bug #178424
[01:04] <ubotu> Launchpad bug 178424 in octave2.9 "Please sync octave3.0 3.0.0-1 (universe) from Debian unstable (main)" [Wishlist,Triaged] https://launchpad.net/bugs/178424
[01:05] <LaserJock> hmm, I don't see how that's a problem
[01:06] <persia> users not being able to upgrade?
[01:06] <LaserJock> why would they not be is my question
[01:06] <LaserJock> octave3.0 conflicts/replaces 2.9
[01:06] <LaserJock> but there's nothing that says that an upgrade would give you 3.0
[01:06] <Fujitsu> I believe the problem was that there is no octave metapackage any more.
[01:07] <persia> LaserJock: No "octave" virtual package.  Just needs a small change for a merge, in my opinion.
[01:07] <LaserJock> but why not use the package from 2.9?
[01:07] <persia> (but someone should probably check with the Debian Octave maintainers to make sure we don't interfere with some cunning plan)
[01:07] <LaserJock> I was just thinking that current 2.9 users would get 2.9
[01:08] <LaserJock> and if people want to install 3.0 they can do that themselves
[01:08] <persia> LaserJock: octave2.9 is scheduled for removal from Debian (and we'd probably want to follow if we import octave3.0)
[01:08] <LaserJock> yeah, that would be the problem
[01:09] <LaserJock> wait
[01:09] <LaserJock> the changelog says: "Dropped the empty octave package.  This will allow
[01:09] <LaserJock>      releasing octave3.0 without an epoch in its version number.  We will
[01:09] <LaserJock>      reintroduce this package later, if necessary (anyway, octave3.0
[01:09] <LaserJock>      provides octave)."
[01:09] <LaserJock> does the provides make it upgradable?
[01:09] <persia> LaserJock: Give it a test.
[01:10] <persia> (create gutsy chroot, install octave, upgrade to hardy with an extra repo including octave3.0, see if it breaks)
[01:13] <persia> Ah.  Wait.  I understand now.  1:2.9.18-1ubuntu1 >> 3.0.0-1.  That's frustrating.
[01:19] <bddebian> Heya gang
[01:19] <persia> hey bddebian
[01:19] <bddebian> Hi persia
[01:22] <ScottK2> LaserJock: I've got another one for you if you have a moment.
[01:22] <LaserJock> k
[01:23] <ScottK2> I need a couple of minutes to fix it.  I missed that a package had moved from Universe to Main and so it needs a few adjustments
[01:26] <ScottK2> LaserJock: The updated package can be dgetted (dgotten) from http://www.kitterman.com/test/libnet-server-perl_0.97-0ubuntu1.dsc
[01:27] <ScottK2> It's signed.
[01:27] <persia> dgotten?  English is annoying flexible and irregular :)
[01:27] <zul> hey
[01:28] <ScottK2> LaserJock: There is also http://www.kitterman.com/test/libnet-server-perl_0.97-0ubuntu1_source.changes if you want it.
[01:29] <bddebian> Is a watch file really worth a delta with Debian?
[01:29] <persia> bddebian: Only for orphaned packages.
[01:30] <LaserJock> ScottK: hmm, you upload the diff.gz with it? I get 404
[01:32] <ScottK2> Urgh checking
[01:33] <ScottK2> LaserJock: It's there now.  Sorry about that
[01:36] <persia> Does Malone support virtual packages?  I'm thinking it might be nice to havea  virtual package against which needs-packaging bugs are filed, so as to create the ability to subscribe to the package as an ad-hoc mailing list for packaging work that needs doing.
[01:37] <LaserJock> ScottK: Donald?
[01:37] <Fujitsu> persia: It does not.
[01:37] <LaserJock> persia: yeah ... well I tried that
[01:37] <persia> Fujitsu: Thanks.  I shan't propose such a thing to a wider forum then.
[01:37] <Fujitsu> You can only file bugs on SourcePackageNames that are published in a distribution.
[01:38] <LaserJock> I went from "virtual package just like wnpp" -> "project for wnpp" -> "tag it"
[01:38] <persia> Ah.  So the discussion has been had before.  The annoying bit being that one cannot subscribe to a tag.
[01:39] <Hobbsee> persia: not unless you actually upload a virtual package of nothing
[01:39] <Hobbsee> make a package called needs-packaging or something.  put it in the archive.  *shrug*
[01:39] <Fujitsu> Bug #151129
[01:39] <ubotu> Launchpad bug 151129 in malone "Can't subscribe to a tag" [Undecided,New] https://launchpad.net/bugs/151129
[01:39] <Ng> is it correct to assign a new needs-packaging bug to MOTU (it covers the thing I'm working on)
[01:39] <persia> Hobbsee: That's just wrong.  Uploading the needs-packaging package which only provides changelog, copyright, and README.gz is not the right solution.
[01:39] <persia> Ng: No.  Correct to assign to yourself, as you're working on it.
[01:39] <Hobbsee> persia: i didn't say it was right.  i just said it would do what you were asking :P
[01:40] <Fujitsu> persia: Well, one could upload, and then remove it again immediately.
[01:40] <Ng> persia: okidoki, thanks
[01:40] <Fujitsu> Once there is any kind of SourcePackagePublishing, it will be filable, but that's a bug.
[01:40] <persia> Fujitsu: Hmm.  Then it would be there, but not distributed.  Hobbsee: would you collude in such a dance?
[01:40]  * Fujitsu prefers being able to subscribe to tags.
[01:41] <Hobbsee> persia: define distribubted in this case?
[01:41] <Hobbsee> persia: it woudl be yet another universe package
[01:41] <persia> Hobbsee: That would be distributed.
[01:42] <LaserJock> I think being able to subscribe to tags is a sane idea
[01:42] <persia> Fujitsu: Yes, that's a more general solution.  Too bad it's still New.
[01:42] <Hobbsee> persia: yes, but how many packages are in universe again?
[01:42] <Fujitsu> LaserJock: So does mpt, apparently.
[01:42] <Hobbsee> LaserJock: far too sane to be implemented.
[01:42]  * Hobbsee ducks
[01:42] <persia> Hobbsee: About 15,000.  Which we support.
[01:43] <Hobbsee> fsvo support, anyway
[01:43] <Hobbsee> but yes
[01:43]  * persia considers confiscating Hobbsee's MOTU badge
[01:43] <LaserJock> heh
[01:43] <ScottK2> LaserJock: Yes.  Scott is my middle name.
[01:43]  * Hobbsee waves her core-dev badge around
[01:43] <Hobbsee> core-dev trumps MOTU, i'm afraid
[01:44]  * Fujitsu looks with dismay at http://qa.ubuntuwire.com/multidistrotools/universe.html#removedfromA
[01:44] <persia> Hobbsee: Right.  Core-dev gets you upload to anywhere, so losing MOTU wouldn't affect much, except that it would indicate you don't have the appropriate positive attitude about supporting all of universe :)
[01:44] <Hobbsee> *grin*
[01:45] <persia> Fujitsu: I'm likely to start hitting that next week, but would be more than happy if you want to start sooner :)
[01:45]  * Hobbsee has reservations with how some of MOTU works.  Therefore, she's less likely to feel an active part of it.
[01:46] <Hobbsee> still, i don't see how a metapackage would actulaly need supporting, per se.
[01:46]  * persia has reservations with how some of core works, and doesn't intend to start participating soon.
[01:46] <Hobbsee> or what the problem is of addign one more, when there's 15K already.
[01:46] <LaserJock> ScottK: does libnet-server-perl have any current core dev owner? I won't be stepping on any toes?
[01:47] <persia> Hobbsee: It's a non-package.  It oughtn't really be there.  Publishing and removing would allow one to file bugs, but publishing and letting die only makes more work for those of us who try to trim the edges.
[01:47] <ScottK2> LaserJock: There isn't currently an Ubuntu diff.  We get it from Debian and the Debian maintainer isn't an Ubuntu person, so I'd think not.
[01:47] <LaserJock> k
[01:49] <Fujitsu> Do we know when ajmitch returns, so we might be able to have rcbugs going again?
[01:49] <nenolod> Hobbsee, transmission 1.0 is out if you're interested in bumping it (but it's not in Debian yet)
[01:49] <persia> He indicated about three weeks around 22nd December, so I'm guessing "soon".
[01:50] <Fujitsu> Thanks persia.
[01:50]  * persia is anxiously awaiting the return of RCbugs :)
[01:51] <Hobbsee> nenolod: i don't see the point in duplicating work like that
[01:51] <LaserJock> ScottK: did you comment that it was uploaded to hardy in bug #69895 because I'm doing it?
[01:51] <ubotu> Launchpad bug 69895 in postgrey "crashes when syslog is not available" [Medium,Fix released] https://launchpad.net/bugs/69895
[01:51] <nenolod> Hobbsee, right. i'll tell the debian maintainer that 1.0 is out. ;)
[01:51] <ScottK2> LaserJock: I commented that it was uploaded because I didn't notice it had moved to main and uploaded it.
[01:51] <LaserJock> ah, k
[01:51] <nenolod> oh.
[01:52] <nenolod> Hobbsee, 1.0 is incoming
[01:52] <bddebian> w00t, on build 200 of newpki-client...
[01:52] <persia> ScottK: Isn't that more easily done with a changelog entry?
[01:52] <ScottK2> LaserJock: After it bounced, I came looking for you...
[01:52] <ScottK2> persia: What?
[01:52] <nenolod> so, i'll just update bug 180534 to a sync bug
[01:52] <ubotu> Launchpad bug 180534 in transmission "Please update transmission to latest version (1.0)" [Undecided,New] https://launchpad.net/bugs/180534
[01:52] <nenolod> ;)
[01:52] <persia> ScottK: Closing bugs for uploads.
[01:52] <ScottK2> I didn't mark 69895 fixed
[01:53] <ScottK2> my changelog marks bug #177408 fixed
[01:53] <ubotu> Launchpad bug 177408 in libnet-server-perl "Please upgrade to 0.97" [Wishlist,Triaged] https://launchpad.net/bugs/177408
[01:53] <persia> ScottK: My mistake.  Sorry.
[01:53] <ScottK2> No trouble.
[01:54] <ScottK2> I was messing with libnet-server-perl because I'm working on getting amavisd-new into Main for Hardy and I'm making sure all the depends are in good shape and in Main also.
[01:56] <LaserJock> ScottK: done
[01:58] <ScottK2> LaserJock: Thanks.
[01:58] <nenolod> Hobbsee, https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/180534 -- if you want to bump it again. it builds fine in my pbuilder.
[01:58] <ubotu> Launchpad bug 180534 in transmission "Please sync transmission_1.00-1 from Debian unstable (main)" [Undecided,New]
[01:59] <ScottK2> nenolod: I thought you said it wasn't in Debian yet?
[01:59] <nenolod> ScottK2, it's in incoming
[01:59] <ScottK2> Ah.
[01:59] <nenolod> actually it just moved out of incoming a while ago into unstable
[02:00] <ScottK2> OK.
[02:04] <LaserJock> man, I've done a lot of dput'ing today
[02:04] <nenolod> (so it can be pulled from merkel, but not from the main pool)
[02:04] <nenolod> (which is where i picked it up)
[02:08] <LaserJock> ScottK: \o/ 3 Main upload is just over 3 hrs ;-)
[02:08] <persia> LaserJock: If you're going for volume, you may find that dput *source.changes can be surprisingly helpful.
[02:09] <nenolod> haha
[02:12] <ScottK2> Thanks for all the help LaserJock.
[02:12] <LaserJock> no problem, glad i could be of some service
[02:17] <LaserJock> hmm, we have iceape but not iceweasel?
[02:24] <LaserJock> anybody have an opinion on "s/iceweasel/firefox/" vs "add firefox|" for dependent packages?
[02:25] <persia> LaserJock: I like "add firefox |" to support future gobuntu plans if they choose iceweasel over epiphany (currently under debate, I believe)
[02:27] <LaserJock> hmm, does epiphany use firefox plugins?
[02:27] <persia> LaserJock: In some limited ways, but not really.
[02:27] <Nafallo> LaserJock: it has it's own plugin package basically.
[02:28] <Nafallo> LaserJock: it can use flash and stuff though.
[02:28] <LaserJock> hmm
[02:28] <LaserJock> I've got a package that creates a mozilla plugin
[02:28] <LaserJock> and in debian it uses iceweasel | iceape | xulrunner
[02:29] <LaserJock> and it build-deps on libxul-dev
[02:30] <ScottK2> For Hardy, I think the idea is to use xulrunner
[02:30] <persia> Be careful there.  F3 is xulrunner1.9, which is not xulrunner.
[02:30] <persia> ScottK: Yes.
[02:30] <LaserJock> I'm assuming that the build-dep on libxul-dev will work for everything
[02:31]  * persia thinks the API may be different, and suggests checking in -mozillateam
[02:31] <LaserJock> some I was just gonna do firefox | iceweasel | iceape | xulrunner
[02:31] <Fujitsu> xulrunner-1.9-dev is the 1.9 dev package.
[02:32] <LaserJock> but I wondered about epiphany
[02:32] <LaserJock> sorry for the ignorance, but should I care about F3 and xulrunner1.9? are they default in Hardy?
[02:33] <Fujitsu> Fx3 isn't default yet.
[02:33] <Fujitsu> They are planned to be, though.
[02:33] <Fujitsu> (Fx3 uses xulrunner-1.9, rather than an embedded Gecko)
[02:33] <LaserJock> hmmpf
[02:33] <LaserJock> I hate mozilla stuff
[02:34] <LaserJock> and I can never get anything from mozilla team
[02:49] <bddebian> Shite, I think my pbuilder is screwed up, I don't know if I can help with UUS persia :(
[02:49] <LaserJock> bddebian: what'd you do now?
[02:50] <bddebian> Dunno :-(
[02:51] <bddebian> It act like it's having issues resolving archive.ubuntu.com
[02:51] <bddebian> acts..
[02:53] <LaserJock> but your machine is fine?
[02:53] <bddebian> Yeah.  In fact in pbuilder-login it acts fine.  I'm not getting it.. :-(
[02:56] <LaserJock> weird
[02:57] <LaserJock> bddebian: paste the output?
[02:57] <bddebian> Yeah and pbuilder update works but not build.. wtf
[03:03] <persia> bddebian: Maybe pbuilder finally died for you.  You might try https://help.ubuntu.com/community/SbuildLVMHowto (there's a handy script in ubuntu-dev-tools to make this pointlessly easy)
[03:07] <bddebian> This is craziness: http://paste.debian.net/46256
[03:07] <LaserJock> man, I *still* have a hard time remembering changelog-closes-bug
[03:07] <persia> bddebian: Maybe some irregularity between arch: i386 and arch: all ?  (Yes, this should never happen)
[03:10]  * persia requests people check other bugs on a package when preparing a new revision.  While it's also nice to fix other outstanding issues, there is really no point to requesting an update to a package that is scheduled for removal.
[03:15] <LaserJock> persia: one last chance to get a changelog entry? ;-)
[03:15] <persia> LaserJock: Cause for rejection of the candidate, in my book.
[03:20] <persia> Vorian: Please check your changes files.  This will be the last set of packages for which I manually add the extra characters to close the LP bugs.
[03:23] <Vorian> persia: I can do that.
[03:48] <persia> Does anyone use transmission?  Bug #180534 is likely good, but might do well with some testing.
[03:48] <ubotu> Launchpad bug 180534 in transmission "Please sync transmission_1.00-1 from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/180534
[03:56] <tuxmaniac> Good morning all. I have been struggling with this error message since yesterday night and unable to resolve the issue. http://paste.ubuntu-nl.org/50934/
[03:57] <tuxmaniac> when I try to remove the Desktop folder inside the debian directory it builds fine but fails at the creating icons stage due to the rules present.
[03:58] <tuxmaniac> When I add this directory back it fails even before building giving the above pastebinned error
[03:58] <tuxmaniac> any pointers?
[03:58] <tuxmaniac> I see that this occurs while building the diff.gz
[03:59] <ScottK> dpkg-source: unrepresentable changes to source is what is killing you
[03:59] <ScottK> You are doing something that pdkg-source thinks is changing a binary file.
[04:00] <ScottK> That'd be dpkg-source, of course
[04:01] <bddebian> Gah, I finally get my pbuilder fixed and the freakin' power runs out :(
[04:01] <persia> tuxmaniac: Could you paste debian/rules?
[04:02] <LaserJock> bddebian: bummer man
[04:03] <tuxmaniac> persia, http://paste.ubuntu-nl.org/50935/
[04:03] <tuxmaniac> bddebian, hahah
[04:03] <tuxmaniac> LaserJock, hi. Long time no see. :-) Hope you "break" was fun
[04:03] <LaserJock> heh ... something like that
[04:07] <LaserJock> wow, a long description that includes 23 lines of help/usage instructions
[04:08] <persia> tuxmaniac: From where are the .png files originating?  I don't see them.
[04:09] <tuxmaniac> persia, I dont understnad what you are asking :-( They are in a desktop folder inside debian directory
[04:09] <tuxmaniac> if thats what you want
[04:09] <persia> tuxmaniac: Does your orig.tar.gz differ from http://revu.ubuntuwire.com/revu1-incoming/alliance-0709221900/alliance_5.0.orig.tar.gz ?
[04:10] <persia> If so, does your orig.tar.gz contain a debian/ directory?
[04:11] <tuxmaniac> persia, yes
[04:11] <tuxmaniac> persia, orig does not contain debian/
[04:11] <tuxmaniac> persia, i removed it. is that wrong?
[04:12] <persia> tuxmaniac: You removed it?  Did you have to repack for other reasons (licensing, zip file, etc.)?  If not, it is wrong.
[04:12] <tuxmaniac> persia, changed some stuff and now its building fine on Hardy before I started "cleaning" up stuff :-D
[04:13] <tuxmaniac> Since this is the first package, I thought the orig should be "ditto" to src tarball and should not contain any contaminations?
[04:13] <persia> orig should be exactly the file distributed by upstream, whenever possible.  If upstream has a debian/, someone should tell them to remove it.
[04:16] <nenolod> persia, my patch worked for you as well?
[04:16] <nenolod> persia, i'm glad to hear that :)
[04:16] <persia> nenolod: Yes.  Crashes gone.  Thank you very much.  Please also forward the patch to Debian, GNOME, and the gtk maintainers.
[04:17] <nenolod> persia, yeah. i'm going to send the patch on to bugzilla.gnome.org now. thanks for testing. :)
[04:23] <LaserJock> dang it, forgot my orig.tar.gz
[04:23] <LaserJock> some days I hate packaging
[04:26] <nenolod> persia, http://bugzilla.gnome.org/show_bug.cgi?id=507605
[04:26] <ubotu> Gnome bug 507605 in recent-files "[patch] gtk_recent_files_menu_populate() does not guard properly against recursion" [Critical,Unconfirmed]
[04:26] <persia> nenolod: Be sure to register that in Malone :)
[04:27] <nenolod> persia, done
[04:28] <persia> Excellent.  I don't know if it will make hardy, but expect it soon enough.
[04:28] <nenolod> well, that patch needs to go into the gtk+ we ship in hardy, as it fixes a fairly nasty bug
[04:29] <nenolod> (not that the bug affects me anymore, mind.)
[04:30]  * nenolod sends to debian too
[04:30] <persia> nenolod: You might subscribe the main sponsors then, to request upload.
[04:30] <nenolod> persia, yep
[04:31] <crimsun> you probably want to just ping lool or slomo, then
[04:32] <crimsun> they already have an upload pending for a gdkpixbuf issue
[04:32] <crimsun> (on the Debian side)
[04:32] <Hobbsee> now, how do i get a program into the add/remove list?
[04:33] <Fujitsu> Hobbsee: gnome-app-install?
[04:33] <Hobbsee> does that just require mvo rerunning his script, or?
[04:33] <Fujitsu> That works by .desktops.
[04:33] <Hobbsee> Unlike Ubuntu Restricted Extras and Kubuntu Restricted Extras, in Gutsy Xubuntu does not have an entry in Add/Remove... for its restricted extras.
[04:33] <Fujitsu> Give you app a .desktop, and wait for mvo to rerun his script.
[04:33] <Hobbsee> none of them have desktop files!
[04:33] <persia> Hobbsee: Then you've a few packages to update :)
[04:34] <Hobbsee> persia: but..but...the other 2 are already there, and don't have .desktop files in their sources at all
[04:34] <Fujitsu> Perhaps there are some that have their .desktop's in the app-install-data source.
[04:35] <persia> Hobbsee: You might try http://people.ubuntuwire.com/~persia/generate-desktop.bash.  It's old and crufty, but leverages the debian/menu files to get some templates prepared.
[04:35] <Hobbsee> ah, yes
[04:35] <persia> Fujitsu: Quite a large number, actually :(
[04:35] <Fujitsu> persia: Urrgh. Why?
[04:36] <Hobbsee> Fujitsu: you're correct.  do i have to put x-r-e in there manually, or mvo's script picks it up?
[04:36]  * Hobbsee thought mvo had a script for that
[04:36] <persia> Fujitsu: Base pragmatism, really.  On the other hand, for things like apache, I agree with that approach, as a menu file isn't appropriate.
[04:36] <LaserJock> weird, requestsync just got totally the wrong version to sync
[04:36] <Fujitsu> Ah, perhaps.
[04:37] <Hobbsee> LaserJock: you were expecting an experimental version?
[04:37] <LaserJock> no
[04:38] <LaserJock> I was expecting 0.8.5-1 and I got 0.6.6-3
[04:38] <LaserJock> which is really ancient
[04:40] <LaserJock> hmm, do I have to have sid deb-src lines for requestsync to work right?
[04:41] <Fujitsu> As far as I know it uses rmadison.
[04:41] <persia> LaserJock: Yes.
[04:41] <LaserJock> which is it?
[04:41] <LaserJock> :-)
[04:41] <persia> I thought it used rmadison for versions, and sid deb-src for changelog.  Does it use changelogs.debian.org now?
[04:42] <Fujitsu> It has always used changelogs.d.n, AFAIK.
[04:42]  * persia uses requestsync once per release, and has yet to be satisfied
[04:42] <LaserJock> well, ok here's the thing
[04:42] <LaserJock> the changelogs it picks up are right
[04:42] <LaserJock> but in the subject text and first paragraph it get's it wrong
[04:43] <Hobbsee> right.  u-r-e finally updated
[04:43] <Hobbsee> no more bugs in it, either
[04:43] <persia> LaserJock: What does rmadison -u debian $package tell you?  I remember someone complaining about an issue where it wasn't in sync in all architectures in Debian.
[04:44] <LaserJock> ohhh
[04:44] <LaserJock> gchempaint |    0.6.6-3 |      unstable | m68k
[04:44] <LaserJock> gchempaint |    0.8.4-2 |      unstable | mips, mipsel, s390
[04:44] <LaserJock> gchempaint |    0.8.5-1 |      unstable | source, alpha, amd64, arm, hppa, i386, ia64, powerpc, sparc
[04:44] <LaserJock> is it picking up the m68k line?
[04:45] <Fujitsu> Ah, probably.
[04:45] <Fujitsu> Shouldn't it be using `-a source' or something
[04:45] <Fujitsu> *?
[04:46]  * persia continues to deprecate requestsync as relying too much on the delicate Debian infrastructure, encouraging laziness (if you're testing and building, you have the source and changelog locally), and failing to hint about requirements for syncs as each freeze passes.
[04:46] <persia> Fujitsu: Doesn't matter.  Not supported by p.qa.d.o at this time.  Kmos reported a bug, but I don't know where.
[04:46] <LaserJock> persia: I just use it to get the format right since people seem to be more picky these days
[04:48] <persia> LaserJock: Format is simple.  "Please sync $package $version ($component) from $source_dist ($component)".  Rationale section describing any dropped ubuntu variation, reason for any freeze exception, and confirming testing.  Changelog since last version imported into Ubuntu.
[04:49] <LaserJock> yeah, well I don't do syncs that often and people get irritated if you accidentally miss $component or something
[04:50] <persia> Ah.  Yes.  $component for Ubuntu is important to help determine who needs to ACK (less important for you).  $component in sync_source is important to get the right thing.
[04:51] <persia> On the other hand, the vast majority of my non-sponsored uploads are sync requests, so maybe I have a different viewpoint than others.
[04:51] <LaserJock> right but at least 99.9% of the time $source_dist ($component) is Debian unstable
[04:51] <persia> s/sponsored/sponsoring/
[04:51] <persia> LaserJock: "Debian unstable (main)", yes.
[04:52] <LaserJock> ah see ;-)
[04:54] <LaserJock> nixternal: yo homey, I finally joined your Vista army when I got my new laptop ;-)
[04:54] <nixternal> haha
[04:54] <nixternal> new lappy ey?
[04:54] <slangasek> ... "Vista army"?
[04:54] <Fujitsu> !nixternal
[04:54] <nixternal> !nixternal
[04:54] <ubotu> Oh no!  The pointy-clicky Vista lover has arrived!  He's rumoured to be giving out free money, too!
[04:54] <nixternal> hahahahahaha
[04:55] <LaserJock> nixternal: yeah
[04:55] <LaserJock> the "Cancel or Allow" thing is driving me nuts
[04:56] <LaserJock> how many dialog boxes do i have to go through just to open up a .exe
[04:56] <nixternal> no less than 2
[04:56] <ion_> Plop. A “Cancel or Allow” dialog box is about to pop up. Cancel or Allow?
[04:56] <nixternal> lol
[04:56] <persia> LaserJock: You do know that if you hadn't actually run it, you'd be eligible for a refund, right?
[04:57] <LaserJock> I don't particularly care tbh
[04:57] <LaserJock> I'll use it for some games maybe
[04:58] <slangasek> oh, so this means LaserJock is actually /running/ Vista, how odd
[04:59] <LaserJock> not at this moment
[04:59]  * nixternal boots into vista to play some call of duty 4
[04:59] <slangasek> persia: are people actually able to collect that refund these days?
[04:59] <LaserJock> but until I put Ubuntu on it I gave it a spin, haven't not seen it
[04:59] <nixternal> I did last year slangasek
[04:59] <slangasek> I have two thinkpads I wouldn't mind a refund on :)
[04:59] <nixternal> with XP
[04:59] <Fujitsu> slangasek: I've heard of people doing it recently.
[04:59] <slangasek> but in what countries?
[04:59] <nixternal> US for me
[04:59] <persia> slangasek: In some places, and from some resellers, yes.  More people pressing legal cases when the reseller ignores them would help.
[04:59] <slangasek> ok
[05:00] <slangasek> right, these are direct from Lenovo, probably not worth my effort then
[05:00] <persia> slangasek: Why not?  If you've never installed, give them a call.
[05:00] <LaserJock> how much do you get?
[05:01] <persia> LaserJock: You ran it: you're no longer eligible :(  You have to have never used the software.
[05:01] <LaserJock> persia: I know, I just wondered how much it's worth
[05:01] <slangasek> how are you supposed to prove never having run it?
[05:01] <persia> LaserJock: I think about half the cost of a retail copy.
[05:02] <persia> nixternal: Didn't you blog about it?  Do you have the archive URL handy?
[05:02] <Fujitsu> Isn't the key accepting the EULA in the OEM post-installation bit?
[05:02] <LaserJock> persia: that's not bad.
[05:02] <nixternal> don't know if I blogged about it
[05:02] <nixternal> I got $97 back
[05:04] <persia> nixternal: What evidence did you need to supply?
[05:05] <nixternal> that you said no and removed anything from the hard drive...I took it to best buy and let them verify it for me
[05:05] <nixternal> they will cancel your registration number for vista anyways, and you will know when that happens, as Vista becomes useless at that point supposedly
[05:06] <Fujitsu> I think they turned that `feature' off a while back.
[05:06] <Fujitsu> Because there were too many false-positives.
[05:06] <slangasek> well, I never said no because I never booted it into Windows before wiping it
[05:07] <slangasek> so I don't know what evidence I'd be expected to supply
[05:08] <TheMuso> slangasek: Did wiping it include the recovery partition, if any?
[05:08] <slangasek> sure
[05:08] <slangasek> I don't want Windows to ever recover
[05:08] <LaserJock> heh
[05:08] <TheMuso> Fair enough.
[05:09] <TheMuso> So you obviously don't care about what you offer to someone who you may resell it to after its lived its useful live for you?
[05:09] <TheMuso> i.e no OS to offer besides linux
[05:09] <slangasek> I've never resold a computer
[05:09] <persia> LaserJock: You forgot the Rationale section.  Why grant the freeze exception?  Does it work in hardy?
[05:09] <TheMuso> slangasek: Ah ok then.
[05:09] <slangasek> and I wouldn't do business with Windows users anyway. :)
[05:10] <LaserJock> persia: :( I just did what request sync told me
[05:10] <persia> TheMuso: I don't see how "no OS to offer besides linux" is a bad thing :p
[05:10] <LaserJock> I've never sold a computer either
[05:10] <guest22> Any MOTUs out there willing to review package photoml (http://revu.tauware.de/details.py?package=photoml)? It's already been advocated once, and the remaining (hopefully) few issues pointed out by persia have been addressed in the most recent upload.
[05:10] <LaserJock> I use them 'til they die
[05:10] <persia> LaserJock: Yes.  I know.  That's part of why I don't like requestsync.
[05:10] <TheMuso> persia: I would agree, but the sale may not be possible if people don't agree.
[05:10] <ScottK> persia: What freeze are we in?
[05:10] <LaserJock> ScottK: DIF
[05:10] <persia> ScottK: Debian import freeze
[05:11] <slangasek> anyway, if I were to resell a computer I'd market it as "own an Ubuntu laptop, as run by the release manager!"
[05:11] <LaserJock> I don't think I need a rationale for DIF, but I should say that it worked in Hardy
[05:11] <slangasek> >:)
[05:11] <persia> As I understand it, all syncs are fine as long as we don't break lots of things (like if we synced octave3.0 without deeper investigation).
[05:11] <LaserJock> sladen: heck yeah ;-)
[05:11] <LaserJock> slangasek rather
[05:11] <TheMuso> slangasek: haha
[05:12] <Fujitsu> slangasek: Heheh.
[05:14] <ScottK> persia: Doesn't that just mean it's not automatic.
[05:14] <ScottK> There's no rule that says manual actions have to be justified.
[05:15] <persia> ScottK: Not quite.  It needs an ACK from a member of ~ubuntu-dev.  I believe even members of ~ubuntu-dev should provide rationales for freeze exceptions (even if it's just "I think it's a good idea" or "I want latest upstream") just for documentation purposes.
[05:15] <persia> Non-members of ~ubuntu-dev are generally required to provide a rationale to convince a member of ~ubuntu-dev to ACK.
[05:16] <ScottK> persia: I understand you think that, but we don't have any actual process requirements to that effect do we?
[05:16]  * nenolod subscribes ubuntu-main-sponsors to bug 180463
[05:16] <ubotu> Launchpad bug 180463 in gtk+2.0 "gnome-panel crashed with SIGSEGV in idle_populate_func()" [Low,Triaged] https://launchpad.net/bugs/180463
[05:16] <LaserJock> it's basically the lowest Freeze barrier possible
[05:16] <persia> ScottK: Process requirements?  No.  There's not even a requirement for a sync request bug at this point.
[05:16] <ScottK> Personally, I think DIF is poorly named
[05:17] <ScottK> It's really just the end of autosync
[05:17] <persia> Especially for an LTS, I think we should really be considering updated applications to make sure they don't break things.  sid is rough sometimes.
[05:19] <persia> Maybe.  Our release manager noted that any further syncs would be "Freeze Exceptions" when announcing DIF.
[05:20] <LaserJock> that's quite odd, IMO
[05:21]  * persia points at https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-December/000359.html
[05:21] <ScottK> Fortunately for me, I haven't been warned by the MC not to do anything, so I can do whatever I want as we've established that one must be warned before being kicked out now.
[05:22] <LaserJock> ScottK: ;p
[05:22] <Fujitsu> LucidFox: Can you please avoid touching sync bugs that are filed by MOTU? It creates unnecessary spam, and isn't particularly useful.
[05:22] <persia> ScottK: You're a member of ~ubuntu-dev.  By my proposed freeze exception process (ACK'd by a release manager), you can sync whatever you want.
[05:22] <LaserJock> persia: yes, that was, IMO, a bit unfortunate
[05:23] <ScottK> persia: The MOTU process for deciding process isn't go ask an RM.
[05:23] <persia> LaserJock: Why?  Would you prefer a more restrictive freeze exception process?
[05:23] <persia> ScottK: Right, which is why my proposed freeze exception process isn't policy.
[05:23] <slangasek> persia: which should have read "merging packages that haven't yet been merged for hardy is a freeze exception", mumble 3am mails
[05:23] <LaserJock> persia: we've *never* had such a freeze
[05:23] <LucidFox> Fujitsu> How do I know if it's filed by a MOTU?
[05:24] <persia> LaserJock: Right.  Blame email sent at 3am :)
[05:24] <ScottK> persia: Please let's stop inventing more freezes and reviews
[05:24] <LaserJock> DIF has always been "no more autosyncs"
[05:24] <persia> ScottK: I didn't.  I don't seek to do so.  Even aside from all that, I still think Rationale is good practice.
[05:24] <slangasek> wasn't there a follow-up mail in there somewhere that said "yes, it's an exception to the freeze; anyone with the corresponding upload rights is still allowed to use their own judgement"?
[05:24] <LaserJock> we've never had to file exceptions before UVF
[05:24] <Fujitsu> LucidFox: If they've confirmed it themselves, they're probably a MOTU. If in doubt, click on their name and check, or get the Greasemonkey script that displays karma and related emblems.
[05:25] <LucidFox> All right.
[05:25] <slangasek> LaserJock: it was never intended that the exceptions should need to get filed anywhere special
[05:25] <persia> slangasek: Yes.  That was my proposed freeze exception process.
[05:25] <LaserJock> DIF is poorly named, as it isn't a freeze really
[05:29] <guest22> persia: Could you please take a look over the new upload of photoml to make sure all of your concerns have been addressed? While you mentioned that you preferred not to officially review it again, it would be good to know whether one of the pickier MOTUs considers it acceptable so that I can address any remaining issues ASAP.
[05:30] <persia> guest22: My memory is that you fixed a couple niggles, and were planning to fix the rest upstream for the next release.  I'm likely happy.
[05:30] <LaserJock> slangasek: well, a 0 barrier freeze is what's confusing about the DIF stuff, IMO
[05:31] <LaserJock> we're saying "We are now in a Freeze and require exceptions, but exceptions are doing what you already do"
[05:31]  * persia agrees with Laserjock, despite having a preference for stability and rationale
[05:32] <LaserJock> persia: I would tend to think that that should be a general requirement ..
[05:32]  * ScottK will forgo the usual rant on increased bureacracy in Ubuntu as it's just to painful.
[05:32] <persia> ScottK: What rant?  Do you not agree with LaserJock?
[05:33] <LaserJock> ScottK: well, tbh, it's only perceived increased bureaucracy. DIF has no practical consequences
[05:33] <guest22> persia: Yes, that seems like a reasonable summary. When I uploaded the package addressing the issues you raised, the single advocacy was zeroed out, and the package dropped out of the lost of those close to being ready for acceptance. Any advice on how to request someone else to take a look at it for another review?
[05:33] <ScottK> persia: I absolutely agree with laserjock.  I think your proposals are entirely off base and unnecessary.
[05:34] <ScottK> I think that's agreeing with laserjock.
[05:34] <ScottK> DIF just means that autosyncs don't happen anymore.
[05:35] <persia> ScottK: My proposal was a workaround for the announced freeze.  It basically means "keep doing whatever you want".  I don't understand how that is bad, nor why you complain to me rather than the person who announced the freeze (who has publically retracted any requirements for the freeze).
[05:36] <ScottK> OK.  Well I guess I didn't read his mail as changing policy and I misread your proposal as imposing additional requirements.  Sorry about that.
[05:36] <slangasek> well, the one requirement is "syncs are now manual, so have to be filed as requests for ubuntu-archive to act"; so they are exceptions, but not intended to be any more burdensome or bureaucratic than before
[05:37] <persia> ScottK: OK.  That makes more sense.  I in no way wanted to add additional requirements, rather the opposite.
[05:37]  * Hobbsee thinks that by the time people have hit MOTU, they should have a fucking clue, and not screw up, and need all the freezes.
[05:37] <Hobbsee> honestly.
[05:37] <Hobbsee> well, all the documentation as to why they're putting something through all the freezes
[05:38] <persia> Hobbsee: Freezes are a good thing.  Annoying exception processes are not.  Announced freezes help us focus on the things that need doing: first catch up with Debian & upstream, then settle and integrate everything, then fix as many bugs as we can.
[05:38] <Hobbsee> exactly.  freezes good, but having to justify every single change for everything == bad.
[05:38] <Hobbsee> you're a MOTU.  you've been doing that previously, and so are therefore good at it.
[05:38] <Hobbsee> why continue, unless someone raises a complaint against you to the MC?
[05:39] <ScottK> Of cource I've done 3 Main Inclusion Reports today, so I mail feel Ubuntu is more bureaucratic than usual right now.
[05:39] <persia> I agree to that, although I personally like Rationale just so people can see what I was thinking without asking me when they wonder why some package was synced.
[05:39] <ScottK> cource/course
[05:40] <LaserJock> slangasek: right, I think the confusion was that that was what we've always been doing, but with out the "exception" which has the bureaucratic "needs sign-off by somebody" connotation
[05:44] <LaserJock> I think the policing vs freedom/responsibility is an interesting one and is a "growing pain" we're gonna have to address
[05:45]  * Hobbsee suggests only allowing competent people to become MOTU's, and everyone else still gets everything policed anyway.
[05:45] <Fujitsu> Hobbsee: That sounds ideal.
[05:45] <LaserJock> well, I'm not sure the answer can be that straightforward
[05:46] <ScottK> Hobbsee: That wouldn't be fair to the incompetent people.
[05:46] <Hobbsee> unless you want all MOTU's to be watching everyone else, round-robin style
[05:46] <Hobbsee> ScottK: heh, why?
[05:46] <ScottK> Because you deny them their god given right to be a MOTU
[05:46] <LaserJock> the problem is that when we become large enough it becomes increasingly difficult to determine "competent" without getting into the "policing" stuff
[05:47]  * Hobbsee gives ScottK the bott
[05:47] <Hobbsee> er, boot
[05:47] <Hobbsee> LaserJock: if competence is determined when they each become MOTU
[05:47] <LaserJock> Hobbsee: still
[05:47]  * persia notes that we're already too large to know each other properly, so policing has become required (unfortunately).
[05:47] <Hobbsee> LaserJock: and if theres' a process to say "hey, someone's noticed errors in your work.  lets put you under surveilance"
[05:48] <Hobbsee> LaserJock: of course, that doesn't stop the "good person, gone bad as they got lazy" problem
[05:48] <LaserJock> you have to either trust people to vouch, have first hand-experience, or require some "test"
[05:48] <Hobbsee> sure, but that appears to be working reasonably well lately, i think
[05:48] <LaserJock> the first 2 become hard with a large group
[05:48] <Hobbsee> true
[05:48] <ScottK> Then you need a way to deal with mistakes
[05:48] <LaserJock> the last is what everybody wants to avoid
[05:48] <persia> And a means of censure for continued mistakes
[05:48] <Hobbsee> ScottK: which was the other thing i proposed, yes.
[05:48] <Hobbsee> "hey, someone's noticed errors in your work.  lets put you under surveilance"
[05:49] <Hobbsee> which is made even easier, as you can just look thru changes mails
[05:49] <Hobbsee> and bugs relating to them
[05:49] <Fujitsu> Soyuz is even growing an automatic debdiff feature next release, to make it easier.
[05:49] <Hobbsee> really?  nice!
[05:50] <persia> How will "automatic debdiff" work for differing orig.tar.gz?  Just lots of output?  What about changed icons?
[05:50] <Hobbsee> persia: it won't.
[05:50] <ScottK> Of course pointing out problems isn't "Nice" and so that's to be avoided.
[05:51] <Hobbsee> ScottK: when people are consistently screwing up, nice goes out the window anyway, at least to some extent
[05:51] <persia> ScottK: How is pointing out problems to be avoided?  Raising problematic issues is important.
[05:51] <Fujitsu> ScottK: This is unfortunately generally implicit in a volunteer community.
[05:53] <ScottK> It's my perception that is someone is causing problems, people who try and get some attention on the matter get pretty thoroughly blown off until they get extraordinarily pointed about it.
[05:54] <persia> ScottK: I think that the recent experience with that was a growing pain, and now that we have established a process, it will be less painful in the future.
[05:55] <Hobbsee> ScottK: if peple actually have access to the archvie, too, it automatically becomes a bigger priority
[05:55] <ScottK> persia: I hope you are correct.  I'm not convinced
[05:56] <Hobbsee> launchpad can be ignored, to an extent
[05:56] <Hobbsee> ScottK: so, smash the MC with a hammer the next time it happens.
[05:56] <persia> ScottK: I also hope I am correct.  We'll see in about 10 days.
[05:56] <ScottK> Hobbsee: Agreed in theory.  Such people also have more to lose and I can see people being more careful not to take away greater privileges.
[05:56] <Hobbsee> and if not, by the end of the month....
[05:56] <Hobbsee> ScottK: yes, that's a point.
[05:57] <Hobbsee> ScottK: but is it really taking away more?
[05:57] <Hobbsee> it's being shoved back to reviews and such, but it's not being asked to leave
[05:57]  * Hobbsee checks that her pitchforks and torches are all in good working order
[05:57] <ScottK> Sure, but I suspect that's how people will view it.
[05:58] <ScottK> Right.  That's the additional problem is that pitchforks and torches becomes the only way to deal with problematic people.
[05:58] <Fujitsu> ScottK: No, the MC deal swiftly with problematic people, as we've seen.
[05:58]  * persia thinks moving core-dev to MOTU or moving MOTU to Contributor for consistent poor quality control can be done in an encouraging manner.
[05:58] <Hobbsee> Fujitsu: surely you lie.
[05:59] <Hobbsee> persia: assuming those in power have the guts to do it, yes
[05:59] <persia> Hobbsee: That's a different issue, but yes.
[06:00] <ScottK> Given that there are people ON the MC who think testing SRU candidates before upload is optional, I don't hold out a lot of hope.
[06:00] <persia> If there is a current MOTU with consistent poor quality, who has failed to respond to peer pressure, consider requesting MC to monitor activities for some time, and possibly ask to become Contributor.  If there isn't such a person, it's entirely theoretical, and doesn't matter as much (although I'd prefer to have a policy in place prior to a test case, personally).
[06:09] <LucidFox> persia> All builds that depend on libfaac-dev seem to fail right now, so I'd wait until jdong or someone else uploads mpeg4ip and completes the libmp4v2 transition
[06:10] <persia> LucidFox: sounds sane to me.  Just doesn't belong in UUS until then (as UUS is roughly equivalent to dput, except with extra review).
[06:18] <ScottK> That's 4 MIRs done today.
[06:32] <LaserJock> man, I always find it interesting when people triage my bugs
[06:32] <ScottK> Heh.
[06:33] <LaserJock> apparently my sync request was supposed to be "Triaged" and "Wishlist"
[06:34] <LaserJock> so I had missing rationale, and bad status/importance
[06:34]  * LaserJock goes to find a paper bag
[06:37] <persia> LaserJock: Triagers shouldn't be triaging sync bugs from members of ~ubuntu-dev.  On the other hand, we should have a button we can press for a sync, with a small box to add a note.
[06:51]  * ScottK gets well into MIR #5.  Discovers it has a universe build-dep (raising the total requirement from 7 to 8), gets frustrated, quits, and goes to bed.
[06:52] <Fujitsu> Night ScottK.
[06:52] <ScottK> Good night.
[07:00] <Hobbsee> LaserJock: i've been trying to discourage that for a while, yes.
[07:00]  * Hobbsee thinks tha'ts a lartable offense
[07:00] <Hobbsee> also, it would be nice to display karma values and icons of everyone by default.
[07:02] <LaserJock> heh
[07:02] <LaserJock> what if we could -5 somebodies karma? :-)
[07:02] <Hobbsee> hehe
[07:04] <Hobbsee> LaserJock: who was it/
[09:40] <ChrisGibbs> Hobbsee gone for the night?
[09:41] <DarkMageZ_> it's only 8:40ish over there. probably not.
[10:02] <persia> 17 Candidates up this week, and 72 packages needing work.
[10:03] <minghua> Hmm, REVU day again.
[10:04]  * minghua is always caught off-guard. :-)
[10:04] <ion_> persia: Re: your comments about bumping version to 0.0.2: i had already tagged and released 0.0.1, and after it i was told it would be a good idea to add licensing information to the man pages as well, so i did that and released 0.0.2. I’ll take care of the copyright years and the install target whenever i touch the software/package the next time.
[10:04] <persia> ion_: OK.  No rush.
[10:07] <ion_> persia: Btw, what’s the progress with apt-mark-sync? Should i receive an email when an archive admin approves/disapproves it?
[10:07] <ion_> Also, should i request an archive admin to take a look at it, or just wait patiently?
[10:08] <persia> ion_: Usually you'd get an email from the rejecting archive admin if it was rejected, and an Accepted message from the archive itself if it is accepted.  Better not to bother them.
[10:08] <ion_> All right, thanks.
[10:10] <white> ion_: patience is a virtue :)
[10:10] <white> . o O(one i do not possess)
[10:11] <ion_> white: I have no problem with waiting, especially since that package is a very low-priority one. I was just wondering what’s the standard procedure. :-)
[10:15] <ion_> If i update the packaging of something already in Ubuntu to a new upstream release (e.g. atool to account for LP #94239), should it go through REVU?
[10:15] <ubotu> Launchpad bug 94239 in atool "Current version may cause files to be deleted inadvertently" [Undecided,New] https://launchpad.net/bugs/94239
[10:18] <minghua> ion_: It's okay to use REVU if there's a new upstream version.  But a bug should also be opened and noted in REVU comments.
[10:18] <ion_> Ok, thanks.
[10:19] <minghua> ion_: For definitive answers, consult persia. :-)
[10:23] <amarillion> Hello
[10:23] <amarillion> I just created a new ubuntu package
[10:24] <amarillion> I'd like to request a review
[10:31] <Hobbsee> ChrisGibbs: no
[10:31] <nenolod> good morning.
[10:31] <minghua> amarillion: Where is the package?
[10:31] <nenolod> amarillion, is it on revu?
[10:31] <ChrisGibbs> Hobbsee: lol
[10:32] <amarillion> I just dput'ed it on revu
[10:32] <amarillion> It's called "speed"
[10:32] <amarillion> I don't see it there yet
[10:32] <nenolod> amarillion, also, you should consider contributing to debian
[10:32] <nenolod> amarillion, yeah. revu cron doesn't run for another 2-3 minutes ;)
[10:32] <amarillion> ah ok
[10:32] <amarillion> sure, but one step at the time :)
[10:32] <ChrisGibbs> Hobbsee: What is the deal with Wednesday? I followed the instructions for gpg and registered it with my launchpad account.
[10:33] <Hobbsee> nenolod: uh, you can't confirm sync bugs - you're not a MOTU
[10:33] <nenolod> Hobbsee, oops.
[10:33] <nenolod> Hobbsee, sorry about that.
[10:33] <nenolod> Hobbsee, i was half asleep.
[10:34] <nenolod> Hobbsee, would you like me to fix the one where i accidentally marked it confirmed?
[10:34] <Hobbsee> nah
[10:34] <nenolod> it's transmission, right?
[10:34] <Hobbsee> yes
[10:35] <nenolod> someone once told me i should mark something as confirmed, so being half asleep i thought it was sync bugs ;)
[10:38] <persia> nenolod: Current best practice is listed at https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue: "Confirmed" for upload candidates, and "New" for approval requests.
[10:39] <nenolod> persia, thanks. i'll memorize it ;)
[10:39]  * persia wonders why it says "Incomplete" for sync requests, and thinks that might not be ideal
[10:46] <nenolod> ok, New for sync, Confirmed for debdiff.
[10:46] <nenolod> got it. ;p
[10:52] <TheMuso> Hobbsee: Re that ubuntu-dev-tools bug, I'm on it. I've fixed it in trunk, but nobody has uploaded a release for ages, so will do that now.
[10:53] <Hobbsee> TheMuso: ahhh.  want me to release it?
[10:53]  * Hobbsee has it here
[10:53] <TheMuso> Hobbsee: I'm doing that now.
[10:54] <Hobbsee> TheMuso: OK
[10:57] <TheMuso> done.
[10:57] <jpatrick> persia: why can't we have NMU versions for ubuntu-specific packs?
[10:58] <Hobbsee> jpatrick: no more u-r-e bugs now, btw :D
[10:58] <jpatrick> Hobbsee: how did you do the flash one?
[10:58] <jpatrick> aha
[10:58] <Hobbsee> jpatrick: duped it.
[10:59] <RainCT> TheMuso: hi. have you already uploaded the new u-d-t version?
[10:59] <jpatrick> Hobbsee: great
[10:59] <TheMuso> RainCT: Yes.
[11:00] <Hobbsee> jpatrick: therefore, not my problem.
[11:00] <Hobbsee> hum.  my flash is obviously coming from somewhere.  probably something autoinstalled.
[11:03] <Hobbsee> badger badger badger badger MUSHROOM MUSHROOM!
[11:04]  * jpatrick 's flash as always worked fine
[11:04] <ion_> Oh! A snake. :-\
[11:07] <nenolod> Hobbsee, that flash still exists?
[11:08] <Hobbsee> oh yes
[11:08]  * Hobbsee uses it to test that her flash is working
[11:08] <white> Hobbsee: hungry
[11:11] <jpatrick> Hobbsee: can you upload http://people.ubuntuwire.com/~jpatrick/kmplayer/ for me?
[11:11] <jpatrick> If so you'll need to -sa it - has Debian tar.gz
[11:17] <amarillion> Oh, I just read this: "Next, ask the REVU admins in #ubuntu-motu to re-sync the REVU uploaders keyring, which grants you upload rights to REVU"
[11:17] <amarillion> This may explain why my package isn't there yet
[11:17] <amarillion> so... could somebody re-sync the key ring?
[11:18] <persia> amarillion: Sure.  Takes a little bit.  I'll let you know when it's done.
[11:18] <amarillion> Ok, thanks persia
[11:19] <amarillion> Signing up for the "contributors of packages for the universe team" is all I need to do on my side, right?
[11:19] <nenolod> amarillion, yes
[11:19] <persia> amarillion: And upload a key to LP.  Both of these are already complete, right?
[11:19] <nenolod> oops
[11:19] <amarillion> yes, I do have a key on LP already.
[11:19] <nenolod> yeah, i assumed he had a key in LP ;)
[11:20] <amarillion> I've used in the past for ppa
[11:20] <nenolod> amarillion, GPG or SSH? :P
[11:20] <nenolod> ah. GPG.
[11:20] <amarillion> right, GPG
[11:20] <stgraber> If someone has some time, please review http://revu.tauware.de/details.py?package=libfprint (two other packages will be uploaded depending on this one)
[11:23] <nenolod> stgraber, debian/control doesn't have Homepage: field.
[11:23] <nenolod> stgraber, it is considered a best practice to include one.
[11:23]  * persia thinks that's only true when upstream has a reasonable homepage (although the specific package hasn't been checked)
[11:24] <nenolod> stgraber, debian/copyright points at GPL, it should probably point at GPL2 instead.
[11:25] <nenolod> other than that, i don't see anything blazingly wrong with it
[11:26] <nenolod> and what i mentioned is more nitpicking than actual fatal problems
[11:26] <nenolod> oh
[11:27] <nenolod> stgraber, you're missing a watch file too. it's generally best practice to include one.
[11:28] <nenolod> oh.
[11:28] <nenolod> oh oh oh.
[11:28] <nenolod> stgraber, problem
[11:28] <stgraber> ah ?
[11:28] <nenolod> stgraber, http://www.reactivated.net/fprint/wiki/Libfprint says LGPL-2.1, your debian/copyright says it's GPL2.
[11:28] <stgraber> oops
[11:28] <nenolod> so do all of the above :D
[11:29] <stgraber> ok, got to go for a while, will fix all that a bit later
[11:29] <nenolod> stgraber, as for debian/watch, http://sf.net/project/libfprint-(.*)\.tar\.bz2 should do
[11:29] <nenolod> (be sure to put version=3 above that line)
[11:29] <nenolod> er.
[11:29] <nenolod> project/fprint
[11:42] <persia> amarillion: Keysync all done.  You should be OK now.
[11:42] <amarillion> Shoud I dput my package again? I never got an email about it
[11:43] <persia> amarillion: You wouldn't get email.  What is the package name?
[11:43] <amarillion> speed
[11:43] <amarillion> speed_1.00-0ubuntu1~ppa4 with version numbers
[11:44] <persia> amarillion: You could try.  If it fails, you might need someone to delete it from the upload directory (I am unable to do so).  Also, you don't want to use a ppa version for a REVU upload.
[11:45] <amarillion> ok. Does it matter that I clutter the changelog with these tiny changes
[11:45] <amarillion> ?
[11:45] <nenolod> amarillion, temporarily no.
[11:46] <nenolod> amarillion, the final upload you will want to fix the changelog to just be the initial release entry
[11:46] <persia> amarillion: Wiping the changelog is often one of the first requests when new packages go to REVU.  Also, the changelog should only have end-user interesting information (which includes significant changes, but not little things, especially for the initial upload).
[11:47] <amarillion> Ok, so I'll worry about that later
[11:47] <nenolod> amarillion, basically, if you find editing debian/changelog to be useful to you while creating the initial package, go ahead and do it, but clean it up when it's ready to go into ubuntu
[11:48] <amarillion> Ok, I was wondering about the name of the package.
[11:48] <amarillion> It's a tiny little game that was named "speed" by the original author
[11:48] <amarillion> It has a single binary which is also named speed
[11:48] <amarillion> I'm worried about potential name clashes. Maybe it's better to name it e.g. "speed-game"?
[11:49] <nenolod> probably.
[11:49] <persia> amarillion: To be safe you might.  Saves issues like those help by the current Debian epiphany maintainer, who is under considerable pressure to change the package name.
[11:49] <persia> s/help/experienced/
[11:50] <amarillion> epiphany isn't that generic is it?
[11:50] <persia> amarillion: There's this browser you see, that people think should be called epiphany.
[11:50] <nenolod> haha
[11:50] <nenolod> amarillion didn't know about that
[11:51] <amarillion> Well, I suddenly had an epiphany :)
[11:51] <nenolod> amarillion, epiphany in debian/ubuntu is a game
[11:51] <nenolod> o_O
[11:51] <amarillion> Yeah I get it now :) Ok, speed-game it is then
[11:51] <nenolod> persia, Ganneff is the maintainer of src:epiphany? i didn't know that. :)
[11:52] <persia> nenolod: Don't know that nick, but the "Maintainer" is mostly a sponsor for the primary uploader, who is also the primary responder to bug reports.
[11:52] <nenolod> persia, Ganneff = Joerg Jaspert
[11:53] <persia> nenolod: Then, in name only.
[11:53] <nenolod> he's one of the ftp-masters
[11:54] <persia> (and my favorite, for the agressive removal activities)
[11:57] <minghua> I think Joerg is ftp-master assistant, but it's not really important.
[11:58] <Fujitsu> Joerg does a tonne of removals, and is to be liked for that, at least.
[11:58] <Fujitsu> Oh, I see persia already brought that up :(
[11:59] <persia> Fujitsu: Why unhappy?  Consensus is good, no?
[11:59]  * minghua likes Joerg for his processing NEW queue.
[11:59] <Fujitsu> persia: I guess so!
[11:59]  * minghua remembers that persia likes people agreeing with him.
[12:01] <Fujitsu> Don't most, minghua?
[12:01]  * nenolod is still in awe at how much firefox-3.0 doesn't suck
[12:02] <minghua> Fujitsu: Yes, but somehow persia seems different to me.  Probably because he explicitly says it. :-)
[12:02] <Fujitsu> nenolod: As am I.
[12:02] <nenolod> i must be dreaming
[12:02] <Fujitsu> It's so much better.
[12:02] <nenolod> quick, someone shoot at their monitor so i wake up
[12:02] <RAOF> Heh.
[12:03] <nenolod> (i've actually had dreams where i was packaging stuff or working on code. it's scary.)
[12:03]  * ion_ recalls the video where the Russian guy shoots arrows at a TFT screen.
[12:03] <nenolod> ion_, that's an interesting way to play WoW.
[12:04]  * persia likes that video, but thought it was a Ukrainian tech show.
[12:04] <nenolod> is it on youtube?
[12:04] <ion_> s/Russian/Cyrillic-writing/ :-P
[12:04] <persia> Should be if it wasn't before.
[12:09] <nenolod> Persia: is this it? http://www.youtube.com/watch?v=seRWMd7tNAo
[12:10] <persia> nenolod: Yes.
[12:11] <nenolod> persia, that monitor is indestructible
[12:11] <nenolod> that scares me.
[12:11] <persia> Nah.  Just shoot it in the back.
[12:11] <nenolod> haha, good point
[12:13] <minghua> persia 1 : monitor 0
[12:13]  * persia is good at breaking things :)
[12:14] <nenolod> they should make windows (the see-through kind) out of that material though
[12:15] <minghua> I'm sure bullet-proof windows use similar materials/techniques.
[12:15] <persia> nenolod: They do, but sapphire gets expensive quickly.
[12:15] <nenolod> that monitor surface is sapphire?
[12:18] <minghua> nenolod: I believe so.
[12:18] <nenolod> that must be one expensive monitor
[12:23] <persia> nenolod: I can't seem to find the reference that told me that before, but that was what I remember.
[12:44] <RAOF> Awww!  Why won't C# allow me to monkey patch a property into a class and have it work seamlessly.  Stupid compile-time checks :(
[13:00] <persia> stgraber: "See above" no longer means "GPL".  Might be worth a quick re-upload to include an extra 'L'.
[13:01] <persia> Then again, it might be worth addressing some of the other REVU comments :)
[13:01] <amarillion> Yay, my package is on REVU
[13:01] <amarillion> http://revu.tauware.de/details.py?package=speed-game
[13:03] <liri> can 'install' be used to copy directories somehow? it seems to error out with 'omitting directory' and the manpage doesn't cover any directory copy arguments
[13:03] <persia> liri: man install talks about -d
[13:03] <liri> I have given that a try though it didn't succeed
[13:04] <persia> Maybe you need -D?
[13:04] <liri> I'll give it another go
[13:05] <minghua> Most of the time you should use dh_install than plain install, IMHO.
[13:06]  * persia wonders if there is something like strace that tracks files touched
[13:08] <minghua> persia: I think grepping "open()" in strace output would be an alternative solution.
[13:08] <persia> minghua: That's what I'm doing, but it somehow doesn't seem as clean.
[13:10] <amarillion> If there is a reviewer with some spare time around, please take a look at http://revu.tauware.de/details.py?package=speed-game
[13:10] <amarillion> please be gentle, it's my first :)
[13:12] <liri> minghua: right, dh_install works much better, thanks :)
[13:16] <liri> what about permissions and ownership though?
[13:17] <persia> amarillion: I don't have time for a full review right now, but a quick look tells me 1) close a bug with the initial release, 2) target hardy rather than gutsy, 3) lexgrog is unhappy with the manpages, and you want \- and \)hy rather than '-', 4) You should add a watch file.
[13:17] <persia> liri: dh_install tends to do the right thing.  Generally 644 or 755 root root.
[13:18] <persia> You may need dh_fixperms afterwards, just in case.
[13:18] <liri> persia: alright I'll check it after the build to see what permission it set
[13:19] <\sh> moins
[13:19] <\sh> guys...I just have a serious problem after upgrading a server with softraid1 and swap spaces on two different drives
[13:19] <\sh> the upgrade path was dapper -> edgy -> feisty -> gutsy
[13:20] <\sh> when I'm trying to do an swapon -a -e it tells me that /dev/sdaX and /dev/sdbX (which are the correct swap partitions) are invalid arguments
[13:22] <amarillion> persia: thanks, regarding no 4: it's unlikely there will be a new version as the original author hasn't updated since 1999, and if he does, I can't predict where it will be
[13:22] <\sh> did anyone see this behaviour ?
[13:22] <Nafallo> anyone has anything to say about Maxtor Atlas 15K II?
[13:23] <persia> amarillion: OK.  Best to document that somewhere (maybe README.Debian), as the lack of a watch file is considered a bug.  Might be worth taking over upstream, if you have an interest, and the original author doesn't.
[13:23] <\sh> Nafallo: you need a good cooling device in your chassy
[13:23] <mok0> \sh: no. I always make a 5G swap when installing
[13:23] <stgraber> persia: yes, I'm working on it. You say : "Please close a bug with the initial upload", though the bug on LP is about the whole package set (3 packages), is it OK to close it once the 3rd is uploaded ?
[13:23] <\sh> mok0: well, this is not the problem...but the setup is 1G for /dev/sda2 and /dev/sdb2 because the other parts are md devices
[13:24] <\sh> mok0: so reading the kernel documentation you can set a priority..but somehow after upgrading from dapper to edgy this didn't work
[13:24] <\sh> but the swap devices are working from a rescue (ramdisk) system perfectly
[13:24] <mok0> \sh: did you try putting those two partitions in /etc/fstab?
[13:24] <persia> stgraber: There ought be multiple tasks for that, which might get created properly by multiple closures in different packages.  Anyway, no harm to close it multiple times in case Malone can't handle it.
[13:25] <\sh> mok0: they are in fstab yeah
[13:26] <\sh> mok0:
[13:26] <\sh> # /dev/sda2 -- converted during upgrade to edgy
[13:26] <\sh> UUID=55c43374-ffec-45e2-9619-eea625b60ea6 pri=1 swap sw 0 0
[13:26] <\sh> # /dev/sdb2 -- converted during upgrade to edgy
[13:26] <\sh> UUID=0850f1bb-f8b0-452e-a69f-1af860967b93 pri=1 swap sw 0 0
[13:26] <Nafallo> \sh: http://www.maplin.co.uk/module.aspx?ModuleNo=37866&doy=6m1 <-- something like that?
[13:26] <mok0> \sh: then you should be able to do swapon -a
[13:26] <\sh> Nafallo: yepp :)
[13:27] <\sh> mok0: well, I should...but it doesn't work
[13:27] <\sh> mok0: the error messages tells me:
[13:27] <\sh> # /dev/sda2 -- converted during upgrade to edgy
[13:27] <\sh> UUID=55c43374-ffec-45e2-9619-eea625b60ea6 pri=1 swap sw 0 0
[13:27] <\sh> # /dev/sdb2 -- converted during upgrade to edgy
[13:27] <\sh> UUID=0850f1bb-f8b0-452e-a69f-1af860967b93 pri=1 swap sw 0 0
[13:27] <bluekuja> persia, what happened to the FTBFS qa page?
[13:27] <\sh> damn
[13:27] <\sh> the error message is:
[13:27] <\sh> root@h1337311:~# swapon -a -e
[13:27] <\sh> swapon: /dev/sda2: Invalid argument
[13:27] <\sh> swapon: /dev/sdb2: Invalid argument
[13:27] <persia> bluekuja: http://qa.ubuntuwire.com/ftbfs/?
[13:27] <mok0> \sh: is the partition id correct?
[13:27] <bluekuja> persia, yes
[13:28] <bluekuja> persia, better to say, why all those packages are waiting another package?
[13:28] <\sh> mok0: sure it is 82
[13:28]  * persia doesn't know
[13:28] <bluekuja> persia, look at the build logs
[13:29] <\sh> Nafallo: http://www.alternate.de/html/product/details.html?articleId=176681 is good for three of them :)
[13:29] <bluekuja> persia, something went wrong with the buildds
[13:29] <mok0> \sh: sda2 and sdb2 are not mounted i take it
[13:30] <\sh> mok0: dude, I'm not stupid :) I know what to do ... but I think it's more a problem of the upgrade
[13:30] <mok0> \sh: just checking :-)
[13:30] <frenchy> If I'm writing an application and I want to make a variable changeable by a maintainer (of a different distro) then what's the best way to do this?  I figure you guys have to do this a bit.
[13:30] <Nafallo> \sh: I only got an offer on one ;-)
[13:31] <mok0> \sw: so you _did_ run mkswap
[13:31] <\sh> mok0: the thing is, using the swap parts in a rescue system works perfectly...but not on the production gutsy...since edgy
[13:31] <frenchy> Is it common for you guys to ./configure CXXFLAGS="-DBLAH=BLAH"?
[13:32] <\sh> mok0: I made everything to get the swap parts running yes...it's only on the production system...and I wonder if it's not a problem in ubuntu
[13:32] <mok0> \sh: I doubt it
[13:32] <mok0> \sh: some stupid little thing probably
[13:33] <\sh> mok0: another problem could be, that something went wrong during upgrade from dapper to edgy regarding the whole mdadm stuff...because sda1/sdb1 are md0 and sda3/sdb3 are md1 and the only parts which are not md parts are sda2/sdb2 marked as swap
[13:33] <mok0> \sh: so, just to understand, you had the same system running before the upgrade, and it worked?
[13:34] <mok0> \sh: a config file got overwritten?
[13:34] <persia> bluekuja: The samples I looked at all have different missing packages, so I doubt it's something systemic (especially as I encountered a transient issue locally earlier today).  On the other hand, I don't understand why there aren't any FTBFS packages listed.  Last time I looked there was still over 800.
[13:35] <mok0> \sh: perhaps mdadm.conf?
[13:35] <bluekuja> persia, yeah, every FTBFS seems to be disappeared now and we have only that missing packages issue in all archs
[13:35]  * persia also thinks "Needs Building" looks strangely light
[13:36] <persia> geser: Any ideas?
[13:36] <bluekuja> persia, we have failed to upload + missing packages only
[13:36] <mok0> \sh: sorry for asking stupid questions, but I often find that it helps people find the problem.
[13:37] <\sh> mok0: dapper worked as base install perfectly
[13:37] <frenchy> Maybe I'll ask later ... looks like you got a big-budda-boom.
[13:37] <\sh> mok0: the mdadm.conf is updated correctly...the swap partitions were never in mdadm.conf ... the kernel can pick up two swap devices perfectly...and it's better not to do a raid0 or raid1 for swap parts
[13:37] <persia> bluekuja: Which, yes, doesn't provide for a nice worklist.  Perhaps http://people.ubuntuwire.com/~dktrkranz/NBS/ can give you some tasks in the meantime?
[13:38] <\sh> mok0: the raid devices are running perfectly :)
[13:38] <mok0> frenchy: you can do it if no configure options are given by the developer
[13:38] <DktrKranz> is someone is intrested in some FTBFS, there is http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=qa-ftbfs-dash;users=debian-qa@lists.debian.org
[13:38] <mok0> \sh: how much memory have you got?
[13:38] <persia> frenchy: Have the upstream Makefile expect to be passed the variable, or use an option to configure.  If you go with the former, assign a sane default if none is provided.
[13:38] <bluekuja> persia, yep, gonna move to the NBS page in the meantime then^^
[13:39] <bluekuja> DktrKranz, nice one
[13:39] <frenchy> persia: mok0: Thanks, I have a #ifndef ... #endif around it.
[13:39] <\sh> mok0: 1G...so I need the swap space ;)
[13:39] <mok0> \sh: ugh
[13:39]  * persia is amused at the FTBFS wontfix bug for nn.
[13:39] <frenchy> i.e. I set a default.  But other distros need different paths.
[13:39] <\sh> mok0: btw..one of the commentors on http://www.debianadmin.com/ubuntu-edgy-upgrade-common-problems-with-solutions.html has the same problem ... no swap space after upgrade from dapper to edgy
[13:39] <DktrKranz> bluekuja, these one surely affects us, so coordinating with debian and provide patches will surely help
[13:39] <Nafallo> £100 to get an additional 154GB in my server :-P
[13:40] <persia> \sh: Common cause of that was the UUID shift, but should be able to be overridden by the mechanisms you've listed above.
[13:40] <bluekuja> persia, the page you linked me got an error in the title (e.g pacakges)
[13:40] <bluekuja> DktrKranz, yep, agreed
[13:40] <persia> DktrKranz: ^^
[13:41] <mok0> \me looks
[13:41] <\sh> mok0: http://ubuntuforums.org/archive/index.php/t-324969.html -> same problems...
[13:42] <stgraber> persia: http://revu.tauware.de/details.py?upid=1162 I think I fixed everything
[13:44] <mok0> \sh: in that ubuntuforums posting the problem was solved by running mkswap
[13:44] <\sh> mok0: well yeah but mkswap tells me the same "invalid argument"
[13:44] <\sh> mok0: or "device or resource is busy"...
[13:45] <\sh> mok0: I do now the old style: /dev/sda2 etc..in fstab and reboot
[13:45] <persia> stgraber: Use DEB_INSTALL_CHANGELOGS_ALL in debian/rules rather than debian/docs to install the changelog.  Also, "GPL" still isn't "above".  Other than that, it also looks to me like you addressed everything (but I'm not doing any more full reviews for ~20 hours).
[13:45] <mok0> \sh: good idea
[13:45] <mok0> \sh: if it's busy it means it's mounted or reserved by the kernel
[13:46] <mok0> \sh: did you check your md config?
[13:46] <\sh> mok0: md config is correct :)
[13:47] <\sh> mok0: the same error "invalid argument" with swapon -a -e
[13:47] <mok0> \sh: that's weird...
[13:48] <\sh> mok0: yepp
[13:48] <mok0> \sh: is the installation ok?
[13:49] <mok0> \sh: apt-get wise
[13:49] <\sh> mok0: yepp
[13:50] <mok0> \sh: try the fdisk -l that ryan talks about
[13:53] <\sh> mok0: fdisk -l gives the correct answer :)
[13:53] <\sh> mok0: it's all correct...I never saw this happen...
[13:54] <mok0> \sh: neither have I, but it seems to be a problem with that UUID=... syntax
[13:54] <mok0> \sh: ... and with hibernation, but I take it yours is a server
[13:55] <\sh> mok0: I switch back to old style fstab so /dev/sda2 and /dev/sdb2
[13:55] <mok0> \sh: yeah
[13:55] <\sh> mok0: funny thing: mkswap /dev/sda2 gives me "device or resource busy"...so something is locking the device...
[13:55] <\sh> mok0: but fuser gives me nothing
[13:56] <mok0> \sh: hmmm. That must be investigated. Is the driver module loaded ok?
[13:57] <mok0> \sh: perhaps the boot tries to mount swap before the driver is loaded and that causes a hangup
[13:57] <\sh> mok0: which module should be loaded for swap?
[13:57] <mok0> \sh: not for the swap, but for the sd** device (scsi?)
[13:58] <\sh> mok0: well, it looks ok...but what's really strange is that the devices are locked now...I wonder from which process
[13:59] <minghua> Can you use lsof on device files?
[13:59] <mok0> \sh: can you umount -r or umount -l /dev/sda2 ?
[14:00] <\sh> minghua: nothing for sda2 or sdb2...but for the raid devices..so it's fine
[14:00] <\sh> mok0: not mounted
[14:01] <mok0> \sh: can you mount it?
[14:01] <\sh> root@h1337311:~# mount /dev/sda2 /mnt/
[14:01] <\sh> /dev/sda2 looks like swapspace - not mounted
[14:02] <\sh> so correctly "no" ;)
[14:02] <mok0> \sh: can you mkswap /dev/sda2 ?
[14:02] <\sh> mok0: as I said before: device or resource busy
[14:02] <\sh> root@h1337311:~# mkswap /dev/sda2
[14:02] <\sh> /dev/sda2: Device or resource busy
[14:05] <mok0> \sh: cat /proc/swaps
[14:05] <\sh> mok0: no swap space
[14:05] <\sh> root@h1337311:~# cat /proc/swaps
[14:05] <\sh> Filename				Type		Size	Used	Priority
[14:06] <mok0> \sh: heh, kernel knows
[14:10] <mok0> \sh: cat /proc/modules | grep sd
[14:10] <\sh> root@h1337311:~# cat /proc/modules |grep sd
[14:10] <\sh> sd_mod 39680 2 - Live 0xffffffff880ea000
[14:10] <\sh> scsi_mod 179896 4 sg,3w_xxxx,libata,sd_mod, Live 0xffffffff880bd000
[14:11] <mok0> \sh: looks pretty much like mine
[14:12] <mok0> \sh: sda2 is not a USB disk, is it?
[14:15] <\sh> mok0: I have a server here :)
[14:15] <mok0> \sh: with real scsi disks
[14:16] <\sh> mok0: I don't think so...it's just a plain rootserver
[14:16] <\sh> so I think ide or sata
[14:16] <\sh> 01:0e.0 RAID bus controller: Broadcom K2 SATA
[14:16] <\sh> so sata
[14:16] <mok0> \sh: not ide, then the device would be hd*
[14:17] <Nafallo> ehrm. when did -motu become a supportchannel anyway?
[14:17] <martoss> hi all, i have a cdbs related question. i set up a rules file according to  http://wiki.debian.org/DebianPython/NewPolicy
[14:18] <\sh> Nafallo: well, on #ubuntu no one runs a server ;) and here I know that people are running servers ;)
[14:18] <Nafallo> Shoragan: -server
[14:18] <\sh> Nafallo: -server is for development :)
[14:18] <martoss> if i do a dpkg-buildpackage -rfakeroot , i get include not found, althoug i can access the includes as my user.
[14:18] <mok0> \sh: here's what I think you should try (if you can reboot the server a few times): try to make the machine forget all about sda2 as a swap partition -- remove it from /etc/disk, reboot, and see if you can mount it as swap manually
[14:18] <Nafallo> s/Shoragan/\\sh/
[14:18] <Nafallo> \sh: server related support as well.
[14:18] <Nafallo> \sh: THIS channel is for development though
[14:19]  * RainCT wonders wheter bug #180788 is valid?
[14:19] <ubotu> Launchpad bug 180788 in openafs "Please change: Don't build on "lpia" arch." [Undecided,New] https://launchpad.net/bugs/180788
[14:19] <\sh> Nafallo: if it happens that I felt over https://edge.launchpad.net/ubuntu/+bug/66637 I'll go to -devel and discuss it with keybuk :)
[14:20] <ubotu> Launchpad bug 66637 in util-linux "After running mkswap, swap space is discarded, system fails to hibernate (invalid swap signature)" [High,Confirmed]
[14:20] <Nafallo> Shoragan: haha
[14:20] <mok0> sorry for spamming the channel with a non-devel discussion, we can take it elsewhere. \sh?
[14:20] <Nafallo> gaah!
[14:20] <Nafallo> s/Shoragan/\\sh/g
[14:20] <amarillion> persia: you said  3) lexgrog is unhappy with the manpages, and you want \- and \)hy rather than '-',
[14:20] <amarillion> But I don't see that problem. lexgrog works fine on that page
[14:21] <\sh> mok0: let's go to -server
[14:21] <minghua> RainCT: Sounds very reasonable.  And indeed openafs FTBFS on lpia.
[14:21] <amarillion> persia, Could you explain a bit more please?
[14:22] <nenolod> Nafallo, lpia is just i386 with special optimizations afaik
[14:22] <amarillion> Also, when you say "close a bug with the initial release"
[14:22] <amarillion> Is that documented somewhere, how to do that exactly?
[14:22] <amarillion> I don't see that mentioned in the wiki
[14:22] <Nafallo> nenolod: I think so to.
[14:22] <Nafallo> too even
[14:24] <nenolod> although it does indeed fail to build on lpia
[14:24] <nenolod> but it's configure-stamp that fails
[14:27] <RainCT> minghua: Ok. But this should be done then when there's a new revision and not now, or?
[14:29] <minghua> RainCT: I'm just saying the bug is valid, not that I know anything if the proposed solution is correct. :-)
[14:29] <nenolod> RainCT, #180788 is not valid, but there is indeed a buildfailure on lpia.
[14:30] <nenolod> http://launchpadlibrarian.net/11133194/buildlog_ubuntu-hardy-lpia.openafs_1.4.6.dfsg1-2_FAILEDTOBUILD.txt.gz
[14:31] <nenolod> the imporant part --> make: *** [configure-stamp] Error 1
[14:31] <nenolod> dpkg-buildpackage: failure: debian/rules build gave error exit status 2
[14:32] <nenolod> curiously, is lpia 32UL or 64UL
[14:42] <guest22> Any MOTUs out there willing to review package photoml (http://revu.tauware.de/details.py?package=photoml)? It's already been advocated once, and the remaining (hopefully) few issues pointed out by persia have been addressed in the most recent upload.
[14:44]  * LucidFox pings jdong
[14:51] <amarillion> What's exactly the format for closing a LP bug from a changelog? I can't find the documentation
[14:51] <LucidFox> amarillion> (LP: #xxxxxx)
[14:51] <amarillion> thanks
[14:51]  * minghua is surprised to see http://revu.tauware.de/revu1-incoming/photoml-0801051900/photoml-0.24/
[15:00] <amarillion> Ok,
[15:00] <amarillion> can someone help me with this review comment
[15:00] <amarillion> "lexgrog is unhappy with the manpages, and you want \- and \)hy rather than '-"
[15:01] <amarillion> I don't understand, the man page works fine for me...
[15:01] <mok0> amarillion: you want to distinguish between hyphen and minus
[15:01] <amarillion> Yeah ok, but I'm doing that... Just a sec, let me paste the text
[15:02] <mok0> amarillion: basically, anything that is not a hyphen (like in "non-conforming") should be \-
[15:03] <amarillion> http://paste.ubuntu-nl.org/50965/
[15:03]  * mok0 looks
[15:03] <guest22> minghua: What's the surprise - the short README in HTML rather than the directory index you expected?l
[15:04] <amarillion> Oh, might it be line 51?
[15:04] <amarillion> "built-in"
[15:04] <mok0> amarillion: looks fine to me. But remove all the boiler-plate cruft
[15:05] <dds> is anyone here a mentor looking for new contributors?
[15:05] <amarillion> mok0 ok
[15:08] <dds> I have a few packages, some of them are ports of Debian packages, some of them are updates of existing universe packages for hardy, some of them are gutsy backports (and some are new versions of Debian packages). I was wondering if anyone could check them out for acceptability.
[15:09] <dds> they're all in http://ubuntu.bosabosa.org/
[15:09] <minghua> guest22: Yes, I expected a directory index.  I suppose it's because upstream ships an index.html in their tarball.
[15:10] <LucidFox> dds> All new packages in Ubuntu go into Hardy.
[15:11] <dds> LucidFox: I know, the gutsy-backports are for my personal use and my users
[15:11] <dds> but they're all in the same pool
[15:11] <dds> that's all I was trying to say.
[15:12] <dds> if you use "deb-src http://ubuntu.bosabosa.org/ hardy main" (even though they should be universe, they're in my main just for simplicity) you'll get them
[15:12] <dds> and the debs are properly built against libs for hardy, gutsy, or sid, as appropriate
[15:13] <LucidFox> If you want to get a package into Ubuntu, the action depends on its status in Ubuntu and Debian
[15:13] <LucidFox> 1. If this version is in Debian, file a sync request
[15:13] <dds> :) right, I'm taking this up with the appropriate debian maintainers simultaenously
[15:13] <dds> but
[15:13] <dds> anyway, could you look at the packages?
[15:14] <dds> the purpose is for my organization to be able to use the TPM chips in our laptops and desktops for VPN and GPG key storage, so it requires new versions of trousers, libtspi, and opencryptoki.
[15:14] <dds> if you have a machine with a TPM chip, you may also find it useful; true security for your GPG subkey.
[15:15] <LucidFox> If it's specific to your organization, just create an intranet repository and configure your Ubuntu systems to look there
[15:15] <dds> we have that already. we like contributing back.
[15:15] <dds> I'm a sysadmin for google, we're already using these internally. I repackaged them without any of our internal dependencies and made them available in my own repo.
[15:16] <LucidFox> So, looking at the package versions:
[15:16] <LucidFox> trousers: File a sync request
[15:16] <LucidFox> libtspi: This is in neither Ubuntu nor Debian, so upload it to REVU
[15:17] <dds> the trousers package can't just be synced because the old ubuntu package uses a different username and group then the debian package
[15:17] <dds> so my modified package moves the group over
[15:17] <LucidFox> Then file a merge request.
[15:17] <dds> err moves the user and group over
[15:17] <LucidFox> Add a debdiff.
[15:17] <dds> libtspi is in both
[15:17] <dds> it's built via the trousers source package
[15:17] <LucidFox> Ah, I see.
[15:18] <dds> and about a merge request, my package is the merge.
[15:19] <dds> about opencryptoki, I'm trying to get upstream to make a new stable release, but in the CVS version that I packaged there are only bugfixes, no new functionality, but enough to get the TPM working properly.
[15:19] <LucidFox> Yes, but when merging from Debian, Ubuntu developers operate diffs rather than whole packages.
[15:19] <LucidFox> (I'll get to opencryptoki)
[15:19] <dds> ok
[15:20] <dds> forgive me, I'm an oldschool debian hacker, I know how to build packages but I'm not up on the ubuntu organization
[15:20] <LucidFox> looking at the packages
[15:20] <LucidFox> Well, first, trousers should be against the latest Debian version
[15:20] <LucidFox> which is 0.3.1-3
[15:20] <LucidFox> And there's no ~ in ubuntu
[15:21] <LucidFox> so when you create your modified version, name it 0.3.1-3ubuntu1
[15:21] <dds> ok
[15:22] <LucidFox> After you build the source package, run debdiff against the Debian package and yours and file a merge request in Launchpad with the output attached
[15:23] <dds> ok
[15:23] <guest22> minghua: Yes, exactly.
[15:23] <dds> can you tell me where in launchpad the merge request goes? just as a bug against the ubuntu package?
[15:23] <LucidFox> yes
[15:24] <dds> ok
[15:24] <dds> also, I'd be happy to be the maintainer for the packages in Ubuntu (I'm asking for maintainership of the packages in Debian, too), any suggestions?
[15:24] <LucidFox> name it something like: "Please merge trousers 0.3.1-3 from Debian unstable (main)"
[15:24] <dds> ok
[15:24] <LucidFox> Ubuntu doesn't have the concept of a single maintainer, to my knowledge
[15:24] <dds> right
[15:25] <LucidFox> so anyone can upload a package over an existing one
[15:25] <dds> anyone in MOTU you mean?
[15:25] <LucidFox> Any MOTU, yes, or any user through sponsorship
[15:25] <dds> nod ok
[15:25] <dds> then I'll just get someone internally to review the packages and sponsor me
[15:26] <dds> tomorrow
[15:26] <LucidFox> Uhm...
[15:26] <dds> someone in my company who's an MOTU
[15:26] <LucidFox> Sponsorship is requested via Launchpad :)
[15:26] <dds> who can sponsor me
[15:26] <LucidFox> by subscribing ubuntu-universe-sponsor
[15:26] <dds> nod
[15:26] <LucidFox> * ubuntu-universe-sponsors
[15:27] <LucidFox> Updates are managed the same as merges, only you attach a debdiff against the current Ubuntu version rather than the Debian version.
[15:27] <dds> nod, ok
[15:59] <DarkSun88> Salve
[15:59] <DarkSun88> Hi all
[16:04] <DarkSun88> persia: Ping
[16:08] <geser> persia, bluekuja: regenerated http://qa.ubuntuwire.com/ftbfs/
[16:27] <jwill> Are sun-java5-jdk and sun-java6-jdk virtual classes in hardy? If so, what are the concrete classes?
[16:28] <crimsun> "classes"?
[16:29] <crimsun> they're most definitely not virtual /packages/ - see apt-cache policy
[16:32] <jwill> my bad, I did mean packages...hmm because pbuilder is failing saying they are virtual that that pbuilder-satisfydepends-dummy  has unmet depends
[16:32] <LucidFox> jwill> They won't work in pbuilder
[16:32] <crimsun> your pbuilder configuration likely doesn't have multiverse as a known component.
[16:32] <LucidFox> It's not just multiverse.
[16:33] <LucidFox> Proprietary Java doesn't work in pbuilder, _period_. It has nothing to do with multiverse.
[16:33] <crimsun> there's debconf buffoonery, true.
[16:33] <LucidFox> Indeed.
[16:34] <LucidFox> jwill> Can you build your package with a free Java SDK? Like icedtea-java7-jdk?
[16:35] <pochu> Can't you set debconf to noninteractive to get it working?
[16:35] <jwill> I think so(using icedtea), pretty sure the package doesn't use java's propr ui api? what if it did need something in multiverse java? How would I test in that case?
[16:37] <LucidFox> I think if it build-depends on proprietary Java, it's out. Because the build will fail on LP as well.
[16:40] <crimsun> pochu: no, it will simply bail, because it defaults to not accepting the EULA.
[16:50] <tjaalton> superm1: ping, openchrome packaging
[16:55] <the_belgain> Hello.  Is this the right place to ask a pbuilder question (i'm trying to package a new program for ubuntu)?
[16:55] <ScottK2> Yes.
[16:57] <the_belgain> I'm trying to package a program (fuppes) following the debhelper guide in the wiki.  I've first made sure that i can compile the program normally (./configure, make, make install) and that works fine
[16:58] <the_belgain> when trying to build the src package using pbuilder, i get the build failing due to unresolved references to dlclose, dlopen, dlsym
[16:59] <the_belgain> i'm guessing something pretty basic is missing from my build-depends, but i'm not sure what (i'd have thought the package containing those would be part of build-essential?)..
[16:59] <the_belgain> any suggestions?
[17:02] <crimsun> it's highly improbable that it's a build-depends issue.  Did you check if the correct options are being passed to the linker during compilation?
[17:04] <the_belgain> i'm just looking through the build output now... one thing i'm noticing is several instances of "FATAL: Could not load /lib/modules/2.6.22-14-generic/modules.dep: No such file or directory" - is this benign?
[17:06] <crimsun> what are you building that needs linux-image-2.6.22-14-generic as a build-dependency?!
[17:08] <the_belgain> it doesn't, but i'm getting those lines output by pbuilder when it's installing packages
[17:08] <LucidFox> That's normal, ignore it.
[17:08] <LucidFox> I get it too.
[17:09] <the_belgain> ok, thanks
[17:09] <the_belgain> so presumably i need to look through the autogenerated debian/rules file to see what could be wrong there?
[17:09] <the_belgain> eg. ./configure options, build flags, etc.?
[17:10]  * RainCT thinks that the CoC should have a "if someone is a idiot you can tell him so" exception :P
[17:12] <crimsun> the_belgain: do you have the build log pastebinned?
[17:13] <the_belgain> i can do - where does pastebin live?
[17:14] <crimsun> any pastebin will suffice.  some people use pastebin.ca, others paste.ubuntu-nl.org, ...
[17:15] <ScottK2> !pastebin | the_belgain
[17:15] <ubotu> the_belgain: pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
[17:15] <ScottK2> That one's fine if you dont have one handy.
[17:16] <the_belgain> http://paste.ubuntu-nl.org/50978/  -  that's the complete output from pbuilder build
[17:20] <geser> LucidFox: build-depending on the sun-java packages works on the buildds as they have the license question preseeded
[17:24] <tormod> ogra: hi, any chance you can look at your ubuntu-main-sponsors bugs before the alpha 3 freeze?
[17:26] <ScottK2> crimsun: I was hoping you were looking at the_belgain's pastebin.  I'm up to my eyeballs in MIRs right now.
[17:29] <the_belgain> has anyone had a chance to take a quick look?
[17:29] <the_belgain> i can paste my debian/rules as well if that helps
[17:34] <bddebian> Heya gang
[17:38] <rzr> hi, my is about to upload a new package to REVU , anyone want to doublecheck it before ?
[17:44] <afflux> some headers in libotr2-dev include gcrypt.h which is in libgcrypt11-dev. Shouldn't libotr2-dev depend on libgcrypt11-dev?
[17:45] <geser> afflux: yes
[17:45] <geser> Hi bddebian
[17:45]  * afflux goes filing a bug then
[17:48] <LucidFox> I wonder if there are already Ubuntu packages of KDE 4 final.
[17:49] <crimsun> ScottK2: in a bit, yes.
[17:49] <crimsun> the_belgain: I'll be at it in about 1,5 hours.
[17:50] <the_belgain> great, thanks
[18:05] <bddebian> Heya geser
[18:12] <dfiloni> if I use debuild binary to build a package, how I can get *_i386.changes file?
[18:37] <the_belgain> crimsun: sorry, i just logged off for a moment - back now
[19:45] <Hattory> Hi all.... I would understand the use of prevu... I already read this how-to http://ubuntuforums.org/showthread.php?t=268687) but I don't understand some things
[19:46] <Hattory> I would build a backport for gutsy
[19:46] <Hattory> the package is sunbird 0.7
[19:48] <Hattory> when I type prevu packagename wich repositories I must put in the sources.list?
[19:48] <jpatrick> Vorian: thanks for the tork patch
[19:49] <Hattory> repo of the development distro, right?
[19:55] <Vorian> jpatrick: no problemo
[19:57] <martoss> hi all, i packaged eric4, I'll inform the debian maintainer of eric3 and hope he will answer in near future.
[19:57] <martoss> so what's the best way to get it in universe?
[20:00] <ScottK> Best way is to get the Debian maintainer to upload it to Debian and then ask for a sync
[20:01] <ScottK> 2nd best way is to prepare an Ubuntu specific package, upload it to REVU and then see if you can get it sponsored for upload directly into Ubuntu
[20:01] <ScottK> !revu | martoss
[20:01] <ubotu> martoss: REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
[20:02] <martoss> ok, also because it depends on qscintilla2 which is not in ubuntu yet, so i hope he will answer in the next days. if not, I consider revu :-)
[20:02] <warp10> TheMuso: may I request the merge of big-cursor (whose you are the last uploader)?
[20:03] <ScottK> martoss: Is it in Debian?
[20:04] <martoss> i think i have the source package from there, mom plz...
[20:05] <martoss> yepp, it's in debian http://packages.debian.org/search?keywords=qscintilla2&searchon=names&suite=all&section=all
[20:05] <martoss> and will be present in hardy ;-)
[20:05] <martoss> ok, so this should not be a problem
[20:08] <ScottK> martoss: In fact: https://launchpad.net/ubuntu/+source/qscintilla2
[20:11] <martoss> ok, so i think it's a good idea to do this REVU stuff. In the last time, i packaged several apps and put them in my private repo.
[20:34] <rzr> just done http://revu.tauware.de/details.py?package=jaaa
[20:35] <ion_> http://revu.tauware.de/revu1-incoming/jaaa-0801062000/jaaa-0.4.2/debian/control You probably should scrap the . from the end
[20:40] <martoss> ok i am at that point "In order to upload to REVU, you will need to be added to the REVU keyring. "
[20:41] <ScottK> Did you add your GPG key to your Launchpad profile and join the contributors of packages to universe team?
[20:42] <martoss> yepp
[20:42] <martoss> key is verified
[20:42]  * ScottK looks around for a REVU admin.
[20:43] <ScottK> imbrandon: You here?
[20:43] <martoss> and i am in the group.
[20:46] <rzr> ion_: ok
[20:56] <Kmos> dh_desktop is valid for kubuntu desktop ? but not dh_icons..
[21:02] <\sh> guys what about clamav in gutsy? is 0.92 being backported even with a soname change?
[21:03] <ScottK> \sh: I plan on it, but want to give it some more time in Hardy first
[21:04] <ScottK> \sh: All the security fixes have already been fixed in Feisty/Gutsy
[21:04] <\sh> ScottK: well, freshclam is crying ,-)
[21:05] <ScottK> Of course it is.
[21:05] <ScottK> You should be able to ignore it for now.
[21:05] <\sh> yeah...
[21:05] <\sh> fingers cross
[21:09] <\sh> ScottK: how do you see that amavisd-new is catching the clamd?
[21:09] <ScottK> \sh: I don't understand the question?
[21:10] <\sh> ScottK: reading my logfiles when I start amavisd It tells me ANTI-VIRUS code not loaded"
[21:10] <\sh> I thought it needs this when you want to use a virus scanner
[21:11] <ScottK> Ah.  I actually use clamsmtp.  It's been a while since I set it up with amavisd-new.  IIRC it was clear enough what to do from their docs.
[21:12] <\sh> ScottK: well according to the debian conf for amavis, just install clamav-daemon and add clamav user to amavis group..restart clamd and amavis...bingo
[21:22] <\sh> scottk: works
[22:11] <amarillion> Should I announce an upload to REVU somewhere, so reviewers can take a look? Or should I just wait...?
[22:12] <crimsun> once per day is a recommended guideline.  spamming hourly is frowned upon.
[22:12] <amarillion> Ok :)
[22:12] <amarillion> I'm talking about this one btw: I'm talking about this btw: http://revu.tauware.de/details.py?package=speed-game
[22:13] <ion_> I was told that on MOTU days, it’s okay to do a request every six hours or so. :-)
[22:13] <amarillion> Already fixed a few issues that persia found earlier
[22:13] <amarillion> Hmmm... it's been 7 hours since my last request, so I'm a bit too quick
[22:14] <pochu> ion_: you mean REVU days? :)
[22:14] <ion_> pochu: Yeah. Brainfart. :-)
[22:15] <amarillion> When are REVU days then
[22:15] <Kmos> amarillion: every monday I think.. =)
[22:15] <pochu> Every Monday in all timezones AFAIK
[22:16] <Kmos> :)
[22:16] <ion_> If you’ve fixed issues pointed out in earlier reviews, i’d assume it to be more than okay to announce it. I’m not a MOTU, though, don’t trust my word on this. :-)
[22:16] <pochu> Kmos: you were faster ;)
[22:16] <Kmos> pochu: I try :P
[22:16] <jpatrick> amarillion: no need to do: "Section: universe/games"
[22:16] <amarillion> Yeah, lintian complains about that. But why?
[22:16] <Kmos> amarillion: try to set only games
[22:17] <pochu> Probably because it's not known to it
[22:17] <nenolod> amarillion, why are you repacking the tarball in speed-game?
[22:17] <amarillion> I think I learned to do that because of ppa.
[22:17] <Kmos> amarillion: bump Standards-Version to 3.7.3 in debian/control
[22:17] <jpatrick> amarillion: This is a NEW package, only one changelog entry is needed
[22:18] <jpatrick> Kmos: he already has that
[22:18] <nenolod> amarillion, _DONT_ do that
[22:18] <Kmos> jpatrick: :)
[22:18] <Kmos> ups
[22:18] <Kmos> checking the old one
[22:19] <bddebian> Heya gang
[22:19] <amarillion> "Section: universe/games" -> "I think I learned to do that because of ppa."
[22:19] <amarillion> (just to be clear)
[22:19] <jpatrick> amarillion: one should not edit the source, use a patch system instead
[22:19] <nenolod> amarillion, the license on your package "This code is free: do with it as you will." is questionable at best
[22:20] <amarillion> nenolod: am I repacking the tarball? I wasn't aware of that
[22:20] <amarillion> nenolod, how should I phrase it then?
[22:21] <amarillion> I'll look into using a patch system
[22:23] <nenolod> amarillion, tell the upstream author to license it under BSD or GPL2 or something legally proven
[22:23] <amarillion> Ok
[22:24] <amarillion> nenolod, what do you mean exactly by "repacking the tarball?"
[22:24] <pochu> nenolod: Public domain is OK, isn't it?
[22:25] <nenolod> amarillion, it appears as if your tarball is repacked.
[22:26] <nenolod> amarillion, as in, you didn't have an .orig.tar.gz in the parent dir so dh_make made one
[22:26] <nenolod> :P
[22:27] <nenolod> pochu, public domain is not acceptable in non-common law countries
[22:27] <nenolod> pochu, in france, public domain-like grants do not take affect until after you die
[22:27] <amarillion> ah ok. Probably a typo in the filename then. I'll look into that as well
[22:27] <pochu> I think we have public-domain licensed software in the archive, don't we?
[22:28] <nenolod> pochu, yes, but that's not really an excuse to add more if you can help it
[22:28] <amarillion> Well, I'll ask upstream to clarify
[22:28] <ion_> i think there was a CC license that was essentially public domain, but it worked around such legalization, or something like that.
[22:28] <nenolod> pochu, also, that's not necessarily a public domain grant
[22:28] <nenolod> ion_, yes, the most leniant CC license would be a good choice
[22:30] <nenolod> pochu, public domain grants are usually the following sentence: "This work is in the public domain."
[22:31] <ScottK> BSD License is a legal way to say do whatever you want.
[22:31] <nenolod> ScottK, incorrect
[22:32] <ScottK> OK.  It's not quite anything, but it's very close.
[22:32] <nenolod> ScottK, BSD license is a legal way to say "do whatever you want as long as you keep this copyright in the source code"
[22:32]  * persia advocates the use of the ISC license in preference to the BSD license for new works
[22:32] <nenolod> persia, me too
[22:36] <amarillion> would it be ok to use something like the allegro giftware license: http://paste.ubuntu-nl.org/51018/ ?
[22:37] <amarillion> (Since this is an allegro game)
[22:38] <nenolod> amarillion, if it's already used in debian/ubuntu, then i don't see the issue
[22:38] <persia> amarillion: Likely safer to use ISC, which has similar terms, but that works too.
[22:38] <nenolod> using ISC is indeed a wiser decision
[22:38] <nenolod> but you'll want to ask upstream for permission
[22:39]  * persia notes that upstream should really be the source of the licensing, regardless of which is chosen
[22:39]  * ScottK agrees with persia.
[22:40]  * pochu agrees with ScottK 
[22:41]  * ion_ agrees with pochu
[22:41]  * persia celebrates consensus, but notes that it doesn't require an experiment in recursion
[22:41] <pochu> persia: you broke it! ;)
[22:42]  * bddebian disagrees just to be different
[22:42]  * Fujitsu agrees with bddebian.
[22:42] <ScottK> Definitely check with upstream then.
[22:42] <ScottK> ;-)
[22:43] <pochu> Fujitsu: are you different then too? :)
[22:52] <ion_> Could i get a second advocation for http://revu.tauware.de/details.py?package=hardware-connected (a program that checks whether given hardware is connected to the system, nice for scripting)? Thanks :-)
[22:57] <amarillion> Ok, I sent an email upstream.
[22:57] <amarillion> thanks for the comments on the package, I've got some things to work on now
[22:57] <imbrandon> ScottK: pong
[23:19] <ScottK> imbrandon: REVU keyring needed syncing
[23:40] <Kmos> what's best.. schroot or dchroot ?
[23:40] <Kmos> more close to buildd machine..
[23:56] <crimsun> the mk-sbuild-lv script in ubuntu-dev-tools is recommended.
[23:56] <crimsun> ^^ Kmos.
[23:58] <cyberix> What do you do instead of dget in Dapper?
[23:59] <crimsun> more precisely?  (You certainly can use dget with absolute pool URLs.)