[00:00] <RAOF> somerville32: Thanks.
[00:00] <RAOF> nxvl_work: You're welcome to merge apt-proxy if you like.
[00:00] <nxvl_work> effie_jayx: i'm looking at you patch, did you make the changes outside of debian/
[00:00] <nxvl_work> RAOF: thnx
[00:00] <RAOF> nxvl_work: Just be careful of the bashism in Debian & dashism in Ubuntu :)
[00:01] <nxvl_work> RAOF: but i haven't notice that it was already merged :(
[00:01] <effie_jayx> nxvl_work,  no
[00:01] <effie_jayx> that I remember
[00:01] <effie_jayx> the manpage was in debian/
[00:02] <nxvl_work> oh right i haven't look well :)
[00:02] <effie_jayx> but it is renamed to runghc.man and when the other are generated, it gets changed to a .1
[00:03] <nxvl_work> effie_jayx: did you build it and install it?
[00:03] <effie_jayx> yes
[00:03] <nxvl_work> effie_jayx: and the man page it's installed correctly?
[00:03] <effie_jayx> yes
[00:03] <effie_jayx> I had to install man in my pbuilder to test it
[00:03] <nxvl_work> so don't mind if the name is changed
[00:04] <nxvl_work> heh, yes, thats the PITA of pbuilder, but i love it
[00:04] <effie_jayx> nxvl_work,  it's cool...
[00:04] <effie_jayx> does it look ok'
[00:04] <effie_jayx> that bug was tricky
[00:05] <effie_jayx> the packaging of the manpages is done through a script that made it more difficult for me ... I couldn't see the manpages it had...
[00:05] <nxvl_work> effie_jayx: they are all tricky when you start
[00:06] <nxvl_work> i still find some bugs tricky
[00:07] <effie_jayx> nxvl_work, well .. I did my best
[00:07] <effie_jayx> and I think this is the first time I go all the way with a bug
[00:08] <nxvl_work> effie_jayx: yes, we need to do our best, and if isn't enough to solve the bugs ask for help :D
[00:08] <nxvl_work> there are somethings i already do mechanically
[00:09] <effie_jayx> nxvl_work,  thoughts on the bug... you think I did ok?
[00:12] <nxvl_work> effie_jayx: well i only take a...
[00:12] <nxvl_work> "mirada rapida"
[00:12] <nxvl_work> and it seems fine
[00:13] <nxvl_work> quick look*
[00:13] <nxvl_work> oh yes
[00:14] <nxvl_work> effie_jayx: you need to add (LP: #95985) to the changelog
[00:14] <nxvl_work> also you have changed debian/rules, and it isn't shown on your changelog entry
[00:15] <crimsun> hum.
[00:15] <effie_jayx> ahhhmmm
[00:15] <effie_jayx> :(
[00:15] <crimsun> there's no license associated with debian/runghc.man.  Is that intentional?
[00:16] <effie_jayx> no
[00:16] <crimsun> (i.e., normally one says that the man page is redistributable under the terms of Foo)
[00:17] <effie_jayx> crimsun,  sure... but hte manpage for ghc didn't mention anything :S
[00:17] <crimsun> effie_jayx: I thought you made debian/runghc.man.
[00:17] <effie_jayx> crimsun,  but that's for runghc...
[00:17] <nxvl_work> effie_jayx: i make a comment on LP with the 2 suggestions i have just made
[00:18] <crimsun> effie_jayx: yes, and that's what I've been referring to...
[00:18] <effie_jayx> there is a manpage for ghc
[00:18] <effie_jayx> and I tried to follow the same pattern
[00:18] <effie_jayx> crimsun,  would you suggest a licence?
[00:18] <somerville32> effie_jayx, You need a copyright notice.
[00:18] <nxvl_work> effie_jayx: change this 2 thinks, the sponsors won't accept your patch until you fix them
[00:19] <effie_jayx> ok
[00:19] <crimsun> effie_jayx: for debian/runghc.man?  I generally choose GPL v2 or later for man pages installed into Debian{,-derived} systems.
[00:20] <effie_jayx> nxvl_work,  I'll have a look at those ...
[00:20] <effie_jayx> and fix them
[00:23] <nxvl_work> effie_jayx: NICE!
[00:24] <crimsun> tehe, jordi just flooded pkg-alsa-devel with several hundred queued e-mails
[00:24] <effie_jayx> crimsun,  where could I see and example of a copyright notice in a man page?
[00:25] <TheMuso> c
[00:25] <TheMuso> ugh wrong tab
[00:25] <nxvl_work> heh
[00:26] <crimsun> effie_jayx: e.g., update-alternatives(8)
[00:29] <effie_jayx> crimsun,  This   manual   page   was   written   by    Efrain    Valles    Pulgar
[00:29] <effie_jayx>        <effie.jayx@gmail.com>. This is free documentation; see the GNU General
[00:29] <effie_jayx>        Public Licence version 2 or later for copying conditions. There  is  NO WARRANTY. ... does that make sence?
[00:29] <effie_jayx> ugh... sorry
[00:29] <effie_jayx> should have pastbined
[00:29] <crimsun> effie_jayx: sure, if you wish to use the GPL v2 or later.
[00:30] <effie_jayx> it's ok
[00:30] <effie_jayx> then I am going again
[00:37] <effie_jayx> changes made
[00:37] <effie_jayx> I have to package and test again?
[00:48] <effie_jayx> that's a yes I guess..
[00:49] <crimsun> yes, regenerate the source package.
[00:50] <effie_jayx> ok that's take a while ;)
[00:51] <effie_jayx> I have done the source package
[00:51] <effie_jayx> and donde the debdiff
[00:51] <effie_jayx> but I need to test it?
[00:52]  * effie_jayx is already building the package for a test on a chroot env
[00:53] <persia> effie_jayx: It's always best to test, as it saves having to do it again after you've forgotten the details when your sponsor tests, or worse needing to make  new upload to fix the mistake when a user tests :)
[00:53] <Ubulette> hi
[00:53] <Ubulette> persia, could you spare some time for prism ?
[00:54] <persia> Ubulette: Not soon :(  You'll get a better package if you get reviews from lots of different people anyway.
[00:55] <Ubulette> i'm sure of that but I've asked 3 or 4 times here, no one answered
[00:55] <Ubulette> oh, RAOF had a quick look but that's about it
[00:55] <persia> Ubulette: Did you ask on a Monday?  Sometimes people wait for REVU day to do reviews.
[00:56] <Ubulette> i can easily have several reviews from the mozilla team but i wanted something external
[00:56] <effie_jayx> ok
[00:57] <effie_jayx> It'll take two hours or so
[01:02] <Ubulette> well, it's not really encouraging. i've tried my best to follow the motu process to integrate my new package.
[01:02] <persia> Ubulette: From a quick look, it's fairly good, although I'm not sure of the value of shipping MPL in debian/ and in the orig.tar.gz, except perhaps to help with building the orig.tar.gz.  One reason it might be taking a while is that people need to really test at this point, rather than just complaining about packaging issues.
[01:04] <persia> Ubulette: You've been following the process wonderfully.  It's just that it often takes a while to get things in, even when they are perfect, as there's not a lot of active reviewers.
[01:07] <Ubulette> what else could I do ? prism will gain more exposure only once it is in. so far, my limited set of users seems happy but now, what ? wait or give up ?
[01:08] <RAOF> Ugh, what happened to font rendering in FF-3?
[01:08] <RAOF> Ubulette: I'll have a more thorough look now.
[01:08] <persia> Ubulette: I'd recommend waiting.  The review queue is down to about two weeks (it was around 2 months a week back), so even FIFO processing will catch you soon enough.
[01:10] <Ubulette> RAOF: which ff3 ? b1 in hardy or my newer packages ?
[01:10] <RAOF> B1 in hardy.
[01:10] <RAOF> Has someone turned off the "build against libcairo-awesome" or something?
[01:12] <RAOF> Oh dear.  I appear to be capped.  Hello, 13kb/s!
[01:13] <RAOF> Ubulette: Oh, on my last run through of prism I noticed that new-orig-source seems to be doing what get-orig-source should do (at least on my reading of policy).
[01:13] <Ubulette> RAOF, ff3 is not using system cairo as mozilla is far ahead
[01:13] <RAOF> On the other hand, your g-o-s rule is obviously useful, and my reading of policy may not coincide with anyone else's.
[01:13] <RAOF> Urgh.
[01:14] <RAOF> Dear upstreams: no matter how cool the new, unreleased library is, it's not worth shipping it in your source tree.  kthxbye.
[01:14] <persia> g-o-s should get the current orig.tar.gz, and other rules to help with updates are nice, but not required.
[01:14] <Ubulette> RAOF, i've tried but hardy has 1.4.10 while mozilla ships 1.5.2
[01:15] <RAOF> persia: Ok.  Maybe I'm reading the "most current" in debian policy differently.
[01:15] <RAOF> s/maybe/obviously/.
[01:15]  * persia looks at policy again
[01:16] <Ubulette> RAOF, get-o-s is supposed to fetch the tarball usefull to build the package, while new-s-o is supposed to fetch the newest possible tarball for the packager to prepare a newer version.
[01:17] <persia> RAOF: No, you're correct, and I'm mistaken, based on an old justification for get-orig-source.  I don't like the policy, but it seems it was too much trouble to try to reconstruct the preferred tarball.
[01:17] <Ubulette> at least, that's how I do things. maybe not what the book says
[01:17] <RAOF> Ubulette: Yeah, I understand what you intend them to do, and they're both useful.  I've just been reading policy to mean g-o-s should get the most recent source, not the one used to build teh package.
[01:17]  * persia apologieses for Ubulette for having previously provided incorrect advice
[01:18] <RAOF> Easy enough to fix.  Rename g-o-s to get-pkg-source, and n-o-s to g-o-s.
[01:18] <persia> RAOF: That's what policy says.  Do you think it's useful (assuming we're not enforcing a policy of having the very latest source)?
[01:19] <Ubulette> both of my rules are getting svn stuff. I assume the policy is about released tarballs
[01:19] <RAOF> persia: It'd really be nice to have two targets, really.  g-o-s as you understood it is probably more useful than a strict reading of policy.
[01:20] <RAOF> Ubulette: Do you know how soon FF3 is planned to be released?
[01:20] <persia> RAOF: I completely agree.  On the other hand, I'm not very familiar with how we might get something useful without breaking all of the Debian syncs.  I'm especially concerned for VCS pulls, as what g-o-s grabs may not even work when following policy.
[01:22] <slangasek> why would you want a target to grab the *current* source, when that's already part of the source package at hand?
[01:22] <RAOF> slangasek: Because you have just the debian/ directory in VCS?  Because you repackage the upstream tarball?
[01:23] <RAOF> Because upstream never releases, so you're packaging a VCS snapshot?
[01:23] <persia> slangasek: 1) maybe you don't trust the packager, and want to reconstruct (paranoid user scenario), 2) maybe it would be nice to just pass a diff in order to reconstruct a package (easy reviewing scenario), 3) maybe it would simplify debian/ in VCS workflows (no need to VCS the orig.tar.gz scenario)
[01:23] <slangasek> RAOF: those are all good reasons to have a target that lets you grab the *new* version for packaging
[01:24] <slangasek> RAOF: but it's simply not true that the get-orig-source target in policy is expected to recreate the current tarball
[01:24] <RAOF> slangasek: I don't disagree with that.
[01:24] <persia> slangasek: A target to grab *new* is also nice, but that's for packaging convenience, and is unlikely to have direct user impact.  On the other hand, having an orig.tar.gz whose md5sum doesn't match the upstream distribution point is annoying, and providing a way for users to verify is useful.
[01:25] <Ubulette> RAOF, FF3, not sure anyone knows. when it's ready ;) b2pre is moving quite fast, full gnome integration with theme and all, better memory handling, etc.
[01:26] <RAOF> Ubulette: Because they're building against their own internal copy of a development snapshot of cairo which seems unlikely to be released before FF3.  This seems like a really awkward situation.
[01:27] <slangasek> persia: packaging convenience is a far more realistic use case than random end-users verifying source packages; and repacking an upstream tarball doesn't guarantee that you'll get the same md5sum as the maintainer anyway
[01:27] <slangasek> s/verifying source packages/& at that level/
[01:27] <persia> slangasek: I don't care if I get the same md5sum, I care that I only need to read the diff.gz to see the distribution-specific changes.
[01:28] <Ubulette> RAOF, I know but mozilla is working closely with cairo devs to optimize it far more than what it is now.
[01:28] <persia> slangasek: Further, I agree completely with your reading of policy: I just want the other as well.
[01:28] <Ubulette> RAOF, I assume your comment is about the freetype patch
[01:28] <slangasek> persia: that's not an end-user operation anymore, then...
[01:29] <persia> slangasek: I was doing that fairly regularly long before I actually sent any email to a debian ML, but perhaps it's just me.
[01:29] <slangasek> or at least, you would still have to verify without the help of md5sum that the two tarballs match if that's what you care about
[01:29] <RAOF> Ubulette: No, my comment is about having to ship FF3 with a development snapshot of cairo.  The font rendering being crap is but one downside of this :)
[01:30] <Ubulette> slangasek, with repacking, you're absolutely sure you'll get a different md5 checksum ;)
[01:30] <persia> slangasek: Well, if I can see a short script to construct it, and run the script, and it works, I don't usually need to go further, as long as the script downloads from a known good source.
[01:30] <slangasek> Ubulette: I mean that two runs of get-orig-source (one generating the tarball in the archive, one on the user's local machine) are not guaranteed to give the same results, even given the same source tarball
[01:30] <slangasek> s/same results/same md5sum/
[01:31] <persia> This is absolutely true, for any g-o-s that goes beyond calling uscan for a verified upstream tar.gz
[01:31] <slangasek> persia: considering how few upstreams sign their tarballs, I think this is more useful for verifying whether upstream is a good source anyway... :)
[01:32] <Ubulette> in prism, with g-o-s, you'll get the same files (diff -r will show no difference) but not the same md5 as tar includes the time stamps which are always local, ie different
[01:32] <persia> slangasek: Right: it just means that my grand plan for streamlining sponsoring needs some rework :(
[01:32] <persia> Ubulette: That's normal.
[01:33] <Ubulette> persia, I know. I'm not a noob in unix
[01:34]  * persia apologies for the perceived slight
[01:34] <StevenK> widgets/.libs/libmodest-widgets.a(modest-mozembed-msg-view.o): In function `set_message':
[01:34] <StevenK> /modest-1.0/src/widgets/modest-mozembed-msg-view.cpp:673: undefined reference to `modest_tny_msg_find_body_part(_TnyMsg*, int)'
[01:34]  * StevenK looks confused.
[01:34] <slangasek> StevenK: ld has lost a body part, you see
[01:34] <StevenK> I see that.
[01:34] <StevenK> I just can't figure out where it lost it.
[01:35] <StevenK> Linking it not exactly my strong point.
[01:35] <StevenK> s/it /is /
[01:35] <slangasek> how about grepping? >:)
[01:36] <StevenK> The header that defines that function is one level down, and ../.libs is empty
[01:36] <Ubulette> persia, no offense taken ;)
[01:36] <slangasek> the function is defined in a header?
[01:46] <Ubulette> RAOF: define crap. are you talking about subpixel rendering improved by the turner's patch ?
[01:46] <Ubulette> bug 164640
[01:46] <ubotu> Launchpad bug 164640 in firefox-3.0 "Apply subpixel rendering patch to cairo" [Undecided,Confirmed] https://launchpad.net/bugs/164640
[01:48] <RAOF> Ubulette: Crap, as in looks much worse than epiphany or FF2.  Possibly related to subpixel rendering, but it also seems to be using a different DPI calculation.
[01:49] <RAOF> I can provide screenshots if you're interested.  I know that "crap" isn't a particularly useful bug description.
[01:50] <Ubulette> well, try setting dpi to 0 in about:config (should be -1 by default)
[01:51] <Ubulette> some X drivers are buggy so 0 is not good, then a positive value is needed, like 82 or 84
[01:51] <RAOF> And restart FF?
[01:51] <Ubulette> no need
[01:52] <RAOF> Ah, well.
[01:52] <sommer> screen -r
[01:52] <sommer> woops
[01:52] <bddebian> Heya gang
[01:53] <RAOF> Heh.  Nouveau is a lot less buggy than I thought.  It's xcompmgr :)
[01:53] <RAOF> Ubulette: Well, that didn't appear to do anything at all.
[01:54] <Ubulette> layout.css.dpi ?
[01:54] <RAOF> Was -1, is now 0
[01:55] <Ubulette> try 82, 84 or anything positive matching your preference for the size
[01:55]  * persia suggests using the number that actually matches your hardware
[01:55] <RAOF> Nope.
[01:56] <Ubulette> strange, works for everyone else
[01:56] <RAOF> Ah, it works for some text but not all.
[01:56] <RAOF> Particularly, it does'nt change the review text on revu at all.
[01:56] <RAOF> And that's what's looking particularly ugly at the moment.
[01:57] <persia> Maybe it's an issue with "monospace"?
[01:58] <RAOF> Maybe.
[01:58]  * RAOF fiddles with font settings
[02:00]  * RAOF gets bored & gives up.
[02:02] <Ubulette> the focus is currently on better gnome integration, so it's time to report things like that
[02:02] <Ubulette> http://www.sofaraway.org/ubuntu/tmp/ff3b2pre-gnome.png <= b2pre with default ff3 theme and default ubuntu gnome theme
[02:03] <Ubulette> http://www.sofaraway.org/ubuntu/tmp/theme-after.png <= default ff3 theme but another gnome theme
[02:03] <Ubulette> (2nd window is nautilus)
[02:05] <RAOF> Ah, so xul is becoming less obnoxious.  Yay.
[02:08] <Ubulette> !info libgnome-desktop-dev hardy
[02:08] <ubotu> libgnome-desktop-dev: Utility library for loading .desktop files - development files. In component main, is optional. Version 1:2.21.2-0ubuntu1 (hardy), package size 59 kB, installed size 452 kB
[02:08] <Ubulette> damn, hardy is late :(
[02:18] <btrigg> Hi There.  I'm on the Colorado LoCo and we have been discussing a user-friendly and educational way to confront this issue: http://ubuntuforums.org/announcement.php?a=54
[02:20] <btrigg> An idea we had was a sort of "sudo tutorial": A graphical tutorial on fresh-installs that pops up and details the power and danger of running commands as root prior to allowing any root commands to be run.
[02:21] <btrigg> Would this be the right place to find a champion for this idea?
[02:21] <somerville32> btrigg, See #ubuntu-doc
[02:22] <btrigg> somerville32: Thanks much.
[02:24] <DarkMageZ> Ubulette, is sofaraway.org/ubuntu/ yours? the firefox-minefield packages have a dependency on pango 1.19 even tho 1.18 is in the repos.
[02:27]  * StevenK kicks his lack of linking knowledge
[02:29]  * persia dreams of a whitespace-aware diff
[02:30] <StevenK> I'm trying to figure out how to fix an undefined references
[02:30] <somerville32> StevenK, in what?
[02:30] <persia> StevenK: Are the symbols available in the objects that you've -l'd into ld/gcc?
[02:31] <StevenK> persia: It's a little more stranger than that, since the symbol is in the program itself, not a library
[02:31] <Ubulette> DarkMageZ: indeed, it's mine. strange, i'm not building pango in there. btw, i'm moving my bot from gutsy to hardy so some packages are broken (yet, the whole firefox-minefield mini dist should be ok)
[02:32] <persia> StevenK: In the same source file that is under compilation?
[02:32] <StevenK> persia: Not the same source file, but the same tree
[02:32] <RAOF> StevenK: It's not some strange template instantiation issue?
[02:33] <persia> OK.  Are you linking the patch where that object file resides when you compile the target?  Separately, are you also explicitly including the header for that reference in the source that references it?
[02:33] <DarkMageZ> Ubulette, yeah. i thought it a little odd that gutsy packages were depending on a version of pango that wasn't in either ubuntu or it's oown repository.
[02:33] <StevenK> RAOF: I don't think so
[02:33] <persia> s/patch/path/
[02:34] <RAOF> Ah, no.  That error message is far to clear to be a template issue.
[02:34] <StevenK> /modest-1.0/src/widgets/modest-mozembed-msg-view.cpp:673: undefined reference to `modest_tny_msg_find_body_part(_TnyMsg*, int)'
[02:35] <Ubulette> DarkMageZ, the goal of my repo is to daily package HEAD of everything so it no longer makes sense to use gutsy as a base
[02:35] <RAOF> So where is that function defined again?
[02:35] <StevenK> in src/modest-tny-msg.c
[02:36] <persia> That looks like a parser issue, rather than a linking issue.  Make sure your -I includes the right directories (even in the same source tree), and that you've explicitly included a header defining that in modest-mozembed-msg-view.cpp
[02:39] <persia> StevenK: Is there a inc/modest-tny-msg.h or src/modest-tny-msg.h?
[02:39] <StevenK> persia: Yup. And it's included in src/widgets/modest-mozembed-msg-view.cpp
[02:40] <RAOF> StevenK: This is the same error as before, right?  The one that starts with "widgets/.libs/libmodest-widgets.a(modest-mozembed-msg-view.o): In function `set_message':
[02:40] <StevenK> RAOF: Right
[02:40] <persia> StevenK: And your gcc call has "-I." ?
[02:40] <StevenK> persia: I'm just checking that
[02:40] <persia> Err.  "-I widgets/"
[02:41] <StevenK> It does not
[02:41] <persia> Err.  I suck!  "-I ./widgets/"
[02:41] <persia> StevenK: In that case, the #include directive probably can't find it.
[02:43] <RAOF> But then it would error out on the compiling phase, right?
[02:43] <StevenK> persia: But this thing is autoconf'd and automake'd, shouldn't it just deal?
[02:43]  * persia is confused: is this *not* a build-time error?
[02:44] <persia> StevenK: It should, but it wouldn't be magic if it was easy to understand :)
[02:44] <StevenK> Heh
[02:44] <StevenK> I thought it was a link-time error?
[02:44] <RAOF> persia: It's already built libmodest-widgets.a, and the linker's complaining about an undefined reference in that archive.
[02:44] <persia> If it's link-time, then the problem isn't -I, but -L
[02:45] <persia> (alternately, if it's trying to link into a .a file, perhaps there's some funny naming redirect, but that's unlikely)
[02:45] <StevenK> There's only one -L, and it's xul stuff
[02:45] <RAOF> Where does modest-tiny-msg.c end up being built into?
[02:46] <RAOF> (This should be findable in the Makefile.am)
[02:47] <persia> I think you usually get "-L ." by default, but likely not "-L ./widgets/" (and Makefile.am should do it right, but might need a hint)
[02:48] <StevenK> RAOF: It ends up modest_SOURCES
[02:49] <persia> Is that the src/ directory in which you are linking?
[02:50] <StevenK> Yup
[02:50] <persia> Just to confirm, the generated object does contain the correct reference mid-build, right?
[02:51] <StevenK> 0# strings src/modest-tny-msg.o  | grep body_part
[02:51] <StevenK> modest_tny_msg_find_body_part
[02:52] <StevenK> So, yes. :-)
[02:53] <persia> Hmm...  You might try a manual link with -L./src/ (or just '.' depending on where you run it), but I'm pretty sure you're supposed to get that by default.
[02:54] <RAOF> Maybe some pastebinning of Makefile.am might be useful?
[02:54] <StevenK> RAOF: src/ or src/widgets ?
[02:55] <StevenK> RAOF: I can put my sources up, if you want?
[02:55] <RAOF> Eh, why not.
[02:55] <RAOF> I'll just do a bit of an update-reboot, and be back shortly.
[02:55]  * StevenK stares at git.
[02:57] <somerville32> ROAF: Didn't you say you were going to let me have access to your server to build on?
[03:02] <RAOF> somerville32: Yup.
[03:02] <RAOF> Still want it?
[03:03] <RAOF> It'll be a bit slower for a couple of days, until I get uncapped again.
[03:03] <StevenK> RAOF: If you want to build it, you also need libtinymail, I can give you source or binaries of it too?
[03:03] <RAOF> Either should be fine.
[03:03] <RAOF> Whatever's easiest.
[03:03] <RAOF> But it's not in the archives yet?
[03:04] <StevenK> This particular version isn't, just in case I need to fiddle it to get modest happy
[03:04] <StevenK> RAOF: amd64 or i386? Since amd64 is built
[03:05] <somerville32> RAOF, yes sir
[03:05] <RAOF> somerville32: LP id?
[03:06] <somerville32> RAOF, cody-somerville
[03:11] <RAOF> somerville32: Right.  You should be able to login to cody-somerville@cooperteam.net now, and use sbuild.
[03:11] <StevenK> Ugh. TPG. :-P
[03:12] <RAOF> Eh, I haven't had (many) problems.
[03:12] <somerville32> woot woot
[03:12] <somerville32> TPG?
[03:12] <StevenK> somerville32: An Australian ISP with a (deserved) reputation
[03:13] <RAOF> I couldn't find anyone else with spare ADSL2+ sockets in my area at the time.
[03:13] <StevenK> RAOF: So, are you building for amd64 or i386?
[03:13] <RAOF> StevenK: amd64 by default.  I think I've got an i386 builder lying around.
[03:13] <StevenK> RAOF: Well, I'm building for amd64, too, so that makes it simple.
[03:14] <RAOF> Yay!
[03:15] <StevenK> RAOF: http://wedontsleep.org/~steven/modest/
[03:16] <StevenK> RAOF: I can run apt-ftparchve in that directory if that makes it simpler
[03:17] <RAOF> There aren't really that many deps, right?
[03:17] <RAOF> And dget is almost as simple as apt-get source
[03:17] <StevenK> RAOF: What's in that directory is the source of the modest and amd64 debs for everything else
[03:18] <StevenK> s/the //
[03:19] <RAOF> Is there any particular reason not to use the libtinymail in the archives?
[03:20] <StevenK> RAOF: Yup. That libtinymail is built against xulrunner-1.9, and the one in the archive is built with firefox-dev -- modest requires xulrunner-1.9 and gets upset if libtinymail isn't using what it needs.
[03:20] <RAOF> K.
[03:20] <RAOF> Eh, run an apt-ftparchive over it then, please :)
[03:21] <StevenK> RAOF: Done.
[03:22] <RAOF> Ta.
[03:23] <RAOF> Let the scratch schrooting begin.
[03:23] <RAOF> ...at the blistering speed of 15kb/s :(
[03:23] <StevenK> Yeah, well, it is using my upstream
[03:24] <StevenK> I suspect the dput I just started isn't helping. :-)
[03:24] <RAOF> No, that's my downstream.  I'm updating my chroot first.
[03:24] <StevenK> Ah
[03:24]  * StevenK hugs his local mirror
[03:25]  * RAOF should buy one of these new-fangled 1TB drives and get him a mirror.
[03:25]  * Fujitsu mounr nhis local mirror.
[03:25] <Fujitsu> Bahh, lag.
[03:25] <Fujitsu> *mourns his
[03:25] <StevenK> Fujitsu: What about it?
[03:25] <Fujitsu> It got eaten by a buggy Gutsy debmirror last week.
[03:25] <RAOF> Presumably it's messy & untimely death.
[03:26] <StevenK> Oh.
[03:26] <StevenK> This is why my mirror runs Dapper.
[03:26] <imbrandon> apt-mirror ftw :)
[03:26] <StevenK> Anyway, I think debmirror is crap, and I need to write something better.
[03:26] <imbrandon> infact i need to request some backports for it
[03:26] <Fujitsu> StevenK: So did mine. And the fix got pushed to -updates within 72 hours.
[03:27] <imbrandon> StevenK: help improve apt-mirror then, or join me and Fujitsu in planning/coding apt-mirror-ng ( pythonized )
[03:27] <imbrandon> :)
[03:27] <Fujitsu> Haha.
[03:27] <Fujitsu> debmiror is really inflexible.
[03:27] <Fujitsu> +r
[03:27] <StevenK> imbrandon: Can I get apt-mirror to download i386, amd64 and lpia for gutsy,gutsy-updates,gutsy-security,hardy and installer-i386,installer-amd64 for gutsy,hardy in one easy command?
[03:27] <RAOF> Thank you, irssi, for preventing me from pasting 22 lines of crap.
[03:27] <imbrandon> StevenK: yup
[03:27] <Fujitsu> StevenK: that was my main problem.
[03:28] <imbrandon> StevenK: actualy you can :)
[03:28] <StevenK> Is it written in Perl?
[03:28] <Fujitsu> Thankyou, 'softies, for downloading a coupl of service packs and making my connection very laggy.
[03:28] <Fujitsu> StevenK: Yes, it's one 500 line file.
[03:28] <Fujitsu> It's very ugly.
[03:28] <imbrandon> yes, unfortunately
[03:28] <StevenK> imbrandon--
[03:28] <imbrandon> i wanna redo it in python someday :)
[03:29] <imbrandon> but atm its perl in all its glory
[03:29]  * Fujitsu decrements StevenK.
[03:29] <imbrandon> one perl file ( ~500 lines of code ) and one config ( /etc/apt/mirror.list )
[03:30] <StevenK> Actually, no, it also needs to pull amd64 and i386 from one place and lpia from another. :-)
[03:31] <somerville32> RAOF, it is slow :]
[03:31] <imbrandon> yea thats doable
[03:32] <imbrandon> StevenK: it takes sources.list lines only modified like deb-i386 deb-lpia etc
[03:32]  * TheMuso returns.
[03:32] <imbrandon> so its totaly doable
[03:32] <somerville32> RAOF, Can you install stuff like, you know... dh-make? :P
[03:34] <RAOF> somerville32: done.
[03:34] <StevenK> imbrandon: Can you pastebin a conffile?
[03:34] <RAOF> somerville32: Anything else?  I usually use that box as just a buildd, so it probably doesn't have much in the way of development utils.
[03:34] <imbrandon> StevenK: yea one sec
[03:35]  * TheMuso wonders how long he will be online before the storm decides to knock out power.
[03:36]  * RAOF should move to the mountains.  He always misses out on the cool storms.
[03:36] <StevenK> Heh
[03:36] <TheMuso> Heh.
[03:38] <imbrandon> StevenK: http://paste.ubuntu.com/2372/
[03:39] <imbrandon> StevenK: with a config like that you litterly just run "10 * * * * apt-mirror apt-mirror" in a cron
[03:40] <StevenK> Mmm
[03:40] <imbrandon> ( after initial sync ofcourse )
[03:40] <imbrandon> and optionaly the clean.sh it generates ( cleaning removed packages )
[03:41] <StevenK> RAOF: Still poking at modest with a stick?
[03:42] <imbrandon> StevenK: it supports these arches .... ( more could be added trivialy )
[03:42] <imbrandon> if($config_line =~ /deb-(alpha|amd64|armel|arm|hppa|hurd-i386|i386|ia64|m68k|mipsel|mips|powerpc|s390|sh|sparc)/) {
[03:42] <RAOF> StevenK: Still updating my chroot with a straw.
[03:42] <imbrandon> StevenK: e.g. lpia :)
[03:42] <RAOF> StevenK: 14.8kB/s 18m13s
[03:42] <StevenK> RAOF: Heh, fair enough. It seems my local mirror has spoilt me
[04:00] <imbrandon> ohhh i'm in love, anyone ever messed with a picotux ?
[04:00] <imbrandon> http://www.picotux.com
[04:01] <RAOF> Ah, one of *those* things.
[04:03]  * RAOF plays around with confusing awn into believing that unminimizing a window creates a new task
[04:15] <StevenK> RAOF: Surely the chroot is up to date now? :-)
[04:15] <RAOF> Yes, indeed.
[04:37] <StevenK> RAOF: No news is good news?
[04:38] <RAOF> There's a downside to using a disposable chroot.
[04:38] <StevenK> Oh? It all went?
[04:38] <RAOF> It's that there's a lot of deps that need to be downloaded before anything interesting happens.
[04:39] <StevenK> I'll put it down to local mirror love again. :-)
[04:39]  * RAOF looks at prices for hard drives.
[04:41] <StevenK> RAOF: You don't have a spare 60G?
[04:41] <Hobbsee> RAOF: btw, you going to slug tonight?
[04:41] <RAOF> Not really.
[04:41] <RAOF> Hobbsee: No.  Still sick.
[04:42] <Hobbsee> :(
[04:42] <RAOF> I presume no one at slug is going to be particularly interested in contracting week long evil cough.
[04:42] <RAOF> With bonus bilateral middle ear infection!
[04:44] <StevenK> RAOF: Ugh
[04:44]  * StevenK tries to debug hildon input method some more
[04:44] <RAOF> Hm.  I totally have 60Gb free.
[04:44] <RAOF> apt-mirror, you say? :)
[04:45] <StevenK> I use debmirror, but want to replace it.
[04:45] <StevenK> RAOF: /dev/mapper/system-mirror 60G   45G   15G  76% /srv/mirror
[04:46] <StevenK> RAOF: That's gutsy{,-{security,updates}},hardy amd64 and i386
[04:46] <RAOF> Binary only?
[04:47]  * RAOF starts working the LVM foo.
[04:47] <StevenK> RAOF: Right.
[04:49] <StevenK> RAOF: It took me about four days to seed my mirror, given I only want to pull down during my uncounted period.
[04:49] <RAOF> It'll take me somewhat longer :)
[04:50] <RAOF> However, this is not going to be terribly useful while I'm capped.
[04:54] <StevenK> RAOF: But you're ADSL2+, and I'm only 1.5 ....
[04:55]  * StevenK needs to figure out how to get 30Gb down to his mother in law's place so he can upgrade his sister in laws machine to Gutsy
[04:55] <StevenK> If only Ethernet wasn't limited to 100m
[04:56] <StevenK> (And there wasn't a main road to cross)
[04:56] <RAOF> Get yourself some gigibit :P
[04:56] <StevenK> My switch is gigabit rated :-)
[04:56] <RAOF> Cars will barely notice the twisted pair.
[04:56] <StevenK> RAOF: Yes, but other people might
[04:57] <Hobbsee> bring SIL's machine to your house?
[04:57] <RAOF> Paint it red & white striped, or something.
[04:57] <StevenK> RAOF: I wonder if it would have been faster to give you an account on my machine.
[04:57] <StevenK> Hobbsee: I've been pondering that
[04:57] <RAOF> StevenK: Survey says: yes.  It may still be faster to do so.
[04:58] <Burgundavia> ahh, yes, the end of the earth, where bandwidth sucks
[04:58] <StevenK> RAOF: Okay, running adduser
[04:58] <persia> Nah.  Austalia's way better than New Zealand, which is itself better than Fiji
[04:58] <persia> r
[04:58] <RAOF> My bandwidth is fine until I download the 50Gb or whatever it is that my cap is.
[04:58] <RAOF> After that... not so good.
[04:59] <Burgundavia> what is this "cap" you speak of?
[04:59] <persia> RAOF: Is it a cap on the local pipe, or a cap on international traffic?
[04:59] <RAOF> persia: Local pipe.
[05:00] <RAOF> Down to a swanky 128kbit/sec.
[05:00] <persia> RAOF: Ah, so even a faster / better / cleaner mirror in AU wouldn't help :(
[05:00] <DarkMageZ> Burgundavia, isp's over here allocate you X amount of traffic a month. once you hit the cap. all sorts of things can happen depending on the agreement.
[05:00] <persia> DarkMageZ: I'm sure I've encountered unlimited domestic plans before (with an international cap)
[05:00] <RAOF> If you're on a Telstra plan, for example, you can then pay an additional 2 cents / MB bywnloaded.
[05:01] <StevenK> It isn't 2 cents, it's more like 18
[05:01] <superm1> Amaranth, did you ever have any luck with the touch?
[05:01] <StevenK> Which works out to be roughly $250 per GB
[05:01] <persia> Per Megabyte?  That's madness!
[05:01] <Amaranth> superm1: no
[05:01] <StevenK> persia: Yup, per megabyte
[05:01] <superm1> that's unfortunate
[05:01] <Fujitsu> persia: That's Australia.
[05:01] <Amaranth> superm1: i'm sending the _exact_ same thing iTunes does and getting no response
[05:01] <Amaranth> superm1: so i'm stumped
[05:01] <DarkMageZ> persia, it's not madness. it's telstra. an extremist form of madness.
[05:01] <StevenK> Meanwhile, my ISP charges $3/GB
[05:02] <Fujitsu> Yay, now-private monopolies..
[05:02] <StevenK> (Excess usage)
[05:02] <RAOF> My last ISP charged $2/GB
[05:02] <superm1> Amaranth, perhaps considering its a handshake, you need to be responding differently depending on the data you see
[05:02] <persia> Fujitsu: I disagree: not everything in Australia is backwards & upside-down
[05:02] <Amaranth> superm1: no no, i mean at the very beginning
[05:02] <superm1> Amaranth, have you compared two transmissions to see if they are always identical between iTunes and the touch
[05:02] <Amaranth> superm1: i can't get the touch to talk to me _at all_
[05:02] <Amaranth> no, i also can't use the touch in vmware (vmware bug) so i only have the one dump
[05:02] <Amaranth> but this is the first command you send to the phone
[05:03] <Amaranth> before you setup any kind of handshake or anything else
[05:03] <Amaranth> just saying 'hello' and getting a response
[05:03] <superm1> Amaranth, well what you are forgetting is that there may be some communication with the driver
[05:03] <superm1> in the OS
[05:03] <superm1> before iTunes says hello
[05:03] <Amaranth> afaik they don't have a driver for it, just a dll
[05:03] <superm1> really.
[05:03] <superm1> hm
[05:03] <superm1> they do have a service running though
[05:04] <superm1> that may handle that portion yet too
[05:04] <Amaranth> yeah but a kernel-level usb sniffer should see anything they do
[05:04] <superm1> yea
[05:04] <Amaranth> i did get some 'magic' command from an iphone kernel module (to make it charge) that made the whole thing at least not error out
[05:04] <Amaranth> but i get 0 bytes when i try to read
[05:05] <superm1> well then this is all rather perplexing as you describe it
[05:05] <Amaranth> yes
[05:05] <Amaranth> there is some header on the first bit of xml sent (and on every bit of xml sent)
[05:06] <superm1> dependent on what happens with that handshake this header?
[05:06] <Amaranth> i think it might be a checksum of some sort
[05:06] <superm1> including the first hello?
[05:06] <Amaranth> no no, they use SSL to hide stuff, you can see that later on
[05:06] <superm1> that checksum?
[05:06] <Amaranth> but yeah, the first XML bit has it
[05:07] <superm1> too bad you only have one transmission to look at
[05:07] <superm1> to see if its the same each time
[05:07] <Amaranth> will be able to get more tomorrow
[05:07] <superm1> cool ok
[05:07] <Amaranth> and with me guiding the thing instead of someone doing 'something' and then sending it to me
[05:07] <Amaranth> and with better tools, this one outputs some HTML crap
[05:08] <superm1> Amaranth, i'm not even familiar with any tools for these tasks whatsoever
[05:08] <Amaranth> i've got a couple
[05:08] <superm1> Amaranth, are similar tools available for mac os?
[05:08] <Amaranth> and if vmware fixes their bug i'll be able to see even more
[05:08] <superm1> Amaranth, i'll be able to hook up to my friends to do some stuff there possibly
[05:08] <Amaranth> no, there is only a tool to sniff _all_ USB traffic, then you have to figure out what is what later
[05:09] <superm1> ick
[05:16] <LaserJock> evening folks
[05:16] <Fujitsu> Evening, LaserJock.
[05:17] <LaserJock> oh, poor somerville32
[05:17] <LaserJock> :-)
[05:17]  * somerville32 moans.
[05:17] <LaserJock> I feel for you man
[05:18] <StevenK> LaserJock: Ponies!
[05:18]  * RAOF feels for StevenK's ponies.  They must get awfully skittish.
[05:19] <StevenK> Ha
[05:19]  * somerville32 slowly and sadly writes an e-mail to elmo
[05:19] <nxvl> ScottK: around?
[05:20] <LaserJock> somerville32: I had to write one of those once
[05:21] <somerville32> LaserJock, really? Did elmo kill you? :P
[05:21] <LaserJock> to the Uni IT head
[05:21] <somerville32> Oh
[05:21] <LaserJock> not to elmo
[05:21] <somerville32> Who do you think would be easier? IT Head or Elmo?
[05:21] <LaserJock> after my uni computer was pinging https ports on 300k computers
[05:21] <LaserJock> somerville32: oh, IT Head for sure
[05:21] <LaserJock> elmo will eat a person alive
[05:22] <LaserJock> ;-)
[05:22] <somerville32> My career is so over :(
[05:22] <somerville32> lol
[05:22] <superm1> somerville32, why slowly and sadly?
[05:22] <somerville32> superm1, because I'd rather not to disclose the situation to elmo :P
[05:22] <superm1> what situation?
[05:23] <somerville32> Erm, lets not discuss this further
[05:23]  * somerville32 shuts his mouth to prevent further embarrassment 
[05:23] <somerville32> LaserJock, You should send me a cheese platter or something :P This is going to be rough.
[05:23] <LaserJock> somerville32: oh, it's not that bad dude, you just gotta deal with it which is no fun
[05:23]  * StevenK tells LaserJock to read #ubuntu-devel logs
[05:24] <LaserJock> me? I already read them
[05:24] <somerville32> StevenK, Do you think it is _that_ bad?
[05:24] <StevenK> Yes.
[05:24] <superm1> is there a time frame from the logs to be looking at?
[05:25] <somerville32> superm1, My private keys have been compromised, thats the story
[05:25] <superm1> oh that's horrible
[05:25] <superm1> so sorry to hear that
[05:25]  * somerville32 cries.
[05:26] <StevenK> superm1: From 15:04 local time, it's currently 14:26
[05:26] <StevenK> So, an hour and a half ago
[05:26]  * superm1 sees
[05:27] <LaserJock> do ssh keys have a revocation?
[05:27] <somerville32> LaserJock, I just need to get them to change the key
[05:27] <ajmitch> 'just'
[05:27] <LaserJock> ajmitch: that's not too hard is it?
[05:27] <somerville32> Now everyone knows and now I'm horribly embarrassed :(
[05:27] <somerville32> It wasn't like criminals got a hold of it or anything
[05:28] <ajmitch> depends on what access he had to servers
[05:28] <LaserJock> yeah
[05:28] <ajmitch> it's more a matter of trust than of difficulty
[05:28] <somerville32> I didn't know better! : (
[05:28] <StevenK> That's no excuse
[05:29] <RAOF> Well, it's a bit of an excuse.  It just doesn't help very much.
[05:29] <ajmitch> to get access restored, you may need a signed email, signed by a new, trusted gpg key
[05:29] <somerville32> Well, I know better now
[05:29] <StevenK> That someone else has signed.
[05:29] <ajmitch> so getting signatures on that new gpg key, so that the ssh key can be trusted
[05:30] <somerville32> So you guys won't sponsor my uploads until then?
[05:30] <StevenK> Personally, I won't.
[05:30] <somerville32> Even though I haven't used gpg key for ages?
[05:30] <StevenK> What the other people do is up to them.
[05:30] <somerville32> *that
[05:30] <somerville32> The key I have been using is secure
[05:31] <somerville32> The GPG key was old and I haven't used it for awhile. The issue, really, is the ssh-keys
[05:31]  * persia doesn't trust anyone's signature anyway, so might sponsor something if the work could be fully reconstructed.
[05:31] <StevenK> persia: Because you've not met anyone?
[05:32] <persia> StevenK: No, because I don't like to sponsor based on the person doing the work, but only on the work itself.
[05:32] <persia> Everyone makes mistakes, so it's better to review than trust them because they are a good person.
[05:33] <persia> If one is reviewing the work anyway, the signature no longer matters.
[05:33] <StevenK> RAOF: That rain has just hit here, so you might get it after all
[05:33] <RAOF> StevenK: Yay!
[05:34]  * Fujitsu laments the lack of rain.
[05:35] <StevenK> Hah. It's Melbourne, it probably stopped raining about five minutes ago.
[05:35] <Fujitsu> Hah, no.
[05:55] <imbrandon> hrm , can you use if/else in a rules file ?
[05:55] <StevenK> imbrandon: ECONTEXT
[05:57] <imbrandon> like if i wanna set a var in debian rules like ummm dist=(shell lsb_release -si) , but i need to use a if statement to set that to a default if its blank
[05:57] <persia> imbrandon: Yes, but you want to use make-style conditionals, rather than shell-style conditionals.
[05:57] <imbrandon> %if  %else %fi ?
[05:59] <persia> imbrandon: http://www.gnu.org/software/make/manual/make.html#Conditionals, but there's a special shortcut for handling default variable values.  I'm looking now.
[05:59] <imbrandon> k
[06:01] <persia> Right: "FOO ?= bar" sets the default if $(FOO) is unset, so could be used following the normal FOO definition.
[06:02] <imbrandon> killer so i could just add dist ?= "somethng"
[06:02] <imbrandon> on the next line
[06:02] <imbrandon> ( using that example )
[06:02] <imbrandon> or rather dist ?= something
[06:02] <imbrandon> but still
[06:03] <imbrandon> any ok, one other ( should be simplish ) question while i have a few ears ... how evil is it to, say , ummm
[06:03] <imbrandon> ok i ship the conf file in debian/my.conf
[06:04] <imbrandon> if i run sed over that BEFORE i try to install it in etc
[06:04] <imbrandon> so the debconf will still try to diff if its ... hrm
[06:04] <imbrandon> or i guess i could try a debian/my.conf.in
[06:05] <imbrandon> ...
[06:05] <imbrandon> and use subsitution vars
[06:08] <imbrandon> this would be the current rules : http://people.ubuntuwire.com/~imbrandon/source/apt-mirror/apt-mirror-0.4.4+debian/debian/rules , i already have it with custom files for debian/ubuntu and that seems to work perfect, but i would also like the ubuntu-mirror.list to be based on the env it was built in
[06:08] <persia> imbrandon: Depends on whether you're better with set or automake.  Both work.  Do it in "build" rather than in "install".
[06:08] <imbrandon> e.g edgy for edgy , dapper for dapper etc
[06:09] <imbrandon> yea i'm doing all this in build, i dont wanna do it at install time
[06:09]  * persia advocates the use of [\d\.]* in place of .*
[06:09] <persia> (for versions)
[06:10] <imbrandon> yea i need to fix that next, the version is 0.4.4 but its reporting 0.4.4-2 from upstream
[06:10] <imbrandon> thus looks like there is a new version upstream ready but there isnt
[06:10] <persia> imbrandon: Ah.  Right.  I remember now.  Annoying upstream.  uversionmangle ought to help.
[06:10] <imbrandon> yea
[06:11] <imbrandon> ok see how i'm using dist= there and then in the install of the conf from debian/
[06:11] <persia> Just in case someone decides to change dh_installman behaviour, you might want to run pod2man in build and into debian/apt-mirror.1, and then compress/install with debhelper (doesn't really matter).
[06:11] <imbrandon> if its Ubuntu i want to run sed over the debian/Ubuntu-mirror.list prior to installation
[06:12] <persia> Right.  You want to construct debian/${builddist}-mirror.list at build-time?
[06:13] <imbrandon> well really just subsitute a few varables in it, but basicly yes
[06:13] <imbrandon> a simple s/hardy/dapper/g debian/Ubuntu-mirror.list would do what i wish
[06:14] <persia> To make the clean rule act properly, I'd suggest starting with base-mirror.list, and then s/DIST/${builddist}/g to generate your list.
[06:14] <imbrandon> but i dident know if that was "evil" in any way, as i've not seen others do it
[06:14] <imbrandon> well the debian and ubuntu ones are totaly diffrent
[06:14] <persia> (or mirror.list.in)
[06:14] <imbrandon> i would have to change more than dist
[06:14] <imbrandon> also mirror url
[06:15] <imbrandon> and components
[06:15] <persia> Ah.  Right.  You'd need to have Debian-mirror.list.in and Ubuntu-mirror.list.in and choose the source based on lsb-release data.
[06:15] <imbrandon> right
[06:17] <persia> So, you set a variable to be "Debian" or "Ubuntu", and sed s/DIST/${buildrelease}/g $(CURDIR)/debian/${builddist}-mirror.list.in > debian/${buildrelease}-mirror.list
[06:17] <imbrandon> yea technicly i dont think its an issue
[06:17] <persia> And then remove debian/${buildrelease}-mirror.list in clean:
[06:18] <imbrandon> right
[06:18] <imbrandon> i currently do almost exactly that
[06:18] <imbrandon> but ummm i was more talking aobut the sub ubuntu sed, eg the release
[06:18]  * persia is probably looking at old rules then
[06:19] <imbrandon> nah your looking at the right one if its from that link
[06:19] <imbrandon> but i dont think you understand what i mean. i currently do so what you are speaking of, using a var to decide the Debian or Ubuntu and install based on that
[06:19] <persia> From here, it looks like you've manually constructed all possibilities of ${builddist}-mirror.list, which breaks for a new model.
[06:20] <imbrandon> right
[06:20] <imbrandon> exactly
[06:20] <persia> Anyway, thinking about it, I'm convinced that build-time is not the right time to do it if you want it to work for debian: you should construct your -mirror.list file at install time, else all Debian users will always get "unstable".
[06:21] <imbrandon> i'm not so much worried about the debian/ubuntu thing , i'm trying to build upon that to also make it release specific now too
[06:21] <persia> So, in your postinst, you generate the list based on the machine onto which you are installing.
[06:22] <imbrandon> right but with postinst it will not complain if i try to overite a file in /etc/ , i dont wanna clobber someones already in place config
[06:22] <imbrandon> correct ?
[06:22] <persia> imbrandon: Then test for the existence of the file: if it is present, don't clobber.
[06:22] <LaserJock> can you read it form /var/ or something
[06:22] <Fujitsu> Ooh, new kernel, in a strange source package.
[06:23] <LaserJock> Fujitsu: ?
[06:23] <RAOF> Now with shiny new tickless x86-64!
[06:23] <imbrandon> persia: well dpkg already takes care of it if i use install blah in rules, thus i would like to do it at build time, so the end user has the choice of seeing a "diff" produced by dpkg
[06:24] <persia> imbrandon: Right, but if you do it at build time, you guarantee that it breaks for all Debian users, as it always generates "unstable".
[06:24] <Fujitsu> LaserJock: The source package now seems to be `linux'.
[06:24] <persia> That's actually a pretty good name: matches upstream :)
[06:24] <imbrandon> yea but the migration from unstable to testing to stable, i forget its only built once
[06:25] <imbrandon> hrm
[06:25] <Fujitsu> persia: Right, it makes more sense.
[06:26] <imbrandon> i wish i knew of another package that did something similar ...
[06:26] <imbrandon> hrm
[06:26] <StevenK> Heh, and FTBFS everywhere but i386 and amd64
[06:26] <imbrandon> *thinks*
[06:26] <persia> I'm also happy to see .24.  Up until now I was under the impression we might have .23.
[06:26] <StevenK>  LD [M]  net/tipc/tipc.o
[06:26] <StevenK> make[2]: *** [sub-make] Error 2
[06:26] <StevenK> make[1]: *** [all] Error 2
[06:26] <Fujitsu> persia: It was decided during UDS that it would be .24.
[06:26] <StevenK> Okay then
[06:27] <Fujitsu> StevenK: Riight.
[06:27] <Fujitsu> Looks special.
[06:27] <persia> Fujitsu: I guess I only saw half that conversation then: I remember fears that .24 wouldn't be entirely stable.
[06:27] <TheMuso> Fujitsu: 2.6.24 is in rc now afaik
[06:27] <imbrandon> ok so am i correct in saying if i do it in postinstall i'll have to manualy check for prior existance and "do the right thing"
[06:27] <TheMuso> s/fujitsu/persia
[06:28] <persia> TheMuso: Yep.
[06:28] <imbrandon> or is there a way to use the rules "install" method there also
[06:28] <persia> imbrandon: Yes, and I think you can't have it be a conffile, as you won't know the md5sum in advance.
[06:28] <imbrandon> cruft, ok
[06:29] <StevenK> TheMuso: No SLUG tonight?
[06:30] <imbrandon> LaserJock: yea as far as that goes i can have it look anywhere for the conffile but that dident really help the issue
[06:30] <imbrandon> :)
[06:31] <LaserJock> imbrandon: no?
[06:31] <TheMuso> StevenK: I don't usually go anyway, but we have family here as it is.
[06:31] <imbrandon> in that i still wouldent want it to clobber someone existing conf
[06:31] <StevenK> TheMuso: Ah
[06:32] <TheMuso> StevenK: I would go if something interested me that was being talked about.
[06:32] <LaserJock> imbrandon: well, the program should take care of that
[06:32] <StevenK> TheMuso: But elky's talking tonight!
[06:32] <imbrandon> LaserJock: hehe should != does
[06:33] <LaserJock> imbrandon: well, that's your problem right there :-)
[06:33] <TheMuso> StevenK: She is? I didn't see that. Oh well, as I said, family are here.
[06:34] <TheMuso> And at this rate, I wouldn't make it.
[06:34] <persia> LaserJock: It also has to support users who want to mirror distributions other than native, no?
[06:35] <LaserJock> persia: right, so the program should install defaults to /usr/share/ or something
[06:35] <LaserJock> and at runtime determine what to do?
[06:36] <LaserJock> i haven't followed the whole conversation so I'm not all up on the requirements and constraints
[06:36] <persia> LaserJock: defaults for each release, with a new update whenever one is defined?  Still, what is the initial configuration?  Debian stable?
[06:36] <imbrandon> LaserJock: its for apt-mirror :)
[06:36] <LaserJock> look at lsb-release?
[06:36] <imbrandon> ( e.g. the mirror.list conffile )
[06:37] <LaserJock> right
[06:37] <persia> Requirements: 1) preserve user preferences, 2) construct a single configuration method that works for Debian and Ubuntu, 3) set a default native mirror when installed.
[06:37] <imbrandon> right but what about those that DONT want to mirror the installed release and instead change it to something else
[06:37] <LaserJock> then they set a conf file somewhere else
[06:37] <LaserJock> just layer the config
[06:37] <persia> Erm.  Maybe going with no default, and shipping some samples with dh_installexamples is the way to go...
[06:37] <LaserJock> look in /etc/mirror.list for user-defined list
[06:38] <LaserJock> if not check lsb-release and use the appropriate one from /usr/share/
[06:38] <imbrandon> hrm , would require some code changes ...
[06:38] <persia> LaserJock: So construct all reasonable configs at build time, and ship them all in /usr/share/apt-mirror/config/ ?
[06:38] <LaserJock> yep
[06:39] <LaserJock> that would also give people easy things if they don't want the default
[06:39] <LaserJock> just cp /usr/share/apt-mirror/config/<one you want> /etc/
[06:40] <imbrandon> so if /etc/apt/mirror.list exist use it, if not use sane default
[06:40] <persia> And then hand-modify if you want some "super newest" broken mix of sid+hardy.
[06:40] <LaserJock> yep
[06:41] <imbrandon> hrm ... sounds good , but more suited for apt-mirror-ng :)
[06:41] <imbrandon> but then again  ....
[06:41] <imbrandon> hrm
[06:41] <persia> It's aggressively engineered, supports lots of cases, and sounds reasonable, but it uses some extra space.  Perhaps just use /usr/share/doc/apt-mirror/examples for now, unless you like patching monolithic perl.
[06:42] <LaserJock> a wrapper script could do it
[06:42] <persia> LaserJock: How?  redirect fs calls based on the presence or absence of a file?
[06:43] <LaserJock> well hmm
[06:43] <imbrandon> well it could cp the file if non exist and that becomes the default ( that way on dist-upgrade also the current mirror dosent suddenly want to download 30GB )
[06:43] <persia> (or just copy the default file to /etc/apt-mirror/foo-mirror.list at runtime)?
[06:43] <LaserJock> how is it getting it's config now?
[06:43] <imbrandon> LaserJock: decided at build time in rules , http://people.ubuntuwire.com/~imbrandon/source/apt-mirror/apt-mirror-0.4.4+debian/debian/rules
[06:43] <imbrandon> via two configs i pre-made
[06:43] <persia> if dist-upgrade breaks a local mirror (which makes sense), that definitely belongs in debian/README.Debian
[06:44] <LaserJock> imbrandon: ok, but at runtime, it just reads /etc/mirror.list?
[06:44]  * persia thinks build-time is usually good for Ubuntu and usually bad for Debian
[06:44] <imbrandon> LaserJock: /etc/apt/mirror.list, but yes
[06:44] <LaserJock> k
[06:44] <LaserJock> so it uses that if available
[06:45] <LaserJock> and if it's not there (new install or whatever) then it uses the default
[06:45] <LaserJock> seems like a wrapper script can handle that no?
[06:46]  * persia likes postinst better than a wrapper script if it only copies once in most cases
[06:46] <imbrandon> yea really i could do that, but just do it via postinst
[06:46] <imbrandon> new installs would get one tailord for the running OS and old installs would be left alone
[06:47] <LaserJock> fine, be that way ;-)
[06:47]  * persia still thinks it can't easily be a conffile, and it may as well be generated with sed at install time rather than shipping lots of different configurations
[06:48] <LaserJock> postinst seems perfectly reasonable to me
[06:48] <persia> LaserJock: For apt-mirror-ng, where upstream is nearby and sane, your solution is vastly better :)
[06:48] <imbrandon> hrm yea, persia thats what i keep comming back to
[06:49] <imbrandon> yea upstream is on crack for this one, but honestly i havent found anythign better yet, thus i guess i'm ( with possibly Fujitsu's help because he expressed intrest ) gonna make apt-mirror-ng
[06:49] <LaserJock> hmm
[06:50] <LaserJock> it seems like we have a lot of apps for this kind of thing
[06:50] <imbrandon> hrm and in reality the current state could be "good enough" if i just left it as is
[06:50] <Fujitsu> LaserJock: i know of two, and they're both evil and perl, and the less evil one is completely inflexible.
[06:50] <imbrandon> LaserJock: we was just discussing this earlier :) non seem as flexable as apt-mirror ( e.g. debmirror )
[06:51] <LaserJock> well, I use reprepro
[06:51] <persia> LaserJock: They are all 40-70% of the way there, but get reinvented rather than patched as it looks like an easy task.
[06:51] <LaserJock> then debmirror, rsync, apt-mirror
[06:51] <imbrandon> thats to make a new repo
[06:51] <LaserJock> I wonder if falcon can do it
[06:51] <LaserJock> imbrandon: it can also easily mirror
[06:51] <imbrandon> falcon CAN but its not designed to
[06:51] <persia> falcon isn't a mirror
[06:52] <LaserJock> well, what I guess I'm saying is, do we need different apps for mirroring and creating repos
[06:52] <imbrandon> persia: falcon can mirror a repo, but arch and component model like apt-mirror is very diffrent
[06:52] <persia> LaserJock: The current state of affairs is itchy.
[06:52] <LaserJock> it'd be nice to have one app that rules them all ;-)
[06:52] <imbrandon> LaserJock: yea , i think they are very diffrent tasks
[06:52] <imbrandon> i do them both
[06:52] <LaserJock> imbrandon: how so?
[06:52] <LaserJock> it's all managing a repo
[06:52] <persia> imbrandon: I guess.  I like falcon, but don't think it's suitable for much other than private repos with 15-50 apps.
[06:53] <LaserJock> whether it is from a remote or local source is somewhat irrevelvant no/
[06:53] <Fujitsu> debmirror/apt-mirror don't manage repos.
[06:53] <LaserJock> ?
[06:53] <LaserJock> sure
[06:53] <LaserJock> just in a very limited way
[06:53] <Fujitsu> They selectively drag in bits from other sources, but don't regnerate any files.
[06:53] <imbrandon> LaserJock: no they use the same sigs and all
[06:53] <imbrandon> thus make true mirrors
[06:53] <LaserJock> I just don't see how they're all that different
[06:53] <persia> LaserJock: For a mirror, you don't typically want to manage the repo, as you want to save on local CPU.
[06:54] <LaserJock> I think syncing is managing
[06:54] <imbrandon> also you dont want the ability to change a mirror typicly, you want it to match the md5sums and sigs from the orig repo
[06:54] <persia> For a repo, you want to build the Packages.gz Contents.gz and Sources.gz, and manage the pool in a sensible way, but aren't as careful about CPU.
[06:54] <TheMuso> c
[06:54] <TheMuso> ugh
[06:54] <LaserJock> but I guess my vocab is a bit different
[06:55] <LaserJock> what I'm saying is it's all kinda the same stuff
[06:55] <LaserJock> so why not superdupertool --mirror for mirroring
[06:55] <imbrandon> kinda but enough diffrent it definatly requires diffrent tools
[06:55] <persia> LaserJock: Probably: it sounds like a nomenclature issue.  My position is that there's once case where you construct metadata, and another where you copy some other metadata, and these are fundamentally different in terms of desired optimisations.
[06:55] <LaserJock> and superdupertool --repo for managing a repo
[06:55] <Fujitsu> LaserJock: Do one thing, and do it well.
[06:55] <LaserJock> Fujitsu: well ...
[06:55] <LaserJock> that only goes so far
[06:56] <LaserJock> at some point it's annoying to have to have a lot of different tools to do similar things
[06:56] <imbrandon> ok LaserJock lets put it like this, there would probably be less than %5 code sharing between the activities so why combine them ?
[06:56] <LaserJock> why would it be that little?
[06:56] <imbrandon> the are very fundimentaly diffrent, one copys one generates
[06:57] <persia> LaserJock: Because the only commonality is the directory structure.
[06:57] <imbrandon> even if the results are similar
[06:57] <LaserJock> right but copy and generate seem pretty similar
[06:57] <imbrandon> not code wise
[06:57] <LaserJock> cp and mv are fairly similar
[06:57]  * persia suggests linking cp to vi
[06:57] <LaserJock> right
[06:57] <LaserJock> there's lots of similar structure
[06:57] <imbrandon> right but its not a matter of cp and mv, its more like cp and gedit
[06:58] <persia> between "cp" and "vi"?
[06:58] <LaserJock> no
[06:58] <LaserJock> like you're creating the same thing
[06:58] <imbrandon> LaserJock: only in the end result, not the way you get there
[06:58] <persia> That's what you're talking about.  A copy program and an editor.
[06:58] <LaserJock> just in one case you're getting remotely
[06:58] <LaserJock> in the other you're getting "internally"
[06:58] <imbrandon> no
[06:58] <imbrandon> see thats where your wrong
[06:58] <LaserJock> ok, my bad then
[06:58] <persia> LaserJock: Same for cp & vi, no?
[06:58] <Fujitsu> The mirroring programs are basically selective recursive wgets. The don't modify any files.
[06:59] <LaserJock> when I use reprepro it's cping
[06:59] <Fujitsu> s/The d/They d/
[06:59] <imbrandon> one your getting remotely packages and metadata. the other your getting remotely packages but not metadata
[06:59] <imbrandon> e.g. the %5 woudl be the easy part of "getting"
[06:59] <LaserJock> I just think from a end-user perspective they are similar tasks
[06:59] <persia> LaserJock: It cp's the .dsc, .diff.gz, .orig.tar.gz, and the .deb, but that's not the interesting part.
[06:59] <LaserJock> and it'd be nice to have a common interface, etc.
[07:00] <persia> LaserJock: Why?  The use cases are different.  I want a repo if I am publishing.  I want a mirror if I want to aggegrate bandwidth, but don't want to have that much on a proxy.
[07:00] <LaserJock> often times people want to do both
[07:00] <imbrandon> right, the end users are totaly diffrent groups
[07:00] <StevenK> I didn't see any mirroring functionality in reprepro.
[07:00] <StevenK> Besides, reprepro is a pile of crap.
[07:01] <LaserJock> heh
[07:01] <persia> LaserJock: Why would anyone want to do both with the same program?  How might that work?
[07:01]  * Fujitsu defers to StevenK's judgment.
[07:01] <Fujitsu> +e
[07:01] <imbrandon> LaserJock: no many many many uni's and such run mirror, very few run repos :)
[07:01] <LaserJock> I used reprepro for some time
[07:01] <LaserJock> imbrandon: lots of companies run both
[07:01] <persia> LaserJock: Right.  Companies run both, but usually in different repos, and have different management constraints for each.
[07:02] <imbrandon> not on the same hardware normaly, they are diffrent tasks
[07:02] <imbrandon> persia: exactly
[07:02] <persia> These constraints are driven by the business goals, and the interface doesn't matter.
[07:02] <LaserJock> it's common, I think anyway, to have a mirror and then a repo besides for custom packages
[07:02] <LaserJock> ok fine :-)
[07:02] <persia> imbrandon: Can be the same hardware, just different IPs or different subdirectories.  Depends on the HW budget.
[07:02] <imbrandon> yea, but same idea
[07:02] <LaserJock> *I* would find it useful, but I guess I"m a corner case, as usual ;-)
[07:02] <somerville32> What is up with the "dash, getconf and a POSIX sh" thread on the mailing list?
[07:03] <persia> LaserJock: It may be common, but it's not ideal to mix them, as the keys are different, so they have different trust paths.
[07:03] <Fujitsu> somerville32: Which ML?
[07:03] <somerville32> I thought dash was POSIX compliant and that Bash was not so much :/
[07:03] <somerville32> ubuntu-devel
[07:03] <persia> somerville32: dash wants patches, but only for rare corner cases.
[07:03] <Fujitsu> dash has some slight non-compliances, and bash a lot of extensions.
[07:04] <persia> Isn't bash also missing a couple tiny compliance issues as well?
[07:04] <Fujitsu> persia: Most probably.
[07:04] <imbrandon> LaserJock: i lub you :)
[07:04] <Fujitsu> Though they're likely different from those that dash is lacking.
[07:05] <SWAT> a program I'm building (preferbly) has a datadir. What would the ideal place to put this? (/opt seems such a nasty place for it, /usr/share ?)
[07:05] <LaserJock> imbrandon: I know, I'm just ---||--- close from taking off ;-)
[07:05] <imbrandon> hrm someone just gave me a 128mb ipod shuffle knockoff
[07:05] <imbrandon> LaserJock: nooooooo!
[07:05] <persia> SWAT: /usr/share/<package>/ /usr/share/games/<package> and /usr/lib/<package>/ are the recommended locations, depending on the type of data.
[07:06] <SWAT> persia, thanks. You don't sleep much, do you?
[07:06] <imbrandon> LaserJock: btw thanks for the idea about the confs, i noted it and will likely use it to apt-mirror-ng
[07:06] <persia> SWAT: I sleep a lot, but you're busy doing other things then :)
[07:06] <imbrandon> :)
[07:07] <imbrandon> brb wife calls
[07:08] <SWAT> persia, harhar, allright then.
[07:11] <imbrandon> woot , after over one year upstream FINALY gives me access to release new upstream verions of apt-mirror on sf.net
[07:11]  * LaserJock finishes his daily Planet Ubuntu *cough* Foresight *cough*
[07:11] <imbrandon> now i dont have to wait to push my patches upstream :)
[07:11] <Fujitsu> LaserJock: Heh, yes.
[07:12] <imbrandon> LaserJock: you also a defector like nixternal ? hehehe
[07:12] <LaserJock> not yet
[07:12] <LaserJock> I hung out over there for a little bit
[07:12] <imbrandon> is it based on ubutnu ?
[07:12] <imbrandon> ubuntu*
[07:12] <LaserJock> but I don't have time to keep up with Ubuntu, let alone build a new distro
[07:12] <LaserJock> imbrandon: nope
[07:13] <LaserJock> I think it's at least related to rPath Linux
[07:13] <LaserJock> but I don't think it's based off of anything else really
[07:13] <imbrandon> ahh rPath being a relitive of Redhat right >?
[07:13] <LaserJock> relative in what way?
[07:13] <imbrandon> e.g. was based on RH some long time ago, like RH 7.3 or soemthing
[07:14] <LaserJock> hmm, have no idea
[07:14] <LaserJock> it's not now for sure
[07:14] <LaserJock> it's a new package system
[07:14] <imbrandon> i *think* it was if memory is right, but no idea really
[07:14] <LaserJock> basically you package in python
[07:14] <imbrandon> ahh
[07:14] <LaserJock> and it's really fast
[07:14] <imbrandon> wow really ?
[07:14] <LaserJock> and they just throw everything in
[07:14] <LaserJock> no free or non-free
[07:14] <LaserJock> if it's useful they do it
[07:14] <imbrandon> i've got too much invested in ubuntu/debian atm personaly, but i might give it a peek
[07:15] <LaserJock> it's interesting at least
[07:15] <imbrandon> ahh gentoo-esque ( no free / non-free
[07:15] <imbrandon> )
[07:15] <LaserJock> many packages take just a few minutes
[07:15] <persia> Do they ship libdvdcss2?
[07:15] <LaserJock> hmmm, I'm not sure on that one
[07:15] <LaserJock> they have a lot of other goodies though
[07:15] <LaserJock> mostly what we'd do in Multiverse
[07:16] <persia> I suspect they don't, and that they just have a looser definition of free/non-free, and exclude all non-free.
[07:16] <LaserJock> java, etc.
[07:16] <LaserJock> well
[07:16] <LaserJock> it's like Main+Multiverse
[07:16] <LaserJock> they don't really have a Universe yet ;-)
[07:16] <LaserJock> they're just now getting KDE going
[07:16] <LaserJock> but it's only a handful of people
[07:17] <LaserJock> and the create packages *fast*
[07:17] <imbrandon> Fujitsu / StevenK / LaserJock / persia : woot, look what i just got emailed to me ~30 minutes ago
[07:17] <imbrandon> http://paste.ubuntu.com/2374/
[07:17] <LaserJock> but I've got too much to do to go over there I think
[07:18] <LaserJock> if anything I'd head over to Fedora I imagine
[07:18] <persia> imbrandon: Excellent.  Can we have 4.5 with LaserJock7s config handler please :)
[07:18] <LaserJock> imbrandon: no vcs?
[07:18] <imbrandon> :) how about i incorp the current patches for 4.5 and shoot for 4.6 for that :)
[07:18] <imbrandon> LaserJock: even better than i can ask him to use bzr :)
[07:19] <LaserJock> heh
[07:19] <persia> Umm..  Can you get 4.6 out by 14th December?
[07:19] <LaserJock> I tried out git-svn the other day
[07:19] <LaserJock> it didn't like the svn repo I was working with so much
[07:19] <LaserJock> I might try bzr-svn and see if it does better
[07:19] <imbrandon> persia: maybe , depends on how much i neglect other things, but apt-mirror has had a history of using -backports :)
[07:20]  * persia dreams of no special histories for packages because everything works perfectly the first time
[07:20] <imbrandon> LaserJock: yea i tried bzr-svn , it isnt terrible
[07:21] <LaserJock> I just wish I could get gchemutils to not use CVS :/
[07:21] <LaserJock> svn is a godsend in comparison
[07:21] <imbrandon> heh i havent used cvs ( other then a rare co of some obsucre source ) since 1999
[07:21] <LaserJock> I <3 svn
[07:21] <imbrandon> guess i'm lucky
[07:21] <LaserJock> imbrandon: really? lots of projects still use it
[07:23] <imbrandon> yea i dont tend to muck in the source of non-familiar software, i've basicly been using the same software i dev for since about ~2000
[07:23] <imbrandon> only a few additions like apt-mirror
[07:23] <imbrandon> here and there
[07:23] <imbrandon> the only mucking i do with it other than that is packaging
[07:23] <imbrandon> that i'll touch damn near anything :)
[07:24] <LaserJock> they only time I've had to use it is with gnome-related stuff
[07:24] <LaserJock> *the
[07:25] <imbrandon> yea i havent touched anythgin gnome specific at all, unless you consider mono part of gnome, but even then i stayed with win.forms stuff and cli stuff ( and political stuff )
[07:25] <LaserJock> heh
[07:26] <imbrandon> oh and a bit, very very little bit of xsp stuff when it was brand new
[07:29] <imbrandon> wow looking back at my fist post ( i could find via google, i know it wasent my very first ) to mono ml was 2002, seems so much longer ago
[07:30] <LaserJock> geeze
[07:30] <LaserJock> that's when I started grad school
[07:30]  * LaserJock suddenly gets depressed
[07:30] <imbrandon> ? heh
[07:30] <persia> LaserJock: Why?
[07:31] <LaserJock> I've been here too long
[07:31] <LaserJock> and imbrandon is so l33t
[07:31] <imbrandon> nah
[07:31] <imbrandon> not by a long shot
[07:31] <persia> LaserJock: I thought 5 years was standard (and also, I bet you know more about computing than he knows about chemistry) (no insult to imbrandon intended)
[07:32] <imbrandon> hahah very very true :)
[07:32] <imbrandon> see
[07:32] <imbrandon> :)
[07:33] <imbrandon> it was even back before i used "imbrandon" heh http://lists.ximian.com/pipermail/mono-list/2002-June/006273.html
[07:33] <persia> uoxdev?
[07:34] <imbrandon> Ultima Online emulator i helped found and develop from 1997 to 2003
[07:34] <LaserJock> "Eagle"?
[07:34] <imbrandon> yea Eagle was my SN upto about 2003 when i coined "imbrandon"
[07:34] <LaserJock> man, that's soo much better
[07:35] <imbrandon> Eagle == short for "Walking Eagle" , my in-game name for Ultima Online, witch also was short for "Walking Eagle, too full of sh*t to fly" :)
[07:36] <imbrandon> i think my eagle nick still has an o: line on irc.stratic.com iirc :)
[07:36] <imbrandon> irc.stratics.com*
[07:38] <imbrandon> persia: and fwiw uox3 ( the "product" of uoxdev.net ) was later rewritten in c# and name changed to runuo ( runuo.com )
[07:38] <persia> imbrandon: And is it free?  Is it in Ubuntu?  Why not?
[07:38] <imbrandon> yea its GPL
[07:39] <imbrandon> but its just the server engine, the client is from EA and its free as in beer but not OSS
[07:39] <imbrandon> and its not in ubuntu because ummmm
[07:39] <persia> Is there a use case to run a server without clients?  Maybe multiverse, but I suspect there are other tools now anyway.
[07:39] <imbrandon> yea you normaly run the server on a dedicated machine
[07:40] <persia> Ah, so it does have a use then :)
[07:40] <imbrandon> it works similar to a dedicated quake3 server, in that the clients connect
[07:40] <imbrandon> but it dosent need to run a client
[07:40] <persia> So the user can construct their own MMORPG for UO clients?
[07:40] <imbrandon> yea it has a use case definately, just never thought about packaing it honestly :)
[07:40] <imbrandon> persia: exactly
[07:41] <dholbach> good morning
[07:41] <imbrandon> there are quite a few large "shards" ( what the server is called when running ) online, like uogamer.com
[07:41] <imbrandon> dholbach: heya
[07:41] <dholbach> hey imbrandon :)
[07:42] <imbrandon> persia: heh i guess yo poked me to my next "new" package :)
[07:43] <imbrandon> honestly i dunno why i never thought about packing it before
[07:43] <imbrandon> there is even a fork "SunUO" with linux specific optimizations and some other custom things upstream thought were too radical
[07:45] <somerville32> persia, Will you ack bug #172926?
[07:45] <ubotu> Launchpad bug 172926 in harvestman "Sync harvestman 1.4.6-6 from Debian unstable (main)." [Undecided,New] https://launchpad.net/bugs/172926
[07:46] <persia> somerville32: I can't compile it right now, so no.  I'll be looking at the sponsors queue in about 210-250 minutes, and may ACK it then if it's not already gone.
[07:47] <LaserJock> good night everybody
[07:48] <somerville32> Night LaserJock :)
[07:48] <LaserJock> somerville32: good luck dude. it'll work out
[07:48] <imbrandon> gnight LaserJock
[07:59] <persia> somerville32: Just glancing at the queue, are you still working on zim, or is it ready for sponsoring?  "In Progress" may not be the ideal status.
[08:00] <somerville32> persia, My server went offline (when I build my packages), so I was hoping for that to come back online
[08:01] <somerville32> persia, I suppose I'll just reconstruct the package and finish locally
[08:01] <persia> somerville32: No big rush.  Shall I push it out of queue until you're ready?
[08:01] <somerville32> persia, I remember the gist of your recommendation but can you post it on lp so I make sure I get it all in one go?
[08:01] <persia> somerville32: I don't remember what you're referencing.
[08:02] <somerville32> persia, Well, whats holding up zim?
[08:02] <persia> somerville32: As far as I know, nothing, but the status "In Progress" might cause people to think someone is working on it, and not sponsor it.
[08:03] <somerville32> persia, Alright, well, if you don't find anything wrong with it then it is ready for upload.
[08:04] <persia> somerville32: I can't usefully check now, but if you change the status, others might be more inclined to look at it.  See https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue
[08:05] <somerville32> imbrandon, are you interested? :]
[08:06] <imbrandon> somerville32: i can be in about ~10 minutes, right in the middle of a bzr push
[08:07] <somerville32> imbrandon, Awesome. Thanks.
[08:07]  * Fujitsu returns.
[08:57]  * Hobbsee waves
[08:58]  * somerville32 waves.
[08:58]  * jussi01 waves at Hobbsee
[08:58] <Hobbsee> :)
[08:58] <jussi01> anyone now who the project lead for ubuntu-mobile is?
[08:59] <frenchy> Hobbsee: Hi.
[08:59] <Hobbsee> jussi01: mithrandir is the tech-lead.
[08:59] <Hobbsee> jussi01: david morely (unsure of the nick), is hte manager of all of it
[08:59] <jussi01> Hobbsee: ok, great :)
[08:59] <jussi01> thank you
[09:00] <Hobbsee> no problem
[09:06] <StevenHarperUK> Hi is this the right place to get the relevant persons attention to https://bugs.edge.launchpad.net/ubuntu/+source/easycrypt/+bug/165281
[09:06] <ubotu> Launchpad bug 165281 in easycrypt "Candidate revision easycrypt_0.2.1.16-0ubuntu1" [Undecided,Confirmed]
[09:06] <somerville32> imbrandon, How is it coming?
[09:08] <persia> StevenK: It is the right place, and your bug is in the right status, and will get addressed as soon as the sponsors have a chance.  I suspect that the delay is in part caused by the speed of release of .16 after .15, and some are waiting for .17, although it may just be that the sponsors are fairly busy.
[09:10] <Hobbsee> persia: wrong nick
[09:10] <persia> More explicitly, users aren't really expected to be using hardy at all at this point, so there's not a huge incentive to push leaf package updates that may need a rebuild later (although it will likely get pushed soon, as it's getting closer to least-recently touched in the sponsors queue)
[09:10] <StevenHarperUK> persia: Yeh I guessed my was that the fast release process was holding it up, it is my last release for a while thout
[09:10] <StevenHarperUK> *thou
[09:10]  * persia grumbles about nick collisions, and apologises to Steve for having incorrectly highlighted.
[09:11] <persia> StevenHarperUK: I remember you saying that before, but have personally been chasing other backlogs.  Someone should get to it soon, and it shan't be forgotten in it's current state.
[09:12] <StevenHarperUK> persia: that all I wanted to hear : ta
[09:12]  * Hobbsee wonders why hardy seems much stabler than gutsy here
[09:13]  * TheMuso raises his eyebrows at Hobbsee's statement.
[09:13] <persia> Hobbsee: You've set the crash on unstable code bit wrong.  Try again.
[09:14] <Hobbsee> TheMuso: my gutsy, having realised that hardy seems to want to work, is deciding to be a royal pain, and crash / drop wifi at random (the card stops lighting up.  never seen that happen before on this machine!), and variosu other things
[09:14] <TheMuso> lol
[09:14] <Hobbsee> it's *really* weird!
[09:27] <Fujitsu> Evening, \sh.
[09:27] <Fujitsu> \sh: Are you dealing with wireshark's -6111 -> -6121?
[09:34] <\sh> Fujitsu, jepp...
[09:35] <\sh> Fujitsu, I#m on it, a bit delicated cherry search picking patches
[09:35] <Fujitsu> Mhm, sounds painful.
[09:37] <dholbach> hmmmm, cherries
[09:51] <\sh> Fujitsu, could you deal with bug #172277 ? I attached a patch from fedora...references are in the comment
[09:51] <ubotu> Launchpad bug 172277 in htdig "[CVE-2007-6110] Cross-site scripting (XSS) vulnerability in htsearch in htdig 3.2.0b6" [Undecided,New] https://launchpad.net/bugs/172277
[09:52] <Fujitsu> \sh: Sure, I'll have a look.
[09:52] <Fujitsu> Going through other new CVEs at the moment.
[09:55] <\sh> Fujitsu, can you give me the link to the ubuntu-cve branch? :)
[09:56] <Fujitsu> \sh: It's the ubuntu-cve-tracker project on LP. The master branch is http://bazaar.launchpad.net/~ubuntu-security/ubuntu-cve-tracker/master.
[09:56] <Fujitsu> I'm working through universe CVEs in my branch.
[09:58] <huats> morning all
[09:58] <effie_jayx> huats,  morning
[09:59] <huats> morning effie_jayx
[09:59] <Fujitsu> \sh: I'm looking at -6131 now.
[10:03] <pwnguin> wow, deluge is pretty nice
[10:04] <RAOF> Quite shiny, yes.
[10:04] <pwnguin> loads faster
[10:05] <RAOF> Than?
[10:05] <pwnguin> guess
[10:05] <pwnguin> azureus
[10:05] <pwnguin> duh
[10:05] <RAOF> Ah.
[10:05] <Fujitsu> Oh dear, oh dear...
[10:05] <RAOF> Yes, that would be the case.
[10:06]  * RAOF prefers his bittorrent clients to be smaller than the files he is attempting to download, and hence has never really tried azureus.
[10:06] <RAOF> Except on windows, it suddenly occurs to me.
[10:06] <Fujitsu> Haha.
[10:06] <RAOF> Many moons ago.
[10:06] <pwnguin> azureus was the first client that did a great job of maxing out download for me
[10:07] <pwnguin> deluge is sitting at 20 MB thouhg
[10:07] <pwnguin> only half of azureus :P
[10:07] <RAOF> I hope you don't mean 20Mb/sec, or I may have to kill you.
[10:07] <pwnguin> no, im not on campus
[10:08] <pwnguin> 20MB RAM
[10:08] <RAOF> Right.  Python + miscelanious crazy C++ libs.
[10:08] <RAOF> (Again, spelling is only enforced on the hale)
[10:12] <pwnguin> well, we'll see how it holds up after a week of use
[10:15] <effie_jayx> I have just posted a second patch following suggestions. https://bugs.launchpad.net/ubuntu/+source/ghc6/+bug/95985
[10:15] <ubotu> Launchpad bug 95985 in ghc6 "no manpage for runghc / runhaskell" [Wishlist,Confirmed]
[10:16] <effie_jayx> I think it's ok now
[10:20]  * \sh needs some aspirine
[10:54]  * txwikinger2 needs some too
[11:41] <Tonio_> hi there
[11:41] <Tonio_> can someone please have a look at http://revu.tauware.de/details.py?package=kpar2
[11:41] <Tonio_> ?
[12:38] <Hobbsee> soren, ajmitch, please respond to the MOTU application on the list
[12:39] <soren> Hobbsee: Thanks for poking. It slipped my mind.
[12:40] <Hobbsee> soren: :)
[12:44] <frenchy> Tonio_: I'm not a MOTU but where did you get your information on where to put the HomePage in the control file?  I ask simply because maybe I've done it wrong.
[12:44] <persia> For all that adding a library in the upstream source is annoying, providing a required patch to a library in upstream source is more so :(
[12:46] <frenchy> Is it wrong of me (as a non MOTU) to ask questions of other packages on REVU?
[12:47] <pochu> I don't think so, but I'm not a MOTU either :-)
[12:47] <Hobbsee> no
[12:47] <persia> frenchy: Not at all.  Please share.
[12:47] <persia> frenchy: I recommend making sure the person is available, and posting a pastebin with your comments in-channel, as this will get your comments reviewed as well.
[12:48] <persia> s/person/packager/
[12:48] <frenchy> Ta
[12:50] <frenchy> persia: Yeah, I don't think Tonio_ is listening. But we just had a bug hiccup in services so maybe he missed my question.
[12:50] <frenchy> Tonio_: you there?
[12:51] <Tonio_> frenchy: yep
[12:51] <frenchy> Especially now that I know some of the basics ... seems a waste of knowledge if I see someone that wants a review.
[12:52] <Tonio_> frenchy: any help required ?
[12:52] <frenchy> Tonio_: I think that there was an inter-server glitch.  Did you get my message about Homepage?
[12:52] <dholbach> congratulations apachelogger!
[12:54] <Tonio_> frenchy: yeah, I wasn't aware of that :)
[12:54] <Tonio_> frenchy: didn't work on native packages for a long time
[12:55] <Tonio_> hello Mr Holbach !
[12:55] <dholbach> heya Tonio_
[12:56] <Tonio_> frenchy: I just reuploaded with the good standard version and homepage tatg
[12:56] <Tonio_> tag
[12:56] <frenchy> Tonio_:  So is what you've done with HomePage correct.  If so then maybe I need to find better web page to read.
[12:56] <dholbach> MOTU Q&A session in 4 minutes in #ubuntu-classroom
[12:56] <frenchy> Ohhh ...
[12:56] <frenchy> Ta
[12:57] <ian_brasil> pochu: hey...i am packaging liferea now for ume !!
[12:57] <pochu> ian_brasil: wow, that's cool!
[12:57] <pochu> ian_brasil: where your changes accepted upstream?
[12:57] <pochu> s/where/were/
[12:58] <ian_brasil> yes...i have cut a dpatch and i will send this
[12:58] <pochu> Cool :)
[12:58] <ian_brasil> :)
[12:58] <pochu> ian_brasil: hmm, does UME use the official repositories?
[12:58] <Hobbsee> pochu: yes
[12:58] <pochu> k
[12:59] <pochu> apachelogger: congrats \o/
[13:00] <Tonio_> frenchy: is the tag Homepage or HomePage ?
[13:00] <pochu> Homepage
[13:00] <Tonio_> k
[13:02] <frenchy> Sorry, to slow.
[13:02] <frenchy> too
[13:04] <apachelogger> woooohooo
[13:04]  * apachelogger starts shaking hands
[13:04] <apachelogger> dholbach: thanks
[13:04] <apachelogger> pochu: thanks
[13:04]  * dholbach hugs apachelogger
[13:04] <dholbach> the first austrian MOTU?
[13:04] <dholbach> where in Austria are you from?
[13:04] <apachelogger> think so :D
[13:05] <apachelogger> dholbach: upper austria
[13:05] <apachelogger> kinda in the middle between salzburg and linz
[13:05] <dholbach> ah nice... my girlfriend is from austria too, NÖ though
[13:06] <apachelogger> ~order beer for everyone
[13:06]  * insanity is going to his secret storehouse to get beer for everyone - might take some time.
[13:06]  * insanity is back and slides beer down the bar to everyone
[13:06] <apachelogger> dholbach: cool :D
[13:06] <apachelogger> cheers everyone!
[13:06] <Nightrose> cheers
[13:07] <frenchy> I assume that apachelogger just became a MOTU?
[13:07]  * ScottK has visited Salzburg and Linz, but it was a LONG time ago.
[13:07] <frenchy> Congratulations.
[13:07] <apachelogger> indeed :D
[13:07] <apachelogger> frenchy: thx
[13:07] <ScottK> apachelogger: Congratuatlions.  Get to work.
[13:07] <frenchy> apachelogger: So how long did it take?
[13:10] <frenchy> apachelogger: I've been thinking of starting the process myself because I've had such great support from these guys but I'm worried that I won't be able to commit time when it's needed.
[13:10] <huats> apachelogger: congratulations
[13:10] <huats> !!
[13:10] <persia> frenchy: I'd recommend doing what you can, when you can.  If you enjoy it, you'll soon find yourself doing more than you expected.
[13:10] <ScottK> frenchy: The pace is up to you, so don't let that stop you.
[13:10] <apachelogger> ScottK: aye captain
[13:10] <apachelogger> frenchy: 1.5 years
[13:10] <frenchy> apachelogger:  Between wife, kid, 'another on the way' and work  ... they sometimes get in the way.
[13:10] <apachelogger> huats: thanks
[13:12] <ScottK> frenchy: No excuse.  I've got the wife and 3 kids so ...
[13:12] <huats> ScottK: and you are always connected :D
[13:13] <huats> ScottK: like if you were in all timezones :D
[13:13] <frenchy> ScottK: But I bet you're not retarded like me .. so there!
[13:13] <ScottK> huats: Sleep is for the week.
[13:13] <huats> :)
[13:13] <ScottK> frenchy: Sooner started, sooner finished.
[13:14] <effie_jayx> persia, check dholbach's comment on the bug... https://bugs.launchpad.net/ubuntu/+source/ghc6/+bug/95985
[13:14] <ubotu> Launchpad bug 95985 in ghc6 "no manpage for runghc / runhaskell" [Wishlist,Confirmed]
[13:15] <effie_jayx> we did it so that it would get erased doing the script generation phase no?
[13:15] <persia> effie_jayx: I suspect that comment comes from looking at the debdiff, and not at the package, because, as I said, that package was strange.  Do you know the answer to the question?
[13:15] <persia> (You put the answer on the wiki, so I think so)
[13:16] <effie_jayx> persia, :D
[13:16] <frenchy> ScottK: Ta, you've inspired me ... I'll start reading about what I have to do.
[13:17] <persia> frenchy: In a nutshell, just help out with universe maintenance for a while.
[13:17] <frenchy> persia: But I assume that I need some kind of mentor (or something)?
[13:18] <ScottK> frenchy: Not required.  Lots of people here to help you.
[13:18] <ScottK> dholbach: ^^^ See: People still think it's required.
[13:18] <persia> frenchy: You've been working with us a month or so: it's just more of the same.
[13:19] <persia> For me it took ~2 years from first contribution to MOTU, but I took a lot of vacations.
[13:19] <Hobbsee> ScottK: it's been long known that poeple think it's required
[13:19] <ScottK> Hobbsee: Understand.  It's an issue for me that it's not been fixed.
[13:20] <ScottK> frenchy: It took me ~ 6 months, but I happened to be in a phase where I had a lot of time and was motivated.
[13:20] <persia> (and ScottK doesn't sleep, as previously noted)
[13:21] <frenchy> ScottK: Hobbsee: dholbach: That was just an assumption.
[13:22] <frenchy> persia:
[13:22] <ScottK> frenchy: It's a common one that I'd like to see us do a better job of clearing up up front.
[13:22] <persia> frenchy: Don't worry.  It's common, and there's not consensus on how to provide Mentoring while making it clear that it's very much not required.
[13:22] <frenchy> persia: Sorry, I was trying to say "you can talk".
[13:22] <frenchy> persia: about the sleeping, that is.
[13:22]  * persia hibernates regularly
[13:22]  * ScottK never said he wasn't weak.
[13:24] <effie_jayx> persia,  well I am merelly following the scheme of making .1 available for the dh_installman to grab ... aren't I
[13:24] <effie_jayx> ?
[13:24] <proppy> hi
[13:24] <persia> effie_jayx: Yes, but you might want to make it explicitly clear what clean: is doing, as that doesn't show in the debdiff.
[13:25] <frenchy> Well from a noobs view, I go the impression that it needed mentoring because most of the other prior to that one, do require assistance.
[13:25] <frenchy> s/other/other steps/
[13:25] <effie_jayx> persia,  but clean is erasing all *.1's after the dh_installman takes them... no?
[13:25] <ScottK> frenchy: From that perspective we're all your mentor then.
[13:25] <ScottK> Gotta run.  $WORK calls.
[13:26] <frenchy> I bet he's going for a quick nap :)
[13:26] <persia> frenchy: I'm certain you'll need assistance, but I'm also certain that you can find most of what you need here, in #ubuntu-classroom during sessions, from the ubuntu-motu-mentors@l.u.c mailing list, and from reviewer comments for your packages and patches.
[13:28] <effie_jayx> persia,  I'm rechecking debian/rules
[13:29] <persia> effie_jayx: To answer your previous question, yes.
[13:29] <effie_jayx> persia,  then .. what is wrong with having the files as a .1 in the first place?
[13:30] <persia> effie_jayx: clean: runs before build:.  What will happen?
[13:30] <frenchy> I'd like to package w_scan if it hasn't already been done.  Is that possible?
[13:30] <frenchy> Probably a bit late at this stage for Hardy.
[13:30] <effie_jayx> persia, it gets erased
[13:30] <effie_jayx> and is there a chance that it runs before the build?
[13:30] <frenchy> Hobbsee: Thanks for that.
[13:31] <persia> frenchy: Take a look in LP to see if there is a needs-packaging bug.  If not, make one, and assign yourself.  If so, and it's not assigned, assign yourself.  If it's assigned, probably not.
[13:31] <persia> effie_jayx: clean: always runs before build:
[13:32] <effie_jayx> persia,  gotcha... thanks
[13:32] <frenchy> Hobbsee: that's ok ... I know Makefiles real good.
[13:32] <persia> effie_jayx: Let me know if you want me to be clear about these things :)
[13:32] <effie_jayx> persia,  you were ;)
[13:32] <effie_jayx> I got it...
[13:33] <effie_jayx> let me reply in the bug... your backup is always welcomed
[13:34] <frenchy> First thing, I better give back this user name ... I stole it.
[13:34] <persia> effie_jayx: I'd rather let you chase it: that way you can practice working with the bugs, the sponsoring process, and chasing the problems.
[13:34] <effie_jayx> persia,  thanks for all the help... I mean it...
[13:35] <RainCT> heya
[13:37] <effie_jayx> RainCT,  hello :D
[13:38] <RainCT> hey Efrain, how is it going? :)
[13:39] <slytherin> Is there any tutorial on how to package java applications?
[13:40] <persia> slytherin: Documentation is weak, but there's some useful information from wiki.debian.org
[13:41] <persia> slytherin: Your best bet to is combine that with comparison to another java package with similar behaviour (library, GUI tool, CLI tool, etc.)
[13:44] <effie_jayx> RainCT,  all cool... learning lots
[13:44] <ScottK> slytherin: And you can ask man-di if you get really stuck.  He knows about Java packaging.
[13:45] <slytherin> ScottK: Sure if I get stuck. I have to yet start. :-)
[13:47] <persia> ScottK: Re: libssl0.9.7: is feisty, etc. still vulnerable, or did it get patched? (or do you not remember?)
[13:47] <persia> s/is/in/1
[13:57] <slytherin> persia: I think looking at some of the existing java application helps more. :-)
[13:57] <persia> slytherin: Yep :)
[13:58] <effie_jayx> dholbach,  I saw your comment
[13:58] <effie_jayx> dholbach,  if you check the package you will fine that in  the clean section of debian/rules .... all *.1 get erased
[13:59] <dholbach> ah ok
[13:59] <frenchy> Hang on, "Ubuntu Developers" = MOTU, right?
[14:00] <frenchy> On https://wiki.ubuntu.com/UbuntuDevelopers, under "Prospective Developers" ... it says ... "work with an existing developer or core developer as a sponsor"
[14:00] <persia> frenchy: Not quite.  Ubuntu Developers = MOTU + core.
[14:00] <persia> It says that.  That should be plural.  I'll fix it now.
[14:01] <effie_jayx> dholbach,  does that make sence?
[14:01] <effie_jayx> sense
[14:01] <frenchy> Also, it has a sub heading on the page "Ubuntu Developers (MOTU)" indicating that Ubuntu Developers = MOTU
[14:01] <dholbach> effie_jayx: maybe, best to add the information to the bug report
[14:02] <effie_jayx> dholbach,  I did comment about it
[14:02] <dholbach> ok great
[14:02] <effie_jayx> anything else I should do?
[14:02] <dholbach> because I'm not the only one looking at those bug reports
[14:02] <dholbach> ok guys, I'm out for lunch, see you later
[14:02] <effie_jayx> dholbach,  bon apetit
[14:02] <dholbach> merci beaucoup
[14:03] <persia> frenchy: Is that more clear now?
[14:04] <frenchy> persia: That certainly changes the feel to one of "working together as a team".  Yes, much better.
[14:05] <persia> frenchy: Thanks a lot for pointing that out.
[14:12] <frenchy> So all you've got to do is get a couple of MOTUs to sponsor you to the MOTU Council after doing some good work.  Sure, there's a whole lot of "subjective" opinion in there but that
[14:12] <frenchy> 's the essence of it, right?
[14:13] <persia> frenchy: That's about it.  I'd suggest also developing a speciality of something you do, and a real interest in some aspect of Ubuntu, as this will help with the subjective parts.
[14:13] <frenchy> No, firmer rules than that?
[14:13] <victor_> z7w 12
[14:13] <persia> frenchy: Nope.
[14:13] <frenchy> Sorry, that came out all wrong ...
[14:14] <frenchy> persia: Thanks .. that's what I meant.
[14:15] <persia> frenchy: Essentially, do what you like.  After a while, you'll become an established contributor and likely start to get involved with something specific.  After doing that for a while, you'll likely be told you need to apply, and then approval takes a week or two.
[14:16] <frenchy> persia: Do you mean like picking a category of application. like "Video applications"?
[14:16] <frenchy> persia: Thanks.  Ok, I'll just plod along contributing where I can.
[14:17] <persia> frenchy: Sure.  working on video stuff, perhaps with the desktop team and mythbuntu team, would be a good area of interest, and a good source of contributions.  As you do more, you'll likely have to touch libraries, sound systems, display systems, etc.
[14:18] <afflux> Am I allowed to use su-to-root in a .desktop file, or should I use gksu/ksu? (and, is that different to debian?)
[14:18] <proppy> $ apt-rdepends -r -b cmake -> E: Reverse build-dependencies are not supported
[14:18] <proppy> too sad :(
[14:19] <persia> afflux: Most seem to use gksu, but su-to-root might work.  I hope it's not too different than debian, as otherwise we need to check all the desktop files and maybe carry a huge variance: if you follow Debian guidelines, you should be safe.
[14:19] <proppy> someone know a package that build-depends upon cmake ?
[14:19] <persia> proppy: You could add a patch :)
[14:20] <proppy> persia: I still have to patch pastebin :)
[14:20] <persia> proppy: Alternately, you might be able to extract something with grep-dctrl
[14:20] <proppy> let's install dctrl-tools
[14:22] <siretart> grep-dctrl -F Build-Depends -s Package cmake -n /var/lib/apt/lists/*_Sources
[14:24] <persia> siretart: Any thoughts about libopenal1 ?  Do you think this is soon, or should I do the libopenal0a merge already?
[14:30] <siretart> persia: I remember you wrote that you wanted to look for an updated patch for debian, what's the status on this?
[14:30] <siretart> persia: TBH, I'd like to keep the pacakges in sync. so if you want to work on openal, please prepare an debian upload and I'll sponsor it immediately
[14:31] <siretart> ok
[14:31] <siretart> ?
[14:31] <persia> siretart: The Redhat patch doesn't work for Debian.  I don't want to add the Ubuntu patch to Debian because Kibi's work with the new upstream is a better solution.
[14:31] <persia> siretart: Please sponsor Kibi's work, and we can sync.
[14:32] <persia> Essentially, the new upstream has all new assembly code that works fine for AMD64 SMP.
[14:32] <siretart> persia: KiBi's work is for experimental, not unstable. that's what I discussed with him
[14:33] <siretart> or did you actually test that the new version actually does work?
[14:33] <persia> Ah.  Hmmm.  OK.  I'll prep a 1:0.0.8-7 then (with the MMX patch).
[14:34] <proppy> persia: grep-aptavail with -F Build-Depends seems not available
[14:34] <siretart> thanks!
[14:34] <persia> I tested the new version in Ubuntu with torcs, and it worked for me, but that's not enough testing (hence my recent call for more testing).  Kibi said he was waiting for you, hence the ping.
[14:34] <persia> proppy: Try siretart's line above.  It should work.
[14:35] <proppy> thanks sirestart
[14:35] <siretart> persia: I'd suggest let's test it in a PPA. I'm following the openal-devel list, and I don't expect upstream to react timely in case of problems
[14:35] <proppy> the pb was to grep Sources files and not Packages :)
[14:36] <persia> No, upstream is currently on hiatus.  OK, I'll push Kibi's to a PPA, and get a 1:0.0.8-7 available somewhere as a sync candidate.  Thanks.
[14:36] <siretart> proppy: you were asking after sources dependencies, after all
[14:36] <proppy> kde switched to cmake :)
[14:36] <proppy> siretart: yep :)
[14:36] <proppy> siretart: and I was not able to figure out how to tell grep-aptavail to look for that
[14:36] <proppy> siretart: thanks for your help
[14:36] <proppy> that make quite a lot of examples to look at
[14:37] <griffinc> asac: I'm working on a small merge and there is no .orig.tar.gz just a .tar.gz.  that means it's a debian native package, correct?
[14:37] <proppy> maybe there is even a cdbs class for cmake available :)
[14:37] <persia> griffinc: Yes
[14:38] <persia> proppy: There is, but it may not be in cdbs itself.
[14:38] <griffinc> so when I run debuild -S, it complains that there is no .orig.tar.gz.  Ok to continue and ignore?
[14:38] <asac> griffinc: right ... we should check if that is valid or a bug in debian
[14:38] <persia> griffinc: What's the version number in the changelog?
[14:38] <griffinc> It seemed to build ok.
[14:39] <griffinc> let me check
[14:40] <proppy> persia: you mean in a patch to cdbs ?
[14:40] <proppy> persia: or something like an additional class shipped within the debian directory ?
[14:40] <griffinc> it's for mailping and the gutsy version was 0.0.4ubuntu4.  the hardy version would be 0.0.4-1ubuntu1 since there was an update in the debian upstream version.
[14:40] <griffinc> am I understanding that correctly?
[14:40] <persia> proppy: Sometimes other packages contain cdbs rules, and sometimes there are cdbs snippets floating around looking for a home.
[14:41] <persia> griffinc: OK.  What's the current Debian version?
[14:41] <griffinc> persia: 0.0.4-1
[14:42] <persia> griffinc: It looks like Debian changed from native to non-native packaging then.  You'll want to make yours non-native, and use the Debian orig.tar.gz
[14:43] <proppy> let's grep cdbs+cmake in build depends
[14:45] <proppy> youpi
[14:45] <griffinc> persia: the previous debian version was 0.0.4-0.1 -- does that mean it changed to non-native previously?
[14:45] <proppy> libwibble-0.1.10ubuntu2/debian/cmake.mk
[14:47] <griffinc> Debian's source is still .tar.gz not .orig.tar.gz according to packages.debian.org.  hm.
[14:47] <persia> griffinc: Argh!  It means several people don't understand versioning most likely.  "0.0.4" is a debian native package.  "0.0.4ubuntu1" is what Ubuntu does to a debian native package.  "0.0.4-0.1" is the first NMU to a native package.  The Ubuntu versioning scheme breaks for these, so we usually use "0.0.4ubuntu2".   "0.0.4-1" is the first revision of a non-native package.  Ubuntu makes this "0.0.4-1ubuntu1".  What happened in debian to arrive at 
[14:48] <asac> persia: you sure that 0.0.4-0.1 is a native NMU?
[14:49] <persia> asac: Yes.  Completely.
[14:49] <persia> asac: Annoyingly enough, this means that Ubuntu never version compares properly for native NMUs.
[14:49] <griffinc> here is the debian changelog:  http://packages.debian.org/changelogs/pool/main/m/mailping/mailping_0.0.4-1/changelog
[14:49] <asac> strange i would have bet that dpkg-buildpackage will pick up a 0.0.4 orig and produce a diff.gz if you have such aversion
[14:49] <persia> asac: Nope.  It's special.
[14:50] <asac> why= is 0.0.5 < 0.0.4.1 ?
[14:50] <persia> asac: The reason being that there isn't an orig.tar.gz: you get a warning, but it is safe to ignore (if you're doing a Debian native NMU)
[14:50] <griffinc> I have made my merges and it seems to build ok, other than the warning when I do debuild -S about no .orig.tar.gz
[14:50] <\sh> siretart, ping
[14:50] <griffinc> I meant "I have made my merges..."
[14:51] <siretart> \sh: ICMP ECHO REPLY
[14:51] <\sh> siretart, what is the result to https://blueprints.edge.launchpad.net/ubuntu/+spec/fai-in-ubuntu? :)
[14:51] <persia> asac: Yes, but there needs to be an indication it's really a NMU.  I don't understnd why they did it that way.
[14:51] <asac> you ever saw an NMU of a native package?
[14:51] <asac> griffinc: if debian now has orig.tar.gz then you should have it as well
[14:51] <persia> griffinc: Right, but you really want to investigate the version state.  native with -1ubuntu1 is just plain wrong.  It may be necessary, but it's wrong.
[14:52] <griffinc> asac: debian does not have orig.tar.gz
[14:52] <persia> asac: Yep.  Look at the changelog for whatever griffinc is merging for an example.
[14:52] <siretart> \sh: the people in boston seemed to prefer puppet. but I think Matthiasz wanted to look further at fai
[14:52] <griffinc> http://packages.debian.org/sid/mailping
[14:52] <griffinc> it still is a .tar.gz it looks like
[14:52] <\sh> siretart, puppet for deploying large server/desktop installations? I thought it's only a cfengine a like replacement
[14:53] <persia> asac: http://packages.qa.debian.org/m/mailping/news/20060812T120213Z.html
[14:53] <\sh> remembering that puppet was coded in ruby..
[14:54] <proppy> telepathy-qt-0.14.1 is also a good example
[14:54] <siretart> \sh: yes. we are comparing apples and peaches here
[14:54] <proppy> (for the cmake thing)
[14:54] <griffinc> maybe I should file a bug report w/ Debian?
[14:55] <\sh> siretart, that's for sure...mass configuration management against mass rollout of machines
[14:56] <asac> persia: i think we really have to buy this in and use -0.2ubuntu1 then, or what would you suggest?
[14:56] <siretart> \sh: fai can be used for several things. one is mass deployment, the other is mass configuration
[14:56] <persia> asac: I've been meaning to write a spec explaining that Ubuntu ought to use -0.0ubuntuX for native packages for a while.  I'm really not sure what to do in this case: it depends on how Debian intends to fix it.
[14:57] <siretart> \sh: I don't see fai as 3rd official supported installer in ubuntu soon.
[14:57] <StevenK> persia: ... but then they aren't native anymore
[14:57] <\sh> siretart, well in combination with other tools, it's fine for mass configuration...
[14:57] <asac> yeah ... but the only safe way (without knowing the next version) is to use a bad version :)
[14:57] <persia> StevenK: Well, there's that too.
[14:57] <siretart> \sh: however I can imagine that we could move fai to main for mass configuration
[14:57] <\sh> siretart, fai is something for consultants  not for the canonical support center ,-)
[14:57] <persia> StevenK: Anyway, you were the person who convinced me to not go on a crusade to un-native all the native packages.
[14:57] <StevenK> persia: So I agree that this problem needs to be looked at. Maybe <version>~ubuntu1 ?
[14:58] <proppy> puppet looks hype
[14:58] <persia> StevenK: version~ubuntu1 sorts less than version
[14:58] <StevenK> persia: Indeed, I just saw that.
[14:58] <asac> griffinc: ok, I would say that you should use the version like above and file a debian bug asking for someone to integrate the NMU changes in a real upload (of 0.0.5 for example) :)
[14:58] <StevenK> persia: Never mind me. :-)
[14:59] <siretart> \sh: well, yes. I still think that one could write something on top of fai which makes mass configuration easy or easier
[14:59] <persia> StevenK: I don't suppose you feel like drafting the -0.0ubuntu1 spec?
[14:59] <asac> persia: is there a policy document defining how debian native NMUs should be versioned?
[14:59] <griffinc> asac: do you mean version-ubuntu1 ?
[14:59] <siretart> \sh: you'd still need some way to securely distribute your configuration space. svn can provide that, if setup properly
[14:59] <asac> griffinc: no ... -0.2ubuntu1
[14:59] <persia> asac: It's in Debian policy somewhere.  I haven't looked it up since feisty.
[14:59] <siretart> \sh: so there is still a lot of room for improvement here
[15:00] <griffinc> asac: current debian is 0.0.4-1
[15:00] <StevenK> persia: Not right now, at least. And I have an objection given that -0.0ubuntu1 is non-native.
[15:00] <persia> asac: The issue is that griffinc really wants to use a version that sorts higher than 0.0.4-1 somehow.
[15:00] <persia> StevenK: Do you have a general objection to the -0.1 practice?
[15:01] <\sh> siretart, yepp.../me needs some time from work to think about some stuff FAI could need
[15:01] <\sh> anyways...leaving now...weekend :)
[15:01] <\sh> cu later
[15:01] <siretart> \sh: cu!
[15:01] <griffinc> darn.. work is calling me ... just as this is getting really interesting... I will be back in about an hour but will leave my chat open so I can catch up.
[15:02] <griffinc> figures that I would pick a tricky one to start with!  :-)
[15:02] <asac> persia: ah ... ok i would suggest to use plain 0.0.4-1ubuntu1 then ... we cannot fix it different without a debian upload
[15:03] <persia> griffinc: For ease of mind, I really recommend bugfixes first, and hitting merges when your package comes up in queue.
[15:03] <persia> asac: Sounds reasonable to me: I just think it's worth deeper investigation with Debian to find out if we're supposed to use an orig.tar.gz.
[15:04] <griffinc> persia, asac thanks for the help
[15:04] <persia> griffinc: Thanks for helping with the merges.
[15:04] <griffinc> brb
[15:04] <griffinc> persia: I am really enjoying this!  :-)  ok, boss is calling... brb
[15:05] <bddebian> Heya gang
[15:06] <pochu> hey bddebian
[15:06] <bddebian> Hi pochu
[15:06] <geser> Hi bddebian
[15:06] <bddebian> Heya geser
[15:06] <RainCT> hey bddebian
[15:07] <bddebian> Heya RainCT
[15:14] <RainCT> is the process to request removal of packages from main described somewhere?
[15:15] <persia> RainCT: Do you mean demoting to universe, or complete removal?
[15:16] <RainCT> persia: to universe
[15:18] <persia> RainCT: It's sort of loosely documented in the information on main inclusion.  Essentially, if nothing in main depends on it, and it's not required for some other purpose, it will drop out unless it appears in the seeds.  Getting it unseeded requires one of a bug, a discussion on the ML, or a sufficiently agreeable archive admin.  Of these, I recommend the ML (ubuntu-devel)
[15:18] <persia> (Or maybe just release-admin, I'm not entirely sure)
[15:18] <persia> Err  release-manager
[15:19] <RainCT> does ubuntu-devel receive much traffic?
[15:19] <Hobbsee> persia: getting it unseeded requires deleting it from the seeds, which any core dev can do.
[15:19] <persia> RainCT: Not so much.  Maybe 20-50 messages a month (at a rough guess).  Most of it is useful if you're involved in development anyway.
[15:20] <Hobbsee> persia: archive-admin doesn't come into it
[15:20] <persia> Hobbsee: I thought they only did it with tacit approval of release managers.  Thanks for the correction.
[15:20] <persia> RainCT: In that case, a bug to U-M-S might also work.
[15:20] <Hobbsee> persia: of course, the archive admin will actually have to throw it to universe, but it appears on the demote/promote list works way easier
[15:21] <persia> Hobbsee: Ah.  RIght.  I sometimes get confused about who sets things up and who does them.
[15:24] <RainCT> persia: ok, thanks
[15:24] <martoss> hi all, is there a howto, which is specific for packaging python programs?
[15:24] <persia> RainCT: No, Hobbsee gets all the credit.  I was not right.
[15:24] <Hobbsee> persia: you were right on the first half, though
[15:25] <persia> martoss: Not really.  There's the basic packaging guide, and http://wiki.debian.org/DebianPython/NewPolicy, which together do a pretty good job.
[15:33] <DaveMorris> I've got a package where the upstream is from cvs, and I'm creating a tarball from a snapshort of that for the usptream.  However some of the files are executable although thy are cpp and h files.  Whats the best way to get this fixed in the packaging?
[15:34] <ian_brasil> martoss: look on the maemo site...i remember a tutorial there..you basically need to create an make file to act as an intermediary
[15:35] <persia> DaveMorris: dh_fixperms can help some.  Beyond that, you're stuck with chmod
[15:35] <persia> ian_brasil: Not necessarily (unless you mean debian/rules).  setup.py is very common, and works well (especially for distutils) in most cases.
[15:35] <DaveMorris> does cdbs autmatically call that helper script?
[15:36] <persia> DaveMorris: I forget off the top of my head.  Take a look in /usr/share/cdbs/1/rules/debhelper.mk
[15:38] <ian_brasil> you can create a Makefile with this in it though i think:
[15:38] <ian_brasil> all:
[15:38] <ian_brasil> 	python2.5 setup.py build
[15:38] <ian_brasil> clean:
[15:38] <ian_brasil> 	python2.5 setup.py clean --all
[15:38] <ian_brasil> install:
[15:38] <ian_brasil> 	python2.5 setup.py install --root $(DESTDIR)
[15:38]  * persia prefers to see that directly in debian/rules
[15:38] <martoss> ok and then call this the standard way...
[15:38] <ian_brasil> ah, ok
[15:39]  * persia further prefers not calling python2.5 directly, to support the future transition to python2.6
[15:39] <afflux> Hi! I'd like to get my package (gdecrypt) in universe, so could any motu please have a look at it? http://revu.tauware.de/details.py?upid=787
[15:39] <ian_brasil> what would this look like in the rules then?
[15:39] <martoss> i am thinking what's the better way to do it. I am trying to package eric4, eric3 is in the repos and all the eric 4 dependencies are at least in debian unstable.
[15:40] <persia> ian_brasil: Almost the same, except changing all to build, and adding the other bits to make a package.
[15:40] <martoss> maybe it's a better idea to reuse all the debian/* stuff from eric3
[15:40] <persia> afflux: Do you want me to look at it again, or do you actually want it approved this time? :)
[15:40] <persia> martoss: That's probably a good guideline.
[15:41] <afflux> persia: hehe, I won't stop you ;)
[15:41] <martoss> yepp, but for this i have to learn a lot about packaging ;-)
[15:41]  * persia prepares to reject gdecrypt again, and looks for a reason
[15:41] <ian_brasil> persia:which source package would be a good example of this approach?
[15:41] <afflux> persia: thank you :D
[15:42] <proppy> dholbach: thanks for your comments on libjuce
[15:42] <persia> ian_brasil: Not being a python person, this will take a bit
[15:42] <dholbach> proppy: no problem
[15:42] <proppy> dholbach: I'm currently working on a CMake build
[15:43] <proppy> dholbach: because the upstream provided build system doesn't support shared library generation nor install rules
[15:43] <persia> ian_brasil: I suspect any of the packages listed under "Python" at the bottom of https://wiki.ubuntu.com/PackagingGuide/Basic would be good examples, but I'm not deeply familiar with python packaging.
[15:43] <proppy> dholbach: and the FTBS on x64 is due to missing -fPIC option at compile time
[15:44] <ian_brasil> persia: thx, i am reading that now actually
[15:46]  * somerville32 woots.
[15:48] <martoss> ok thanks, i think, I have an impression on where to start
[15:49] <dholbach> have a great weekend everybody - see you!
[15:49] <afflux> dholbach: thank you for gdecrypt
[15:49] <dholbach> no problem
[15:49] <geser> dholbach: have a nice weekend
[15:49] <dholbach> you guys too
[15:52] <persia> afflux: I'm still finding a couple really minor things, minor enough that I'll be reading all the source files to check licensing, etc.  It'll be a while for the comment.
[15:53] <afflux> persia: okay, no hurry. I'll have a coffee ;) thanks
[15:57] <LucidFox> dholbach> replied in the kwest bug
[16:05] <LucidFox> https://edge.launchpad.net/ubuntu/+source/babel <-- holy cow, it has consistently FTBFS since dapper and was completely neglected
[16:06] <LucidFox> (it's completely unrelated to kwest, I just stumbled upon it when searching for "babel")
[16:08] <geser> LucidFox: therefore we now have a page where we can see which packages don't build right now
[16:08] <LucidFox> looking at http://packages.qa.debian.org/b/babel.html , it has been removed in Debian - maybe Ubuntu should remove it too?
[16:08] <persia> LucidFox: Now's your chance to fix 5 releases at once :)
[16:08] <persia> Err..  Likely.  Why was it removed in Debian?
[16:08] <bddebian> persia: Heya.  Sounds like Fuddl has had success on scorched3d so you can probably remove that from your list. ;-)
[16:09] <persia> bddebian: You already told me to remove it.  I still owe you one.
[16:09] <bddebian> persia: Ah, good, how's your Java sk1llz? ;-P
[16:10] <persia> bddebian: I haven't written anything bigger than a patch in about 2 years, but once was an "enterprise developer".  What's the package?
[16:11] <bddebian> persia: I'm trying to package megamek (a BattleTech clone).  I have a "working" package but have a few issues.
[16:11] <persia> bddebian: Ah.  Java packaging.  That's even more mysterious.  What's not working?
[16:12] <persia> siretart: http://people.ubuntuwire.com/~persia/openal/ is the paper-tape for now (and a sync candidate).
[16:13] <bddebian> persia: Well for one it hangs on the opening dialogue.  But my main issue is that it has a libs/ dir that contains a few small .jar files that aren't being built from source but need to be in /usr/share/java/
[16:14] <persia> bddebian: Ah.  That'd be a license issue.  Do the .jar files also contain source, or are they just class files?
[16:14] <bddebian> persia: The source is in the tarball but compressed
[16:14] <dsop> i have a question: I have a package with a some *.sh files that are generated into files without the *.sh during the package build. Therefore these files without the prefix doesnot exist in the orig.tar.gz, and the diff have them. Is that okay, i mean, they are generated and should be packaged but they are not part of the source
[16:15] <bddebian> dsop: They shouldn't show up in the diff if they are generated.  Clean them up in the clean target
[16:15] <persia> dsop: best to construct them in the build: rule, and delete them in the clean: rule then (or if they are "generated" with mv, mv them back in clean:)
[16:17] <siretart> persia: did you commit it to an svn branch?
[16:17] <persia> bddebian: Hmmm..  Are they libraries that anything else makes available?  If not, they should be able to be rebuilt by unpacking, removing the .class files, and rebuilding.
[16:18] <persia> siretart: I'm not familiar enough with SVN to know how to commit that without overwriting the libopenal1 changes.  I'd be happy to learn how.
[16:18] <bddebian> persia: That's the part I don't know.  They seem like they should be.  One of them is a tinyxml parser
[16:18]  * bddebian sucks
[16:20] <geser> bddebian: you need to rebuild them for several reasons: 1) to know if there's source for them 2) that rebuilding works (in case a patch (e.g. security) is needed)
[16:24] <persia> bddebian: You get to choose.  Either they exist in another package (Contents.gz can help), or you get to package them, or they can be in this package.  I don't know enough about Java packaging to know why you might make the choice either way.  Sorry.
[16:26] <bddebian> OK, thanks guys
[16:31] <geser> what's the difference between "if [[ ... ]]" and "if [ ... ]" in bash?
[16:32] <geser> and how can I replace the first with something that works in dash?
[16:33] <somerville32> geser, What are you trying to do?
[16:33] <geser> somerville32: fixing a build failure
[16:33] <geser> somerville32: /bin/sh: [[: not found
[16:34] <geser> the Makefile has: if [[ $${deps} != "" ]]; then \
[16:41] <griffinc> persia: can I ask you a question back on my mailping issue?
[16:41] <persia> griffinc: You can, but I'll encourage you to ask generally, as others might be faster to answer.
[16:41] <griffinc> ah, yes, of course.  thanks.  :-)
[16:43] <griffinc> I just want to understand something before I file a bug w/ Debian.
[16:45] <griffinc> According to the Debian changelog for mailping, which is a native package, at one point an update was made to verion 0.0.4.  Then, a NMU was a made which brought the version 0.0.4-0.1.  Then another NMU was made to 0.0.4-0.2.  Everything was ok so far.  Then, the Debian maintainer was changed to the Debian QA group and the new upload was 0.0.4-1 when it should have been 0.0.5.  Is that correct?
[16:46] <griffinc> Changing the version to 0.0.4-1 essentially makes it appear to be a non-native package?
[16:47] <LucidFox> What's a native package?
[16:47]  * RainCT thinks he has found 404main's author :)
[16:48] <RainCT> LucidFox: a package whose upstream is Debian/Ubuntu afaik
[16:48] <griffinc> LucidFox: it's a package that is native to Debian as opposed to something obtained from an outside upstream release
[16:48] <LucidFox> ah
[16:49] <LucidFox> http://revu.tauware.de/details.py?package=libhiglayout-java <-- this can be archived again, synced from Debian
[16:50] <griffinc> In reviewing the discussion from two hours ago, I see that the recommendation was to go with 0.0.4-1ubuntu1 for hardy.
[16:50] <persia> griffinc: That sounds like a correct summary of the situation.
[16:51] <persia> Personally, I don't like 0.0.4-1ubuntu1, but it's least likely to impair our ability to sync in the future.
[16:51] <persia> (which is a major win)
[16:51] <griffinc> dumb question:  why is 0.0.4-1ubuntu1 less than 0.0.4ubuntu4 - is it because the 'ubuntu1' is less than 'ubuntu4'?  I would think 4-1 is greater than 4.
[16:52] <griffinc> persia: thanks :-)
[16:52] <nxvl_work> lionel: around?
[16:52] <geser> griffinc: because the -1 doesn't belong to the upstream version
[16:52] <geser> 0.0.4 < 0.0.4ubuntu4
[16:52] <lionel> nxvl_work: yep
[16:52] <griffinc> geser: ah, now it clicks.  heh
[16:53] <griffinc> geser: thanks
[16:53] <persia> griffinc: Because 0.0.4ubuntu4 is all upstream version, whereas 0.0.4-1ubuntu1 parses to be version 0.0.4 and revision 1ubuntu1.  This versioning is done to support upstreams who release 0.4a and then 0.4b
[16:53] <nxvl_work> lionel: did you upload apt-proxy 1.9.36-1ubuntu1?
[16:53] <nxvl_work> bug #120379
[16:53] <ubotu> Launchpad bug 120379 in apt-proxy "Merge apt-proxy-1.9.36-1 from debian unstable" [Wishlist,Fix released] https://launchpad.net/bugs/120379
[16:54] <lionel> hu, maybe :) changelog and my packages page on LP should say that
[16:54] <griffinc> persia: I understand now.  :)
[16:54] <griffinc> makes sense
[16:54] <nxvl_work> lionel: as i understand on the comments you sponsored it
[16:54] <lionel> yep
[16:55] <nxvl_work> lionel: but apt-proxy-1.9.36-1ubuntu1 isn't on the repos
[16:55] <lionel> right, but that's not the version that I sponsored
[16:55] <lionel>  apt-proxy (1.9.36ubuntu1) gutsy; urgency=low
[16:56] <lionel> not the one you said :)
[16:58] <nxvl_work> lionel: oh, ok, i have a confusion because the bug talks about apt-proxy-1.9.36-1 and it's a debdiff of apt-proxy-1.9.36
[16:58] <nxvl_work> i will open the bug again
[16:58] <lionel> right, the title is wrong
[16:58] <nxvl_work> the title or the diff?
[16:58] <nxvl_work> because there it is apt-proxy-1.9.36-1
[16:58] <lionel> the title of the bug
[16:59] <nxvl_work> and needs to be merged
[16:59] <lionel> no
[16:59] <lionel> 1.9.36.1
[16:59] <persia> afflux: My apologies that took so long.  If you can successfully convince me that none of my comments on gdecrypt matter, I'll upload it.
[16:59] <lionel> not 1.9.36-1 :)
[17:00] <nxvl_work> oh you are right
[17:00] <nxvl_work> i will open a new bug
[17:01] <mdomsch> apachelogger, ping
[17:01] <apachelogger> mdomsch: pong
[17:01] <mdomsch> apachelogger, thanks for the revu of firmware-tools and f-a-d
[17:02] <apachelogger> mdomsch: you're welcome
[17:02] <mdomsch> are ~${DIST} tags in the version only supposed to be used for backporting - not for the current release?
[17:02] <apachelogger> mdomsch: yes
[17:03] <mdomsch> hmm, that'll be fun to handle programattically
[17:03] <apachelogger> hehe
[17:04] <mdomsch> so people manually run pdebuild, not via some nice autobuilder?
[17:04] <persia> mdomsch: You might check with jdong: I think he has a script that automatically adds those and test-builds against the selected repository.
[17:04] <geser> does somebody know how to make "if [[ $${deps} != "" ]]; then" POSIX compliant?
[17:04] <persia> geser: Is that inside a makefile?
[17:04]  * mdomsch does a 'for dist in feisty gutsy hardy; do make sdeb DIST=$d; done
[17:04] <geser> persia: yes
[17:05] <persia> geser: That's just not the right way to do things.  Could you please pastebin the stanza?  I'd be happy to give you a suggestion.
[17:05]  * somerville32 needs to hurry up if we wants to make the top ten uploader list.
[17:06] <apachelogger> lol
[17:06] <geser> persia: http://pastebin.ubuntu-nl.org/46348/ (the package is coq)
[17:08] <afflux> persia: alright. for the upstream changelog, since there is no debian packaging anymore, there will be no notes in there on that anymore.
[17:09] <persia> Well, if it weren't in a for statement, you could use ifeq (${deps},""), but this a particularly bad example of forgetting that debian/rules is not a shell script.
[17:09] <persia> afflux: Right.  That's an easy win.  How about the other three?
[17:10] <geser> persia: do you know the difference between [[ and [ in bash?
[17:10] <afflux> persia: yep, guess you're right with them ;) Is it okay to just copy the untranslated strings to the en.po?
[17:10] <persia> geser: No.  But I still think this is sufficiently un-make-ish to want to try to rewrite it.
[17:11] <RainCT> geser: [[ is faster and supports more stuff (or that's what they told me in #bash, at least)
[17:11] <persia> afflux: Yep.  en.po is stupidly simple, until someone branches en_US, en_IN, en_GB, en_CA, etc.  Don't forget the localisations in the .desktop file.
[17:12] <martoss> cu folks...
[17:12] <proppy> hi
[17:12] <proppy> http://pastebin.com/m480eb354
[17:13] <proppy> does this looks wierd ?
[17:13] <persia> geser: Just to make sure I'm unrolling properly: this loops over $(ML4FILES), gets a basename, runs CAMLP4DEPS to get some deps, and if there are do, constructs a .depend file, right?
[17:13] <persia> proppy: At least odd.  I'd expect libjuce.so.1 instead of libjuce.so.0
[17:14] <proppy> 1.45 is the upstream library version
[17:14] <persia> (unless there was a SONAME bump that shouldn't have happened)
[17:14] <proppy> right ?
[17:14] <persia> proppy: upstream SONAME, but yes.
[17:14] <proppy> what is the upstream doesnt maintain SONAME
[17:15] <proppy> I mean the upstream tarball is called juce-1.45.zip
[17:15] <persia> proppy: Then you get to patch it to maintain a SONAME :)
[17:15] <afflux> persia: you mean the Comment[en]?
[17:15] <geser> persia: looks correct
[17:15] <proppy> so I assume that the library version is 1.45
[17:15] <persia> afflux: And Name[en] and GenericName[en], but yes.
[17:15] <proppy> but I understood there is not relation between SONAME and library version
[17:15] <proppy> but I may be wrong
[17:15] <persia> proppy: Do you know what a SONAME is or does?
[17:15] <proppy> SONAME is for abi compatibility
[17:15] <somerville32> Would anyone be kind enough to sponsor bug #165285 ?
[17:15] <ubotu> Launchpad bug 165285 in zim "New upstream version: 0.23" [Low,Confirmed] https://launchpad.net/bugs/165285
[17:16] <proppy> persia: you bump SONAME when you break binary compatibility IIRC
[17:16] <persia> Right.  So, you'll want to pick a version that matches this ABI, and keep it (possibly for several upstream versions).
[17:16] <persia> somerville32: You've just hit a low point in sponsor productivity :(
[17:17] <crimsun> I'll take it.
[17:17] <proppy> persia: but I thought there were no relation between the upstream version and SONAME
[17:17] <somerville32> persia, pardon?
[17:17] <persia> proppy: There isn't (except for very annoying upstreams)
[17:17] <proppy> ok so does the upstream version should appear in the library name or not at all ?
[17:18] <persia> somerville32: That's the longest I've seen an upgrade bug sit in the queue in the last month or so.  It's apparently a low point in queue processing, which is unfortunate for you.  I was commiserating.
[17:18] <proppy> persia: libjuce.so.0.1.45
[17:18] <afflux> persia: what if they don't differ? can I just use Name?
[17:18] <proppy> if soname 0 and upstream version 1.45 ?
[17:18] <persia> proppy: There's no relation generally.
[17:18] <crimsun> somerville32: hmm
[17:18] <crimsun> somerville32: sid has 0.22
[17:19] <crimsun> somerville32: will you correspond with emfox at debian dot org and see about 0.23-1 into sid?
[17:19] <somerville32> crimsun, You mean, ditch what I did and ask emfox to do it?
[17:19] <persia> afflux: You can, but then if someone wants it different, they will change Name, which would break things if you later move to using the .po files to automatically add the Name[], Comment[], and GenericName[] fields from your desktop.in file.  Depends how much you want to do now, and how much later.
[17:20] <crimsun> somerville32: there's not much point in using the diff, since sid already has 0.22-1, so yes, see if the Debian maintainer will put in 0.23-1.
[17:20] <lionel> nxvl_work: did you look at your debdiff before attaching for #173088 ? :)
[17:20] <nxvl_work> lionel: yep, why?
[17:21] <lionel> debdiff looks a bit empty here :)
[17:21] <lionel> (just changelog changes)
[17:21] <nxvl_work> empty?
[17:21] <nxvl_work> lionel: oh, yes, it's a merge
[17:22] <somerville32> nxvl_work, Then maybe you want to sync if the only delta is the changelog? :P
[17:22] <nxvl_work> mmm
[17:22] <nxvl_work> maybe
[17:22] <nxvl_work> i will have a look
[17:22] <nxvl_work> i maybe make a mistake creating the debdiff
[17:22] <somerville32> crimsun, I worked hard on that package :(
[17:22] <proppy> persia: so what's the second .0 in libfoo.0.0 ?
[17:23] <proppy> persia: the minor version of the SONAME ?
[17:23]  * somerville32 goes to his e-mail client
[17:23] <somerville32> Oh wait a sec.
[17:23] <persia> proppy: Usually.
[17:23]  * somerville32 notes that this has bigger ramifications
[17:23] <proppy> persia: oh ok
[17:23] <proppy> persia: and when do you bump the minor version ?
[17:24] <persia> proppy: At this point you'll do better with Google than with me.
[17:24] <somerville32> And I have to go pay bills
[17:24] <proppy> persia: thanks a lot anyway :)
[17:24] <nxvl_work> somerville32: the debdiff i made was between the old ubuntu, and the new one
[17:25] <proppy> persia: reading http://debid.vlsm.org/share/Debian-Doc/debian-policy/ch-sharedlibs.html seems a good idea
[17:26] <nxvl_work> lionel: i have uploaded a new debdiff
[17:27] <nxvl_work> lionel: the new debian vs new ubuntu one, maybe thats what you are looking for
[17:28] <lionel> I realized looking at the merge it was a debdiff against last Ubuntu package after telling you
[17:28] <nxvl_work> heh
[17:28] <lionel> will have a look if nobody does before me. need to go now :)
[17:28] <nxvl_work> well, i have uploaded 2 debdiff so you can take a better look
[17:29] <lionel> yeah, thanks nxvl_work
[17:31] <proppy> "The minor number and release number support configuration control by letting you know exactly what version(s) of the library are installed."
[17:31] <proppy> http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
[17:33] <persia> geser: http://paste.ubuntu.com/2385/ isn't tested, but doesn't require bash, and uses make more agressively.  It depends on the fact that DEPS is set with = instead of :=, and so is interpolated at use.
[17:34] <persia> Note that this only works if $(ML4FILES): aren't rules in some other context.
[17:36] <persia> Err., and $${deps} should be $(DEPS) and $${bn} should be $(basename $@)
[17:37] <proppy> could be libjuce.so.0.0 or libjuce.so.0.0.1.45
[17:37] <proppy> but I don't see any library named like that
[17:37] <proppy> in /usr/lib
[17:37] <proppy> so libjuce.so.0.0 seems ok
[17:38] <persia> geser: http://paste.ubuntu.com/2387/ is likely more correct
[17:39] <jdong> mdomsch: I use prevu, which automatically does no-source-change rebuilds with the ~7.10prevu1 type version numbers for backports testing. Otherwise it is identical to running a pdebuild against a $DIST pbuilder with a local APT repo, and all Ubuntu repos enabled.
[17:39] <mdomsch> jdong, thanks for the pointer
[17:40] <mdomsch> for now I'll do 'make sdeb DIST=gutsy DISTTAG='~gutsy1'  in my builders
[17:40] <mdomsch> which does the pbuilder against $DIST
[17:40] <mdomsch> sounds exactly the same
[17:40] <jdong> mdomsch: yeah, whatever floats your boat :)
[17:42] <proppy> persia: seems that the minor and the release number can match the upstream number: http://pastebin.com/m3f6306bc
[17:42] <persia> proppy: Sure.  It can optionally do that.  As the packager, you get to choose (especially when upstream isn't choosing)
[17:43] <proppy> then I guess it will be libjuce.so.0.1.45
[17:43] <proppy> If i understand correctly
[17:43] <ScottK> persia: I'm fairly certain it (libssl0.9.7) was not patched.  I was focused on getting it removed from Gutsy at the time.
[17:44] <geser> persia: I've put the whole Makefile at http://members.ping.de/~mb/tmp/Makefile
[17:44] <proppy> or maybe lijuce.so.0.0.1.45 not sure
[17:44] <proppy> let's look at libossl :)
[17:45] <geser> persia: so I replace beginning from line ".PHONY: depend" till the newline before the ml4clean target with your snippet?
[17:46] <proppy> for libssl SONAME match the upstream version -> "annoying upstreams" ?
[17:49] <persia> geser: You need to keep whatever was in .PHONY before, and add $(ML4FILES).  The depend rule can be replaced with my snippet (but it needs testing: this was just a quick edit)
[17:50] <persia> proppy: When I said "annoying upstreams" I was referring to libraries that change ABI with every release.  Not everyone who tracks the third (optional) version in the SONAME is guilty.
[17:51] <proppy> persia: but libssl seems not to have a room for bumping the so name if abi breaks
[17:51] <persia> geser: Also, the makefile needs to not have rules matching $(ML4FILES) anywhere else.  If it does, more adjustment is required to make it work cleanly.
[17:51] <proppy> persia: they will have to bump to 1.9.8 ?
[17:52] <proppy> not only the soname but also their package version
[17:52] <persia> proppy: Maybe.  I forget if libssl is annoying.
[17:53] <geser> persia: perhaps I should leave this FTBFS to someone more experienced with makefiles
[17:53] <proppy> persia: :)
[17:53] <proppy> let's name libjuce libjuce.so.0.0
[17:55] <persia> geser: The cheap & dirty solution is to create a depsmangle shell script that doesn't require bash, and pass it $(MLFILES).
[17:55] <persia> (if you just want to fix a FTBFS and don't want to make a pretty makefile)
[17:56] <persia> Alternately, you could force bash in the makefile, but that's even less preferable.
[17:56] <geser> persia: shouldn't it be enough to replace the [[ ]] with [ ] to fix the FTBFS?
[17:56] <DarkSun88> Hi
[17:58] <persia> geser: Well, you'd need to change "[[ $${deps} != "" ]]" to "[ "x$${deps}" != "x" ]" as bourne test has issues with empty strings, but it might.
[17:59] <geser> right
[18:00] <geser> persia: is it equal to "[ -z $${deps} ]"?
[18:01] <persia> geser: That's even cleaner, and yes.
[18:01] <persia> Err "[ -z "$${deps}" ]"
[18:01] <persia> As otherwise you get "[ -z  ]" which will cause make to exit.
[18:02] <nxvl_work> jdong: around?
[18:10] <afflux> persia: I'm back :) http://revu.tauware.de/details.py?upid=797
[18:11] <persia> No need to hit all the channels :)
[18:14] <persia> afflux: Advocated.  Nice work.  Now your package joins the special purgatory of packages I've advocated at the top of the REVU list.
[18:16] <bluekuja> persia, the new afflux's upload needs another ack before getting uploaded right?
[18:16] <persia> bluekuja: Right.  It looks great to me.  Take a look if you have a few minutes.
[18:16] <bluekuja> persia, as far as daniel's one was done in the previously uploaded package
[18:16] <persia> bluekuja: Right.
[18:17] <bluekuja> persia, k, let me check it. I hope I won't need to leave for dinner/training
[18:17] <persia> Sometimes (rarely) there are regressions in new uploads, so the two advocations have to happen for the same upload.
[18:19] <afflux> persia: thanks for ACKing. Anyone else for http://revu.tauware.de/details.py?upid=797 ? (since dholbach is in weekend now ;))
[18:20] <bluekuja> afflux, I've started checking it, but I'm not sure I can make it for this evening (cause dinner+training)
[18:21] <geser> ajmitch: what's the status on bug #104616 or Debian bug #380825?
[18:21] <ubotu> Launchpad bug 104616 in gnue-appserver "[apport] gnue-appserver crashed with ImportError in <module>()" [High,Confirmed] https://launchpad.net/bugs/104616
[18:21] <ubotu> Debian bug 380825 in gnue-common "Python transition (#2): you are building a private python module !" [Serious,Open] http://bugs.debian.org/380825
[18:23] <persia> Ubulette: At long last, I've taken another look at prism.  Almost there.
[18:23] <Ubulette> persia, thanks.
[18:38] <afflux> bluekuja: no hurry ;)
[18:38] <bluekuja> afflux, ok, I'm leaving now
[18:38] <bluekuja> it's on TODO anyway
[18:38] <bluekuja> cya
[18:40] <afflux> persia: I love you :P
[18:40] <persia> afflux: What'd I do?
[18:41] <afflux> persia: advocate me, finally... ;)
[18:41] <persia> afflux: Well, you fixed everything.  Some packages get in before I find them, but you weren't so lucky :)
[18:50] <geser> afflux: do you really need python-all-dev in b-d for gdecrypt? should python be enough as you don't need any python headers or all python versions
[18:50] <persia> geser: Thanks.  I suck at python packaging details :)
[18:50] <geser> afflux: doesn't gdecrypt work with python2.4?
[18:53]  * afflux goes kill himself
[18:53] <Ubulette> persia, fixed & re-upped on REVU
[18:53] <afflux> geser: persia made me do that ;)
[18:53] <persia> afflux: Don't do that: gdecrypt'll never get in that way :)
[18:54] <persia> Wait.  What did I do?  I only said I wasn't sure it complied with the python packaging policy.
[18:54] <afflux> geser: I'll check python2.4
[18:54]  * effie_jayx takes afflux  to a healing temple and sees him resurrect
[18:55] <persia> Ubulette: Thanks.  It'll be a bit, but I should have a little time this weekend (it's late here)
[18:56] <geser> I might not but uptodate on the python policy but afaik python is enough for python apps, python-all for python modules and python-all-dev for python extensions (need python headers)
[18:57] <geser> afflux: so it will work with python-all-dev in b-d (but is more than needed)
[18:57] <afflux> persia: You asked whether there was a reason to Build-Depend on python-dev instead of python-all-dev? Since there was none (that I know), I used python-all-dev.
[18:57] <afflux> geser: okay. So, python or python-all?
[18:58] <persia> My understanding was that python-dev was python2.5 only and python-all-dev was all versions of python.  I may be mistaken.
[18:58] <persia> (aptitude makes me think I'm right, but I'm lousy with python packaging)
[18:58] <geser> python should be enough as one python version is enough (you don't need all python versions installed during build, do you?)
[18:59] <persia> Doesn't having all the pythons installed during build do something special for python-support/python-central ?
[18:59] <afflux> persia: maybe, I was really confused about python{,-all}{,-dev} ;)
[19:00] <persia> afflux: No worries.  It's confusing, and apparently I don't get it either.
[19:00] <geser> persia: afaik it's only needed for modules which install into /usr/lib/pythonX.Y/
[19:00] <geser> persia: "Some applications and pure Python modules may be able to depend only on python or python-all and not require the -dev packages." [http://www.debian.org/doc/packaging-manuals/python-policy/ap-build_dependencies.html]
[19:00] <persia> geser: Ah.  So scripts don't need it then?
[19:00] <geser> afaik no, but I'm no python packaging guru
[19:01] <persia> geser: Isn't that the less NEW python packaging policy?  I usually point at http://wiki.debian.org/DebianPython/NewPolicy
[19:02] <persia> Hmm.  Maybe www.d.o has caught up.  Ignore that.
[19:02] <DktrKranz> Are archive open or still waiting for Alpha 1?
[19:02] <persia> DktrKranz: It never closed
[19:03] <DktrKranz> persia, I know, but it has been told to limit uploads to packages relevent for Alpha
[19:04] <afflux> persia, geser: okay, b-d on python is linda/lintian clean, I'll upload that now.
[19:04] <persia> DktrKranz: It only matters for packages that affect the CD builds.
[19:05] <DktrKranz> persia, probably I missed that point. thanks
[19:06] <geser> DktrKranz: the freeze announcement aren't often very specific if they also apply for universe
[19:06] <geser> but during the gutsy freezes processing of universe uploads was only on manual
[19:06] <persia> DktrKranz: It wasn't clear from the ML post.  Anyway, pretty much until DIF, you can upload as much of anything as you want.  Between DIF and FF, there's a little more effort to make sure things work properly.  After FF the freezes are fairly firm, and the focus is bugs.  Further, if there is a freeze, you can upload, but it won't get applied until the freeze is over.
[19:07] <DktrKranz> well, I preferred to limit uploads to avoid problems, luckily I had not urgent packages to manage
[19:10] <afflux> persia, geser: and another one... :) http://revu.tauware.de/details.py?upid=799
[19:10]  * persia is too tired to do another review tonight.
[19:13] <DktrKranz> afflux, since python-support depends on python, I think it is useless to have it listed in build-deps
[19:14] <geser> DktrKranz: afaik linda/lintian checks it
[19:15] <DktrKranz> geser, lintian/linda reports are clear
[19:15] <geser> DktrKranz: without a python b-d?
[19:15] <DktrKranz> IIRC, yes
[19:16] <geser> but imho it's better to depend on python and don't rely on other packages pulling it in
[19:18] <DktrKranz> List it in b-d does not harm, but I don't think python-support will exclude python from its dependencies. Anyway, it's not an error
[19:20] <jdong> nxvl_work: hey, got your e-mail on Azureus; I don't see any sense in merging it right now
[19:21] <jdong> nxvl_work: az 3.x requires SWT version 3.3, which in Ubuntu we derive from Eclipse 3.3
[19:21] <jdong> nxvl_work: last I heard there's people actively working on said Eclipse package already, so once that's in the merge of Azureus should be extremely trivial.
[19:22] <nxvl_work> jdong: a read something like that on LP, i send you the email to make sure of it, so if it's so, let's wait
[19:22] <jdong> nxvl_work: agreed :)
[19:23] <nxvl_work> is there any way to search ubuntu member by country?
[19:26] <geser> afflux: advocated. Please don't do any other uploads unless absolutely necessary.
[19:26] <persia> DktrKranz: About the NBS parser: could the depending package names link to their LP pages?
[19:27] <DktrKranz> persia, it's a WIP, I plan to interface it with python-apt first
[19:27] <persia> DktrKranz: OK.  I'll stop snooping for nifty-cool tools then :)
[19:28] <DktrKranz> heh
[19:28] <DktrKranz> :)
[19:28] <DktrKranz> Are NBS tracker sources available somewhere?
[19:30] <persia> DktrKranz: Frustratingly not, but the output is.
[19:30] <persia> Actually, the source might be available, but I can't see it.  Which reminds me.
[19:30] <DktrKranz> I based my script on its output
[19:30] <DktrKranz> but it's barely unfinished :)
[19:31] <persia> DktrKranz: Oh, you mean the one that generates that list?  I think it might be available.
[19:32] <DktrKranz> I mean the one who generate NBS output, probably I can find better ways to improve my *bad* script
[19:33] <geser> I assume it runs in the data center and the output is only copied to people.u.c
[19:33] <geser> DktrKranz: you might want to ask pitti
[19:34] <DktrKranz> I fear he's away now, but I'll ping when he will be online
[19:37] <persia> I think the sources aren't, as I don't see them in any of the usual places.
[19:37] <geser> DktrKranz: where are you stuck with your script?
[19:38] <persia> DktrKranz: The equivalent for Debian is available: look in the (opaque) DAK package.
[19:38] <DktrKranz> geser, http://people.ubuntuwire.com/~dktrkranz/NBS/. I'm not stuck, just I haven't found time to work on it :)
[19:39] <geser> DktrKranz: http://people.ubuntu.com/~pitti/scripts/checkrdepends might be source for it
[19:39] <persia> That looks like it takes input from somewhere else, no?
[19:40] <geser> then it's only a part of it
[19:41] <persia> That's what I thought.  Best to ask pitti on Monday
[19:58] <afflux> persia:  sorry, looks like I had a disconnect with tor. Did you say anything about gdecrypt since about 19:18 UTC?
[19:58] <DktrKranz> Lutin, mlt package requires sox-dev -> libsox-dev transition. Mind if I look at it or you plan to do some changes?
[20:00] <geser> afflux: advocated. Please don't do any other uploads unless absolutely necessary.
[20:02] <AnAnt> Hello, I made an icon-theme which is a modified version of human-icon-theme. human-icon-theme is licensed under CC, so what should the copyright my icon theme look like ?
[20:03] <Lutin> DktrKranz: planning to do some changes, I'll have a look. thanks for the heads-up :)
[20:03] <DktrKranz> Lutin, you're welcome :)
[20:03] <Lutin> DktrKranz: :)
[20:04] <MenZa> AnAnt, read the specific licence; it should say.
[20:13] <AnAnt> ok, if I have a package that contains several files, some are under GPL, some are under CC, how do I explain that in copyright file ?
[20:14] <geser> list which files are under which license
[20:15] <AnAnt> geser: can you tell me about an example package ?
[20:16] <AnAnt> geser: note that each of those files has a separate copyright holder ?
[20:16] <geser> sorry, not of my head
[20:17] <AnAnt> ok, thanks anyways
[20:17] <geser> AnAnt: I'd simply repeat the "author, copyright, licence"-block as often as needed and state to which files it applies
[20:19] <AnAnt> geser: ok, thanks
[20:39] <erable> Hi,
[20:40] <erable> I work with this package : http://revu.tauware.de/details.py?upid=725
[20:40] <erable> and I don't understand this comment "-dev needs to depend on the actual lib"
[20:42] <erable> dpkg --info libqextserialport-dev_1.1-0ubuntu1_i386.deb | grep Depend
[20:42] <erable> return:
[20:42] <erable> Depends: libqextserialport1 (= 1.1-0ubuntu1), libqt4-dev
[20:43] <geser> apachelogger: ^^ as you added that comment
[20:44] <geser> erable: it looks ok, so I don't understand that point either
[20:44] <apachelogger> agreed
[20:44] <apachelogger> was just me being stupid
[20:44] <apachelogger> erable: sorry
[20:45] <erable> Ok ;-)
[20:45] <erable> thank you for your comments
[20:46] <apachelogger> erable: hehe, you're welcome :)
[20:46] <erable> :-)
[20:53] <TheMuso> Hey folks.
[20:58] <geser> Hi TheMuso
[20:58] <apachelogger> erable: please merge the qtsmbstatus changelog lines to one: Initial release (LP: #119179)
[20:59] <apachelogger> erable: newline missing at the end of control file missing
[21:00] <erable> OK. I'll do that
[21:01] <apachelogger> erable: I think section="Applications" for .menu has been changed
[21:01] <apachelogger> not sure about that though
[21:01] <apachelogger> actually I think you can drop the .menu anyway, since everyone should be using freedesktop desktop files
[21:02] <apachelogger> that's my personal opinion though
[21:02] <apachelogger> typo in the .init: # Provides:          QtSbstatusd
[21:03] <apachelogger> erable: # Required-Start:    $smb should be samba AFAIK
[21:03] <apachelogger> cat /etc/init.d/samba | grep Provides
[21:03] <apachelogger> # Provides:          samba
[21:04] <apachelogger> erable: .pam also missing a newline at the end
[21:04] <erable> Yes, it's a generic script (sUSE USE $smb)
[21:05] <erable> ok
[21:10] <sistpoty> hi folks
[21:11] <apachelogger> erable: advocted qextserialport
[21:12] <sistpoty> persia: did you advocate sdlmame-cheat on purpose? (as you mention things to be fixed)
[21:12] <sistpoty> apachelogger: congrats to motu-ship!
[21:12] <apachelogger> sistpoty: thanks :)
[21:13] <erable> apachelogger: thanks :-)
[21:40] <Ubulette> RAOF, mozilla wants cairo 1.6 for ff3.
[21:49] <TheMuso> Did anybody request the removal of cinepaint from hardy?
[21:51] <sistpoty> dear lazyirc, I'm looking for a tool to fetch mail (just like fetchmail) via ssh from an mbox-file, any infos?
[21:52] <RAOF> Ubulette: Are they likely to get it?
[21:53] <geser> TheMuso: I only see a record in http://people.ubuntu.com/~ubuntu-archive/removals.txt but no bug for it
[21:53] <TheMuso> geser: Right.
[21:54] <TheMuso> Oh thats why.
[21:55] <TheMuso> geser: Theres no bug, because Debian removed it.
[21:56] <Ubulette> RAOF, they committed a bump to 1.5.2-55 today
[21:56] <Fujitsu> -55? That's insane!
[21:57] <Ubulette> 1.5.2-55-g39b8ddf to be precise
[21:57] <RAOF> Ubulette: What I mean is - is 1.6 likely to be released before FF3?  From what I gathered at the cairo site, the 1.5 unstable branch is pretty new.
[21:57] <geser> TheMuso: Debian removed also other packages that are still in Ubuntu
[21:58] <TheMuso> geser: Yeah I know. I was just chacing down a broken ubuntustudio metapackage thats all.
[22:00] <Ubulette> RAOF, I don't know for cairo but I doubt mozilla could even roll that back. it's too deeply merged
[22:00] <RAOF> Awkward.
[22:00] <Ubulette> ff3 b2 is nearly ready
[22:01] <RAOF> Presumably they're talking with cairo about it.
[22:01] <Ubulette> yes
[22:18] <LordKow> is the "Application" category for desktop files still being used? I thought I remember this not being the case
[22:19] <Amaranth> it was never supposed to be used, iirc it's not actually in the spec
[22:19] <geser> LordKow: iirc no, but check your desktop file with desktop-file-validate
[22:20] <LordKow> okay its Deprecated
[22:21] <LordKow> grr, we could sync this package with debian except for that one minor glitch
[22:27] <Amaranth> LordKow: If that's the only thing ignore it
[22:27] <Amaranth> LordKow: Everyone using Application in their categories anyway
[22:28] <Fujitsu> It is illegal, and anybody doing it is wrong, but it's not worth holding a delta for.
[22:29] <geser> LordKow: you could open a bug for it in Debian
[22:29] <Amaranth> This whole spec is stupid anyway so don't feel bad :P
[22:31] <LordKow> okay, what about UTF8 encoding?
[22:32] <Amaranth> that is deprecated, UTF-8 is the only encoding allowed
[22:32] <Amaranth> so it doesn't need to be there but can be
[22:32] <LordKow> okay, i'll request a sync.
[22:41] <Ubulette> !info libx264-dev hardy
[22:41] <ubotu> Package libx264-dev does not exist in hardy
[22:41] <Ubulette> !info libx264-dev gutsy
[22:41] <ubotu> libx264-dev: development files for libx264. In component multiverse, is optional. Version 1:0.svn20070309-4ubuntu1 (gutsy), package size 219 kB, installed size 660 kB
[22:41] <Fujitsu> sistpoty: You can drop the distros/ from LP URLs now, you know?
[22:41] <Ubulette> hmm
[22:42] <jdong> Ubulette: is there something wrong with x264?
[22:42] <norsetto> ubotu and ubulette falling in love it seems ......
[22:42]  * jdong puts on his blame-me badge
[22:43] <Ubulette> gst-plugins-bad-multiverse0.10 needs libx264-dev
[22:43] <jdong> Ubulette: which I don't know why isn't in Hardy.
[22:43] <jdong> https://edge.launchpad.net/ubuntu/+source/x264/1:0.svn20070930-0.0ubuntu1/+build/449762
[22:43] <jdong> it built on i386 5 days ago
[22:44] <Ubulette> #  Removal requested  12 hours ago.
[22:44] <jdong> huh?
[22:45] <Ubulette> https://edge.launchpad.net/ubuntu/+source/x264/1%3A0.svn20070930-0.0ubuntu1
[22:45]  * jdong looks confusedly at that
[22:46] <Ubulette> https://edge.launchpad.net/ubuntu/+source/x264    no hardy in there
[22:46] <Fujitsu> Did we inherit that removal from Debian?
[22:46] <jdong> why is it superseded?
[22:46] <jdong> Fujitsu: I don't think x264 was ever in Debian
[22:46] <jdong> at least not this release cycle
[22:46] <Fujitsu> jdong: I don't think it's superseded. It was directly requested to be removed.
[22:46] <Fujitsu> Otherwise you'd see `Superseded on blah'
[22:46] <jdong> Fujitsu: is there a log of who requested it?
[22:47] <Fujitsu> (From Debian) RM: RoFTPM; patent issues
[22:47] <jdong> Fujitsu: that shouldn't be applicable to our multiverse, should it?
[22:47] <Fujitsu> jdong: One would think not. Talk to an archive admin before it is properly removed.
[22:47]  * Fujitsu looks through other removals to see what shouldn't have been done.
[22:47] <jdong> hmm are any online currently?
[22:48] <Fujitsu> jdong: Most probably.
[22:48] <TheMuso> jdong, Fujitsu, I was asking similar questions about cinepaint earlier, however theres good reason why that has been removed.
[22:49] <Fujitsu> I'm glad to see cinepaint dead, right.
[22:49] <Ubulette> jdong, http://packages.qa.debian.org/x/x264.html
[22:49] <geser> we should decide what we do about the split out php5 modules (I see php5-interbase got removed)
[22:49]  * Fujitsu blinks.
[22:49] <jdong> Ubulette: correct, DEbian stopped distributing it and it went back to multimedia
[22:49] <Fujitsu> Why didn't the 7.10 removal run kill it?
[22:50] <Fujitsu> jdong: Get it blacklisted if you find an archive admin, please.
[22:50] <jdong> Fujitsu: does that mean blacklisted from removal?
[22:50] <Fujitsu> jdong: It should mean that the automatic tools (autosyncer and removals) should exclude it, I think.
[22:51] <jdong> Fujitsu: ok, gotcha, will keep eyes peeled for archivies :)
[22:51] <Ubulette> jdong, so what should I use instead ?
[22:51] <Fujitsu> I really wish the -changes lists actually showed changes, rather than just some uploads.
[22:52] <jdong> Ubulette: x264 must be restored. or I'll cry.
[22:52] <jdong> Ubulette: sit tight while we sort this out
[22:52] <jdong> Ubulette: feel free to flag down an archive admin if I don't get there first
[22:52] <TheMuso> Fujitsu: Like removals as well?
[22:52] <Fujitsu> TheMuso: Yes. And copies.
[22:53] <Fujitsu> And security uploads, but they're returning soon.
[22:55] <Ubulette> jdong, ok. I'll drop that from my bot queue
[22:56] <LordKow> ah crap, i cant file a sync on this for 1 reason
[22:56] <sistpoty> Fujitsu: btw: great work on security, keep going!
[22:56] <LordKow> +Exec=su-to-root -X -c gsambad
[22:56] <Fujitsu> sistpoty: Where did you discover I was doing much security stuff? The uploads aren't announced anywhere.
[22:57] <sistpoty> Fujitsu: I'm a member of motu-swat :P
[22:57] <Fujitsu> Ah.
[22:57] <Fujitsu> Of course.
[22:57] <Fujitsu> We need more people :(
[22:58] <Ubulette> hmm, my new shiny ipod is unusable in ubuntu. rhythmbox/exaile/banshee are all crashing.
[22:58] <Fujitsu> Ubulette: Touch?
[22:58] <Ubulette> hipo too
[22:58] <Ubulette> nano
[22:58] <sistpoty> Fujitsu: definitely... I'm feeling guilty for not having done a security fix for ages, since I'm just out of time :(
[22:58] <Fujitsu> IIRC I saw some uploads to Hardy to support them.
[22:58] <Fujitsu> sistpoty: Most people haven't done a security fix ever.
[22:59] <DarkMageZ> Ubulette, check the libgpod site and see if they've implemented support for it. if so then rebuild libgod then your prefered player against that.
[23:00] <superm1> Ubulette, actually i've got a fair deal of stuff for gutsy to help make it work you can try
[23:00] <sistpoty> Nafallo: not most, but some... (e.g. crimsun did quite some security in the old days)
[23:00] <superm1> with the newer libgpod
[23:00] <superm1> and everything rebuild against it
[23:00] <superm1> in the ~ipod-touch ppa
[23:00] <sistpoty> s/nafallo/Fujitsu
[23:01]  * keescook hugs all the motu-swat :)
[23:01] <Fujitsu> Hey keescook.
[23:01] <keescook> heya!
[23:01] <Nafallo> sistpoty: hi :-)
[23:01] <superm1> hi keescook
[23:01] <sistpoty> hi Nafallo :)
[23:01] <sistpoty> and hi keescook:
[23:01]  * TheMuso would help with security, but he already has enough on his Ubuntu plate.
[23:02] <keescook> hai sistpoty, superm1 :)
[23:02] <Ubulette> !info libgpod hardy
[23:02] <ubotu> Package libgpod does not exist in hardy
[23:02] <superm1> Ubulette, in hardy its libgpod3
[23:02] <Ubulette> !info libgpod3 hardy
[23:02] <ubotu> libgpod3: a library to read and write songs and artwork to an iPod. In component main, is optional. Version 0.6.0-3 (hardy), package size 191 kB, installed size 400 kB
[23:02] <Fujitsu> keescook: Was there any reason you didn't roll the single character fix for CVE-2006-3122 into you recent dhcp security uploads?
[23:02] <ubotu> The supersede_lease function in memory.c in ISC DHCP (dhcpd) server 2.0pl5 allows remote attackers to cause a denial of service (application crash) via a DHCPDISCOVER packet with a 32 byte client-identifier, which causes the packet to be interpreted as a corrupt uid and causes the server to exit with "corrupt lease uid." (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3122)
[23:02] <sistpoty> Fujitsu: however feel free to take the lead and remove old/inactive members
[23:05] <sistpoty> Fujitsu: btw.: there is one pending request from emgent (obviously not around)... did he provide debdiffs or some stuff yet? otherwise I'll decline him.
[23:06] <Fujitsu> sistpoty: He has done a little bit of stuff, but I'm not sure. I declined somebody else a couple of days back; they hadn't done anything at all.
[23:07] <sistpoty> Fujitsu: ok, then I'll just leave him as waiting approval and you'll approve/decline him once the time has come ;)
[23:07] <Fujitsu> sistpoty: Yep.
[23:13] <TheMuso> c
[23:13] <TheMuso> ugh fingers
[23:13] <Fujitsu> TheMuso: Yes, damn fingers. Best to cut them off.
[23:15] <TheMuso> Fujitsu: If only, if only.
[23:24]  * sistpoty needs to go to bed now... gn8 everyone
[23:26] <RainCT> good night
[23:32] <Ubulette> ok, i've packaged libgpod-0.6.0+svn20071126r1804, i'm gonna try that one
[23:40]  * emgent heya
[23:40] <Fujitsu> Hi emgent.
[23:43] <LordKow> bug 173155
[23:43] <ubotu> Launchpad bug 173155 in gsambad "Please upload merge gsambad-0.1.8-1 (universe) from Debian unstable (admin)" [Undecided,Confirmed] https://launchpad.net/bugs/173155
[23:44] <Fujitsu> keescook: Do you agree with Debian's unimportant assessment of CVE-2007-6131? It is marketed as just a demo script, but you never know...
[23:44] <ubotu> buttonpressed.sh in scanbuttond 0.2.3 allows local users to overwrite arbitrary files via a symlink attack on the (1) scan.pnm and (2) scan.jpg temporary files. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6131)
[23:57] <norsetto> g'night all