[00:01] <crimsun_> jdong: "interested" may be ... harsh :-)
[00:01] <jdong> crimsun_! long time no see!
[00:01] <crimsun_> hi
[00:01] <jdong> http://jdong.mit.edu/~jdong/motu/azureus_2.5.0.4-1ubuntu2.dsc
[00:01] <Fujitsu> jdong: Didn't you just upload it a couple of days back?
[00:01] <jdong> tested in pbuilder and so on
[00:01] <crimsun_> I'll be up at Lincoln Labs visiting colleages soon
[00:02] <jdong> Fujitsu: yeah, minor fix (launcher feature) needed
[00:02] <jdong> crimsun_: awesome, so you're gonna be wearing one of those huge red TEMPORARY VISITOR badges? :)
[00:02] <Fujitsu> Does it actually work now?
[00:02] <jdong> Fujitsu: yep
[00:02] <Fujitsu> Wow.
[00:03] <jdong> Fujitsu: currently there's a gutsy bug with icedtea-java7 where amd64 crashes
[00:03] <jdong> Fujitsu: but that's an icedtea problem nad I'm looking at a fix right now
[00:03] <Fujitsu> It's now actually based on Debian? Sounds like what I'm trying to do to mplayer, though worse.
[00:03] <jdong> Fujitsu: yeah, our debdiff from Debian is < 10 lines
[00:03] <StevenHarperUK> Hi, I am looking for another review on REVU, I have made all the changes requested in my last review : I have no advocates so far : http://revu.tauware.de/details.py?upid=437
[00:03] <Fujitsu> Good, good.
[00:03] <crimsun_> jdong: something like that
[00:04]  * Fujitsu ponders upgrading to Hardy some time today.
[00:04] <jdong> Fujitsu: as soon as we get this SRU to Gutsy over with, then I'll move onto getting 3.0.3.4 into Hardy :)
[00:04] <crimsun_> though generally when people visit my workplace, they wear those huge red visitor badges ;)
[00:04] <Fujitsu> jdong: And diverging horribly from Debian again? Yay!
[00:05] <jdong> Fujitsu: no, Debian has 3.0.3.4 already :)
[00:05] <Fujitsu> Oh.
[00:05] <jdong> Fujitsu: just their SWT 3.3 build-dep magically is missing. And I need to talk with eclipse gods (i.e. doko) to figure out what our plans of SWT 3.3 are
[00:05] <LaserJock> people still use azureus? ;-)
[00:05] <jdong> LaserJock: people who use it have been unpacking it from tarballs...
[00:05] <Fujitsu> Yeah, I read about that somewhere.
[00:05] <montgoej> Does anyone know why iceweasel has no installation candidate? it leaves iceweasel-torbutton with a broken dependency so it's uninstallable
[00:05] <jdong> LaserJock: which is why we need our packaging to work
[00:05] <Fujitsu> jdong: Worked out how you're going to get it back to Feisty yet?
[00:06] <jdong> Fujitsu: not yet.... that's on a side burner for now...
[00:06] <Fujitsu> OK.
[00:06] <jdong> Fujitsu: since you've asked the most questions,w ould you care to upload? :D
[00:06] <LaserJock> montgoej: because we have firefox?
[00:06] <Fujitsu> montgoej: We don't have iceweasel in Ubuntu, and that is a known-broken package.
[00:06] <montgoej> ok, just making sure
[00:06] <Fujitsu> jdong: Sure, once I check the debdiff.
[00:07] <jdong> Fujitsu: sounds good! *hug*
[00:07] <montgoej> I just saw all the iceweasel-related packages and noticed that they couldn't be installed
[00:09] <StevenHarperUK> Fujitsu: you reviewing packages on REVU anymore?
[00:09] <Fujitsu> jdong: Looks sane, I'll upload it shortly.
[00:10] <Fujitsu> StevenHarperUK: I've not reviewed more than a few before, and not recently.
[00:10]  * Fujitsu hides.
[00:10] <StevenHarperUK> Fujitsu: wuss :p
[00:10] <crimsun_> well, in his defense, he has dealt with azureus for a while.  That's enough to scar sane people.
[00:11] <Fujitsu> I need to run off for about 20 minutes now, I'll upload when I get back, hopefully after it has built.
[00:11] <Fujitsu> I looked at merging it a couple of times... I'll never recover from that.
[00:11] <StevenHarperUK> Wow bet Azureus is evil to package
[00:15] <LaserJock> man I hate email and web browsers
[00:16] <crimsun_> true, give me the raw hex anyday!
[00:18] <LaserJock> maybe my laptop just stinks
[00:26] <LaserJock> Amaranth: ping
[00:30] <jdong> Fujitsu: merci beaucoup!
[00:31] <_16aR_> Hello
[00:31] <_16aR_> Has someone a link to a debian/watch file usage ? And how it works ? (does it work with .zip etc...)
[00:32] <ion_> man uscan, and now read the topic, please.
[00:32] <ion_> Sorry! Please ignore that.
[00:32] <ion_> I thought this was #ubuntu-devel.
[00:33] <_16aR_> ion_: was it for me ?
[00:34] <ion_> man uscan, please :-)
[00:34] <_16aR_> yes, i'm already reading it
[00:34] <_16aR_> thanks
[00:35] <ion_> I don’t think zip files are supported, since the orig.tar.gz must be, well, tar.gz :-)
[00:35] <_16aR_> 1 point :p
[00:36] <_16aR_> but a upstream package shouldn't be named orig.tar.gz, and so it could be in another format too, no ?
[00:36] <ion_> They’d have to be converted (some also put the original zip file inside a tarball and use e.g. cdbs or their own rules to unpack it on build).
[00:37] <Amaranth> LaserJock: pong
[00:41] <Fujitsu> jdong: What did you do to it? It runs at an almost reasonable speed! (though is asking me to update...)
[00:42] <jdong> Fujitsu: magical jdong sauce ;-)
[00:42] <jdong> Fujitsu: and yeah, the stupid updater wants to update itself, THEN use itself to update itself
[00:42] <LaserJock> Amaranth: alacarte seems to really hog CPU and is very difficult to check/uncheck more than one menu item in arow
[00:42] <jdong> Fujitsu: -EUPSTREAMRETARDEDNESS
[00:42] <LaserJock> Amaranth: is that "normal"
[00:42] <jdong> LaserJock: I think you spelled "Is written in Python" in correctly.
[00:42]  * jdong ducks
[00:43] <Amaranth> LaserJock: it shouldn't chew CPU but the check/uncheck thing is 'normal'
[00:43] <Amaranth> LaserJock: I've been meaning to add a speed hack in there but I've also been rewriting it in vala on the side
[00:43] <Amaranth> If vala had a libxml2 binding or something I'd be done already
[00:44] <LaserJock> k
[00:44] <LaserJock> I installed KDE and it dumped a tone of items in Other
[00:44] <LaserJock> it's seriously gonna take 5-10 minutes to clean it up
[00:44] <Amaranth> yeah, it's _awesome_ like that
[00:44] <Amaranth> just hide the entire Other menu
[00:45] <LaserJock> except other usefull stuff ends up in Other :(
[00:45] <Amaranth> so copy it elsewhere :)
[00:51] <Fujitsu> jdong: uploaded
[00:52] <jdong> Fujitsu: thanks
[00:53] <gnomefreak> any motus around that can look at http://revu.tauware.de/details.py?upid=438
[01:09] <bddebian> Heya gang
[01:09] <crimsun_> 'lo barry
[01:09] <bddebian> Heya crimsun_
[01:11] <crimsun_> eek, I had forgotten what a behemoth iceape is
[01:11] <bddebian> heh
[01:18] <gnomefreak> crimsun_: it is huge :(
[01:19] <gnomefreak> wait for xulrunner+iceape :(
[01:22] <LaserJock> I hope we can really use xulrunner soon
[01:23] <ion_> Indeed
[01:29] <LaserJock> dang it, my laptop won't stay on
[01:29] <LaserJock> must've overheated it or something
[01:30] <jdong> LaserJock: try threatening it
[01:30] <jdong> LaserJock: place a Vista Home Basic DVD in the CD tray.
[01:31] <jdong> it won't DARe turn off
[01:31] <LaserJock> heh
[01:31] <LaserJock> I was mid installation too
[01:31] <zul> saying dag nab it might help ;)
[01:31] <LaserJock> hopefully it didn't corupt the dpkg cache
[01:31] <jdong> LaserJock: might wanna give it some ACPI T-state throttling love next time?
[01:33] <LaserJock> jdong: how do I do that?
[01:33] <jdong> LaserJock: /proc/acpi/processor/CPU[0-9]/throttling
[01:33] <LaserJock> I don't think my proc does throttling
[01:33] <jdong> LaserJock: it lists all available states, should be like "echo T3 > throttling" to set one
[01:33] <jdong> LaserJock: most ACPI capable CPU's do throttling (not all do CPU frequency scaling)
[01:34] <jdong> LaserJock: throttling just forces the CPU to sleep X% of the time
[01:34] <LaserJock> ah
[01:34] <jdong> LaserJock: so remember, 0% is least throttled, 87% is almost braindead :)
[01:34] <LaserJock> well, the stupid thing is already slow, but maybe that might help
[01:34] <jdong> great for reducing heat
[01:34] <LaserJock> I was hoping winter would help ;-)
[01:34] <jdong> LaserJock: I use bottles of compressed air for that ;-)
[01:34] <jdong> LaserJock: hold upside down and spray, propellant comes out in solid form
[01:35] <jdong> LaserJock: also very entertaining for flash-freezing annoying insects.
[01:39] <LaserJock> jdong: /proc/acpi/processor/CPU0$ cat throttling
[01:39] <LaserJock> <not supported>
[01:39] <jdong> LaserJock: shucks
[01:39] <jdong> LaserJock: well, periodically ctrl+z dpkg and let the computer rest?
[01:39] <jdong> ROFL
[01:40] <jdong> human throttling governor
[01:40] <LaserJock> yeah, one of my more brilliant purcheses
[01:40] <jdong> LaserJock: or use the wad-of-propellant idea :)
[01:40] <jdong> just make sure no earth hippies are around
[01:40] <LaserJock> haha
[01:41] <jdong> we used that all the time in robotics, to flash-cool overdriven motors
[01:41] <jdong> best stuff ever. swiss army knife in a can
[02:17]  * jdong shakes fists at bulletprooof X
[02:18] <jdong> diagnosticproof X is more like it
[02:18] <jdong> edit xorg.conf for 10 minutes, then figure out it's reading xorg.conf.failsafe
[02:23] <bddebian> Grr, damnit.  What option to diff creates that Index: foo/bar/baz.c stuff?
[02:23] <bddebian> I usually use -urN
[02:26] <bmk789> hey crimsun_
[02:39] <blueyed> bddebian: AFAIK the Index: stuff comes from e.g. "cvs diff"
[02:40] <bddebian> hrm
[03:05] <s1024kb> Good morning everyone
[03:06] <s1024kb> It's 10:06 here in China
[04:41]  * Hobbsee waves
[04:41] <Hobbsee> wow, people really must hate me.
[04:42] <bddebian> Hi Hobbsee.  It's super quiet tonight
[04:42] <persia> Good afternoon Hobbsee (I'm just slow, rather than filled with hatred :)  )
[04:42] <Hobbsee> bddebian: ahh.  probably driven them all away
[04:42] <Hobbsee> persia: fair enough
[04:47] <Hobbsee> ScottK: ping
[04:47] <bddebian> Hey since you're here, I'm in a quandry.  I'm working on the games team packages and kxl had config.{sub,guess} that were out of date so I copied them in.  Now I just realized that they were patching them.  You think I should revert what I did or take those out of the patch?
[04:49] <persia> bddebian: I'd recommend you drop the patches, and copy them in configure:  If the build breaks, other files should be adjusted: not those.
[04:49] <Hobbsee> pass.  i tend to let them just regenerate
[04:51] <minghua> !weekend | Hobbsee
[04:51] <ubotu> Hobbsee: It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
[04:51] <ajmitch> hi Hobbsee
[04:51] <minghua> Hobbsee: The same applies to love. :-)
[04:52] <ajmitch> Hobbsee: how could you possibly suggest that people hate you?
[04:52] <slangasek> minghua: Ubuntu has paid lovers?
[04:52] <LaserJock> Hobbsee: hi!
[04:52] <bddebian> Yeah, it's me they all hate :-)
[04:52]  * LaserJock hugs Hobbsee 
[04:52]  * bddebian spreads love all over #debian-devel
[04:52] <LaserJock> bddebian: designated hatee? ;-)
[04:52] <minghua> slangasek: Not that I know of... But who knows?
[04:52]  * ajmitch hugs the Hobbsee 
[04:52] <bddebian> slangasek: You have thoughts on my question above?
[04:52] <bddebian> LaserJock: Heh. Heya
[04:53] <Hobbsee> minghua: ahhh
[04:53] <slangasek> bddebian: what question?
[04:53] <Hobbsee> ajmitch: oh, i dont know.  i just hear poeple bitching about me wanting change :)
[04:53] <ajmitch> Hobbsee: bitter about work again? :)
[04:53] <slangasek> bddebian: er.  someone was patching config.{guess,sub}? DIE
[04:53] <bddebian> Hobbsee: You are just becoming grumpy like the rest of us ;-P
[04:53] <Hobbsee> ajmitch: apparently it's MOTU's job to impose rules which would be more done for kids, isntead of making them grow up.
[04:53] <bddebian> slangasek: Well that was my thought but I never know how much hatcheting to do without getting bitched at
[04:53] <ajmitch> ah, I see...
[04:54] <Hobbsee> ajmitch: which, oddly enough, i have rather large objections with :)
[04:54] <ajmitch> which rules are these?
[04:54] <slangasek> bddebian: anyone who's forking config.{guess,sub} should have their head examined.  But are you sure it's not a case that they're "patching" them with a newer upstream version?
[04:55] <Hobbsee> ajmitch: oh, just various ones.  test before upload, don't upload openoffice to the buildds repeatedly.  dont ask for reviews every 20 mins.  check *all* ubuntu changelog entries to see if the changes are still required when merging/syncing.
[04:55] <ajmitch> right
[04:55] <Hobbsee> ajmitch: those are some ones from the last couple of days :)
[04:55] <ajmitch> common sense stuff, you mean
[04:55] <Hobbsee> ajmitch: exactly.  which people don't seem to have.
[04:56] <Hobbsee> or choose not to use.
[04:56] <ajmitch> uploading openoffice would be painful in itself
[04:56] <Hobbsee> ajmitch: 3 times to a ppa is special, i thought.  and then i get bitched at for making a stand for it, when i'm not a LP dev.
[04:56] <ajmitch> ah much as we'd love LP to have infinite resources for building & all
[04:58] <bddebian> slangasek: Well that is essentially what they are trying to do, yes
[04:58] <Testing> /nick RAOF
[04:59] <bddebian> But that's still static isn't it?
[04:59] <blueyed> Hobbsee: again, I've uploaded it three times - because it failed before (syntax error with the patch). There was someone else also uploading it (once) without any patch. So altogether it got built twice..
[05:00] <Hobbsee> blueyed: wasnt particularly attempting to point out names - just of recent questionable things that people had particularly done.
[05:00] <Hobbsee> blueyed: btw, do you know about buildprep, which will check if your patches apply?
[05:00] <persia> bddebian: Yes.  It's common for packages to have either a manual copy of the build hints, or to stick it in the clean: rule (for auto-patching each source build), both of which result in an apparently intentional patch.
[05:01] <blueyed> Hobbsee: no, obviously not.. :) Does it work also for the OOo patch system?
[05:01] <bddebian> You folks are making my head hurt :-)
[05:02] <Hobbsee> blueyed: i'd expect so. give it a try, anyway.
[05:02]  * Hobbsee looks up the rune
[05:02] <Hobbsee> #check all patches apply, autoconf runs, and removes the patches again
[05:02] <Hobbsee> sudo make -f debian/rules buildprep
[05:02] <Hobbsee> blueyed: useful in kde packages too, where you dont want to build the entire source :)
[05:03] <persia> bddebian: OK,  The build hints can be taken from upstream, taken during packaging, taken at source package build time, or taken at binary package build time.  I like the last, but all four are used for packages.
[05:04] <bddebian> Aye, in the configure target I am copying them from /usr/share/misc then removing config.{sub,guess} in the clean target
[05:05] <blueyed> Hobbsee: there's no buildprep target in ooo (and apt, too)
[05:06] <Hobbsee> blueyed: unsure if there needs to be.  just try it.
[05:06] <blueyed> Hobbsee: did so (in the apt package, which I'm currently hacking)
[05:06] <blueyed> ooo is currently building anyway.
[05:07] <persia> bddebian: If you're doing that, you can drop any patches to those files in diff.gz.
[05:07] <LaserJock> perhaps a buildprep rule would be handy to add
[05:08] <LaserJock> it'd be nice if people just didn't upload OOo period
[05:08] <bddebian> heh
[05:09] <LaserJock> or perhaps a better queue management
[05:09] <LaserJock> where OOo and long jobs can run on one machine
[05:09] <Hobbsee> LaserJock: i've already pinned the latest upload of ooo until there are more, better changes in it.
[05:09] <Hobbsee> LaserJock: there are only 2 machines for ppa anyway
[05:09] <LaserJock> well, of course that's a problem to start with ;-)
[05:10] <Hobbsee> yeah wlel.
[05:10] <LaserJock> elmo told me they had at least a dozen "community" build machines for MOTU
[05:10] <bddebian> Grr, this is what I was trying to avoid, how the hell am I still getting this??:
[05:10] <bddebian> W: kxl; The file config.guess contains a timestamp line that is less than 2002.
[05:10] <LaserJock> so I'm not sure why they only would have 2 for PPA
[05:10]  * bddebian suggests just removing PPA ;-)
[05:10] <ajmitch> Hobbsee: they're probably 2 xen domains on the same server, too :)
[05:10] <Hobbsee> LaserJock: i wonder if they didnt expect them to take off so much - or if they expected people would follow the "dont dos the buildds
[05:10] <Hobbsee> a little more
[05:10] <Hobbsee> ajmitch: most likely, yes.
[05:12] <blueyed> Hobbsee: bug 131526 might be worth to include in the next upload :) - it's confirmed to be fixed for amd64 once, based on the ppa build.
[05:13] <blueyed> https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/131526
[05:13] <persia> bddebian: lintian isn't very good about that.  You can make it shut up with a static copy as well as the configure: change, or just ignore it as irrelevant.
[05:13] <Hobbsee> blueyed: i'm not crazy enough to upload openoffice.
[05:14] <bddebian> persia: OK, thanks man
[05:15] <persia> bddebian: No problem.  Thanks for chasing all this so early in the cycle: I forsee a lot of syncs, and a great gaming platform for hardy.
[05:17] <LaserJock> people play games on Ubuntu?!?!?!
[05:17] <ajmitch> apparantly so
[05:18] <LaserJock> what a waste of CPU
[05:18] <LaserJock> they could be building packages
[05:18]  * ajmitch puts WoW into the background so that LaserJock doesn't see it
[05:18] <persia> LaserJock: Isn't that what it is designed for?  Seems a nice platform for games, and new free ones are available every six months.
[05:18] <LaserJock> as a part of the vast Pbuilder@Home project ;-)
[05:18] <bddebian> persia: Yeah baby.. :-)
[05:19] <bddebian> heh
[05:19]  * LaserJock is hardware limited
[05:19] <imbrandon> http://picasaweb.google.com/holtsclawb/Holloween2007/photo#5125865068756227570    woot, "fun with the kids"
[05:19] <imbrandon> LaserJock, tell me about it
[05:19] <LaserJock> if I had any machines that could run games I might be tempted
[05:19] <LaserJock> imbrandon: happy Nevada Day!
[05:19] <imbrandon> Ubuntu Pumkin heh
[05:19] <bddebian> The Witcher releases in 4 days w0000t
[05:20] <imbrandon> LaserJock, bleh , lol
[05:20]  * bddebian will be even more useless for Hardy when The Witcher arrives
[05:20] <LaserJock> I got the day off man, I'll celebrate darn near anything for a day off
[05:20] <imbrandon> UO ? lol
[05:20]  * Hobbsee wonders what a day off is
[05:21] <LaserJock> Hobbsee: a day when you get to spend more time working on Ubuntu than work *without* getting into trouble
[05:21] <bddebian> heh
[05:25]  * slangasek questions this definition :)
[05:26] <Hobbsee> LaserJock: right.
[05:26] <imbrandon> slangasek, well for you its the other way arround i guess ;)
[05:27] <bddebian> hehe
[05:28] <bddebian> Damn the games team channel is lonely :'-(
[05:28]  * bddebian just talks to freakin' much
[05:29]  * minghua wonders why his OO.o keep using ~80% CPU.
[05:29] <persia> bddebian: You could be more verbose with questions.  Complaining there, and getting solutions here makes it kind of empty :)
[05:29] <imbrandon> my house is lonely too right now. everyone is asleep and i'm just gazing at my pumkin ;)
[05:30] <bddebian> persia: ?
[05:30] <persia> imbrandon: When the pumkin begins to gaze back, you can sleep :)
[05:30] <bddebian> imbrandon: Is that what they are calling it these days? ;-P
[05:30] <imbrandon> lol
[05:31] <imbrandon> damnit , i lost part of my blog db
[05:31]  * imbrandon grumbles
[05:41] <persia> ajmitch: I'm looking at wx2.4 again (with greater determination).  Is GNUe completely dead upstream?  Any thoughts about dropping it from Ubuntu?
[05:42] <ajmitch> parts of it just don't get love upstream, other parts need packages updated
[05:45] <persia> ajmitch: OK.  The current version doesn't seem to work with newer WX.  Is this something you're likely to find time for in the next couple months?  Do you think there are many users?
[05:45] <ajmitch> very few users
[05:46] <persia> Hmm...  If there are users, dropping seems less ideal.
[05:46] <ajmitch> I can't really tell :)
[05:46] <ajmitch> I'm most likely to update & orphan at same time
[05:47] <persia> ajmitch: I haven't seen many recent bug reports, but that's not an ideal indication.  I'll wait on your upload, and if it still doesn't work, try to get a python person to port it, or request a drop.
[05:48] <mudoch> hi all, got a question regarding the latest update. phpMyadmin dumped my config, now I'm forced to login, when I run the scrtipts/setup.php I get a user/pass propmt any ideas?
[05:48] <LaserJock> geeze, can KDE possibly make *smaller* file chooser :(
[05:48] <imbrandon> newer phpmyadmins dont store the pass in the config anylonger
[05:49] <mudoch> actually it was 7.10 that replaced the config, now phpMyAdmin bugs me for user
[05:50] <mudoch> yeah I got that some what figured out... the htpassword file show admin:* but that does not work
[05:52] <mudoch> imbrandon, is this a ubuntu thing or something that can be found in the phpMyAdmin doc
[05:55] <imbrandon> its a phpmyadmin practice, it was changed
[06:02] <bddebian> Ah well, gnight folks
[06:02] <ajmitch> night
[06:29] <s1024kb> Hello everyone. Hello Hobbsee.
[06:29] <Hobbsee> hi s1024kb
[06:30] <s1024kb> Hobbsee, nice to meet you again. Today i had made a little bit progress...
[06:34] <Hobbsee> yay!
[06:36] <coNP[uni]> Good morning MOTUs!
[07:22] <imbrandon> moins coNP[uni]
[07:23] <coNP[uni]> hey imbrandon
[07:23] <imbrandon> heh my pumkin finaly hit planet, we'll see if it takes off like the ubuntu cakes did
[07:32] <jdong> http://paste.ubuntu.com/1355/
[07:32] <jdong> This... HTML... is... MADNESS
[07:32] <jdong> Why does MS Office think it's neccessary to open and close like 5 nested tags per line?
[07:33] <persia> jdong: It tracks format changes based on the active area of the selection at the time the format is created.  Further, it has an internal hierarchy of classes, which is never broken (fonts do not stay constant between paragraphs).
[07:34] <jdong> persia: interesting...
[07:34]  * jdong would still like a plaintext equiv though :)
[07:35] <coNP[uni]> imbrandon: it is cool :)
[07:52] <imbrandon> err did ntp.ubuntu.com go away ?
[07:54] <persia> imbrandon: It resolves and pings from here...
[07:55] <imbrandon> hrm
[07:55] <imbrandon> persia, ...
[07:55] <imbrandon> brandon@enterprise:/storage/www/imbrandon.com$ sudo ntpdate ntp.ubuntu.com
[07:55] <imbrandon> 27 Oct 01:51:57 ntpdate[5190]: no server suitable for synchronization found
[07:56] <elmargol> I think html is broken. we have to start fram scratch :/
[07:57] <imbrandon> hrm dident the canonical staff have a sysadmin channel at one time
[07:57] <LaserJock> is that #canonical-sysadmin>
[07:57] <imbrandon> i dident even notice untill my /var/log/mail filled to 108mb with errors
[07:58] <imbrandon> i guess i should .forward that
[08:12] <CyrilleB> hi there
[08:12] <CyrilleB> I am trying to build a package following instruction at http://doc.ubuntu.com/ubuntu/packagingguide/C/basic-scratch.html
[08:13] <CyrilleB> but I get a very strange error http://pastebin.com/d2fd2d134
[08:13] <CyrilleB> the diff and dsc are there http://cyrille.diwi.org/tmp/krita/deb/
[08:13] <CyrilleB> if someone has an idea of what I am doing wrong ?
[08:22] <gpocentek> CyrilleB: you don't install the CONTROL file
[08:22] <gpocentek> so dpkg-deb doesn't find it
[08:22] <gpocentek> dpkg*
[08:24] <gpocentek> s/CONTROL/control/ BTW :)
[08:35] <persia> For hardy, does each package still need to check for /var/run/ individually, or is this being guaranteed at a higher level?
[08:39] <CyrilleB> gpocentek: seems to work better :) thanks, but I still have removed too much stuff from binary-arch
[08:41] <gpocentek> CyrilleB: honnestly, use debhelper
[08:42] <gpocentek> packaging without with is not easy (even though it's a nice way to learn)
[08:42] <gpocentek> s/with /this /
[08:42] <CyrilleB> gpocentek: I first try with that, but it didn't work for me, I don't remember where I failed :
[08:42] <CyrilleB> :/
[08:43] <gpocentek> CyrilleB: if you can build debian/rules from scratch it shouldn't be hard to use the template provided by dh_make and adapt it for your package
[08:44] <gpocentek> but that's up to you :)
[08:45] <CyrilleB> ok I will try again, maybe it will work better now that I understand a little bit more how to create debs package ;)
[08:46] <gpocentek> yep :)
[08:51] <CyrilleB> gpocentek: ah I remember now, debuild insists for the package to be signed
[08:51] <gpocentek> CyrilleB: ah, that's not a problem
[08:52] <gpocentek> you can use debuild -us -uc
[08:52] <imbrandon> debuild -us -uc
[08:52] <imbrandon> heya gpocentek
[08:52] <gpocentek> hello imbrandon
[08:55] <nxvl> i'm having a problem with nmap and wirelles, but i think is a driver problem, where should i report it, tu laptop team or tu MOTU/nmap ?
[08:55] <persia> nxvl: You should probably report it to LP first :)
[08:56] <nxvl> persia: yes, i know, but i report it as a driver problem, or as an nmap problem?
[08:57] <persia> nxvl: Ah.  Depends on how it breaks.  You'll want to investigate a bit: run it in a debugger, and if the problem appears to be in kernelspace, report as a driver issue.  If the problem appears to be in userspace, report as an nmap issue.
[08:57] <nxvl> persia: how do i debug it? with debug command?
[08:58]  * persia points nxvl at https://wiki.ubuntu.com/DebuggingProcedures and #ubuntu-bugs
[08:58] <nxvl> persia: thnx
[08:58]  * nxvl hugs persia 
[09:06] <nxvl> did someone knows which is the SysRq key?
[09:08] <imbrandon> the one that says sys req ( normaly with print screen on it too )
[09:17] <persia> DktrKranz: The aolserver4 packages in Debian underwent some significant changes to not include the library and daemon in the same place.  Do you have an interest in the packages, or were you just chasing QA?
[09:18] <DktrKranz> persia, I managed several merges of it, but I have no direct interest
[09:20] <persia> DktrKranz: OK.  From what I can tell, there's a transition underway.  If you're planning to merge the others, I wanted to ask you to also merge aolserver4 (my change can be dropped).  If not, I'll take a look at all of them later (if someone else doesn't first).
[09:23] <DktrKranz> persia, I'll have a look at it, maybe askink Debian maintainer additional informations to avoid future issues
[09:23] <DktrKranz> *asking
[09:23] <jeromeg> anyone running kubuntu gutsy here for a little test ?
[09:23] <persia> DktrKranz: Thanks.
[09:24] <jpatrick> jeromeg: I could try
[09:24] <DktrKranz> thanks to you for pointing that out
[09:24] <imbrandon> jeromeg / jpatrick , there is also #kubuntu-testers with lots of guiney pigs
[09:24] <jeromeg> jpatrick: bug 157332
[09:25] <jeromeg> jpatrick: you just need to install xfce4-terminal, run it and see if there is a scroll bar
[09:25] <jeromeg> thx
[09:26] <CyrilleB> ok a big thanks again, I now have a package :) bye
[09:26] <jeromeg> imbrandon: i'll go there
[09:26] <imbrandon> jeromeg, no biggie, just thought you would reach a better target there
[09:27] <imbrandon> was mostly FYI
[09:38] <DktrKranz> persia, after a quick look, I tend to agree with you. There could be several packages involved, they are maintained by the same DD of aolserver4, so it will be easier to have things clear.
[09:39] <persia> DktrKranz: Personally, I'd really prefer libaolserver4 to aolserver4-core, but I suspect it won't get quite that clean :)
[09:40] <DktrKranz> well, since it can be confused with SONAMEs, maybe it's a pondered choice
[09:41] <persia> DktrKranz: Perhaps.  On the other hand, it is providing libraries against which clients link...
[09:42] <DktrKranz> it has no explicit soname, maybe ABI/API compatibility is stable enough to justify it
[09:43] <DktrKranz> but frankie surely knows what he does :)
[09:57] <jeromeg> does anyone knows the name of the package which enables to set up shared folders in the gnome system menu ?
[09:58] <persia> jeromeg: I don't know the package, but I can give you a way to find out:
[09:58] <jeromeg> persia : apt-file ?
[09:58] <persia> First, find and remember the name of the control tool used in the gnome menu to enable that.
[09:59] <persia> jeromeg: apt-file doesn't translate menu entries into applications :)
[09:59] <jeromeg> :)
[09:59] <persia> Then, grep "Name" /usr/share/applications/*, to find out if it is in an installed .desktop file.
[10:00] <persia> If it's not there, take a look in /usr/share/app-install/desktop to see if it's used in any of those (which list package names).
[10:01] <persia> Once you find a target file, you can use apt-file or the like to get a package name.
[10:01] <jeromeg> ok thank you
[10:05] <jeromeg> persia : got it thank you, gnome-system-tools
[10:44] <DarkMageZ> apachelogger, about projectm 1.01. it appears to work fine under amarok here :s. not sure what's wrong with their setups. also 1.0 branch is supported by upstream.
[10:45] <apachelogger> hm
[10:45] <apachelogger> DarkMageZ: what driver?
[10:45] <apachelogger> ati?
[10:46] <DarkMageZ> apachelogger, ati rv350 (ati 9600se) with the fglrx driver.
[10:46] <apachelogger> hm
[10:46] <apachelogger> so projectm 1.0 is the only thing that runs on an ati chip better than on nvidia ;-)
[10:46] <DarkMageZ> apachelogger, have you had problems with it yourself?
[10:46] <apachelogger> yep
[10:46] <apachelogger> intel here
[10:46] <apachelogger> also with nividia-glx
[10:48] <DarkMageZ> apachelogger, hmm. if it's not user error. then it'd be worth poking @ carm/structured on #projectm and see if you guys can get it sorted rather than falling back to obsolete software :(
[10:49] <apachelogger> well, they know about it
[10:49] <apachelogger> for now I'll just wait whether they come up with a fix
[10:49] <DarkMageZ> apachelogger, are you aantipop on sourceforfe?
[10:49] <apachelogger> using 0. is really the last thing I'd do
[10:49] <apachelogger> nah, apachelogger ;-)
[10:50] <DarkMageZ> apachelogger, i have a thought. gimme a sec.
[11:34] <proppy> hi
[11:36] <proppy> regarding http://unittestcpp.aminche.com/UnitTest++/debian/control
[11:36] <proppy> are the two following line correct ?
[11:36] <proppy>  Conflicts: libunittest++-dev (< 1.3.0), libunittest++0 (< 1.3.0) Replaces: libunittest++-dev (< 1.3.0), libunittest++0 (< 1.3.0)
[11:37] <proppy> I want the new version of libunittest++-dev 1.3.0 to completly replace  previous version of libunittest++0 and libunittest++-dev
[11:39] <Fujitsu> proppy: Is it conflicting/replacing old versions of itself (ie. same package name), or am I missing something?
[11:39] <proppy> Fujitsu: yep
[11:39] <Fujitsu> proppy: That's useless.
[11:40] <proppy> Fujitsu: the previous source package provided binary + -dev
[11:40] <persia> proppy: There's no need to conflict/replace to itself.  dpkg assumes that anyway
[11:40] <proppy> Fujitsu: and the new one only -dev
[11:40] <Fujitsu> proppy: Er, what? Why is this -dev containing binaries?
[11:40] <Fujitsu> That sounds very very wrong.
[11:40] <proppy> Fujitsu: I want the binary removed if installing the new -dev package
[11:40] <persia> proppy: new non-dev should conflict/replace -dev.  -dev can be left alone.
[11:40] <proppy> Fujitsu: nop It doesnt 'contain binary
[11:40] <proppy> Fujitsu: only .a and .h like usual -dev package
[11:41] <proppy> Fujitsu: I removed the .so and binary support
[11:41] <Fujitsu> proppy: What's the -dev for compiling against now?
[11:41] <proppy> persia: I should provide an empty non -dev
[11:41] <proppy> Fujitsu: the new dev
[11:41] <persia> proppy: Now I'm confused.
[11:41] <proppy> persia: ok
[11:41] <proppy> persia: let me sum it up
[11:42] <proppy> unittest++ (<= 1.2.1) provided libunittest++0 and libunittest++-dev packages
[11:42] <proppy> and was autotools based with a patch I provided
[11:42] <proppy> the autotools support permitted to generate .a and .so file
[11:43] <proppy> thus I put the .a in the -dev and the .so in the non -dev
[11:43] <Fujitsu> Ew, non-lib* packages Providing libraries and their -dev?
[11:43] <proppy> Fujitsu: unittest++ is the name of the source package
[11:43] <Fujitsu> I don't see a unittest++ in the archive...
[11:43] <Fujitsu> Ohh.
[11:43] <Fujitsu> Right, that makes more sense.
[11:43] <Fujitsu> Provides as in builds, OK.
[11:44] <proppy> the new version unittest++ (1.3.0)
[11:44] <proppy> remove my autotools patch
[11:44] <proppy> and is based on the upstream provided Makefile
[11:44] <proppy> which do not generate .so anymore
[11:44] <persia> OK.  So there's no library to link against anymore?
[11:44] <proppy> thus I decided to drop libunittest++0 instead of providing an empty one
[11:45] <proppy> persia: yep no dynamic library, only a static one
[11:45] <Fujitsu> Oh dear dear dear.
[11:45] <persia> proppy: Right...  So what's the use case for the package?
[11:46] <proppy> persia: install the package
[11:46] <proppy> persia: create some code using the library and the .h
[11:47] <persia> OK.  Why do I want to do this?
[11:47] <proppy> persia: you can only build-depends of libunittest++-dev
[11:47] <Fujitsu> So we can have static-linking security fun!
[11:48] <proppy> persia: because you want to c++ test driven development
[11:48] <persia> proppy: So a developer will want to compile against the static unittest library, and ship the results?  Or is this only for provate testing, and wouldn't be used for release?
[11:48] <proppy> persia: that will not be used for release
[11:49] <proppy> persia: this will only run test by the make check rules
[11:49] <proppy> persia: before the packaging steps
[11:49] <proppy> persia: to assert that there is no regression in the code
[11:50] <persia> proppy: I'd suggest a unittest++ package that didn't provide either libunittest++-dev or libuntitest~~0, with the conflicts/replaces as you have them listed.  Also, you might want to see if you can put in a hook somewhere to make it extra clear that nothing compiled against the library should every be released.  Otherwise, it is as Fujitsu said: "static-linking security fun" (although this is not a definition of "fun" I typically use)
[11:51] <persia> proppy: If it runs during make check, doesn't it need to have had the binary to be checked compiled against the unit testing library?
[11:52] <proppy> persia: yep only your test code has to be compiled against it
[11:52] <persia> proppy: The test code needs to be compiled against it, but the binaries being tested don't?
[11:53] <proppy> persia: if you mean the shipped binary yes
[11:53] <proppy> persia: usually you test code link against the binary, and make some function call on it, and assert some result
[11:54] <persia> proppy: OK.  I write hello-test.cpp.  I then write hello.cpp to implement the spec.  I then compile & link to get hello-test and hello.  Is it true that hello-test is linked against unittest++, and hello is not?
[11:54] <proppy> persia: but you can also re-compile part of your code with the test code
[11:54] <proppy> yep
[11:54] <proppy> hello-test: is compiled using unittest++ hello.cpp and hello-test.cpp
[11:55] <proppy> hello: is compiled using hello.cpp
[11:55] <proppy> hello is released
[11:55] <proppy> hello-test is run with make check
[11:56] <persia> If that is the case, I'd use just unittest++, but given the risk that some developer might not follow the guidelines, or might ship the test binaries, a dynamic library seems safer (with libunittest++0 and libunittest++-dev)
[11:57] <proppy> persia: what about an empty libunittest++0 ?
[11:57] <Fujitsu> If it must be static, splitting it like that is probably inappropriate, especially considering its purpose.
[11:57] <persia> proppy: If it's not intended to provide a library against which clients are to be compiled, I think not using a lib* preface is better, and there's no need for multiple binary packages.
[11:58] <proppy> persia: what about if people have libunittest++0 and libunittest++-dev already installed
[11:58] <proppy> persia: they won't dist-upgrade to unittest++
[11:59] <proppy> persia: automagicaly
[11:59] <Fujitsu> In that case you have dummy upgrade packages.
[11:59] <persia> proppy: unittest++ should versioned conflict/replace libunittest++0 and libunittest++-dev, and provides both old binary names
[11:59] <Fujitsu> persia: That won't give it an upgrade path...
[11:59] <persia> Fujitsu: Does conflicts/provides not work?
[12:00] <proppy> persia: Conflicts/Provides/Replaces ?
[12:00] <Fujitsu> You'd need to have empty libunittest++{0,-dev} binaries depending on the unittest++.
[12:00] <persia> Right.  proppy: listed to Fujitsu about this :)
[12:00] <persia> s/ted/ten/
[12:00] <Fujitsu> It won't look through Provides to find a potential upgrade candidate.
[12:03] <proppy> I see
[12:03] <mohammad> Hello, is any motu online?
[12:03] <proppy> persia: Fujitsu: what about patching the Makefile, to provide a shared library ?
[12:04] <persia> mohammad: It's probably better to ask your question generally instead of trying to find a specific person.
[12:04] <mohammad> would you please merge http://packages.debian.org/lenny/liblucene2-java to Hardy?
[12:04] <mohammad> persia: ok
[12:05] <Fujitsu> !info liblucene2-java hardy
[12:05] <mohammad> I mean can anyone merge it please
[12:05] <Fujitsu> !info liblucene2-java sid
[12:05] <Fujitsu> Bah, no ubotu.
[12:06] <proppy> persia: Fujitsu: http://unittestcpp.aminche.com/UnitTest++/debian/control this seems correct ?
[12:06] <proppy> persia: Fujitsu: no Conflicts/Replaces/Provides but empty transition package
[12:06] <proppy> I should had the depends
[12:06] <Fujitsu> Ah, we don't have that package at all. mohammad: it will automatically appear in the next week or two.
[12:06] <persia> mohammad: It's scheduled to be synced in the next couple weeks, and doesn't need manual attention.  For the time being, we still have libdb4.3, so it's not so critical.
[12:07] <persia> Fujitsu: https://launchpad.net/ubuntu/+source/lucene2
[12:08] <Fujitsu> proppy: unittest++ should still conflict/replace older versions.
[12:08] <proppy> Fujitsu: ok
[12:08] <proppy> Fujitsu: Provides too ?
[12:08] <mohammad> if it is scheduled to be merged, then that's fine. Thank you, see you then.
[12:08] <persia> proppy: I'd mention that the dummy packages were dummy packages for upgrade purposes only.  Further, you need conflicts / replaces / provides.  lastly, it might be worth mentioning that unittest++ provides a static library.
[12:08]  * StevenK waves, from a little place called Boston.
[12:09] <persia> Hi StevenK.  How do you like the other side of the globe?
[12:09] <StevenK> persia: I dunno, I've not seen much of it yet. :-)
[12:09] <Fujitsu> Hi StevenK.
[12:10] <StevenK> persia: Didn't get to the hotel until 12:30am local time, thanks ever so, United.
[12:10] <proppy> persia: Description: unit testing framework for c++, static library and headers
[12:10] <proppy>  
[12:10] <persia> StevenK: Ah.  US Carriers.  Best to avoid :)
[12:10] <proppy> persia: Description: unit testing framework for c++, transition package
[12:11] <persia> proppy: That sounds more explicit.  It's just to make sure nobody tries to link against it and ship :)
[12:11] <StevenK> persia: Indeed. The international flight was great, but the domestic flight from San Francisco to Boston was delayed and dragged on for ever.
[12:11] <persia> StevenK: Did they feed you?  I heard that all US domestic flights were now fasting freindly (tm)
[12:12] <ajmitch> hi StevenK
[12:12] <StevenK> persia: The domestic flight didn't, no.
[12:12] <StevenK> Hey ajmitch
[12:12] <ajmitch> good to see you're there in 1 piece
[12:12]  * StevenK grins.
[12:12] <ajmitch> all your bags there as well? :)
[12:13] <StevenK> Yes, which is wonderful.
[12:13] <ajmitch> lucky
[12:14] <StevenK> I've not heard of anyone losing baggage yet, but I've only spoken to five people. :-)
[12:14] <proppy> persia: Fujitsu: thanks for all the hint
[12:14] <Fujitsu> Yay, they fixed the bugwatches.
[12:15] <proppy> persia: Fujitsu: I'm testing it right now
[12:15] <ajmitch> mithrandir didn't have his for a few days last time
[12:15] <ajmitch> mine was only delayed until the next morning, thankfully
[12:15] <StevenK> ajmitch: So it got to the hotel while you were sleeping
[12:15] <StevenK> ?
[12:16] <ajmitch> no, about lunchtime
[12:17] <persia> Fujitsu: What was wrong with bugwatches?
[12:18] <Fujitsu> persia: They broke and went to Unknown with 1.1.10.
[12:19] <persia> Fujitsu: Ah.  I thought the ones I saw were just unknown.  Thanks for the hint: I'll have to look again :)
[12:22] <Fujitsu> persia: You shouldn't trust much for a couple of days after a release.
[12:40] <StevenHarperUK> Hi, I am looking for MOT's to review my package on REVU : I currently have 0 avocations: http://revu.tauware.de/details.py?upid=437
[12:49] <StevenHarperUK> Hi does anyone know how much of a backlog the PPA build server has, is there a page on Launchpad that shows you he backlog of packages to be built?
[12:50] <Hobbsee> it'll be similar to
[12:50] <Hobbsee> https://edge.launchpad.net/ubuntu/+builds
[12:52] <StevenHarperUK> Hobbsee: is there a overall Queue, showing all the packages that are queued ?
[12:52] <Hobbsee> StevenHarperUK: yes, somewhere.
[12:52] <Hobbsee> someone's probably uploaded another version of openoffice, which takes 6+ hours for a successful build.
[12:53] <StevenHarperUK> I uploaded packages about 22hours ao,  they havent been done yet
[12:54] <Hobbsee> [21:52] <Hobbsee> someone's probably uploaded another version of openoffice, which takes 6+ hours for a successful build.
[12:54] <dalinian> Don't shoot, but where could an ubuntu-phyte get help with a problem?
[12:55] <persia> dalinian: Depends on the problem.  If it's a local system issue, #ubutu or #ubuntu-locale, if it's a problem with reproducing a bug or working with bugs, #ubuntu-bugs.  If it's a question about packaging, this is the place.
[12:55] <Hobbsee> StevenHarperUK: https://edge.launchpad.net/+builds suggests that they're doing a whole bunch of langpacks
[12:56]  * Hobbsee can't find the build queue for ppas
[12:57] <dalinian> Well, I seem to have a sound bug that may be related to an alsa package that will not install?
[12:57] <Hobbsee> dalinian: likely #ubuntu
[12:57] <dalinian> ty
[13:07] <albert23> Hello all. I found a patch to solve bug 138728. Would that be a candidate for SRU in Gutsy? It' s a patch to gst-plugins-bad-multiverse.
[13:09] <Fujitsu> bug #138728
[13:09] <albert23> https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/138728
[13:09] <Ubotwo> Launchpad bug 138728 in rhythmbox "m4a files playback choppy with crossfading on" [Undecided,Confirmed]
[13:10] <minghua> albert23: The procedure for proposing an SRU is at https://wiki.ubuntu.com/StableReleaseUpdates
[13:10] <persia> albert23: probably not.  See https://wiki.ubuntu.com/StableReleaseUpdates.  It doesn't seem to be any of a security vulnerability, a possible cause of data loss, or a severe regression (although the my definition of severe is not authoritative)
[13:10] <minghua> Good morning Fujitsu.
[13:10] <minghua> and persia :-)
[13:10] <persia> good evening minghua
[13:11] <minghua> albert23: First it probably helps to assign that bug to the correct package...
[13:12] <albert23> So the same requirements for SRU in main also apply to multiverse?
[13:13] <Hobbsee> albert23: see the bottom half of that page.
[13:13] <Hobbsee> but yes, effectively.
[13:14] <Fujitsu> Hi minghua.
[13:20] <proppy> hi
[13:22] <proppy> persia: Fujitsu: I tried the packaging scheme you've suggested to me
[13:22] <proppy> repo here http://farmpoker3d.pokersource.info/packaging-farm/unittest++/gnulinux/debian/gutsy/src/
[13:23] <proppy> I get the following error
[13:23] <proppy>   libunittest++-dev: Depends: unittest++ but it is not going to be installed
[13:23] <proppy> E: Broken packages
[13:23] <persia> proppy: Does it achieve the results you sought?
[13:23] <proppy> when running sudo apt-get install libunittest++-dev
[13:23] <proppy> but apt-get install unittest++ seems to go fine
[13:24] <Hobbsee> sounds like ti's apt being stupid again.
[13:24] <proppy> I wonder if this is due to libunittest++-dev depending of a package that conflicting with it
[13:24] <persia> proppy: You need versioned conflicts / replaces
[13:24] <Fujitsu> proppy: Hence the versioned conflicts..
[13:25] <proppy> persia: <= versionned ?
[13:25] <proppy> (< 1.3.0) versionned should go fine ?
[13:26] <proppy> let me try this thanks a lot
[13:26] <persia> proppy: Also, after a little thought, you probably don't want to Provide libunittest++0, just in case any clients are linked against the old dynamic library.
[13:26] <persia> (only provide -dev)
[13:26] <proppy> persia: you're right
[13:27] <proppy> I was wondering what about people which are still linked against the static library
[13:27] <proppy> persia: but I should still conflicts/replace it ?
[13:27] <persia> proppy: Yes.
[13:29] <proppy> persia: I should keep libunittest++0 transition package as well
[13:29] <proppy> persia: for people to update
[13:29] <persia> proppy: Yes.
[13:30]  * persia gives proppy a certificate of correct intuition
[13:30] <proppy> :)
[13:30] <proppy> persia: I remembered lintian was not very happy with versionned conflict
[13:30] <proppy> obsolete-relation-form
[13:31] <proppy> found the fix
[13:31] <proppy> http://lintian.debian.org/reports/Tobsolete-relation-form.html
[13:31] <proppy> policy 7.1
[13:32] <proppy> s/</<<
[13:33] <minghua> Wow.  I never knew < means <=.
[13:33] <minghua> I knew to avoid using them, though.
[13:33] <persia> minghua: That's why it's deprecated :)
[13:45] <proppy> persia: Fujitsu: it works :)
[13:45] <proppy> proppy@nekun:~/Desktop/20071027/unittest++$ dpkg -l | grep unittest++
[13:45] <proppy> ii  libunittest++-dev                          1.3.0-1                                 unit testing framework for c++, transition p
[13:45] <proppy> ii  libunittest++0                             1.3.0-1                                 unit testing framework for c++, transition p
[13:45] <proppy> ii  unittest++                                 1.3.0-1                                 unit testing framework for c++, static libra
[13:45] <proppy> Thanks a lot
[13:46] <Fujitsu> Very good!
[13:55] <hellboy195> hey guys. is that true that gimp 2.4 final only comes with gutsy-backports?
[13:56] <Fujitsu> hellboy195: If it's there at all, yes.
[13:58] <hellboy195> Fujitsu: well it isn't in backports yet so I'm asking
[14:00] <Hobbsee> i think they were thinking of pushing it to updates, but were undecide
[14:00] <Hobbsee> d
[14:03] <hellboy195> Hobbsee: well I hope so because the difference between the latest RC and the final isn't very big and it looks better if you have the final ;)
[14:10]  * proppy hugs Fujitsu and persia
[14:30] <ScottK> Hobbsee: Pong
[14:30] <Hobbsee> ScottK: written that email yet?
[14:31]  * persia is filled with sudden and pungent curiosity
[14:32] <zul> hello
[14:32] <TheMuso> 'lo Hobbsee, ScottK. From overcasgt Bosto.
[14:32] <TheMuso> overcast Boston even.
[14:32] <persia> Hey TheMuso.
[14:33] <TheMuso> Hey persia.
[14:33] <Fujitsu> Hi TheMuso, ScottK.
[14:33]  * TheMuso is glad he has two days to recover for the summit.
[14:33] <Hobbsee> hiya TheMuso :)
[14:35] <ScottK> Hello The
[14:35] <ScottK>  and Fujitsu
[14:35] <ScottK> Hobbsee: No
[14:35] <Hobbsee> ScottK: please get to it
[14:36]  * Fujitsu is also rather curious.
[14:36] <ScottK> Doing mail --> TODO soonish
[14:36] <coNP[uni]> Hey Hobbsee, persia, ScottK, TheMuso, zul
[14:36] <coNP[uni]> And others as well
[14:36] <coNP[uni]> :)
[14:37] <ScottK> StevenK: Which domestic airline was it?
[14:39] <Hobbsee> ScottK: also read -devel - but remove any sharp objects.
[14:40] <ScottK> Hobbsee: Which?
[14:40]  * ScottK just woke up and is moving slowly
[14:40] <persia> either?
[14:40] <Hobbsee> ScottK: #ubuntu-devle, sorry
[14:40] <ScottK> Ah.
[14:41] <Hobbsee> last half hour should be enough
[14:41] <Hobbsee> ScottK: and you can add that into your mail, and your stuff to the CC.
[14:41] <ajmitch> ah, fun
[14:41] <ScottK> Well I'm going to be assembling evidence for a while.  There's a lot.
[14:41] <zul> ajmitch: should you be like sleeping
[14:42] <Hobbsee> ScottK: indeed.  but i think this section should be the clincher :)
[14:42]  * ScottK is still reading.
[14:42] <ajmitch> zul: yes
[14:43] <Hobbsee> OH YOU'RE FSCKING JOKING!!!!
[14:44] <zul> O-?/LP;U8IJ76YYUU767YYYYYYYYYYYYYYYYYYYYY
[14:44]  * Fujitsu is confused.
[14:45] <zul> sorry
[14:45] <crimsun_> that last string of "Y"s could be an angry admin responding to rpm -U
[14:45] <Fujitsu> Hah.
[14:45] <zul> liam
[14:45] <Fujitsu> Hobbsee: What about?
[14:46] <Fujitsu> 23:43:08?
[14:46] <zul> sorry liam is at the stage where he has to mash keyboard
[14:47] <Fujitsu> zul: Ah, fun.
[14:47] <Hobbsee> Fujitsu: -devel
[14:47] <Hobbsee> Fujitsu: just read it.  remove all sharp objects first
[14:48] <Fujitsu> Hobbsee: I've been following since the start.
[14:48] <nenolod> sharp objects?!$%
[14:48] <nenolod> sounds fun
[15:04] <StevenK> ScottK: United.
[15:05] <ScottK> StevenK: Ah.  They are on my "will not fly on" list.  Every time I think maybe they've reformed and I'll try them again, I regret it.
[15:05] <StevenK> ScottK: Internationally, they are okay. Aside from the food.
[15:07] <elkbuntu> StevenK, i dunno, they were pretty crap last year...
[15:09] <StevenK> elkbuntu: The international flight was okay. The domestic flight was *crap*
[15:09] <elkbuntu> they have no concept of leg room. im short as, and even i felt cramped...
[15:10] <elkbuntu> lifeless got told off for trying to go to the loo at one point too, iirc
[15:10] <elkbuntu> (in a completely legit situation)
[15:11] <lifeless> elkbuntu: ?!
[15:11] <StevenK> elkbuntu: So guess how I felt...
[15:11] <lifeless> elkbuntu: oh yes, I remember. the United fligt was crap.
[15:11] <elkbuntu> lifeless, the united flight from sydney...
[15:11] <elkbuntu> the food at least ranked better than your 'chicken' at syd airport... but only just
[15:12] <StevenK> I had Subway before boarding, that was nice.
[15:13] <elkbuntu> we were not so wise
[15:13]  * StevenK chuckles
[15:18] <jsgotangco> fly singapore air with the huge 500-seater airbus!
[15:18] <zul> if you can afford it
[15:18] <jsgotangco> :D
[15:20] <nenolod> airbus planes scare me
[15:21] <nenolod> when they take off they sound like they're about to rip apart
[15:21] <nenolod> when they get airbourne they're ok though
[15:25] <elkbuntu> jsgotangco, yeah, and have an actual bed! :D
[16:38] <Rospo_Zoppo> Hobbsee: ping
[16:39] <Hobbsee> You sent me a contentless ping.  This is a contentless pong.  Please provide a bit of information about what you want and I will respond when I am around.
[16:39]  * persia grumbles that releasing is supposed to make my system more stable, not make it crash regularly.
[16:40] <Hobbsee> Rospo_Zoppo: what's up?
[16:40] <Rospo_Zoppo> Hobbsee: I'm working at merging vertex, I've seen that you merged it some time ago.
[16:41] <Rospo_Zoppo> Hobbsee: there is something I don't understand with build-depends
[16:41] <Rospo_Zoppo> Hobbsee: I mean, there were some changes to it, now I think that they're not necessary but I'm not sure about that
[16:42] <RainCT> what do you think about this for ubuntu-dev-tools? http://paste.ubuntu-nl.org/42366/
[16:42]  * Hobbsee looks
[16:42] <Rospo_Zoppo> thanks
[16:42] <TheMuso> persia: lol
[16:43] <persia> RainCT: Could you make it not require pbuilder?
[16:43] <Rospo_Zoppo> Hobbsee: I opened a bug (156732)
[16:43] <rexbron> persia: Quick question, I am looking at trying to get a package from debian-multimedia into univerese, does debian/changelog need to be updated (ie changing of release)?
[16:44] <persia> TheMuso: Actually, when Edgy was released, my system didn't get unstable (unlike all the others).  Of course, it was are least stable release from a regular perspective.  I think I have the $breaks_stuff switch set wrong - about three weeks before UVF is always most reliable.
[16:44] <RainCT> persia: could be done, but then either a copy of /usr/lib/pbuilder/pbuilder-satisfydepends would be needed, or the same must be rewroten there
[16:44] <persia> rexbron: Which package.
[16:44] <Hobbsee> Rospo_Zoppo: oh, the mesa stuff?
[16:44] <TheMuso> persia: right
[16:44] <Rospo_Zoppo> Hobbsee: yep
[16:44] <persia> RainCT: Hrm.  I wonder about abstracting it out.  I don't use pbuilder.
[16:45] <Rospo_Zoppo> Hobbsee: I don't know very well how to deal with that stuff, you can see it in the bug report :)
[16:45] <Hobbsee> Rospo_Zoppo: i dont think most people do :)
[16:45]  * Hobbsee has a further look
[16:45] <rexbron> persia: OpenLibraries
[16:45]  * rexbron hopes to follow that up with Jahshaka
[16:45] <Rospo_Zoppo> Hobbsee: :)
[16:45] <Hobbsee> tepsipakki: ping?
[16:46] <Hobbsee> tepsipakki: un-ping
[16:46] <persia> rexbron: http://sourceforge.net/projects/openlibraries?
[16:46]  * RainCT is checking pbuilder-satisfydepends
[16:46] <Hobbsee> Rospo_Zoppo: if you do an apt-cache show libglu1-xorg-dev, you'll see it says it's a transitional package
[16:46] <Hobbsee> Rospo_Zoppo: basically, the transitional packages get removed once everything is updated to non-transitional packages
[16:47] <Rospo_Zoppo> i see
[16:47] <Hobbsee> Rospo_Zoppo: if you apt-cache show the other, you'll see it's *not* a transitional package
[16:47]  * persia thinks the mesa transition is still underway in Debian...
[16:47] <Hobbsee> persia: looks like it.  i'd hoped they'd have finished, by now
[16:47] <Rospo_Zoppo> Hobbsee: so the changes are needed ?
[16:47] <Hobbsee> Rospo_Zoppo: basically, keep merging that stuff in - we dont want to dep/build-dep on transitional packages.
[16:47] <Hobbsee> Rospo_Zoppo: yup
[16:47] <persia> Hobbsee: Yeah.  I was surprised as well.
[16:48] <Hobbsee> Rospo_Zoppo: as for how they tell which ones they're making transitional, and which they're changing to, and how to do the dep changes - that's for the X guys :)
[16:48] <Hobbsee> Rospo_Zoppo: and i dont think you need to know it for merging
[16:48] <Hobbsee> Rospo_Zoppo: the same thing seems to happen for all of the X transition - but if you look at the descriptions of the deps, it should all be fairly obvious.
[16:48] <geser> Hobbsee: transitions take a long time in Debian, it's not like in Ubuntu where you do a mass-upload and be done with it
[16:48] <rexbron> persia: Yes
[16:49] <Hobbsee> geser: true.  but over a year?
[16:49] <Rospo_Zoppo> Hobbsee: thanks :)
[16:49] <geser> Hobbsee: do you know how long the /usr/doc -> /usr/share/doc transition took?
[16:49] <persia> rexbron: Whilst I'm downloading, Thank you for working to integrate third-party repositories with Ubuntu, and please feel free to ask questions generally in the channel, rather than waiting until I am around.
[16:49] <Hobbsee> geser: no idea :)
[16:49] <persia> geser: Didn't that start in potato?
[16:50] <Hobbsee> Rospo_Zoppo: you're welcome
[16:50] <rexbron> persia: sure
[16:50] <Hobbsee> persia: btw, rexbron's good.  you want to sponsor his uploads :)
[16:50] <rexbron> Hobbsee: That's high praise :). Thanks!
[16:50] <Hobbsee> rexbron: :)
[16:51] <persia> Hobbsee: Yeah - I should sponsor some things.  For now, I'm just blathering, although I'll agree with the sentiment :)
[16:51] <Hobbsee> persia: hehe :)
[16:55] <geser> Hobbsee: I don't have a reference right now but afaik it took over a debian release (or even two releases)
[16:55] <Hobbsee> geser: ouchy
[16:56] <persia> geser: Ummm..  There are still open /usr/doc -> /usr/share/doc bugs.  All RC now, but not all closed.
[16:57] <RainCT> persia: that pbuilder thing is a mess lol
[16:59] <persia> RainCT: That's one reason I don't use it :)  Perhaps one could write a script that depended on apt internals or debuild internals to grab the right stuff, rather than trying to calculate it directly.
[16:59] <Hobbsee> which pbuilder thing?
[17:00] <RainCT> persia: well, actually it would be enought to just get the build dependencies out of the debian/control file, passing them to apt-get would do it then
[17:00] <persia> Hobbsee: pbuilder-satisfydepends.  It works, but...
[17:01] <persia> RainCT: That and trying to fix all the bugs for the corner cases is how pbuilder-satisfydepends was made.  I think it's better to either leverage known good internals, or just work with pbuilder-satisfydepends, rather than reimplementing something that already exists three different ways.
[17:01] <Hobbsee> persia: ahh
[17:02] <RainCT> persia: yeh, that's why I'm using pbuilder-satisfydepends :P
[17:03] <persia> RainCT: Hmm...  I'm looking at something else right now, but I think leveraging the system used by debuild might be better.  It's the algorithm used by the buildds, and it's guaranteed installed on all developer systems.
[17:07] <persia> rexbron: The changelog doesn't need an update because it comes from a foreign location: imports can be processed (although it is a little harder for source != Debian).  However, the changelog will need an update because: 1) The package doesn't build for hardy, 2) Ubuntu OpenAL actually works on other architectures, 3) The package isn't lintian or linda clean.
[17:10] <persia> Could someone please give me a close brace to match { ?
[17:11] <TheMuso> persia: ?
[17:12] <RainCT> persia:  }
[17:12] <RainCT> broken keyboard?
[17:13] <persia> TheMuso: My keyboard mapping has been broken since Breezy, and I've not found out where.  I'm missing close bracket, and close brace in X.  close bracket appears here a lot, but close brace is trickier.
[17:13] <persia> RainCT: Thanks.
[17:13] <Hobbsee> how weird!
[17:14] <RainCT> I had problems with < and > with Dapper, there's some config file in ~/ I think where it can be fixed
[17:14] <persia> Hobbsee: Yes.  It's something related to jp106 keyboards, as the mapping was also broken on a fresh Feisty install I did for someone else.  The key doesn't get used much by non-programmers, so it's not that bad, but annoying.
[17:14] <Hobbsee> persia: ahh
[17:15] <TheMuso> persia: ah.
[17:15] <persia> RainCT: I'm sure.  I'm further sure that it needs either a poke to xkbd or the GNOME keyboard mapper, but haven't gotten around to it (and am not a fan of local fixes)
[17:20] <persia> RainCT: `aptitude install $(dpkg-checkbuilddeps 2>&1 | awk -F: '{ print $3 }')` could benefit from a bit further cleanup, but does almost the right thing.  It doesn't handle build conflicts, and should really use cut instead of awk, but it's certainly smaller than pbuilder-satisfydepends.
[17:21] <RainCT> persia: was looking at that, but there's still one problem..  ex. libopenal-dev (>= 0.2005080600-1) libalut-dev libglpng-dev
[17:22] <persia> RainCT: `... | s/([^]*)//g | ...`
[17:24] <RainCT> persia: where would this go?
[17:24] <persia> Then, call dpkg-checkbuilddeps again to see if it succeeds.  Alternately, pull those from the dpkg-checkbuilddeps output with a regex, and use grep-dctrl to check if there is a sufficient version in the cache.  I suspect that if you look at the source of dpkg-checkbuilddeps you'll find a shortcut.
[17:25] <persia> RainCT: i.e. aptitude install $(dpkg-checkbuilddeps 2>&1 | awk -F: '{ print $3 }' | s/([^]*)//g )`
[17:26] <persia> Ummm.... `aptitude install $(dpkg-checkbuilddeps 2>&1 | awk -F: '{ print $3 }' | sed s/([^]*)//g )`.  Someone perly could probably give you a nice one-liner that did both at once.
[17:33] <RainCT> persia: uh.. that's doing something strange.   build dependencies are «libopenal-dev (>= 0.2005080600-1) libalut-dev libglpng-dev», but it tries to install «festival festlex-cmu festlex-poslex festvox-kallpc16k gsfonts-x11 libestools1.2»
[17:34] <persia> RainCT: Which package are you using as a base.  I'll try to mirror.
[17:35] <RainCT> persia: chromium
[17:35] <persia> mmmm..  chromium....
[17:35] <RainCT> it's the first relatively small package I thought of :P
[17:36] <persia> Relatively small?  Are you planning a merge?
[17:40] <RainCT> ?
[17:40] <RainCT> persia: do you mean to test that     aptitude install $(dpkg-checkbuilddeps 2>&1 | awk -F: '{ print $3 }' | s/([^]*)//g )`     or have I missed something?
[17:41] <persia> "Relatively small?" => I would call it moderate to large.  "Are you planning a merge" => You and I share the last meaningful changelog entry.  If you are working on it, I'll wait.  If you're not, I'll push & sync.
[17:43] <RainCT> no, I just got it to test this
[17:44] <persia> RainCT: $(dpkg-checkbuilddeps 2>&1 | awk -F: '{ print $3 }' | sed 's/([^)]*)//g' | sed 's/|\s[^\s]*//g) generates the right string for me.  Testing an install.
[17:46] <RainCT> have you copied the complete command? it says to me that it's incomplete
[17:46] <persia> RainCT: That worked.  92 packages installed, and dpkg-checkbuilddeps is satisfied on completion.  There are better ways to handle version checking and alternates: the apt source is your best guide.  I suspect it's exposed, but would need to investigate in more depth.
[17:47] <persia> `sudo aptitude install $(dpkg-checkbuilddeps 2>&1 | awk -F: '{ print $3 }' | sed 's/([^)]*)//g' | sed 's/|\s[^\s]*//g')`
[17:48] <RainCT> ah. for what are the ``'s?
[17:50] <persia> RainCT: Surrounding the entire string?  Just quotes in a style that matches a shell request to execute the entire bit.
[17:53] <RainCT> ah, it doesn't work for me with the `, they are hiding the output but aptitude asks for confirmation before installing. without them it works fine.       (btw, on your previous msg at 18:44:10 there was a ' missing, that's why it said it's incomplete :P)
[17:54] <persia> RainCT: Ah.  Yes.  You should only feed the shell the ` marks if you plan to do something with the output.  My apologies for the confusion.
[17:55] <RainCT> persia: ah ok.    Thanks :D
[17:55] <persia> RainCT: Ah.  Yes.  The final '.  Sorry about that.
[17:56] <persia> RainCT: You'll still want to look at the dpkg-checkbuilddeps source, and maybe apt.  I suspect there's a way to feed apt a string, and get a useful response directly, rather than playing with awk and sed.  This would then do the right thing with regard to alternatives and version checking.
[18:32] <StevenHarperUK_> Hi: I am looking for MOTU's to review my package on REVU - I have 0 advocation's so far : http://revu.tauware.de/details.py?upid=437
[19:01] <bddebian> Heya gang
[19:01] <lamego> hi
[19:02] <bddebian> Hello lamego
[19:05] <geser> Hi bddebian
[19:05] <bddebian> Heya geser
[19:14] <jdong> bug 1
[19:14] <jdong> aww
[19:16] <apachelogger> sacater: ping
[19:34] <rexbron> I have a python  extention for python2.4 that depends on libboost-python (which depends on python2.5) and afaik is compiled against python2.4. I get this error when I try and import the module in python2.4:
[19:34] <rexbron> python2.4: symbol lookup error: /usr/lib/libboost_python-gcc41-1_34_1.so.1.34.1: undefined symbol: Py_InitModule4_64
[19:35] <rexbron> From doing some quick googleing, that symbol was changed in 2.5. Is this error due to libboost-python being compiled against 2.5 or something else entirely?
[19:38] <rexbron> Looking through the build log, the module is compiling against python2.4
[19:39] <geser> rexbron: doesn't your extension work with python 2.5 as python2.5 is currently the default on Ubuntu
[19:40] <rexbron> geser: The ./configure script has an explicit dependancy on python2.4
[19:40] <rexbron> and all the includes are python2.4 when compiling
[19:42] <rexbron> geser: I could attempt to patch the source and change the configure script to look for python2.5 and compile against it, but as I have not written the code, I have no idea if it depends on some python2.4 features not present in 2.5
[19:44] <sacater> apachelogger: ping
[19:44] <sacater> apachelogger: sorry irssi doesnt have alerts
[19:50] <imbrandon> sure it does, you just have to turn them on and configure them ;)
[19:52] <imbrandon> can even make it beep or use libnotify local through screen+irssi
[19:57]  * rexbron is in python hell
[19:57] <rexbron> damn version mismatches
[19:59]  * ScottK suggests you point your agnst at whoever hard coded your extension for 2.4
[20:00] <apachelogger> sacater: any specific reason why ye wanna join the amarok wolf brigade on launchpad?
[20:01] <rexbron> ScottK: Hmm, appropreate, what a novel idea
[20:05] <imbrandon> wow, that couldent have went more smoothly, i upgraded a box just now from breezy -> dapper -> edgy -> Feisty , then gutsy
[20:05] <TheMuso> ScottK: Sorry to see you have to pull back for Hardy, but I do understand why you have chosen to do so.
[20:05] <imbrandon> no hickups at all, /me is suprised
[20:05] <TheMuso> s/have to/choose to/.
[20:06] <ScottK> TheMuso: Thanks.  I hope it's a one cycle thing.
[20:06] <TheMuso> ScottK: Likewise. You are a wonderful, and valuable contributor, and it would be a shame to loose you.
[20:06] <ScottK> Thanks again.
[20:07] <sacater> apachelogger: cos i love using amarok, and if find any bugs i will immeidiatly report them
[20:07] <ScottK> TheMuso: You're at UDS, right?
[20:08] <TheMuso> ScottK: yes I am.
[20:08] <apachelogger> sacater: well, the groups is more about actually getting the bugs sorted as fast as possible... still, if you think it makes sense to be a member ;-)
[20:08] <sacater> :)
[20:08] <TheMuso> Fosscamp is today, but I'm not attending. I'm just in my room with joejaxx, who is rooming with me.
[20:08] <sacater> go for it :)
[20:08] <ScottK> TheMuso: Great.  I'm taking an overnight train and will be there tomorrow.
[20:08] <TheMuso> ScottK: Sweet. For how long?
[20:09] <TheMuso> dholbach and I were actually talking earlier today about possibly having a Fosscamp MOTu session, if one hasn't already been held.
[20:09] <ScottK> TheMuso: I'll leave very early Wed.
[20:09] <TheMuso> it would be great if you were here for that, whever it turns out to be.
[20:09] <ScottK> Well Sun/Mon/Tues I'll be there.
[20:09] <TheMuso> Great.
[20:09] <TheMuso> There will be something at UDS likely enough, but I was just thinking of an informal chat.
[20:12] <ScottK> OK.
[20:16]  * pwnguin hopes the scottK email wasnt about him
[20:17] <ScottK> pwnguin: No.
[20:17] <ScottK> No rworries.
[20:17] <ScottK> worries even
[20:18] <sacater> apachelogger: :)
[20:18] <sacater> apachelogger: got the email
[20:19] <pwnguin> ScottK: well, i think theres nothing wrong with having written guidelines ala debian-policy, though for the moment i do agree that MOTU should be informed and intelligent
[20:20] <ScottK> pwnguin: Agreed.  Better documentation is a good thing, but lack of it isn't an excuse for doing obvious things.
[20:20] <ScottK> Gotta run.
[20:21] <pwnguin> debian policy is pretty big
[20:21] <stani> ignore what I will say (working on the abbreviations wiki page)
[20:21] <stani> !SRU
[20:22] <Ubotwo> Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
[20:32] <geser> ScottK: as I got burned myself with gnumed-client, what's your opinion on https://bugs.edge.launchpad.net/ubuntu/+source/gnumed-client/+bug/154136/comments/5 ?
[20:32] <Ubotwo> Launchpad bug 154136 in gnumed-client "gnumed - "new upstream available" - 0.2.7.1" [Low,In progress]
[20:32] <StevenHarperUK_> Hi I am looking for MOTU's to review my Package (easycrypt) on REVU : I currently have 0 Advocation's: http://revu.tauware.de/details.py?upid=437
[20:33] <stani> !DaD
[20:33] <Ubotwo> Factoid dad not found
[20:33] <stani> !DAD
[20:33] <geser> StevenHarperUK_: what about the warning for the menu file?
[20:34] <StevenHarperUK_> geser: thats a pointless warning, the new Debian Menu structure spec allows that entry, the test are no longer valid
[20:37] <geser> StevenHarperUK_: isn't http://www.debian.org/doc/packaging-manuals/menu-policy/ch2.html the current list for the sections anymore?
[20:39] <StevenHarperUK_> A MOTU gave me another link the other day
[20:39] <geser> http://www.debian.org/doc/packaging-manuals/menu.html/ch3.html#s3.2 that one?
[20:40] <StevenHarperUK_> geser: yes
[20:40] <StevenHarperUK_> geser: which is right
[20:40] <geser> is also contains a menu structure but is it also contains "The authoritative list of Debian's menu structure is maintained in the Debian Menu sub-policy document which is part of the Debian Policy package." and "The menu structure below is included only for convenience and is not authoritative."
[20:40] <geser> any DD around who knows which document is right about the menu structure?
[20:41] <StevenHarperUK_> I keep finding these conflicting docs :P
[20:41] <StevenHarperUK_> My current choice is : section="Applications/File Management"
[20:42] <StevenHarperUK_> And that appears in Accessories in my 7.10 install
[20:42] <StevenHarperUK_> so it does work
[20:42] <StevenHarperUK_> and I think meets the new (coming) spec
[20:43] <geser> StevenHarperUK_: have you also a reference for that hotkey entry in your menu file? I can't find in it mentioned in that page and linda misparses it.
[20:43] <StevenHarperUK_> Right Ill remove it
[20:45] <geser> StevenHarperUK_: does your app appear in the menu because of the menu file (Ubuntu doesn't use it by default) or because of your .desktop file?
[20:47] <StevenHarperUK_> geser : I don't know
[20:48] <rexbron> geser: Compiling against 2.5 seems to cause no issues
[20:49] <StevenHarperUK_> geser: I have removed that hotkey and im resubmitting now
[20:49] <joejaxx> anyone know the colour legend for merges.ubuntu.com/universe.html/
[20:49] <joejaxx> ?
[20:49] <StevenHarperUK_> geser: is that ok?
[20:50] <jdong> is there a way to scrape source packages from Launchpad without resorting to link-scraping?
[20:50] <jdong> (like an API of some sort?)
[20:51] <geser> joejaxx: it's the Priority: field from debian/control
[20:51] <jdong> grr never mind, I'll just continue to do it the old fashioned way
[20:51] <geser> StevenHarperUK_: yes
[20:52] <StevenHarperUK_> geser: ok ill stick the comment on it too
[20:55] <bddebian> Grr, why doesn't library packaging suck so much? :-(
[20:55] <joejaxx> ksdjflkslkdfslkdjflksdfsdflkslfkjw/in 315
[20:55] <joejaxx> gah
[20:56] <TheMuso> bddebian: Doesn't?
[20:56] <joejaxx> blasted ssh lag
[20:56] <bddebian> Erm s/doesn't/does/
[20:57] <TheMuso> bddebian: Thought as much. :p
[20:57] <StevenK> joejaxx: Where are you hiding?
[20:58] <joejaxx> StevenK: i am hiding? lol
[20:58] <StevenK> joejaxx: And you can't complain about ssh lag if you're not ssh'ing to Australia.
[20:58] <joejaxx> StevenK: :P
[20:59] <bddebian> dh_makeshlibs is supposed to create the shlib file right?
[20:59] <StevenK> .shlibs, yes
[21:02] <StevenHarperUK_> geser: its there
[21:02] <StevenHarperUK_> geser: I have added comment on what I did
[21:09] <geser> StevenHarperUK_: just curious: as easy crypt is a gui for truecrypt does it work without it?
[21:10] <geser> StevenHarperUK_: just minor (no need to do a extra upload for it): install only *.py files (no *.pyo or *.pyc). Your easycrypt.install has "*.py* usr/share/easycrypt
[21:11] <geser> " but as you only have *.py files that just minor
[21:13] <geser> StevenHarperUK_: besides this looks ok, I'll do a final review later and advocate it if I don't find any new issues
[21:13] <bddebian> StevenK: OK, it's creating <package>/DEBIAN/ files as it should but it doesn't seem to be doing anything with them??
[21:14] <StevenK> So what should it be doing?
[21:15] <bddebian> Dunno but I keep getting a linda warning that the package is not in an shlibs file
[21:21] <bddebian> Gah, why is this so freakin difficult? :-(
[21:22] <StevenK> bddebian: Does dpkg -I mention it?
[21:22] <ajmitch> good morning
[21:23] <lamego> good night :P
[21:23] <StevenK> Morning
[21:23] <bddebian> Heya ajmitch
[21:23] <bddebian> StevenK: The shlib file you mean?
[21:23] <TheMuso> Hey ajmitch
[21:24] <StevenK> bddebian: Yes
[21:24] <bddebian> Yes it's there
[21:25] <bddebian> Would the source package name cause an issue?
[21:25] <bddebian> For this the source package name was just libwfut while the binary is libwtfu-0.1-0
[21:25] <erable> Hi.
[21:26] <StevenK> bddebian: I don't think so.
[21:26] <erable> I'm looking for someone to review packages on REVU (qdevelop, qextserialport and qtsmbstatus). Thanks.
[21:27]  * ajmitch wants a libstfu
[21:35] <bddebian> ajmitch: For me? :-)
[21:51] <bddebian> aaaaaaaaaahhhhhhhhhhhhh I give up
[21:54] <TheMuso> bddebian: What package?
[21:54] <bddebian> libwfut.  It's in the games svn, not in Debian yet
[21:54] <TheMuso> ca
[21:54] <TheMuso> ah
[21:55] <bddebian> This is the warning:
[21:55] <bddebian> W: libwfut-0.1-0; The library libwfut is not in a shlibs file.
[21:56] <TheMuso> bddebian: Does the package contain a shlibs file/
[21:57] <bddebian> afaict, yes.  It uses dh_mkshlibs to create it and as StevenK pointed out, dpkg -I shows it
[21:58] <rexbron> perhaps I am just daft, but could some one point me to documentation on how to update a source package from a svn checkout?
[21:58] <TheMuso> right
[21:58] <TheMuso> bddebian: Did you use -i with lintian to get a better explanation?
[21:59] <bddebian> lintian doesn't give that error but yes, I did with linda and it didn't help much
[21:59] <bddebian>  The library shown above is not listed in a shlibs file. This means
[21:59] <bddebian>  that packages that depend on this one won't get ${shlibs:Depends}
[21:59] <bddebian>  correctly.
[22:03] <geser> bddebian: does dpkg-deb -I shlibs give back useful output for it?
[22:03] <geser> can you put the deb on some webspace?
[22:04] <bddebian> libwfut-0.1 0 libwfut-0.1-0 (>=0.1.0-0), libwfut-0.1-0 (<<0.1.0-99)
[22:05] <geser> bddebian: that's the only lib inside this deb?
[22:06] <bddebian> Yep
[22:06] <RainCT> Can someone please merge ~rainct/ubuntu-dev-tools/dev into ~ubuntu-dev/ubuntu-dev-tools/trunk?
[22:06] <TheMuso> RainCT: If bandwidth here at UDS wasn't so bad, I'd do it in a hearbeat. :p
[22:07] <TheMuso> heartbeat even
[22:07] <hellboy195> good night guys :)
[22:07] <geser> bddebian: this looks ok, I'd probably ignore that error then
[22:07] <RainCT> TheMuso: :)
[22:08] <bddebian> OK..
[22:10] <RainCT> bddebian: is «balsa» free (the merge) or are you working on it?
[22:11] <bddebian> RainCT: Go for it
[22:12] <RainCT> ok :)
[22:13] <RainCT> btw, does anyone know what the status about adding grab-merge to ubuntu-dev-tools is?
[22:13] <TheMuso> RainCT: Theres a bug filed on it.
[22:14] <TheMuso> https://bugs.launchpad.net/bugs/155098
[22:14] <tepsipakki> it needs a license
[22:14] <Ubotwo> Launchpad bug 155098 in ubuntu-dev-tools "add grab-merge.sh" [Wishlist,New]
[22:15] <RainCT> ah
[22:17] <RainCT> TheMuso, tepsipakki: thx
[22:17]  * RainCT grumbles something about what's so difficult on licensing stuff properly before making it public
[22:18] <TheMuso> RainCT: In this case, the script was written to simply grab files from the site, and it requires the author to give it a license. IMO I don't see the need for it to be in ubuntu-dev-tools, unless it was rewritten to include fetching from DaD, but even thne, I think its fine where it is.
[22:18] <bahadunn> howdy
[22:20] <RainCT> well, it's always nice to get everything there with an apt-get install
[22:20] <RainCT> but you're right, this one isn't difficult to find
[22:29]  * minghua wonders why ubuntu-dev-tools depend on reportbug.
[22:32] <TheMuso> minghua: Theres a script to submit source changes to debian.
[22:32] <TheMuso> Which uses it.
[22:33] <minghua> Aha, it's for reporting bugs to Debian.  Thanks TheMuso.
[22:33] <TheMuso> np.
[22:38] <RainCT> bddebian: "comment out *_DISABLE_DEPRECATED" do you know what those are?
[22:38] <RainCT> (about the Makefiles)
[22:40] <bddebian> RainCT: Not exactly sure what they do but fixed several packages that way :-(
[22:40] <TheMuso> RainCT: has there been a new upstream version since the last merge?
[22:40] <bddebian> Well I should say they disable deprecated glib/gnome/etc commands
[22:41] <bddebian> Not that I'm aware of
[22:41] <minghua> RainCT: Is that a GTK application?
[22:41] <TheMuso> balsa is yes.
[22:42] <RainCT> TheMuso: yes, 2.3.17 -> 2.3.20
[22:42] <TheMuso> actually i think its a gnome app
[22:42] <TheMuso> RainCT: Right
[22:42] <TheMuso> RainCT: Try without the disable depricated stuff first, to be sure its not needed.
[22:42] <minghua> RainCT, TheMuso: Then I believe it's because of a new glib/gtk version.
[22:43] <JanC> if anybody has experience with the 'python-django' package: http://www.djangoproject.com/weblog/2007/oct/26/security-fix/
[22:43] <RainCT> TheMuso: ok, building
[22:43] <TheMuso> minghua: yeah. Somethign similar was needed for another app I've worked on.
[22:43] <minghua> Glib/GTK label some functions as obsolete for every new major version.
[22:45] <RainCT> uh.. is there any reason for «dpkg-source -x package.dsc» to be really slow when being used with something downloaded using grab-merge?
[22:45] <RainCT> ahh
[22:45] <RainCT> gpg: keyserver timed out
[22:45] <TheMuso> ah
[22:46] <RainCT> how can I get the keys for debian? (or what else can I do in order that it works properly)
[22:46] <TheMuso> RainCT: I don't worry about checking sigs when unpacking packages.
[22:47] <RainCT> ah ok, where can I disable it then?
[22:47] <minghua> I didn't know dpkg-source would check signature remotely.
[22:47] <minghua> ...maybe on Debian it doesn't...
[22:47] <TheMuso> Me neither.
[22:47] <TheMuso> minghua: nor on Ubuntu
[22:48] <RainCT> well, it toke a lot and then said this http://paste.ubuntu-nl.org/42403/
[22:48] <RainCT> and the same with the stuff I downloaded previously
[22:49] <minghua> RainCT: Installing debian-keyring package *may* help.
[22:49] <TheMuso> d/c
[22:49] <TheMuso> uh
[22:49] <RainCT> ok, thanks
[22:54] <minghua> RainCT: I think it has something to do with your gpg setting.
[22:55] <minghua> I just tried under gutsy, it doesn't connect to a remote keyserver here.
[23:00] <StevenHarperUK_> Hi I am looking for MOTU's to review my Package (easycrypt) on REVU : I currently have 0 Advocation's: http://revu.tauware.de/details.py?upid=437
[23:09] <RainCT> minghua: it's the default one, + seahorse installed
[23:11] <JanC> https://bugs.launchpad.net/ubuntu/+source/python-django/+bug/157903
[23:11] <Ubotwo> Launchpad bug 157903 in python-django "security vulnerabiity in django i18n system" [Undecided,New]
[23:13] <POX_> buxy: ^^ (we need to fix it in DPMT)
[23:20] <RainCT> balsa is writing a lot of  "cc -DG_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED ....." lines
[23:23] <TheMuso> RainCT: Did you check for a patch to make that happen?
[23:27] <RainCT> the package was build fine tought
[23:29] <TheMuso> RainCT: Yeah but if that was showing up, something is still causing it to disable the depricated warnings or whatever it is.
[23:30] <RainCT> yeh, the Makefiles contain that
[23:30] <RainCT> in the latest ubuntu revision this was commented out, but directly on the makefiles (no patch)
[23:31] <TheMuso> Right.
[23:31] <TheMuso> Maybe try commenting it out.
[23:31] <persia> RainCT: patches in diff.gz are still patches: just a different way of doing them (one patch for everything)
[23:32] <RainCT> well, so this should continue?
[23:32] <RainCT> *continue there
[23:32] <TheMuso> RainCT: Basically, it would be good to find out whether the disabling is needed.
[23:35] <nenolod> anyone have tips on packaging CMake based buildsystems?
[23:36] <persia> nenolod: You'll need to add the right cmake calls to both the configure: and the build: rules.
[23:37] <nenolod> darn! i was hoping there was a cdbs overlay file for it :(
[23:37] <nenolod> oh well, there's other things that need to be done before it's packageable anyway
[23:38] <nenolod> the damn library doesn't even set a SONAME and it installs as library.so
[23:38] <TheMuso> nenolod: have you told upstream?
[23:38] <nenolod> yeah
[23:38] <nenolod> i have
[23:38] <nenolod> ;p
[23:38] <TheMuso> Ok.
[23:39] <nenolod> but upstream is a gentoo luser, so we'll see if he chooses to care or not
[23:39] <nenolod> ;p
[23:39] <nenolod> IT WORKS ON MY GENTOO BOX
[23:39] <nenolod> is probably what he will say ;p
[23:40] <nenolod> although AFAIK portage complains about missing SONAME too
[23:40] <nenolod> ;p
[23:40] <TheMuso> lol
[23:40] <TheMuso> But if its a library.
[23:40] <persia> nenolod: The problem is that cmake allows wide latitude in the way it wishes to be called in each step.  If you can find a way to generalise, and prepare a candidate cmake rule for CDBS, it may be accepted (although CDBS changes usually take a complete cycle for review & acceptance).
[23:41] <nenolod> persia, i've noticed that cmake is very flexible
[23:41] <persia> TheMuso: even a library doesn't matter on Gentoo.  all clients get recompiled when it is updated, even if there is no API or ABI change.
[23:41] <nenolod> it is annoying ;p
[23:41] <TheMuso> persia: See thats dangerous.
[23:41] <TheMuso> Lulls programmers into a bad practice.
[23:42] <nenolod> TheMuso, well, portage goes
[23:42] <persia> TheMuso: That, and makes packaging problems worse.  If there's an API change, and the packager forgets to change the package name, the system breaks.
[23:42] <nenolod> QA Notice: missing SONAME for libfoo.so
[23:42] <nenolod> or something
[23:43] <TheMuso> yeah. Portage should just stop and say "I'm not going any further"
[23:43] <nenolod> it's portage
[23:43] <nenolod> lowest common denominator
[23:43] <nenolod> ;p
[23:43] <TheMuso> Well he deserves to have his ass kicked by sane packagers/distro maintainers.
[23:43] <persia> TheMuso: We don't do that for lintian.  Why should portage for the equivalent?  I'm not trying to defend portage as a whole, just the decision to allow breakage if the packager really wants to.
[23:44] <TheMuso> persia: True.
[23:44]  * persia completely agrees that the developer/packager who lets that through deserves direct physical appreciation from all the users
[23:45] <bmk789> what should i do with my GPG keys to transfer them to a new OS?
[23:45] <TheMuso> Afaik the only time one doesn't need to use a soname is for plugins, but even then...
[23:47] <persia> bmk789: Copy the pubring.gpg and secring.gpg files from ~/.gnupg.  You may also want the trustdb.gpg, but that is less essential.  If you forget pubring.gpg, you can at least download your key from the keyservers.  If you forget secring.gpg, you'll have trouble...
[23:48] <TheMuso> Thats if your public key is on a key server.
[23:48] <bmk789> so basically transfering the whole .gnupg dir over will do the job?
[23:48] <persia> TheMuso: Technically, one never needs a soname: it's just a mechanism to identify the ABI so that clients can select the right library version at runtime, and multiple versions can be installed.
[23:48]  * TheMuso nods
[23:49] <persia> TheMuso: Publishing to a keyserver is a requirement for Contributors :)
[23:49] <TheMuso> persia: yeah I know that.
[23:49] <persia> bmk789: That might work, but you may wish to adjust gpg.conf if your gpg version changes, you don't really need the backup files, and it doesn't hurt anything to generate a new random seed.
[23:52] <bmk789> thanks
[23:55] <RainCT> (Can someone please merge ~rainct/ubuntu-dev-tools/dev into ~ubuntu-dev/ubuntu-dev-tools/trunk?)
[23:59] <nenolod> persia: i don't understand this using CMake trend
[23:59] <nenolod> persia, what is so wrong with autotools :/
[23:59] <persia> RainCT: Ummm..  About line 45 of get-build-deps.  It fails to guarantee either that sufficient versions are installed, or try installing alternates if the preferred dependencies are not available.  The second it's a big issue, but the first can be a problem.  Can these not be extracted, and checked with grep-dctrl or similar?