[00:07] <TheMuso> Looking at bug 157129
[00:07] <ubotu> Launchpad bug 157129 in blobwars "Please merge blobwars 1.07-2 from Debian unstable" [Wishlist,Confirmed] https://launchpad.net/bugs/157129
[00:11] <ScottK> IIRC (re libowfat) at least in Debian you can use .tar.bz2.
[00:11] <ScottK> It's a recent dpkg? change
[00:11] <TheMuso> Bout bloody time IMO.
[00:11] <ScottK> Or maybe standards version 3.7.3.
[00:12] <ScottK> IIRC it turned up in the lintian diff when I was reviewing it for syncing.
[00:12] <TheMuso> Ah right.
[00:12]  * somerville32 cries as his package doesn't compile.
[00:12] <ScottK> Which is also conveniently available in gutsy-backports for those interested in that
[00:12] <TheMuso> c
[00:12] <TheMuso> ugh
[00:13] <ScottK> somerville32: Step away from the keyboard to avoid risk of electrical shock.
[00:14] <somerville32> Can someone take a look at this?
[00:14] <somerville32> http://pastebin.com/m1ba00dad
[00:15] <TheMuso> still trying to connect
[00:17] <TheMuso> Hrm. I'd have to look at the code to work that one out.
[00:19] <TheMuso> somerville32: Could you put your .dsc/.diff.gz up somewhere and give me a link to the tarball?
[00:19] <TheMuso> somerville32: And I'll see what I can work out.
[00:19] <somerville32> I'll put it on revu
[00:19] <mok0> somerville32: Take a look at libapm.h, it seems like it includes both <sys/types.h> and <linux/types.h>
[00:19] <somerville32> mok0, okay
[00:20] <mok0> somerville32: if that's the case, try removing the latter
[00:20] <soren> somerville32: __KERNEL_STRICT_NAMES might be of interest...
[00:21] <soren> somerville32: Google will explain. I haven't the time. Sorry.
[00:23] <mok0> somerville32: Also, in your cc statement (7) it looks like the CFLAGS are present multiple times
[00:23] <mok0> somerville32: e.
[00:24] <mok0> somerville32: f.ex you have -DPNG_NO_MMX_CODE three times
[00:24] <LaserJock> does anybody here have any interest in helping package Ubuntu artwork?
[00:24] <TheMuso> LaserJock: Yeah whats up?
[00:24] <somerville32> "#include <linux/apm_bios.h>
[00:24] <somerville32> #include <sys/types.h>"
[00:24] <somerville32> Those are the only two include statements in libapm.h
[00:24] <mok0> somerville32: Hmm
[00:25] <soren> somerville32: linux/apm_bios.h is likely including linux/types.h
[00:25] <LaserJock> TheMuso: basically, the art team is looking for somebody to handle the packaging of the artwork
[00:25]  * soren idly points at __KERNEL_STRICT_NAMES again..
[00:25] <LaserJock> TheMuso: currently they have nobody that's got packaging experience
[00:26] <mok0> somerville32: just for fun, see what happens if you comment out the <sys/types.h> line
[00:28] <TheMuso> LaserJock: Right.
[00:28] <LaserJock> TheMuso: interested?
[00:28] <TheMuso> LaserJock: Well I'm actually looking at a better way to do the UbuntuStudio art packaging, so if and when I come up with something, I could help out with the ubuntu artwork packag.
[00:28] <TheMuso> package.
[00:28] <LaserJock> TheMuso: I think that would be stellar
[00:29] <_MMA_> LaserJock: Ive been talking to kwwii about this as well.
[00:29] <LaserJock> right
[00:29] <LaserJock> I just thought I'd ask as I told him I would see
[00:30] <_MMA_> Oh yeah. You were there. :) Well I thought you were gonna put a "wider call" out. Actually I think Ken did.
[00:30]  * _MMA_ looks.
[00:30] <LaserJock> well, I thought I'd see here first before announcing something on ubuntu-devel ;-)
[00:31] <LaserJock> it'd be nice to get somebody who is a core-dev or wants to be one
[00:31] <TheMuso> LaserJock: Yeah well I think the biggest issue with the artwork currently, is the way its built. I think for something as simple as art, this can be simplified.
[00:35] <somerville32> mok0, more errors
[00:35] <Fujitsu> ajmitch: Your rcbugs page doesn't seem to have been updated in almost a month.
[00:35] <somerville32> sys and linux still seem to be included somewhere
[00:35] <somerville32> I've uploaded it to revu
[00:35] <mok0> somerville32: hmm, something is seriously wrong with the source
[00:36] <mok0> somerville32: it was a wild shot :-)
[00:36] <soren> somerville32: Ask google about __KERNEL_STRICT_NAMES  and you'll likely be much happier.
[00:37] <somerville32> Ok
[00:38] <somerville32> I'll try that
[00:38] <ajmitch> Fujitsu: oh well
[00:41] <mok0> somerville32: it says to include features.h before linux/types.h
[00:41] <Fujitsu> ajmitch: It would be nice if you could update it, so we can fix more bugs.
[00:41] <mok0> somerville32: features.h should define __KERNEL_STRICT_NAMES
[00:42] <somerville32> mok0, I saw.
[00:42] <somerville32> :)
[00:42] <mok0> hehe
[00:43] <LaserJock> can I possibly pick a package to work on that *doesn't* take at least 1 hr to build? >:/
[00:44] <Fujitsu> LaserJock: No.
[00:44] <ajmitch> Fujitsu: I'll consider it, if I can rsync to qa.uw.c properly
[00:45] <Fujitsu> ajmitch: Why can't you rsync to there?
[00:45] <LaserJock> ok, any git-cvs or git-svn users here?
[00:45] <ajmitch> because it wanted to use my regular ssh key on LP
[00:45] <Fujitsu> Oh, right.
[00:45] <Fujitsu> I think imbrandon was working on that.
[00:46] <Fujitsu> Not sure what came of it.
[00:46] <LaserJock> Fujitsu: have you had a look at axiom by chance?
[00:46] <ajmitch> yes, and I was waiting on that
[00:46] <Fujitsu> LaserJock: I heard you were.
[00:46] <LaserJock> Fujitsu: well, I tried
[00:46] <imbrandon> Fujitsu: i was waiting on your input , i got stuck, thats why i pointed you to my copy ;)
[00:46] <LaserJock> looking at the changelog it looks to be a sync
[00:46] <Fujitsu> Should be syncable, I think.
[00:46] <Amaranth> LaserJock: I use git-svn, why?
[00:46]  * Fujitsu checks.
[00:46] <LaserJock> but 4 people tried to build it and it gave 3 different errors
[00:46] <Fujitsu> DId you point me at your copy?
[00:47] <Fujitsu> Wow.
[00:47] <imbrandon> yea, one sec i'll do it again
[00:47] <imbrandon> hehe
[00:47] <LaserJock> Fujitsu: I have absolutely *no* clue why it would fail, for me it fails during a cp
[00:47] <Fujitsu> imbrandon: Erm, oops, thought it was LaserJock saying he'd pointed me at his copy.
[00:47] <LaserJock> Amaranth: do you commit using it?
[00:48] <Amaranth> LaserJock: I have (once)
[00:48] <LaserJock> hmm, well that's not all that much
[00:48] <LaserJock> some guys were using it on an upstream project
[00:48] <LaserJock> and it was doing funky things
[00:48] <somerville32> mok0, Ok, got rid of the redefinition errors
[00:48] <LaserJock> like reviving removed directories :-)
[00:48] <Amaranth> I mostly use it for tracking things
[00:49] <LaserJock> Fujitsu: my copy of what?
[00:49] <somerville32> How can I see if something built successfully in debian?
[00:49] <Fujitsu> LaserJock: I presumed axiom, but it was in fact imbrandon saying it.
[00:50] <LaserJock> oh man, we're so messed up
[00:50] <LaserJock> maybe I need more sleep
[00:50] <ScottK> Which must be while I feel at home here.
[00:50] <LaserJock> ScottK: lol, so true ;-)
[00:50] <ScottK> ;-)
[00:50] <somerville32> mok0, <<<
[00:52] <imbrandon> ajmitch: Fujitsu is looking at the code i started now, hopefully he can finish the python-foo on it and have it working soon-ish/tonight/today
[00:52] <ScottK> Oohh.
[00:52]  * ScottK reads the new devscripts changelog.
[00:52] <ScottK> debdiff: Support tarball in tarball (Closes: #439667).
[00:52] <LaserJock> hmm, so I wonder when we could get this "merge Universe/Main" thing done, Hardy+1?
[00:52] <imbrandon> LaserJock: huh ?
[00:52] <somerville32> We should do it for Hardy
[00:52] <LaserJock> seems like it'd take quite some Launchpad work
[00:52] <Fujitsu> imbrandon: See the revolutionary email to ubuntu-devel.
[00:52] <somerville32> lol
[00:53] <Fujitsu> somerville32: It's not going to happen.
[00:53] <Fujitsu> LaserJock: Yeah, just a bit.
[00:53] <ajmitch> imbrandon: k, I won't be looking at anything for awhile though
[00:53]  * imbrandon looks, subject ?
[00:53] <imbrandon> ajmitch: kk
[00:53] <LaserJock> somerville32: I don't know dude, it'll take a lot of soyuz work and governance issue resolution
[00:53] <LaserJock> imbrandon: Keybuk proposed to merge Universe and Main
[00:53] <LaserJock> imbrandon: and to manager permissions via seeds
[00:53] <LaserJock> basically
[00:54] <imbrandon> kick ass, i sugested it a few months ago, no one listened , leaste someone will listen to him maybe
[00:54] <imbrandon> yea
[00:54] <imbrandon> if a pacakges is seeded core-dev does it, if not -dev does
[00:54] <ScottK> imbrandon: Maybe someone did listen.
[00:54] <LaserJock> it's would be sooo messy though
[00:54] <LaserJock> can you imagine the LP team web that'll create
[00:54] <pwnguin> apparently MT is gpl'd or something
[00:55] <Fujitsu> LaserJock: I don't see it as particularly messy.
[00:55] <ScottK> LaserJock: And we can't have messy because it's all so neat and clean now?
[00:55] <Fujitsu> Just ubuntu-dev will be a member of a few teams.
[00:55] <LaserJock> ScottK: no, but it'll take some work
[00:55] <LaserJock> Fujitsu: starts out as a few
[00:55] <LaserJock> but people will have to be careful who they let into their team
[00:55] <LaserJock> will the TB have to approve all uploaders?
[00:55] <imbrandon> LaserJock: they should be now
[00:56] <LaserJock> imbrandon: why?
[00:56] <Fujitsu> LaserJock: The emails says that will be up to the seed-managing teams, not the TB.
[00:56] <LaserJock> right
[00:56] <LaserJock> I'm just saying as we say get 30, 40, ... seed teams
[00:56] <LaserJock> this could be a bit interesting
[00:56] <imbrandon> the thing about overlap sucks
[00:56] <ScottK> I think Keybucks followup about how to deal with it makes sense.
[00:56] <TheMuso> I'll be interested to read other Canonical dev thoughts, such as from people like Colin and pitti.
[00:57] <mok0> somerville32: cool, did it finish?
[00:57] <somerville32> mok0, Look at private query
[00:58] <ScottK> So then you'd be able to be, say, a Kubuntu developer for KDE stuff even if you weren't even a MOTU yet.  It allows for a new class of specialist that I think would be useful.
[00:58] <ScottK> See you later.  Off to go Christmas shopping.  Yeah!!!
[00:59] <LaserJock> ScottK: agreed, and cya
[00:59] <Fujitsu> ScottK: Fun...
[00:59]  * TheMuso has already done his.
[01:00] <Fujitsu> Keybuk's followup cleared most things up, which is good.
[01:00] <LaserJock> I think it also kinda goes to this issue that was brought up by Till
[01:00] <_MMA_> ScottK: Arundel Mills FTW! ;)
[01:00] <LaserJock> it's sometimes very weird to have people go for MOTU who've never worked in Universe and never plan to
[01:01] <Fujitsu> LaserJock: Right.
[01:01] <LaserJock> while, as Keybuck said, not locking into a Debian-style maintainership
[01:02] <LaserJock> man, I can just hear cprov groaning
[01:02] <Fujitsu> Yep.
[01:02] <LaserJock> and as _MMA_ just mentioned to me, what happens to all the bugmail?
[01:02] <Fujitsu> It loses the component information and gets seed information instead.
[01:03] <Fujitsu> Hm, both would need to exist.
[01:03] <LaserJock> say ~motu is a part of a team that wants to get all it's bugmail
[01:03] <Fujitsu> But is that what you meant?
[01:03] <Fujitsu> Ah.
[01:03] <Fujitsu> I see.
[01:03] <LaserJock> then ~motu will also get the bugmail
[01:03] <Fujitsu> That requires LP to drop its one-size-fits-all idea.
[01:03] <LaserJock> *gasp*
[01:03] <Fujitsu> And provide *gasp* user-configurable settings.
[01:04] <Fujitsu> Damn, you beat me to the gasp.
[01:07] <LaserJock> hmm
[01:08] <LaserJock> well, I guess I better get home so I can get some work done ;-)
[01:11] <ScottK> _MMA_: If you can find a parking place.
[01:14] <_MMA_> :D
[01:19]  * somerville32 goes to merhe electricsheep
[01:19] <TheMuso> somerville32: How did you go with that code compilation problem?
[01:20] <somerville32> TheMuso, Still working on it. Got rid of issue #1
[01:20] <somerville32> now working on issue #2
[01:20] <TheMuso> Ah right.
[01:50] <TheMuso> slangasek: Where does the universe sponsors queue stand WRT DIF and processing requested merges/syncs? Are they still ok to go through even if DIF comes into effect?
[01:51] <Fujitsu> Isn't DIF more of an advisory rather than actual freeze?
[01:51] <TheMuso> Yeah, but still.
[01:51] <LaserJock> it's when we don't get auto-sync
[01:51] <LaserJock> and if somebody bothered to do the work I don't think we should turn them down
[01:52] <LaserJock> IMO
[01:52] <TheMuso> Another one down.
[01:53] <slangasek> TheMuso: well, the discussion on ubuntu-motu@ covers everything IMHO
[01:53] <TheMuso> ok
[01:54] <StevenK> Which is you can continue to do merges if you can justify them?
[01:56] <DaSkreech> Is there some reason that seamonkey isn't in the repos?
[01:57] <TheMuso> LaserJock: Did you take care of bug 175725?
[01:57] <ubotu> Launchpad bug 175725 in regina-normal "Please merge regina-normal (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/175725
[01:57] <TheMuso> I still see it on the sponsors queue list.
[01:57] <LaserJock> TheMuso: still waiting for it to build
[01:57] <somerville32> Ummm...
[01:57] <somerville32> I have a problem :/
[01:58] <LaserJock> TheMuso: I know how to pick'em
[01:58] <TheMuso> LaserJock: Oh ok. In the future, could you please unsubscribe uus from the bugg, so that an indication is given as to whether someone is working on it?
[01:59] <LaserJock> ahh
[01:59] <LaserJock> I wondered if I should assign it to myself or something
[01:59]  * LaserJock goes to read the sponsoring wiki page again
[02:02] <Ubulette> I'm doing a native package, arch=all, using cdbs. It FTBFS at the end with "dpkg-genchanges: failure: cannot read files list file"? indeed, no debian/files are created. Any hint ?
[02:02] <LaserJock> somerville32: we know you have problems, but what's up? ;-)
[02:03] <somerville32> LaserJock, xfce4-battery-plugin doesn't compile with 2.6.24 linux
[02:04] <zul> evening
[02:04] <zul> surprise surprise
[02:05] <LaserJock> hi zul
[02:07] <somerville32> What does the S in FTBS mean?
[02:07] <StevenK> Source
[02:07] <TheMuso> somerville32: FTBS or FTBFS?
[02:07] <StevenK> Fails To Build From Source
[02:07] <somerville32> Oh, ok
[02:08] <persia> LaserJock: Both: unsubscribe & assign (unless it's a quick comment/rework, in which case unsubscribe is usually sufficient)
[02:09] <LaserJock> man, things have changed so much ...
[02:09] <persia> LaserJock: That's not changed since it was presented at a MOTU Meeting in May :)
[02:10] <LaserJock> well, I know
[02:10] <LaserJock> but umm... it's been a while
[02:10] <persia> he
[02:10] <persia> h
[02:10]  * txwikinger gets the feeling MOTUs never sleep ;)
[02:11] <LaserJock> sleep?
[02:11] <txwikinger> what is that?
[02:11] <txwikinger> :D
[02:11] <TheMuso> More like, there is always a MOTU on hand, 24 hours a day.
[02:11] <persia> txwikinger: As a group, we don't.  Individually, occasionally.
[02:11] <txwikinger> persia: hehe
[02:12] <StevenK> Sleep is for the week
[02:12] <txwikinger> weekor weak?
[02:12]  * persia likes "week" :)
[02:12]  * StevenK too :-)
[02:13]  * TheMuso likes sleep.
[02:13] <TheMuso> It ensures I don't make packaging mistakes.
[02:15] <somerville32> I've had packages in the queue for like, over 24 hours now :P
[02:15] <somerville32> boo! :P
[02:15] <TheMuso> persia: Good follow up mail.
[02:16] <bddebian> Heya gang
[02:17] <DaSkreech> Hi bddebian
[02:17] <somerville32> Heya bddebian :)
[02:17] <bddebian> Heya DaSkreech, somerville32
[02:18] <DaSkreech> has anyone tried to package seamonkey?
[02:19] <LaserJock> DaSkreech: I think there's something up with that
[02:19] <LaserJock> you might as the Mozilla Team
[02:19] <DaSkreech> LaserJock: Something technical or legal?
[02:20] <LaserJock> most likely technical
[02:21] <DaSkreech> cause it occurs to me that it's been a long time since Ubuntu came out and there is still no Seamonkeys :(
[02:21] <imbrandon> ajmitch: fyi, you can add custom ssh keys to /srv/ssh-keys/<user>.key now too whenever your ready, the new system is in place
[02:21] <persia> DaSkreech: seamonkey is in hardy: request a backport if you can compile it on gutsy (but I think you may have trouble)
[02:22] <DaSkreech> persia: hooray! More reasons to jump to hardy! :)
[02:22] <dmb> hello
[02:22] <persia> DaSkreech: There's also lots of reasons not to jump.
[02:22]  * imbrandon jumped a few days ago, lots of "small" things, hehe
[02:23] <DaSkreech> persia: don't tell me about it :) still waiting for the not to jump reasons to come low enough for me to jump over them!
[02:25]  * ajmitch will probably upgrade to hardy about 2 months after release
[02:27] <mok0> somerville32: if you declare typedef unsigned short  apm_event_t;
[02:27] <mok0> in libapm.h it compiles in hardy.
[02:27] <mok0> but I doubt that it works
[02:27] <somerville32> mok0, It does.
[02:28] <LaserJock> I'll upgrade at RC most likely
[02:28] <somerville32> mok0, That change is not intentionally I don't think
[02:28]  * TheMuso is running hardy on non-critical boxes.
[02:28] <somerville32> mok0, Upstream (ie. Linux) has been notified
[02:28] <mok0> somerville32: cool
[02:28] <mok0> somerville32: you mean the panel app works?
[02:29] <somerville32> mok0, we'll find out in a second :P
[02:29] <somerville32> Ooo...
[02:29]  * somerville32 gets an idea.
[02:30] <somerville32> mok0, I'm going to apply the the patch to the kernel so that I have it on my upload list :P
[02:30] <mok0> :-)
[02:31] <mok0> another bug bites the dust
[02:32] <mok0> TheMuso: did you do a fresh hardy install?
[02:34] <TheMuso> mok0: On the non-critical boxes, yes.
[02:34] <mok0> I wanna upgrade a box soon
[02:37]  * mok0 is going to bed
[02:37] <mok0> g'night all
[02:37] <bddebian> Gnight mok0
[02:38] <LaserJock> wow, that regina-normal build to 90 minutes
[02:39] <TheMuso> ouch
[02:40] <LaserJock> yeah, spent the first 90 verifying that our current package doesn't work
[02:41] <LaserJock> then another 90 building with the fix
[02:41] <bddebian> heh
[02:42] <Ubulette> persia, you told me earlier that 'Uploaders' has no meaning in ubuntu and should be dropped, yet, i have to add it in a new (native) package i'm doing, in order to stop lintian from thinking i'm attempting an invalid NMU
[02:42] <TheMuso> haha
[02:43] <LaserJock> Ubulette: what?
[02:43] <LaserJock> Ubulette: on what release do you get that?
[02:43] <Ubulette> LaserJock, a new package i'm preparing
[02:44] <LaserJock> Ubulette: yeah, but I took care of NMU in lintian quite some time ago
[02:44] <bddebian> Ubulette: Did you set the maintainer to Ubuntu MOTU?
[02:44] <LaserJock> Ubulette: are you using Ubuntu versioning?
[02:44] <Ubulette> 0.1 (native)
[02:44] <persia> Ubulette: set an Ubuntu package version, and an Ubuntu maintainer, and it will go away.  Anyway, why native?
[02:44] <bddebian> Oh, LaserJock "fixed" it..?? ;-P
[02:44] <Ubulette> mozillateam as maintainer
[02:45] <LaserJock> Ubulette: yeah, 0.1 is not a valid version
[02:45] <Ubulette> native because i'm upstream
[02:45] <persia> LaserJock: Yes it is, just not an Ubuntu version.
[02:45] <persia> Ubulette: So? package it as upstream, and make a distro package.
[02:45] <LaserJock> persia: I don't think it is is it?
[02:45] <LaserJock> oh wait, it's hative
[02:45] <persia> LaserJock: Yep.
[02:45] <LaserJock> *native
[02:45] <LaserJock> for non-native it wouldn't be valid I don't think
[02:45] <persia> LaserJock: Right.
[02:46] <bddebian> Frick I still can't build half my games packages because of this stupid sdl bug
[02:46] <Ubulette> with uploaders matching changelogs, lintian and linda are both happy, even with version 0.1
[02:47] <LaserJock> right
[02:47] <LaserJock> because it thinks it's a Debian package
[02:47] <persia> Ubulette: Yes, but that's because nobody has bothered to change lintian and linda to ignore Uploaders.  It's a very minor bug in those packages.
[02:47] <LaserJock> should it ignore Uploaders?
[02:47] <persia> (err, ignore "Uploaders" for Ubuntu-versioning, that is)
[02:48] <persia> LaserJock: For Ubuntu, yes.  For Debian, certainly not.
[02:48] <LaserJock> persia: but it's not ubuntu versioned?
[02:48] <persia> LaserJock: That would be a bug for a new package in Ubuntu, no?
[02:48] <Ubulette> i wanted to do a native ubuntu only package
[02:48] <LaserJock> but he's not got Ubuntu versioning
[02:48] <LaserJock> Ubulette: you *don't* want to do a native package
[02:48] <Ubulette> why ?
[02:48] <LaserJock> because native packages are for packages that are not useful outside the distro
[02:49] <persia> Ubulette: I am an opponent of native packages.  Anyway, even if you did one, it should be ubuntu-versioned, or you'll need to preemptively blacklist.
[02:49] <Ubulette> LaserJock, that's the case
[02:49] <LaserJock> Ubulette: what is the package?
[02:49] <persia> Ubulette: Describe the package.
[02:49] <Ubulette> no use at all outside the mozillateam.
[02:50] <Ubulette> it's a kind of cdbs-like package to create all the proper tarballs for mozilla packages
[02:50] <Ubulette> doing embedded or not, nobinonly clean-up stuff, and more
[02:51] <Ubulette> so it will be a build-dep
[02:51] <Ubulette> that's why i wanted a native package
[02:52] <persia> hrm.  I see the point, and yes, that type of package should be native.  Any chance it would be useful to mozilla maintainers in Debian?
[02:52] <persia> s/should/could/
[02:52] <Ubulette> i doubt it. the branding thing
[02:52] <LaserJock> yeah, but that's just a patch to your package
[02:53] <Ubulette> but it's highly customizable so who knows
[02:53] <persia> Ubulette: It's the "who knows" that makes me extra unsure.
[02:54]  * somerville32 hugs bryce
[02:54]  * persia grumbles at the Mozilla Foundation for forcing code duplication in multiple tarballs due to annoying attitudes about branding
[02:55] <somerville32> bryce, It has been 15 minutes and I don't see the upload
[02:56]  * TheMuso should tackle the festival merge.
[02:56] <Ubulette> persia, providing debian uses git, dpatch, standard dh_ stuff, does unbranding and remove all non free files, while ubuntu uses bzr, quilt, cdbs, keeps the original branding and only remove binaries, it's a loooong way to resync
[02:56] <bryce> somerville32: hmm, well I've not gotten a reject yet, so maybe things are just slow?
[02:57] <LaserJock> dang, it's really been too long since I've done real packaging work
[02:57]  * somerville32 nods.
[02:57] <persia> Ubulette: Sure, I'm just not sure about whether your add-on package would be useful there (as I have no idea what it does)
[02:57] <LaserJock> I keep forgetting that Launchpad closes bugs these days :(
[02:58] <LaserJock> Ubulette: to be honest, it seems more like a script you'd keep somewhere rather than something you'd package
[02:58] <Ubulette> persia, the idea is to use if for firefox, xulrunner, thunderbird, sunbird, seamonkey, and all their mozilla friends
[02:59] <Ubulette> we have too many copies of the clean up script, too many rules diverging, it's a pain in the *s to maintain and to review for everyone
[03:01] <persia> Ubulette: Understood, but that's a description of why the package exists, not what it does, and so doesn't provide any indication of whether non-Ubuntu native versioning is acceptable.
[03:01] <Ubulette> let me past you the core of the stuff
[03:01] <persia> As another workflow alternative, you could keep common scripts in a branch, and pull the branch at packaging time, with an include statement in debian/rules.
[03:01]  * persia suggests a pastebin
[03:03] <Ubulette> http://paste.ubuntu.com/2682/
[03:04] <persia> Ubulette: Is that essentially the entirety of it: a makefile snippet?
[03:04] <Ubulette> the core ony, a dozen of files, makefiles + patches for the multi-stages cvs fetch
[03:04] <Ubulette> anly
[03:05] <persia> Ubulette: That seems awfully light for a package.  Have you asked about including it as a default CDBS extension?
[03:06] <LaserJock> persia: I agree
[03:06] <Ubulette> it has no relation to cdbs
[03:06] <Ubulette> it's just cdbs-like
[03:06] <persia> Ubulette: Except that it serves much the same type of purpose: a set of things that get included in debian/rules to make packaging easier.
[03:07] <persia> Further, if it's only 12 files, it's not that big, and so it may be less archive space / bandwidth to just push it there.
[03:08] <persia> Of course, if the answer is no, then it makes sense to go for a separate package (ubuntu-mozilla-dev or something) that might include this and more as required (and yes, non-Ubuntu native versioning would be acceptable for such a package)
[03:09] <Ubulette> well, forget it, i'm tired. the package is ready, asac welcomed the idea (and we've been using my previous version for 6 months inside the team). I'll hand it to him and he'll do whatever he want, drop, merge, keep..
[03:10] <Ubulette> it's 4am here, sorry to be rude :(
[03:10] <persia> Ubulette: Sleep on it, but come back: the code is good, but why the separate package rather than just CDBS integration.  Have a good night.
[03:11] <LaserJock> Ubulette: in any case you can ignore NMU warnings in Ubuntu
[03:11] <persia> LaserJock: Well, that's dangerous blanket advice: in many cases it indicates that the package isn't versioned correctly (although it's not the case for this package)
[03:12] <LaserJock> well yeah
[03:13] <TheMuso> c
[03:13] <TheMuso> ugh damn orca
[03:13] <persia> Er?  How does orca drop a /?
[03:15] <superm1> TheMuso, can you map that key that orca uses, 'c' to a different one?  Perhaps a period would be less conspicuous, and easier to brush off as coming in to say hi
[03:15] <superm1> :)
[03:15] <Ubulette> now i'm all nervous, not good for sleep
[03:15] <TheMuso> persia: By locking the modifier key used for keyboard commands. :)
[03:15] <persia> TheMuso: Ah.  I see.  Annoying that.
[03:15] <TheMuso> yeah
[03:17] <persia> Ubulette: Nervous?  Why?  Relax: you've created a good thing, that should be in the archive.  You've packaged it, and if the NMU error is your only automated check report, you've packaged it well.  We're recommending it be further integrated with CDBS, but that's something you can look at tomorrow.
[03:26]  * TheMuso kicks GNOME mag.
[03:36] <LaserJock> if all goes well, this will be my most productive package day in a couple of releases
[03:36] <LaserJock> :-)
[03:41] <TheMuso> LaserJock: More sponsoring?
[03:41] <LaserJock> well, I did 3 sponsors
[03:41] <LaserJock> and I'm gonna have at least 2 uploads of my own
[03:42] <TheMuso> Right.
[03:42] <TheMuso> I'm taking a break from the sponsors queue myself as well, as there are merges I want done.
[03:42] <LaserJock> but then I gotta get some other work done :(
[03:43] <TheMuso> Yay! Finally a new festival into the archive.
[03:48] <TheMuso> persia: Are you likely to get to freqtweak any time soon?
[04:00] <persia> TheMuso: No real point.  I might get to it, but Debian's tarball is ugly, so I'd be doing a fakemerge at best.
[04:01] <persia> TheMuso: Just for context: both represent VCS pulls from dead upstream.
[04:05] <TheMuso> persia: Ok.
[04:06] <TheMuso> I won't worry then.
[04:15] <LaserJock> ok, any mozilla gurus around?
[04:15] <LaserJock> I've got a debian package that build-deps on libxul-dev
[04:15] <LaserJock> is that ok for Ubuntu?
[04:28] <persia> LaserJock: Provided by xulrunner_<IP_ADDRESS>-1ubuntu1, but you might want to test it.
[04:30] <LaserJock> persia: right, I'm wondering if that build dep is ok for a Dep on firefox
[04:31] <LaserJock> I've used it in my PPA and nobody has complained
[04:31] <persia> LaserJock: Ah.  That'd be different then.  Most packages seem to depend on firefox-dev, but I don't know.
[04:31] <persia> There's the man who would :)
[04:31] <LaserJock> I just wondered if there was some policy/guidance for how we're dealing with it
[05:18]  * ScottK butchers some more SQL.
[05:20] <Fujitsu> Watch out. SQL bites back.
[05:20] <bddebian> delete from ...
[05:21] <ScottK> bddebian: Well the funny thing is the admin was in a hurry and I think I have the permissions to do that.
[05:22] <Fujitsu> Heh.
[05:23] <bddebian> Heh, just drop any table with the name sys in it ;-P
[05:25] <LaserJock> shesh, keescook has screwed up my fonts ;-)
[05:25] <Fujitsu> LaserJock: Tut tut. What do we say about running untrusted code from the 'net?
[05:26] <StevenK> Fujitsu: If you do it, you get what you deserve?
[05:28] <Fujitsu> StevenK: Something like that.
[05:28] <LaserJock> I just wonder why my gnome-terminal looks completely different from his
[05:28] <StevenK> Because he is Kees, and therefore rocks. Simple.
[05:28] <LaserJock> I guess so
[05:29]  * Fujitsu intercepted your HTTP request and modified the content on the way.
[05:29] <StevenK> Hah
[05:29] <LaserJock> ahhhh
[05:31]  * Fujitsu is god of the Internets, you see.
[05:32] <StevenK> I challenge your godliness
[05:33]  * Fujitsu is challenged.
[05:33] <StevenK> We knew that
[05:33] <Fujitsu> Hah.
[05:39]  * Fujitsu applauds Soyuz for generating very readable pages:
[05:39] <Fujitsu> https://edge.launchpad.net/ubuntu/gutsy/+queue?queue_state=3&queue_text=&start=40
[05:40] <ScottK> We all know who the god of this channel is, anyway.
[05:41] <Fujitsu> ScottK: Going by the wiki, I hope?
[05:41] <bddebian> ScottK: slangasek?
[05:42] <ScottK> Fujitsu: Of course.
[05:42] <ScottK> Of course slangasek is new here and he may not know. Someone should show him.
[05:42] <Fujitsu> ScottK: Thank bddebian!
[05:43] <StevenK> Oh, drat!
[05:43] <StevenK> IOError: [Errno 28] No space left on device
[05:43] <StevenK> close failed: [Errno 28] No space left on device
[05:43] <Fujitsu> Hah.
[05:43] <bddebian> Gah, hasn't that frickin' page died yet?
[05:43] <ScottK> Obviously he hasn't been paying enough attention to his spam.   Doing now.
[05:48] <LaserJock> ah ..
[05:49] <Fujitsu> slangasek: Can you please capitalise your first and last characters, just for consistency?
[05:49] <Fujitsu> ScottK, StevenK, StevelangaseK, StevenHarperUK...
[05:50]  * persia argues that one of those fails to match S[a-z]*K
[05:50]  * Fujitsu thought he made a similar point a week ago, but disregards it now anyway.
[05:51]  * persia was indeed attempting to steal Fujitsu's previous point
[05:51] <persia> Anyway, SlangaseK would be much easier to type reliably.
[05:52] <Fujitsu> True.
[05:52] <StevenK> How about slangasek changes his nick to SteveK to just confuse everyone even more
[05:53] <StevenK> Er, SteveL
[05:53] <Fujitsu> Heh.
[05:53] <StevenK> Damn QWERTY keyboard
[05:53]  * persia suggests a chording keyboard for reduced obviousness of typos
[05:53] <Fujitsu> StevenK: What do you normally use?
[05:53] <StevenK> QWERTY
[05:54] <StevenK> I'd rather blame the keyboard than my fingers. :-P
[05:54] <Fujitsu> Of course.
[06:01] <bddebian> GNight folks
[06:19] <slangasek> ScottK: wait, if there are gods here, shouldn't sabdfl be /divinely/ appointed?
[06:20] <ScottK> slangasek: https://wiki.ubuntu.com/BddebianIsAGod
[06:21] <slangasek> oh, why have I seen this page before
[06:21]  * Fujitsu notes there are recent additions.
[06:21] <Fujitsu> slangasek: You have seen it?
[06:21] <slangasek> yes
[06:21] <LaserJock> it's a universal truth
[07:06] <warp10> Hi all!
[07:39] <kagou> Good morning
[07:41] <LaserJock> darn it, some days I have CLI
[07:42] <dholbach> good morning
[07:42] <LaserJock> s/have/hate/
[07:42] <LaserJock> hi dholbach
[07:42] <dholbach> heya LaserJock
[07:42] <LaserJock> I just rm * 'd my code directory
[07:42] <dholbach> ARGH
[07:43] <dholbach> LaserJock: do you have it in a VCS somewhere?
[07:43] <LaserJock> I was about to clean it up to back it up
[07:43] <LaserJock> dholbach: no, that's what I was getting ready to do
[07:43] <LaserJock> but I have an older copy on my school machine
[07:43] <dholbach> damn :-/
[07:43] <LaserJock> I'll just lose what I've been working on this week
[07:44] <LaserJock> and of course I have to meet with my advisor tomorrow
[07:44] <LaserJock> so I have to rewrite it and get the data fitted before then
[07:45] <DarkMageZ> apachelogger__, i can now replicate your white screen issue with libvisual-projectm. it's your graphics setup.
[08:18] <POX_> ScottK: great (about recruiting :)
[08:18] <dholbach> ScottK: did you manage to sleep up until now?
[08:21] <siretart> Riddell: I've just uploaded a new xine-lib which should avoid dragging half of gnome into kubuntu
[08:21] <siretart> (well, in fact, yesterday already)
[08:22] <Riddell> siretart: great, thanks
[08:23] <siretart> sorry for the delay
[08:23] <siretart> I actually have dropped the jack plugin from debian as well, and wanted to request a sync. however, I cannot upload to debian right now because of directfb woes...
[08:39]  * LaserJock discovers git branches
[08:50] <imbrandon> siretart: is there a reason bzr-svn is versioned so tightly arround 0.92 - 0.93 ? ( i'm wanting ti for 1.0~ and wondering if there was a reason not to just rebuild it )
[08:51]  * LaserJock wonders what imbrandon is doing still up
[08:51] <imbrandon> just woke up
[08:51] <siretart> imbrandon: better ask jelmer. he is using pretty experimental features from bzr for bzr-svn.
[08:51] <imbrandon> smokin a cig, and likely to go back to bed a few hours :)
[08:51] <LaserJock> imbrandon: you have the weirdest schedule
[08:51] <imbrandon> siretart: ahh ok
[08:52]  * persia doesn't think what imbrandon does matches the definition of "schedule"
[08:52] <imbrandon> lol yea
[08:52] <imbrandon> me either
[08:53] <LaserJock> well, my brother-in-law has a very tight schedule for work that's really weird
[08:54] <persia> LaserJock: One of those 12-on 16-off type things?
[08:54] <LaserJock> he does rotating shifts so he does 1 week of mornings, 1 week of evenings, 1 week of nights, and then 1 week off
[08:54] <LaserJock> and then Christmas vacation is rotated too on a 7-year cycle
[08:54] <persia> That's not bad, really.
[08:55] <LaserJock> not horrible, but annoying when you're trying to schedule stuff with him
[08:57] <imbrandon> LaserJock: speaking of what are YOU still up for, your close to my physical timezone ( close enough to sleep arround the same time if we were 9 to 5 people )
[08:57] <imbrandon> hehe
[08:58] <LaserJock> imbrandon: I did a rm * accidentally in my code directory and I have a meeting tomorrow
[08:58] <imbrandon> ouch, in bzr or git ?>
[08:58] <siretart> imbrandon: it's pretty well possible that a rebuild would just work, however this needs to be decided on a case to case basis
[08:59] <LaserJock> imbrandon: well, I was actually cleaning it up to put in bzr when it happened
[08:59] <imbrandon> siretart: totaly, you know when he's likely to be arround irc ?
[08:59] <LaserJock> I wanted to do a rm *~
[08:59] <imbrandon> ouch
[08:59] <LaserJock> stupid ~ files
[09:00] <imbrandon> LaserJock: alias rm="rm -i" hehe
[09:00] <imbrandon> in your bashrc
[09:00] <imbrandon> -i will ask you to confirm before deleting
[09:00] <persia> LaserJock: You can also just tell just about any VCS to ignore *~
[09:00] <LaserJock> perhaps alias rm_stupid="rm -i && echo you stupid idiot"
[09:01] <persia> LaserJock: That should be `rm`.    Should catch up soon (assuming someone doesn't have a heap of NBS uploads they plan for tomorrow)
[09:12] <imbrandon> yea but 20 hours is a bit rediculus at any time in the cycle, we should have enough buildds thi never happens
[09:14] <LaserJock> heh
[09:14] <LaserJock> seems like I remember times when it was up around 1 week
[09:14] <LaserJock> langpacks and OO.o
[09:15] <imbrandon> yea and in a 6 month cycle thats simply not acceptable
[09:15] <persia> Why?  When the first syncs start, we're sometimes 8-10 days out.  As long as we're all caught up by midway between DIF & FF, I don't see any issues.
[09:15] <imbrandon> you increase the buildd's or the 6 months
[09:16] <imbrandon> persia: there is other work too, and even if there wasent that still dosent make sense
[09:17] <slicer> Does anyone have time to do a review update of http://revu.tauware.de/details.py?package=mumble ?
[09:18] <persia> imbrandon: To put it another way, why does it matter if the buildds are caught up during the first couple months of the cycle?  I don't understand what developer work is being delayed due to this (although yes, some things take longer).
[09:19] <persia> Further, I'd much prefer a lag in the beginning than a chance of a lag later by trying to avoid a lag in the beginning.  Once we enter a more agressive testing environment, turnaround becomes more important.
[09:19] <imbrandon> you dont understand a delay when i have to wait if my packages are built? i'm not going to move on and do something else untill i'm sure those are complete
[09:20] <persia> imbrandon: OK.  It's that that I don't understand.  I tend to pipeline.
[09:20] <imbrandon> infact most developers touch only a very limited set of packages, so would be in the same boat, its rare for contributors like yourself that "touch it all" or even have the ability to
[09:23] <persia> imbrandon: OK.  That makes more sense.  Given a limited set of packages, with possibly complex interactions, pipelining vastly increases the chance of a FTBFS due to poor schedule interactions.
[09:23]  * persia notes that personal volume is low, and while the package selection is fairly random, this isn't an indication of actually doing everything
[09:24] <imbrandon> hehe yea, just an example, probably a bad on
[09:24] <imbrandon> one*
[09:26] <LaserJock> geser's the one that touches everything
[09:27] <imbrandon> yea i really ment more than 2 to 3 pet packages , i think persia got the gist of it hehe
[09:28] <imbrandon> people that do more than that are the exception
[09:28] <imbrandon> as much as it would be nice for that not to be so, it is
[09:28] <LaserJock> hmm
[09:28] <LaserJock> that would also be an interesting metric to try to quantify
[09:29] <imbrandon> well look at my +packages , i touch quite a bit, but there is still a patern to what i work on "mostly"
[09:29] <persia> LaserJock: What, mean, median, and mode of breadth of packaging activity?
[09:29] <LaserJock> average number of unique packages touched/MOTU
[09:30] <LaserJock> perhaps with a std. dev. or something to give an idea of the range
[09:30] <persia> LaserJock: People who do NBS would skew that madly.  Median or mode is likely more interesting, given the nature of the curve.
[09:30] <LaserJock> or better yet a plot of it
[09:30]  * persia is certain it's not normal, and std.dev. is meaningless
[09:31] <LaserJock> probably just a histogram would suffice
[09:31] <persia> LaserJock: ping ogasawara about that
[09:32]  * TheMuso touches what interests him first, and then helps whereever possible.
[09:32] <imbrandon> TheMuso: yup thats me
[09:32] <LaserJock> persia: who?
[09:33] <imbrandon> LaserJock: she hangs in #u-devel and #ubuntuwire , a Canonical employee
[09:33] <LaserJock> really?
[09:33] <persia> LaserJock: The person who I understand to be working on the developer metrics effort.
[09:33] <LaserJock> sys admin type?
[09:33] <LaserJock> ohh, we have developer metrics? when did this happen? :-)
[09:33] <imbrandon> what persia said :)
[09:34] <imbrandon> LaserJock: in-the-works hehe
[09:34] <persia> LaserJock: We don't, but lots of people think they'd be nice...
[09:34] <TheMuso> What are developer metrics?
[09:35] <imbrandon> stats really
[09:35] <TheMuso> ah
[09:35] <LaserJock> well, it's a modified metric system
[09:35] <LaserJock> where instead of a meter they use how far a geek is willing to be away from his laptop
[09:35] <persia> TheMuso: Ideally, some information that goes beyond what joejaxx used to provide to tell us how we're doing.
[09:36] <TheMuso> persia: ah ok
[09:36] <imbrandon> and some idea to give the release managers an overview of how the reelase is ( first goal )
[09:36] <imbrandon> aka weatherreport spec
[09:36] <LaserJock> and temperature is in C but shifted so that 100 is the "OMG my computer melted" point and 0 is "hmm, that's good beer" point
[09:36] <LaserJock> hmm, not in C rather
[09:37] <persia> LaserJock: Yes in C, where "C" is "centigrade" (and no, not in Celsius)
[09:37] <LaserJock> ah
[09:37]  * LaserJock prefers Kelvin but the weather people don't seem to agree
[09:38]  * TheMuso decides to hit up the uus queue again.
[09:38] <imbrandon> ok smokes done, time to try to get a bit more sleep for tomarrow
[09:38] <imbrandon> bbiab
[09:39] <LaserJock> how do you smoke and then go to bed?
[09:39] <LaserJock> isn't smoking supposed to keep you awake?
[09:39] <persia> LaserJock: Depends on serum levels and tissue tolerance.
[09:40] <LaserJock> I guess that's like my older brother who drinks Mt. Dew to go to sleep
[09:40] <persia> LaserJock: caffine is different: high volumes provide a shock effect, causing immediate drowsiness.
[09:41] <TheMuso> That sounds sick, both for smoking and drinking soft drink before going to bed.
[09:41] <persia> TheMuso: definitely not healthy.
[09:41] <TheMuso> I generally can't go to bed within an hor of eating something.
[09:41] <TheMuso> hour
[09:46] <TheMuso> ugh. Lots and lots and lots of compiler warnings.
[09:49] <LaserJock> man, the upstream I work a little on, the author makes sure there are 0 compiler warnings before he releases the code
[09:49] <TheMuso> Wow.
[09:49] <TheMuso> Thats good.
[09:50] <LaserJock> at first I thought it was kinda weird, but fixing them actually help, who'dve thunk it
[09:52] <TheMuso> Afaik a warning starts to show that your code is not up to scratch with latest compilers
[09:53] <persia> It may also show that your code is not entirely multiarchitecture safe (e.g. not properly 64-bit clean, or doesn't properly support alternate endianness)
[09:54] <LaserJock> well, mine was just bad programming
[09:54] <LaserJock> ;-)
[09:54] <LaserJock> usually involving casting or unused variables
[09:55] <txwikinger2> Hey folks.. still awake :)
[09:55] <TheMuso> persia: Endianness issues don't always show up with compiler warnings.
[09:57] <persia> TheMuso: Unfortunately true :(
[09:57] <StevenK> TheMuso: Same for some 64-bit clean issues
[10:01] <TheMuso> Those who are requesting sponsorship. Please ensure your lp bug closure syntax is correct, and sponsors, please unsubscribe uus, or ask someone to unsubscribe uus, to ensure bugs aren't left lying around.
[10:11] <LaserJock> geeze, what's a good way to make an empty list in python?
[10:11] <soren> LaserJock: foo = [] ?
[10:11] <LaserJock> sorry, by empty I mean filled with zeros
[10:11] <soren> LaserJock: How many of them?
[10:11] <LaserJock> 501 :-)
[10:11] <soren> foo = [ 0 ] * 501
[10:12] <soren> I kid you not.
[10:12] <LaserJock> really?
[10:12] <soren> really
[10:12] <soren> Sometimes, principle of least surprise can be quite surprising in itself.
[10:14] <soren> You can also do a list comprehension of sorts, if that makes you feel less dirty..
[10:14] <soren> foo = [ 0 for soren_rules in range(501) ]
[10:15] <StevenK> That only makes me feel dirty due to "soren_rules"
[10:15] <soren> Oh, ye of little faith.
[10:16] <StevenK> "insane_soren" more works for me. :-P
[10:16] <TheMuso> lol
[10:18] <soren> There's plenty of prior art to suggest that ruling and being insane go quite well together.
[10:18] <dholbach> haha
[10:18]  * dholbach hugs super-soren
[10:18] <StevenK> soren: Yeah, well
[10:47] <coNP[uni]> Hey MOTUs!
[10:48] <coNP[uni]> dholbach: for bug #174467 I see some REVU upload and also some debdiffs in LP. Should I merge them?
[10:48] <ubotu> Launchpad bug 174467 in gnome-schedule "Please sponsor gnome-schedule-1.2.1 into Hardy" [Wishlist,New] https://launchpad.net/bugs/174467
[10:48]  * pochu waves
[10:49] <coNP[uni]> Hey pochu
[10:53] <dholbach> coNP[uni]: I hope they are actually the same?
[10:55] <coNP[uni]> REVU has gnome-schedule-1.2.1-0ubuntu1 and I have debdiffs up to 0ubuntu5
[10:55] <coNP[uni]> But I guess this makes no sense since we have 1.1.0-2 in hardy
[10:55] <coNP[uni]> s/I have/I have seen/
[10:55] <coNP[uni]> ? gnome-schedule hardy
[10:55] <dholbach> weird
[11:05] <persia> coNP[uni]: That's just the process of education at work :)
[11:05] <coNP[uni]> persia: sure
[11:07] <\sh> jono, you are brave...cheering kubuntus day on planet.gnome ,-)
[11:07] <jono> \sh: :)
[11:24]  * persia grumbles about UTC+9 having more bandwidth than UTC-9, but the ML not being the appropriate place to complain about this.
[11:25] <TheMuso> heh
[11:26] <persia> I just don't like the phrase "The Western World" to mean "The northern hemisphere + Antipodes - central/south asia".
[11:29]  * TheMuso calls it a night re Ubuntu work.
[11:29] <persia> TheMuso: Good night.
[11:29] <TheMuso> persia: I'm not off to bed yet.
[11:29] <TheMuso> Just have had enough processing sponsors queue. :p
[11:30] <persia> TheMuso: heh.  Thanks for chasing that: I'm just getting started, and expect to find a significantly shorter list.
[11:30] <TheMuso> Yes. I've killed just about all the merges at least.
[11:31] <persia> Perfect.  That's one of the two classes I shy from :)
[11:31] <TheMuso> haha
[11:31] <TheMuso> Thats one of the classes I really don't mind doing.
[11:36] <persia> TheMuso: I just tend to either forget the -v, or get annoyed at the merger for not closing a couple other bugs while they are at it.  Saves grief for changelog readers, mergers, and myself if I don't touch them :)
[11:38] <LaserJock> argg, my brain is gonna explode
[11:38] <persia> LaserJock: Why?
[11:38] <persia> (aside from the hour)
[11:39] <LaserJock> it's 3:40 and I can't figure out why the heck my code isn't working
[11:39] <LaserJock> it's not getting to the else:
[11:39]  * persia suspects the code isn't working in part because it's 3:40
[11:39] <LaserJock> which is really weird cause it should get their the majority of the time
[11:39] <persia> LaserJock: reverse the sense of the check: most compilers optimise for if to be true by default anyway.
[11:41] <LaserJock> what the heck, I even took out the elif
[11:41] <BUGabundo> hi ppl
[11:41] <BUGabundo> do you need help with pidgin?
[11:41] <persia> Hi BUGabundo
[11:42] <BUGabundo> I would like to help making it v2.3.1
[11:42] <persia> BUGabundo: We don't really work on pidgin.  You might try #ubuntu-desktop.
[11:42] <BUGabundo> redirecting. thanks persia
[11:47] <LaserJock> ok, I'm doing something fundamentally wrong here
[11:47] <LaserJock> I flipped the check
[11:47] <LaserJock> but it will only go to the else: at the very end
[11:48] <LaserJock> I could scream
[11:49] <persia> LaserJock: Check your input.  You may find that you're being surprised.  Alternately, you may be transforming the data in a manner other than you expected.
[11:50] <LaserJock> hmm, perhaps it's some whitespace error
[11:50] <LaserJock> IndentationError: unexpected indent
[11:51] <\sh> use emacs...;)
[11:52] <persia> (and then, use lisp, so whitespace won't be as critical)
[11:52] <txwikinger2> hehe. and count the parenthesis ;)
[11:52] <LaserJock> ok, whitespace figured out
[11:53] <LaserJock> but it still won't go to the else:
[11:57] <LucidFox> TheMuso> qink has appeared in the Debian archive, so can be synced now
[11:57] <mruiz> hi all
[11:58] <LucidFox> hi mruiz
[11:58] <BUGabundo> hi mruiz
[11:58] <mruiz> hi LucidFox , BUGabundo :-)
[11:59] <LaserJock> you HAVE to be kidding me!!!!
[11:59] <LaserJock> the stupid else: wasn't tabbed properly and had a couple spaces
[12:00]  * LaserJock stabs python in the heart and cuts of it's head with his laser
[12:00]  * persia claims that syntactical markers should be visible
[12:01]  * pochu points persia to vim then ;)
[12:02] <persia> pochu: It's my preferred editor :)  (If only I had a close-brace key instead of a ^Z key)
[12:03] <\sh> fight against mcdonalds http://www.youtube.com/watch?v=pRv0WBOwxfo ;)
[12:04]  * \sh has too much time sitting around and doing nothing because nothing is what we do right now
[12:05] <TheMuso> Night folks.
[12:05] <persia> \sh: ?
[12:06] <\sh> persia, our jobs are done...and they don't want to send us home...:(
[12:06] <persia> \sh: Ah.  Pointful.
[12:07] <\sh> persia, so what should we do but surfing all the crappy video portals ,-)
[12:07] <persia> \sh: Do you actually want me to give you a suggestion?
[12:08] <\sh> persia, I'm bored so yes, try :)
[12:08] <persia> \sh: http://qa.ubuntuwire.com/uehs/no_updated.php
[12:08] <\sh> persia, this I can only do at home...I just don't have a machine anymore wich is powerful enough to compile :(
[12:08] <persia> (more points for longer time since last upload)
[12:08] <txwikinger2> \sh: fix some bugs
[12:09] <txwikinger2> there are lots of them available for pick up :D
[12:09] <Hobbsee> siretart: presuming you know about the mail interface to launchpad.
[12:09] <persia> \sh: That's fine.  Unlike bugfixing or security stuff, you don't need to compile to check the upstream, and get a candidate ready.  Mostly just a text editor.  For even easier things, try http://qa.ubuntuwire.com/uehs/no_watch.php
[12:09] <\sh> txwikinger, I want to ... I'll attend the pykde tutorial :)
[12:11] <txwikinger2> \sh: where?
[12:11] <txwikinger2> oh tonight?
[12:11] <\sh> txwikinger, #kuibuntu-devel @15UTC
[12:11] <mruiz> TheMuso, thanks for your comments and uploads :-)
[12:12] <\sh> txwikinger, it's kubuntu tutorial day :) see p.u.c :)
[12:12] <txwikinger2> well... I know.. I don't have a choice but to be there :P
[12:13] <siretart> Hobbsee: oh, it is documented
[12:13] <siretart> and actually working
[12:14] <Hobbsee> siretart: true
[12:15] <\sh> bbl
[12:19] <slytherin> Is anyone planning to package batik toolkit from apache?
[12:22] <persia> slytherin: The SVG library?
[12:23] <slytherin> persia: yes.
[12:23] <LaserJock> \o/, i did it
[12:23] <LaserJock> going to bed now, night/morning all
[12:23] <LaserJock> dang, 4:30 almost :(
[12:24] <persia> slytherin: I suggest you may want to try to to resolve the confusion inherent in bug #141212, bug #147818, and bug #150484
[12:24] <ubotu> Launchpad bug 141212 in j2se1.4-i586 "j2re1.4 etc cannot be installed non-interactively, which breaks buildds" [Undecided,New] https://launchpad.net/bugs/141212
[12:24] <ubotu> Launchpad bug 147818 in ubuntu "[needs-packaging] batik SVG lib" [Wishlist,Confirmed] https://launchpad.net/bugs/147818
[12:24] <ubotu> Launchpad bug 150484 in batik "batik has FTFBS forever" [Undecided,New] https://launchpad.net/bugs/150484
[12:25] <persia> To put it another way, it appears to be packaged, but doesn't work, and this isn't clear to people.
[12:25] <slytherin> persia: How about using icedtea for building?
[12:26] <slytherin> persia: or better use gcj
[12:27] <persia> slytherin: Maybe worth a try.  If you want to look at it, I'd suggest verifying that the source matches the needs packaging bug (and if it does, closing the needs-packaging as done), then trying to resolve the FTBFS by working around the library issue.  To start, assign yourself all three bugs.
[12:27] <persia> s/library/compiler/
[12:28] <persia> Err.  I'm full of mistakes right now: assign yourself the batik bugs, I don't expect the j2re1.4 bug can be resolved easily, and it's certainly not closely related.
[12:30] <slytherin> persia: Downloading the source. Let me check.
[12:31] <persia> slytherin: Thanks.  I suspect you'll make a few people happy.  Also, next time, try searching for the application name from https://bugs.launchpad.net/ubuntu/+bugs, which is where I found the three bugs.
[12:34] <slytherin> persia: I had no idea that the package was FTBFS for long time. And since it never ended up in the repos I assumed it was not packaged. :-)
[12:36] <persia> slytherin: Understood: it's an odd case.  Searching the bug reports usually gets something.  You might also try `rmadison possible-package-name` to check sources (or play with grep-dctrl)
[12:41] <mruiz> hi MOTUs! ... IDF is applying right now ?
[12:42] <mruiz> s/IDF/DIF
[12:43] <persia> mruiz: I haven't seen an annoucement, but likely
[12:44] <mruiz> I asked because I have some details to fix with 2 merges :-)
[12:44] <persia> mruiz: Well, you're officially late, so finish :)
[12:45] <persia> (but take time and care to do it right: no need to rush just because it's DIF)
[12:45] <Hobbsee> dholbach_: responded to your mail.
[12:47] <Sikon_Stargate> Hobbsee> slomo has asked me to ask buildd administrators to rerun failed builds of tomboy0.9.1-0ubuntu1
[12:47] <Sikon_Stargate> * tomboy 0.9.1-0ubuntu1
[12:48] <Sikon_Stargate> no idea why he couldn't do that himself, though
[12:48] <persia> Sikon_Stargate: Likely busy with something else (assuming you had a specific interest in tomboy)
[12:49] <Hobbsee> grumble.  MC council mail got moderated.
[12:49] <Hobbsee> Sikon_Stargate: hardy, presumably?
[12:50] <Hobbsee> hm, yes, seems so
[12:50] <Hobbsee> Sikon_Stargate: done
[12:51] <mruiz> TheMuso, any advance about bug #175966 ?
[12:51] <ubotu> Launchpad bug 175966 in endeavour "Please merge endeavour 2.8.4-1 (universe) from Debian (unstable)" [Undecided,In progress] https://launchpad.net/bugs/175966
[12:52] <slytherin> where can I find information about all the fields in control file?
[12:52] <pochu> slytherin: http://www.us.debian.org/doc/debian-policy/ch-controlfields.html
[12:53] <pochu> slytherin: new fields haven't been added yet (Homepage, Svn-*)
[12:53] <persia> mruiz: timezones are such you'll have a wait asking like that (UTC+11).  Try again?
[12:54] <mruiz> persia, then ?
[12:56] <persia> mruiz: As I've suggested before, it's best to ask the channel generally to get an answer, and people may be busy or asleep.  This is even true when a sponsor is working on a bug with you: generally others are happy to provide suggestions and advice, and the sponsors don't tend to mind if someone else sponsors (as long as they aren't currently in the middle of a compile).
[12:56] <persia> Err.  "as people may"
[13:03] <slytherin> persia: Say if I succeed in fixing FTBFS for batik, what do you suggest, upload the fixed package first and then upload latest version or directly upload latest version?
[13:03] <persia> slytherin: Unless there is some important reason to separate the two, I'd recommend only one upload.
[13:04] <DaveMorris> persia: that rhythmbox upload was meant for ppa(I emailed the uploaded and he confirmed it) so it can be nuked - http://revu.tauware.de/details.py?package=rhythmbox
[13:04] <slytherin> persia: The reason I am asking is that if I fix the build for current package and the patches are forwarded to debian then we can wait for some time for latest version to appear in debian and then sync.
[13:05]  * persia grumbles about asking the channel generally and archives it.
[13:07] <mruiz> then, I need a review for the bug #175966, please :-)
[13:07] <ubotu> Launchpad bug 175966 in endeavour "Please merge endeavour 2.8.4-1 (universe) from Debian (unstable)" [Undecided,In progress] https://launchpad.net/bugs/175966
[13:07] <persia> slytherin: We've passed the point where we wait for a sync (DebianImportFreeze).  If you think the current version is sufficient for hardy, just fix the FTBFS.  If there's some feature you think is critical for hardy, do the update (but explain why in the bug report).
[13:07] <persia> mruiz: Thanks.  Looking now.
[13:08] <persia> mruiz: Check the fourth paragraph under "Build, check, and report" in https://wiki.ubuntu.com/UbuntuDevelopment/Merging.  Looking at the debdiff...
[13:09] <slytherin> persia: Ok. I haven't yet checked latest version.
[13:10] <mruiz> persia, thanks for the modifications ...
[13:11] <persia> mruiz: debdiff looks sane.  I avoid merges, but I suspect someone would get to it before too long.
[13:13] <ScottK> dholbach_: Yes.  I did get some sleep, so I'm all the way up to really tired.
[13:16]  * persia asks someone with the ability to build large packages to take a look at bug #133888.
[13:16] <ubotu> Launchpad bug 133888 in wxwidgets2.8 "upgrade wxwidgets2.8 to the <IP_ADDRESS> release" [Wishlist,Confirmed] https://launchpad.net/bugs/133888
[13:22] <persia> Kmos: About Debian bug #455711: where the package has a watch file, this information is presented to the maintainers from http://dehs.alioth.debian.org/
[13:22] <ubotu> Debian bug 455711 in strongswan "New upstream version 4.1.9" [Wishlist,Open] http://bugs.debian.org/455711
[13:28] <mruiz> persia, then I need another comment to approve the upload?
[13:29] <persia> mruiz: No, one sponsor is enough.  You just need to catch someone who normally does merges (or wait for the queue to clear, when I might get to them, but I suspect the former will happen first).  Should happen with no further effort on your part within the next 12 hours or so.
[13:46] <persia> dholbach_: Please unsubscribe ubuntu-universe-sponsors and subscribe yourself when rejecting candidates.
[13:48] <slytherin> persia: need a bit help. I am getting following error even when the evrsion is available in ubuntu,
[13:48] <slytherin>   -> Considering build-dep libavalon-framework-java (>= 4.2.0-1) Tried versions:  -> Does not satisfy version, not trying
[13:49] <persia> slytherin: I'm not somebody who knows much about that.  You might ask others.  As generic advice, I'd suggest looking at the libavalon-framework-java package to see why it can't be satisfied.
[13:50]  * Hobbsee would expect teh fact that it's in multiverse has something to do with it.
[13:50] <Hobbsee> slytherin: what are you trying to build?
[13:50] <slytherin> Hobbsee: batik
[13:50] <persia> Hobbsee: Just for context, we've never had a successful build in Ubuntu.
[13:51]  * Hobbsee checks the build log
[13:51] <persia> Hobbsee: For more context, slytherin addressed that problem, and is looking at the next in the chain
[13:52] <slytherin> persia: Hobbsee: Ok. Found the problem. Actually I was first trying to build in gutsy in which avalon depends on kaffee. I guess I better build in hardy chroot
[13:52] <Hobbsee> you should *always* be doing FTBFS' to do with dependancies, etc, in a chroot.
[13:54] <slytherin> Hobbsee: You misunderstood, I am building in chroot (but of gutsy). Since the package will be fixed in hardy only I better try that chroot.
[13:55] <persia> slytherin: Once you get it working in hardy, it may be interesting to try to fix it in earlier releases, but hardy is definitely the first step.
[13:56] <slytherin> persia: Even if I fix it for gutsy, will it be accepted?
[13:56] <persia> slytherin: Once it is in hardy, you can apply for an SRU to the SRU team.  FTBFS bugs are often accepted, depending on the invasiveness of the changes.
[13:58] <dholbach> persia: which bug are you referring to?
[13:58] <dholbach> Hobbsee: great
[13:58] <dholbach> ScottK: I hope you'll have some time to relax a bit soon
[13:59] <persia> dholbach: bug #175802 and bug #175018 are the two I noticed, although I may be seeing a false pattern.
[13:59] <ubotu> Launchpad bug 175802 in gfceu "Sponsor gfceu_0.6.0-0ubuntu2" [Wishlist,Confirmed] https://launchpad.net/bugs/175802
[13:59] <ubotu> Launchpad bug 175018 in strongswan "strongswan: New upstream release 4.1.9" [Wishlist,In progress] https://launchpad.net/bugs/175018
[13:59] <dholbach> persia: OK, thanks for taking a look at them
[14:00] <persia> dholbach: No problems: it just seems odd to be reviewing something already rejected (I'm happy to override you sometimes, but neither of these were suitable for upload anyway)
[14:04] <dholbach> persia: yeah
[14:06] <ScottK> dholbach: Thanks.
[14:07] <txwikinger2> dholbach: Is there a Q&A session tomorrow again?
[14:07] <dholbach> txwikinger2: yeah, 13:00 UTC - we made it a fixed date
[14:07] <txwikinger2> Ah cool..
[14:08] <txwikinger2> I will put it into kAlarm ;)
[14:08] <dholbach> take a look at the header of https://wiki.ubuntu.com/MOTU
[14:08] <txwikinger2> Nice :)
[14:09] <txwikinger2> I guess I have to do something tonight then ;)
[14:10] <txwikinger2> The page has no green spots
[14:28] <nxvl_work> yesternay it was the debian freeze, did't it?
[14:28] <nxvl_work> oh no, it's today
[14:31] <mruiz> nxvl_work, https://wiki.ubuntu.com/HardyReleaseSchedule
[14:31] <nxvl_work> mruiz: i have just take a look in there, thnx
[14:31] <mruiz> nxvl, anytime
[14:37] <slytherin> persia: Hobbsee: any idea why libavalon is in multiverse?
[14:38] <Hobbsee> slytherin: probably due to the java it uses to build
[14:38] <Hobbsee> slytherin: the one that has the licence agreement needed
[14:38] <slytherin> Hobbsee: It uses gcj (java-gcj-compat)
[14:38] <persia> slytherin: You'll do best to ask generally, rather than specific people.  This is especially true as it gets late on this side of the globe.  What license does libavalon have?
[14:39] <slytherin> persia: Apache and as I just pointed out it uses gcj to build.
[14:40] <persia> slytherin: Next, check the dependencies.  Perhaps it relies on something else unfree.  If there's nothing wrong, then it's likely there for historical reasons, and it's worth asking for promotion.
[14:40] <slytherin> hmm
[14:40] <Hobbsee> slytherin: because of  j2re1.4 and j2sdk1.4
[14:40] <Hobbsee> whcih are pulled in as build deps
[14:40] <persia> Hobbsee: java-gcj-compat, no?
[14:41] <geser> slytherin: avalon-framework was in the past in Debian contrib
[14:41] <Hobbsee> persia: i don't know the specifics of java, i just know that anything that ends up build-depping on those packages will send it to multiverse.
[14:41] <slytherin> Hobbsee: no, java-gcj-compat pulls gcj. persia: it depends on  nothing than java.
[14:42]  * Hobbsee is just looking at the existing build log for it.
[14:42] <slytherin> geser: Right but is has moved out of contrib for long time. SO I guess it is time to move it to universe.
[14:42] <geser> slytherin: nobody found out till now that it moved to Debian main and can also move from multiverse to universe
[14:42] <geser> slytherin: please file a bug
[14:42] <persia> slytherin: Again, you're asking non-ideal people :)  We'll answer, but aren't the best.  What about ant-optional,, liblog4j1.2-java,, liblogkit-java,libxalan2-java, and junit?
[14:43]  * persia defers to geser
[14:43] <dholbach>  * Riddell bigs up Kubuntu Tutorials Day in half an hour in #kubuntu-devel https://wiki.kubuntu.org/KubuntuTutorialsDay
[14:43]  * dholbach passes on the message :)
[14:43] <slytherin> persia: Do you suggest that I create a page listing java based packages which should be moved to universe? I will then file a tracking bug perhaps.
[14:44] <slytherin> persia: I just found this because batik depends on avalon and I didn't have multiverse enabled in my pbuilder.
[14:44] <persia> slytherin: There's a page on the Debian wiki showing the current status of moving things to main.  If you check that against Ubuntu, and find a bunch of things that should be in universe, file a bug with a task for each package, and describe the reasoning to move to universe, and subscribe the sponsors queue (but as I've said, others may answer better than I)
[14:45] <persia> slytherin: That's actually really helpful.  If it's free, it shouldn't be in multiverse.
[14:46] <slytherin> persia: I will start with avalon and other dependencies of batik for now. :-)
[14:55] <slytherin> geser: should I file bug against source package or binary packages?
[14:55] <persia> slytherin: Best to ask the channel generally, and source
[14:56] <slytherin> persia: Sorry, forgot that.
[15:00] <slytherin> Done. bug 176139
[15:00] <ubotu> Launchpad bug 176139 in avalon-framework "Move package to universe" [Undecided,New] https://launchpad.net/bugs/176139
[15:00] <persia> slytherin: Are there any other packages that you will need to move for your batik project?
[15:03] <slytherin> persia: None. Just checked. All others are in main or universe.
[15:04] <Hobbsee> you can still get it sponsored, even if it's in multiverse
[15:04] <zul> morning
[15:04] <persia> slytherin: In that case, I'd recommend adjusting the description to use "please", as this will be a request passed to the archive admins, and subscribing ubuntu-universe-sponsors to get a sponsor to confirm and submit to the archive-admins.
[15:04] <persia> Hobbsee: But it doesn't need to be in multiverse.
[15:04] <Hobbsee> persia: this is true
[15:05] <slytherin> persia: will do.
[15:05] <persia> Hobbsee: So, if avalong gets moved first, batik doesn't need to be moved later :)
[15:05] <Hobbsee> persia: both will need to be moved.
[15:05]  * persia really ngeeds to replace the ng key with a normal "n" key
[15:06] <persia> slytherin: You might want to add a batik task to that, with your batik patch.
[15:07] <geser> slytherin: acked bug #176139 and subscribed ubuntu-archive
[15:07] <ubotu> Launchpad bug 176139 in avalon-framework "Please move package to universe" [Wishlist,Confirmed] https://launchpad.net/bugs/176139
[15:08] <slytherin> persia: Let me first build batik. The page on Debian wiki says there are some problems related to SWING/AWT events and hence the package is still not in main in Debian.
[15:08]  * slytherin will be back in 5 miinutes
[15:09] <persia> slytherin: In that case, you'll want a new bug for batik (especially as the other has already been passed to the archive-admins)
[15:12]  * RainCT is looking for something fast to fix
[15:12] <persia> RainCT: watch files
[15:13] <persia> RainCT: Java migrations to main
[15:13] <persia> s/main/universe/
[15:14]  * RainCT has no idea about java
[15:14] <RainCT> persia: I'll fix some watch file then. thanks :)
[15:15] <persia> RainCT: There's also 216 source packages left in universe with "ubuntu" in the version but no "ubuntu" in the maintainer.
[15:16] <geser> RainCT: you could also look at unmet deps
[15:16]  * persia notes that anyone else interested in little projects might find any of the above interesting as well
[15:16] <persia> geser: Doesn't that usually take a compile?  Easy, but not always fast.
[15:16] <RainCT> persia: those are interesting heh. is there a list of them?
[15:17] <persia> RainCT:  `wget -O - http://archive.ubuntu.com/ubuntu/dists/hardy/universe/source/Sources.gz| gunzip | grep-dctrl -sPackage,Maintainer -FVersion ubuntu  | grep-dctrl -sPackage -FMaintainer -v -n ubuntu | sort -u`
[15:18] <RainCT> thx
[15:19] <persia> RainCT: As with anything else, it's worth combining things: maybe watch file + unmetdeps + maintainer change + a couple easy bugs on the package from LP.
[15:20] <geser> persia: doesn't (nearly) every fix need a compile test?
[15:21] <persia> geser: Except for watch files or the java migrations, I'd say yes, and even in those cases, it's a good idea.  My error.
[15:23] <geser> ok, those fixes doesn't necessary need a build test
[15:23] <CarlFK> apt-get source ubiquity, change files.  how do I make a patch?  (hoping for something like svn diff)
[15:25] <bddebian> Heya gang
[15:28] <persia> CarlFK: Check for a patch system, but assuming you've made the patch in the preferred manner, debuild -S; $TEST_BUILD_PROCEDURE; $TEST_PROCEDURE; debdiff ubiquity_1.7.1.dsc ubiquity_1.7.2.dsc
[15:28] <persia> !patch
[15:28] <ubotu> Patches are files describing the changes in code to achieve some results.  There are a number of ways these can be produced, but https://wiki.ubuntu.com/Bugs/HowToFix and https://wiki.ubuntu.com/PackagingGuide/PatchSystems may provide some useful guidelines.
[15:29] <geser> Hi bddebian
[15:29] <CarlFK> thanks
[15:30] <bddebian> Heya geser
[15:30] <slytherin> damn, batik does not build with free java
[15:31] <persia> slytherin: Not even iced tea?
[15:32] <slytherin> persia: Will have to check. Sources contain some import statements of the form com.sun.image.codec.jpeg.JPEGEncodeParam
[15:33] <persia> slytherin: That might require deeper investigation, but if you find a free implementation, patching the sources is a possible solution.
[15:34] <slytherin> persia: Will check if gcj implements image classes.
[15:35] <persia> slytherin: Also check iced-tea.  It's less ideal due to greater variance from Debian, but is at least universe.
[15:35] <slytherin> will do. don't worry I am a java developer so I can put more brain in this. :-)
[15:40] <nxvl_work> !sync
[15:40] <ubotu> Sorry, I don't know anything about sync - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[15:40] <nxvl_work> !SyncRequest
[15:41] <ubotu> Sorry, I don't know anything about syncrequest - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[15:41] <persia> nxvl: Either use requestsync, or open a bug including the version to be synced, an explanation of why it should be synced, and the changelog since the last Ubuntu upload, and subscribe the sponsors queue.
[15:44] <mruiz> hi all, I need a second opinion for the bug #175966, please. thanks
[15:44] <ubotu> Launchpad bug 175966 in endeavour "Please merge endeavour 2.8.4-1 (universe) from Debian (unstable)" [Undecided,In progress] https://launchpad.net/bugs/175966
[15:45] <persia> mruiz: Firstly, why do you need a second opinion?  Secondly, as it's in the sponsors queue, it should get uploaded or commented in due time.
[15:46] <nxvl_work> can someone please give a look at bug #174593 and sponsor it?
[15:46] <ubotu> Launchpad bug 174593 in gramps "merge gramps 2.2.9-2 from debian sid" [Wishlist,Confirmed] https://launchpad.net/bugs/174593
[15:47]  * persia reemphasizes that advertising bugs in the sponsors queue is unlikely to draw much focus.  IF you've a question about your implementation, or want to better understand a sponsor comment, it's useful.  If you just seek an upload, please be patient.
[15:47]  * RainCT can't figure out why this isn't working (watch)  http://www.exit1.org/download/ff http://www.exit1.org/packages/Gtk2-Ex-FormFactory/dist/Gtk2-Ex-FormFactory-(.*).tar.gz
[15:48] <nxvl_work> persia: i know, i was only remaining the sponsors, if there is one with some free time, so it can upload it before the freeze, i'm not impacient :D just trying the merge to be done :D
[15:49] <RainCT> nxvl_work: afaik it can still be uploaded after the freeze :)
[15:49] <persia> nxvl_work: The freeze is already in place, but any of the sponsors can (and likely will) grant a freeze exception.
[15:51] <persia> RainCT: Because "http://www.exit1.org/packages/Gtk2-Ex-FormFactory/dist/Gtk2-Ex-FormFactory-(.*).tar.gz" doesn't work very well as a regex deliminated by '/'.  Either escape the '/' characters, or find a shorter string (e.g. /.*Gtk2-Ex-FormFactory-([\d\.]*).tar.gz/)
[15:51] <geser> nxvl_work: Where is the mentioned "- Removed dh_python from debian/rules" change? I can't find it in the debdiff
[15:51] <persia> s/deliminated/delimited/
[15:52] <nxvl_work> geser: ups..
[15:52] <nxvl_work> geser: :D
[15:53] <nxvl_work> i make a mistake applying the changes i have been working on and forgot to recheck
[15:53] <nxvl_work> making a new one
[15:54] <RainCT> persia: ah. this works :)   http://www.exit1.org/download/ff (?:.*)Gtk2-Ex-FormFactory-([\d\.]*).tar.gz
[15:54] <RainCT> thanks
[15:54] <persia> RainCT: No problem.  Yours is much better than mine as well :)
[15:54] <nxvl_work> ok, so now that we are on freezy, what is the next step
[15:55] <persia> nxvl_work: How do you mean?
[15:55] <mruiz> persia, I didn't know about exceptions for DIF
[15:55] <nxvl_work> which are the most important bugs on this step of the development circle
[15:55] <nxvl_work> geser: fixed
[15:55] <persia> nxvl_work: Current focus is integration: find things that don't build, aren't build from source, don't work together well, etc.
[15:56] <nxvl_work> persia: so, the main site to check now is ubuntuwire?
[15:57] <persia> nxvl_work: LP still has thousands of bugs waiting for attention, so it's worth looking there as well.
[15:57] <RainCT> can debhelper be a Build-Depends-Indep?
[15:57] <geser> RainCT: no, unless you don't need it in clean
[15:58] <persia> mruiz: Policy on universe DIF freeze is not cast in stone.  Current discussion can be found in the thread starting https://lists.ubuntu.com/archives/ubuntu-motu/2007-December/002888.html
[15:58] <nxvl_work> what is the Build-Depends-Indep field for?
[15:58] <nxvl_work> is the only one on control i don't understand
[15:58] <persia> nxvl_work: packages needed to build architecture:all binary packages
[15:59] <RainCT> geser: there's dh_* stuff in clean:. so should I change it to a Build-Depends?
[16:00] <geser> yes
[16:00] <RainCT> ok, thanks
[16:00] <geser> linda/lintian should afaik complain
[16:02] <persia> RainCT: If you're working on a package not in Debian, and you feel like fixing all the lintian & linda items, that'd be nice too.
[16:02] <RainCT> and is it encouraged to bump it's version from >= 4.0.0 to >= 5.0.38 on the way?
[16:02] <persia> RainCT: Only if you need features from the newer debhelper
[16:07]  * persia doesn't understand why moderation is required for mail to MC
[16:11] <RainCT> well.. sponsor queue got 2 items longer.. I've to go now :)
[16:11] <geser> persia: are you perhaps subscribed with the wrong e-mail address?
[16:12] <persia> geser: That might be it (although I'm not sure it's that I'm subscribed with the wrong address as that I may have sent from the wrong address)
[16:15] <mok0> hi
[16:20] <bddebian> hello mok0
[16:20] <bddebian> Is anyone super familiar with help2man?
[16:24] <mok0> bddebian: I've used help2man. What's up?
[16:24] <mok0> Lemme guess: it doesn
[16:24] <mok0> t work :-)
[16:24] <bddebian> Is there a way to get it to generate without a -version?
[16:24] <mok0> Hmm. Explain
[16:25] <bddebian> I can override the help option with --help-option=-h but there is nothing in the package for --version so I can't use --version-option :-(
[16:26] <mok0> In my version of help2man there is...
[16:26] <mok0> -v, --version-option=STRING  version option string
[16:26] <bddebian> mok0: Aye, help2man has that but the package I'm trying to create a manpage for (xbattle) has no option for displaying the version
[16:27] <mok0> bddebian: what is it you want to do, then?
[16:27] <bddebian> So I would like help2man to ignore version entirely
[16:27] <mok0> bddebian: you have to edit it into the manpage manually (eeech)
[16:28] <mok0> bddebian: why don't you just give it the help option, then
[16:29] <bddebian> mok0: I just tried that but then I get a shitload of duplicated entries :-(
[16:29] <mok0> Arrgh. Isn
[16:29] <mok0> isnt there some other option that gives no output?
[16:31] <mok0> bddebian: Perhaps you can help me with advice
[16:32] <bddebian> I can't find anything that gives no output :-(
[16:33] <mok0> I am working on the merge of xtide, but the debian maintainer didn't do a very good job of it. For the program to run, it needs some aux. data files that are not in the package. So I can (1) include a script that gets the data and unpacks it, or (2) create another package with the data only. What should I do?
[16:34] <persia> mok0: How big is the data?  Is the data architecture dependent?  Is the package architecture dependent?
[16:35] <mok0> persia: It's pretty big, maybe 30Mb
[16:35] <mok0> 37 to be exact
[16:35]  * persia waits for the other two answers
[16:36] <mok0> the data is not arch dependent
[16:36] <mok0> the program is an ordinary X program
[16:37] <bddebian> Is the data in the package and the maintianer just didn't include another binary package for it?
[16:37] <bddebian> Or are there any license issues?
[16:37] <mok0> bddebian: no, the data is not in the package. The program starts, but shows a nearly blank window, and there is only one location for which to show the tide
[16:38] <mok0> the world map is blank because there is no shoreline data
[16:38] <persia> mok0: Is the data in the source (upstream)?
[16:38] <white> Fujitsu: are you happen to be at the miniconf?
[16:38] <mok0> persia: you can get it from upstreams home page. Some of the data is in the public domain.
[16:39] <mok0> persia: some data is available that is not. I would choose the PD stuff of course
[16:39] <persia> mok0: OK.  Just to make sure I understand, the arch;any xtide binary package doesn't currently work very well because it has no data.  Upstream provides 37MB of data with reasonably free license available in a separate download, but this data is not currently packaged.  Is this correct?
[16:40] <mok0> persia: yes
[16:40] <mok0> persia: the program installs itself in the menu, so it is tempting to run for a user exploring the system
[16:41] <mok0> persia: but pretty boring without data
[16:41] <persia> mok0: Check with the debian maintainer.  If they are currently working on packaging that, it may be worth waiting a bit, and asking for a sync later (yes, DIF exception, but generally good).  If they are not working on it, package it, set a recommends: from xtide, and pass it to the Debian maintainer for consideration (most importantly the orig.tar.gz)
[16:42] <mok0> persia: sounds like a reasonable idea
[16:43] <mok0> persia: You'd almost think that the debian maintainer had never actually run the program :-P
[16:44] <bddebian> It's possible :-)
[16:45] <mok0> Actually, that ought to be a requirement in the packaging guidelines: you need to run the program and check that it works as intended!
[16:45] <persia> mok0: That's currently considered best practice
[16:46] <mok0> I haven't run into that myself, since I've only packaged programs that I actually use myself
[16:47] <slytherin> persia: Sorry, batik depends on some image processing apis which are available only in Sun Java/Jre. :-(
[16:48] <persia> slytherin: In that case, go ahead and get it working in multiverse
[16:48] <slytherin> persia: How? One can not install sun-java non-interactively
[16:49] <persia> slytherin: Can you confirm it builds properly when built that way, and can you confirm it works properly when so built?
[16:49] <bddebian> You can't afaik because it ask you to accept the license
[16:49] <mok0> bddebian: I was sure the problem you had with help2man was another one, because it doesn't work if the help and version info is written to stderr :-/
[16:50] <mok0> bddebian: I have a little wrapper script to help with that
[16:50] <bddebian> Yeah, it blows.  I'm hacking it up manually
[16:50] <mok0> bddebian: You know about asciidoc?
[16:51] <slytherin> persia: I will try building and running it standalone but then what is next step? It won't build in chroot
[16:51] <persia> slytherin: Even if you log into the chroot?
[16:52] <slytherin> persia: That way I will be able to do. Please tell me what all things I should try. I will be offline in 5 minutes and will try all these things tomorrow.
[16:53] <persia> slytherin: I couldn't possibly.    Find out the minimal set of requirements to do so.  Document everything, and submit a bug to the sponsors.
[16:54] <slytherin> persia: Ok. That is the best I can do.
[16:54]  * persia wishes jdstrand luck, and hopes he'll find time to help with MOTU-swat as well
[16:56] <slytherin> persia: Leaving now. See you (or rather bug you) tomorrow. :-)
[16:56] <persia> slytherin: You'll get better responses (especially about this) by asking generally for assistance.
[16:57] <slytherin> sure.
[17:02] <geser> persia: are you going to ask jdstrand about his plans in MOTU like work in motu-swat or should I?
[17:03] <persia> geser: I'm neither sponsor nor MC, and I don't have community objection, so I don't feel I have voice in this.  Please ask.
[17:51] <asac> RAOF: when back could you please ping me in #ubuntu-mozillateam channel to talk about miro?
[18:00] <tsmithe> are there any examples of get-orig-source rules that are well known that i can check out? mscore has to repack a bzip2'd tarball and remove some files, and add dfsg and it's going to look nasty...
[18:04] <persia> tsmithe: There's some examples in the repacking the tarball section in the wiki packaging guide, but nothing quite that complex.
[18:05] <tsmithe> i'll check it out
[18:05] <persia> tsmithe: I'd think you'd want a four line rule: unpack, clean, rename, pack
[18:06] <persia> (or, maybe 5 or 6 if you want to add some debhelper calls to do things like move to the right directory, etc.)
[18:07] <tsmithe> righty
[18:07] <tsmithe> thanks
[18:07] <persia> tsmithe: Thanks for including the rule.
[18:07] <tsmithe> it's good practice :)
[18:07] <persia> tsmithe: By the way, what are you planning to use for the sounds?  freepats?
[18:08] <white> StevenK: ha, take this :)
[18:08] <white> StevenK: http://people.debian.org/~weasel/weboftrust/debian/20070813/output/msd-sorted.html
[18:08] <white> StevenK: look for stevenk and for white :P
[18:09] <tsmithe> i'm not sure yet. did you get my comment about the fluidsynth dev package shipping a rather strange sounding (but obviously free) font? that could be moved out into the main package, rather than the development one, i suppose, and i could point to that.
[18:09] <tsmithe> it's installed to /usr/share/doc/libfluidsynth-dev/examples/example.sf2
[18:09] <tsmithe> persia, ^^
[18:09] <persia> In -dev?  That's just odd.
[18:09] <tsmithe> i'm also a tad annoyed that pulse is on by default in hardy, and as it doesn't support mmap access, mscore (or any fluidsynth application) will fail
[18:10] <tsmithe> persia, that's what i thought, but there it is
[18:11] <blueyed> interdiff does not get used for packages without orig.tar.gz (native packages). Is there a way to compare two native tar.gz archives, so that a -p1 compatible diff gets created?
[18:12] <blueyed> See bug 136863 - I would have a patch for debdiff, so if somebody could confirm the bug, please.. :)
[18:12] <ubotu> Launchpad bug 136863 in devscripts "debdiff: make debdiff "patch -p1" compatible, when there are no diffs" [Wishlist,New] https://launchpad.net/bugs/136863
[18:12] <persia> tsmithe: unfortunately, with that license, it's multiverse, so fluidsynth-dev isn't in the right place.  On the other hand, I think Ian has a few fonts, and that's a loose license.
[18:14] <tsmithe> persia, which is multiverse?
[18:14] <tsmithe> libfluidsynth-dev is in universe
[18:14] <tsmithe> and i can't find any mention of example.sf2 in the copyright file
[18:15] <persia> tsmithe: The soundfont.  It's in the wrong component: cannot be modified except for private use.
[18:15] <persia> tsmithe: sf2/COPYRIGHT in the source
[18:16] <tsmithe> ah. damn; i don't have the sources here, so i didn't see that.
[18:16] <tsmithe> hmm. who is Ian?
[18:16] <persia> tsmithe: The font author: http://www.geocities.com/SiliconValley/Campus/8645/sf2.html
[18:19] <tsmithe> right, but none of those have source... in fact, nor does example.sf2, but as that's already disregarded..
[18:20] <persia> tsmithe: What's the source of a soundfont?  A bunch of WAV files?
[18:21] <tsmithe> well, yes. that's what i would have thought. however, i'm not totally sure what the definition of "source" is when "sources" are required, nor am i certain of how stringent those requirements are.
[18:22] <persia> tsmithe: "source" is the preferred format for editing.  Stringency is based on the intepretation of the preferred format for editing by the archive-admins (or Debian ftp-masters) when the package is first uploaded, and later tracked as bug reports (which may get a package moved to multiverse if not addressed, (or possibly removed from the archive if GPL))
[18:25] <tsmithe> so we are agreed that a sf2 file in its native state is acceptable?
[18:26] <persia> tsmithe: Sure.  Lets call it a swami file :)
[18:27] <bddebian> heh
[18:27] <tsmithe> hehe, if you say so :)
[18:27] <tsmithe> now i've just got to find some nice distributable soundfonts
[18:28] <persia> tsmithe: More problematically, all the GS or GM sets I can find are non-commercial, and some (like Vintage Dreams 2.0 Waves) are unmodifiable except for personal use.
[18:28] <tsmithe> yeah, it's not cool.
[18:29] <persia> tsmithe: From what I understand, it's because people are just grabbing random samples that they like, rather than resampling everything.  The alternative is about a week of studio time, with a good session team, and a huge instrument rental budget.
[18:30] <tsmithe> hmm. i wonder if i could get it done at school..
[18:30] <tsmithe> we are a music college..
[18:31] <persia> tsmithe: You've probably access to all the right patches, and you can offer publication to anyone who wants to help (everlasting fame as the $instrument on the first completely free soundfont)
[18:32] <persia> s/patches/patch sources/
[18:32] <tsmithe> what exactly is a patch source?
[18:35] <persia> tsmithe: In this context, a "patch" would be a set of samples to represent a virtual instrument.  You'd want to record each note, variations between notes, variations within a note, etc.  Then you assemble these into a patch.  A soundfont contains a bunch of patches (one for each instrument), which can be loaded into your sampler (e.g. fluidsynth).   Any news on bug 156210? :)
[18:36] <ubotu> Launchpad bug 156210 in virtualbox-ose "Please update Virtualbox to 1.5.2" [Undecided,Confirmed] https://launchpad.net/bugs/156210
[18:36]  * persia dislikes buffers "get a audio stream."
[18:37] <tsmithe> ah :)
[18:37] <tsmithe> and i'd have to do this for each GM instrument?
[18:37] <tsmithe> where's a list of those?
[18:38] <persia> GM is the minimal set, GS is the common set (and standard in XP).  XG is the Yamaha extensions to that GS.  Modern samplers have > 1000 patches, but that's more than one needs as a base.
[18:38]  * tsmithe chews lip
[18:38] <persia> tsmithe: Wikipedia has an entry on GM at http://en.wikipedia.org/wiki/General_MIDI
[18:38] <tsmithe> got there :)
[18:40] <tsmithe> i'm not sure we could do the helicopter, but i'm sure we could do the rest
[18:40] <tsmithe> although...
[18:40]  * tsmithe imagines hiring a helicopter just to get a patch
[18:41] <persia> tsmithe: http://en.wikipedia.org/wiki/Roland_GS is the extras you probably want.  XG would be nifty, but almost nobody supports it other than Yamaha.
[18:44] <tsmithe> right, i'll have a chat tomorrow
[18:44] <tsmithe> now, back to get-orig-source
[18:44] <persia> blueyed: You might consider using filterdiff --strip to achieve that, rather than sed.
[18:45] <dholbach> hey blueyed
[18:45] <blueyed> persia: actually I've now patched debdiff (I did not remember having used the sed snippet too often :D)
[18:45] <blueyed> Hi dholbach
[18:46] <persia> blueyed: I saw the bug, I was just thinking of using something in patchutils rather than sed, as that way debdiff isn't reponsible for how it works, only calling it properly.
[18:47] <persia> tsmithe: Good luck :)
[18:47] <blueyed> persia: debdiff does not call sed.. Do you think the debdiff script should rather use filterdiff --strip, instead of doing it in perl?
[18:47]  * persia reads the bug again
[18:48] <blueyed> persia: read the debdiff/patch. It could be done with filterdiff, too - of course. I did not know about it though.
[18:48] <blueyed> ..just like debdiff uses interdiff for non native packages. But the current patch will work without filterdiff installed.
[18:49] <persia> blueyed: Ah.  I was reading the bug, not the patch.  That seems sane.
[18:50] <blueyed> persia: I've filed the bug some time ago already, but my debdiff for meta-gnome2 reminded me of it.. :)
[18:51] <jdstrand> persia: thanks!
[18:52] <persia> blueyed: Now that there is a patch, it's more likely to happen.  Personally, for that deep layer stuff, I tend to submit the patch to Debian, just in case.  Sometimes even the main sponsors don't like to make changes in the tools we use so often.
[18:53] <blueyed> persia: I'm looking already at the debian devscript bugs.. will try to link/forward it.
[19:01] <tsmithe> can someone tell me why make thinks there is "nothing to be done" for http://paste.ubuntu-nl.org/48125/ ?
[19:03] <persia> tsmithe: is get-orig-source .PHONY?
[19:03] <tsmithe> yes
[19:04] <persia> OK.  You don't need all the &&\ as make automatically assumes that (although you will need more frequent references to ../ without it)
[19:05] <tsmithe> ok then. i thought it'd make life easier if i could cd to a directory and assume i'd stay there :)
[19:05] <persia> Line 8 should be find --name *sf2 -exec rm {} +
[19:06] <tsmithe> ok. find has always confused me, and i've read the manpage a number of times
[19:06] <persia> tsmithe: Sure, but it breaks the "debian/rules is not a shell script" best practice
[19:06] <tsmithe> oh ok then
[19:08] <persia> OK.  If it's .PHONY, I have no idea why it would report "Nothing to be done".  The dependencies of .PHONY should always run.
[19:10] <Ubulette> we have two venkman in hardy
[19:11] <Ubulette> !info venkman hardy
[19:11] <ubotu> Package venkman does not exist in hardy
[19:11] <Ubulette> damn, this is still broken
[19:13] <persia> Ubulette: mozilla- and xulrunner-1.9- ?
[19:13] <Ubulette> yep
[19:13] <persia> Ubulette: Which should remain?
[19:14] <Ubulette> the one in xul is native and is in the (new) target dir
[19:14] <persia> Ubulette: Then file a bug requesting the archive admins to remove mozilla-venkman from hardy and add it to the blacklist.  Explain why it shouldn't be in Ubuntu in the description, and subscribe the sponsors queue.
[19:43] <tsmithe> in http://paste.ubuntu-nl.org/48137/ why wouldn't make wait for uscan to have finished?
[19:44] <tsmithe> the line works in the shell..
[19:47] <Ubulette> you're confusing make variables and shell variables
[19:49] <Ubulette> and iirc, get-orig-source should work from anywhere so starting with "cd .." makes me think will not
[19:49] <Ubulette> +it
[19:50] <soren> "cd .." can never fail..
[19:51] <Ubulette> please re-read
[19:51] <Ubulette> the "work from anywhere" part
[19:51] <tsmithe> anywhere is irrelevant
[19:51] <tsmithe> it just wants to work in the directory above current, to avoid clutter
[19:52] <Ubulette> isn't debian policy saying otherwise ?
[19:52] <tsmithe> i am following the example at https://wiki.ubuntu.com/PackagingGuide/Examples/ChangingTheOrigTarball for using a watch file
[19:52] <tsmithe> Ubulette, is it?
[19:53] <soren> "This target may be invoked in any directory, and should take care to clean up any temporary files it may have left."
[19:54] <soren> From "4.9 Main building script: debian/rules"
[19:55] <tsmithe> thank you. it will work "invoked in any directory" and will "clean up any temporary files"
[19:57] <tsmithe> doing echo $$(uscan --force-download --dehs --destdir .. | sed -n 's/.*<upstream-version>\(.*\)<\/upstream-version>.*/\1/p') works, however
[19:57] <tsmithe> (in the makefile)
[19:58] <tsmithe> it does seem to be waiting correctly, just not filling the variable...
[19:58] <Ubulette> $(shell uscan ...)
[19:59] <Ubulette> $$(uscan ...) is just make-ified shell
[20:00] <Ubulette> and as I said, your $version is a shell variable, it will be lost the next line
[20:00] <Ubulette> rewrite as:
[20:00] <Ubulette> get-orig-source: version = $(shell something)
[20:00] <Ubulette> get-orig-source:
[20:00] <gouki> nmap 4.50 is out! :)
[20:00] <Ubulette>       something else using $(version)
[20:01] <tsmithe> Ubulette, thanks :)
[20:03] <Ubulette> tsmithe, have a look at http://codebrowse.launchpad.net/~mozillateam/seamonkey/seamonkey-1.1.dev/files
[20:03] <Ubulette> at the bottom of debian/rules
[20:05] <Ubulette> mine is complex, with embedded tarball + clean up and all, but you get the idea
[20:06] <tsmithe> Ubulette, yeah. that's very helpful. thank you very much. however, i'm now getting the error "commands commence before first target."
[20:06] <tsmithe> they don't seem to, and i think i've formatted the line correctly.
[20:06] <Ubulette> plz pastebin it
[20:07] <tsmithe> http://paste.ubuntu-nl.org/48140/
[20:07] <Ubulette> you need two lines
[20:08] <tsmithe> oh right, i see now :)
[20:08] <Ubulette> http://paste.ubuntu-nl.org/48141/
[20:08] <tsmithe> yep, thank you again :)
[20:10] <effie_jayx> can anyone point me towards a simple merge ?
[20:16] <tsmithe> yay my first ever get-orig-source rule and it works!  I'd like the mercury package working, and I'm willing to do at least part of the work myself.
[20:31] <geser> Iwanowitch: Hard to say, it depends how much time you need to learn the packaging basics, how complex the package is, how often upstream releases new versions (if you want to always have the latest versions), how many bugs the package has, etc.
[20:31] <mruiz> where can I find information to help with FTBFS bugs?
[20:32] <Gunirus> otu
[20:32] <tsmithe> persia, on revu for mscore: "11) Missing copyrights on the demos: they should be GPL or explicity PD"
[20:32] <geser> mruiz: which information do you look for?
[20:32] <tsmithe> persia, what makes you think they aren't copyright Werner Schweer, like most of the rest of the package?
[20:32] <Iwanowitch> Yeah, I suppose so... I'll think about it and try some stuff before I'm asking more wide-open questions.
[20:33] <geser> mruiz: there is http://qa.ubuntuwire.com/ftbfs/ which lists all problems and is currently updated once daily, so you need to check if the display data is still accurate
[20:36] <mruiz> hi geser ... is difficult to solve these problems?
[20:37] <geser> mruiz: it depends on the problem :)
[20:37] <geser> mruiz: some are easy as the only problem was that the packages were build in the wrong order
[20:37] <geser> mruiz: fixing some bashism in the packaging is usually also quite easy
[20:38] <geser> but there are also packages where some deeper knowledge is needed
[20:39] <geser> mruiz: e.g. http://launchpadlibrarian.net/10553993/buildlog_ubuntu-hardy-i386.whizzytex_1.3.1-1_FAILEDTOBUILD.txt.gz is quite easy
[20:40] <mruiz> geser, can you guide me with this one?
[20:40] <geser> mruiz: you need to check that it builds now and ask an build-admin for a give-back (I usually ask pitti for give-backs)
[20:40] <nixternal> w/o scrolling up...I take it there is an issue with the main repos? pbuilder keeps crashing out on trying to update for hardy as well as tryinging to build for hardy
[20:42] <geser> mruiz: sure
[20:43] <mruiz> geser, I'm downloading the source...
[20:44] <mruiz> nixternal, I'm updating my hardy pbuilder without problems
[20:44] <nixternal> hrmm
[20:44] <nixternal> 404 Not Found [IP: <IP_ADDRESS> 80]
[20:45] <mruiz> sorry, nixternal I got this error: Some packages could not be installed. This may mean that you have
[20:45] <mruiz> requested an impossible situation or if you are using the unstable
[20:45] <mruiz> distribution that some required packages have not yet been created
[20:45] <mruiz> or been moved out of Incoming.
[20:45] <mruiz> The following information may help to resolve the situation:
[20:45] <mruiz> The following packages have unmet dependencies:
[20:45] <mruiz>   aptitude: Depends: libapt-pkg-libc6.6-6-4.5 but it is not installable
[20:45] <mruiz> E: Broken packages
[20:45] <nixternal> that be the one that crashes on update
[20:45] <nixternal> and all of my deps from main during a build are crashing out
[20:47] <mruiz> geser, I'm ready
[20:47] <geser> in this case (whizzytex) all you need to test is if the package builds (in a hardy pbuilder)
[20:49] <tsmithe> if there are pdfs without sources in my package, do i have to remove them to comply with dfsg?
[20:50] <geser> iirc yes
[20:50] <TheMuso> Hey folks.
[20:51] <geser> Hi TheMuso
[20:51] <mruiz> hi TheMuso
[20:52] <nxvl_work> whet is the feature freezy about?
[20:52] <bddebian> Hi TheMuso
[20:52] <nxvl_work> i mean, whats the goal on this part of the circle
[20:52] <nxvl_work> TheMuso: hi!
[20:56] <mruiz> TheMuso, I have a question about mailping... the original merge changelog looks strange for me:  http://paste.ubuntu-nl.org/48145/
[20:58] <TheMuso> mruiz: Whats happening is MoM and perhaps DaD think there is a nwer version, which there is. But, when the merge is done, I think the merging realizes that the ubuntu version is newer than the Debian version.
[20:58] <TheMuso> mruiz: As I said, use dpkg -=-compare-versions to see what I mean.
[20:59] <CheGuevara> hi, i wanted to ask if someone could re-sync the REVU uploaders keyring as per wiki
[21:00] <mruiz> TheMuso, if you look the changelog the latest version is Debian (0.0.4-1) and the merge would be 0.0.4-1ubuntu1
[21:02] <TheMuso> mruiz: using dpkg --compare-versions, 0.0.4-1ubuntu1 is not a greater version than 0.0.4ubuntu4.
[21:25] <mruiz> I have to go... bye guys
[21:26] <jpatrick> adios mruiz
[21:26] <mruiz> cya jpatrick
[21:32] <RainCT> uhm.. I've found a package which is released under a "do what you want but don't remove this notice" license, but debian/copyright says it's GPL2.. :/
[21:32] <LordKow> man the xine-libs are a cluster-___ atm
[21:33] <LordKow> Depends: libxine1-plugins (= ${source:Version}) | libxine1-misc-plugins (= ${binary:Version}), <-- why does one package depend on the source version while the other the binary version? the binary version of what?
[21:33] <LordKow> itself?
[21:33] <RainCT> that license is in the header of all source files, but additionaly there's also a LICENSE file with the GPL2 text (probably just copied from another app, as there's also an empty NEWS file and a standard GNU INSTALL file)
[21:34] <LordKow> i thought the source package version depends the binary version so in essence they should be the same thing...
[21:34] <LordKow> err, i thought its the source version that determines the binary version
[21:34] <LordKow> having a source package with a different version than the binary packages it builds just seems wrong
[21:35] <LordKow> when i compile program-1.0.0 i expect the compiled program to be of version 1.0.0
[21:35] <man-di> LordKow: in Ubuntu thats true, but not in Debian. In debian exist binNMUs
[21:36] <LordKow> those need to be removed from existence, its confusing and defies all logic
[21:38] <LordKow> dpkg: regarding libxine1_1.1.8-3ubuntu1_amd64.deb containing libxine1:libxine1-bin conflicts with libxine1 (<< 1.1.8-4) libxine1 (version 1.1.8-3ubuntu1) is to be installed.
[21:38] <LordKow> LOL@that one
[21:38] <LordKow> so in essence this version of xine should never be installable.
[21:41] <Flare183> Umm, i'm trying to become a MOTU and I would like to know how I would go to find out if there are any packages that I need to fix/debianize/upload, etc. ?
[21:41] <LordKow> unless libxine1-bin is not installed.. hmm
[21:43] <geser> Flare183: if you look at the bugs you should find enough packages to fix :)
[21:43] <Flare183> ok
[21:44] <geser> Flare183: there is also a list of needs-packaging bugs
[21:44] <Flare183> where at?
[21:44] <Flare183> on lauchpad as well
[21:44] <LordKow> looks like the ubuntu xine team meant for the xine version to be 1.1.8-4ubuntu3 not -3ubuntu3
[21:44] <geser> yes, look for the needs-packaging tag
[21:45] <LordKow> or  the control file was simply messed up
[21:45] <geser> Flare183: https://launchpad.net/ubuntu/+bugs?field.tag=needs-packaging
[21:45] <Flare183> ok thanks
[21:46] <LordKow> in debian control does "<<" mean less than?
[21:46] <LordKow> or something like.. less than major version?
[21:50] <LordKow> well time to compile xine-libs with a proper control file
[21:51] <LordKow> in the end the binary packages conflict with each other due to a version mistake, generally.
[21:52] <LordKow> if they did that intentionally i dont know why, because they should have just left them out of the repos then
[21:52] <LordKow> i could see it being a milestone towards a newer version
[21:53] <TheMuso> Ouch. arc builds are badly broken.
[21:54] <TheMuso> sparc
[21:55] <LordKow> yea today is not a good day for unbreaking things
[21:55] <LordKow> in fact i think more packages are broken today than ever before in hardy's history heheh
[21:55] <geser> TheMuso: yes, it's known
[21:55] <TheMuso> Could somebody who has an AMD64 please have a look at the FTBFS report for the latest version of gnunet in hardy?
[21:55] <TheMuso> geser: I thout as much.
[21:55] <LordKow> sec
[21:55] <TheMuso> thought
[21:56] <TheMuso> damn cold fingers
[21:56] <LordKow> TheMuso, is it in the repos right now?
[21:56] <TheMuso> LordKow: Yes, and its a compilation error.
[21:56] <LordKow> k
[21:56] <TheMuso> I'd investigate if I had the hardware.
[21:56] <LordKow> TheMuso, is there a bug report for it?
[21:57] <Flare183> DEB Packages Generation of iFolder files ready for upload
[21:57] <TheMuso> LordKow: No.
[21:57] <TheMuso> I am just going through recent build failure emails.
[21:57] <Flare183> anybody want to upload them to the repos?
[21:57] <LordKow> k
[21:57] <geser> TheMuso: cold fingers? shouldn't it be warm in australia now?
[21:58] <LordKow> TheMuso, 0.7.2c-4ubuntu1 right?
[21:58] <TheMuso> LordKow: The latest version in hardy
[21:58] <StevenK> geser: Should be, isn't.
[21:59] <Flare183> anybody?
[22:00] <LordKow> /usr/bin/ld: /usr/lib/libdialog.a(formbox.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
[22:00] <geser> TheMuso: my guess is that dialog needs some -fPIC and a rebuild
[22:00] <LordKow> yea :)
[22:00] <LordKow> let me pass the cflag and see what happens
[22:01] <TheMuso> Hrm.
[22:01] <LordKow> er libdialog hm let me find the package
[22:01] <geser> LordKow: you would need to build dialog with that first and the rebuild gnunet with that package
[22:01] <geser> LordKow: dialog
[22:01] <LordKow> k
[22:01] <StevenK> Unless dialog is already -fPIC
[22:01] <StevenK> But both gnunet and dialog need to be checke
[22:01] <StevenK> checked
[22:02] <geser> why should it complain then about libdialog.a?
[22:02] <LordKow> StevenK, it is not
[22:02] <Flare183> I have converted the iFolder RPM's to DEB files see bug 87122
[22:02] <ubotu> Launchpad bug 87122 in ubuntu "[needs-packaging] iFolder" [Wishlist,Confirmed] https://launchpad.net/bugs/87122
[22:02] <LordKow> -g -Wall sometimes with -O2
[22:02] <geser> !revu | Flare183
[22:02] <ubotu> Flare183: REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
[22:02] <Flare183> oh ok
[22:02] <LordKow> does O2 include -fPIC?
[22:02] <LordKow> i hate gcc docs :P
[22:03] <Flare183> sorry i forgot newbie motu
[22:03] <StevenK> LordKow: Nope, -O2 is only optimization
[22:03] <DaveMorris> LordKow: no
[22:03] <StevenK> -O2 -funroll-all-loops -i-am-a-gentoo-ricer
[22:04] <TheMuso> StevenK: lol
[22:04] <Flare183> umm do I have to join the Ubuntu Universe Contributors Group team on launchpad?
[22:04] <LordKow> haha i love those gentoo users with (word-wrap on) ~1 page of CFLAGS
[22:04] <somerville32> Flare183, No one will force you
[22:04] <LordKow> and they're wondering why they have a crapton of compiler errors and their system doesnt even boot
[22:05] <Flare183> but do i have to in order to upload packages?
[22:05] <LordKow> StevenK, ah okay. i thought -O2 was a meta flag for a bunch of others
[22:05] <StevenK> Nope, just ricing
[22:06] <pwnguin> Flare183: to revu, yes
[22:06] <Flare183> ok
[22:06] <StevenK> And then the Gentoo ricers end up with SIGILL and SEGVs every place
[22:07] <LordKow> go gnunet go go
[22:07] <LordKow> ah still working on those deps :) not even to build yet
[22:08] <somerville32> bryce, I still don't see the catfish upload.
[22:08] <pwnguin> Flare183: so im not exactly seeing the packages in that bug...
[22:08] <Flare183> According to the wiki it says that i have to ask you'll to re-sync the REVU uploaders keyring
[22:09] <Flare183> so can you'll do that please?
[22:10] <pwnguin> Flare183: when you say "converted" im thinking of a specific process that MOTU likely won't accept. how did you make the packages?
[22:10] <Flare183> pwnguin:> well they were in rpm format so i used alien to convert them into deb fomat
[22:10] <pwnguin> doh
[22:10] <Flare183> what?
[22:10] <pwnguin> you have just failed the test =(
[22:10] <TheMuso> LordKow: Thanks for your help in advance.
[22:11] <Flare183> wow
[22:11] <Flare183> and how?
[22:11]  * TheMuso will join the amd64 crowd some day.
[22:11] <pwnguin> MOTU deals with source packages
[22:11] <pwnguin> alien deals with binary packages
[22:11] <Flare183> ok doing that then
[22:11] <pwnguin> revu takes source package uploads and compiles into a deb
[22:12] <Flare183> i know
[22:12] <Flare183> oh ok
[22:12] <LordKow> does pbuilder make a build log anywhere? compiling dialog w/ -fPIC did not fix gnunet FTBFS but i cannot confirm that adding -fPIC in the rules actually took effect
[22:13] <jpatrick> LordKow: I like to add "&> pbuilder.log" after pbuilder build.. to get a log
[22:13] <LordKow> ah
[22:13] <LordKow> yay for shell magic
[22:15] <somerville32> Is DIF in effect yet?
[22:15] <StevenK> Or | tee pbuilder.log
[22:16] <bryce> somerville32: rats, ok I'll look into it.  Maybe there's another lever I have to pull.
[22:16] <LordKow> brb
[22:17] <TheMuso> Wow. I like the new dpkg-shlibdeps functionality, telling you if a library thats linked to your binary doesn't use its symbols.
[22:20] <mok0> RainCT: I noticed set importance -> wishlist and added tag to my gpp4 needs-packaging report, thanks! Perhaps you will do the same to coot, clipper, mmdb and ssm? :-)
[22:21] <TheMuso> brb
[22:22] <nxvl_work> what is the feature freezy about?
[22:22] <nxvl_work> i mean, whats the goal on this part of the circle
[22:23] <Flare183> bug #153386
[22:23] <ubotu> Launchpad bug 153386 in ubuntu "Please add PeaZip to Ubuntu" [Wishlist,In progress] https://launchpad.net/bugs/153386
[22:23] <nxvl_work> add new features programming them or just adding new packages?
[22:23] <RainCT> mok0: no problem :). sure, if there are that many I'll run two scripts I've for this :)
[22:23] <mok0> RainCT: hehe, well that's it for now :-)
[22:24] <StevenK> nxvl_work: The former, probably not the latter, and beginning stabilizing
[22:24]  * Mahoru`Tsunemi is away: dodo
[22:24] <Mahoru`Tsunemi> oyasumi nasai minna-san
[22:24] <Flare183> Ok can someone resync the keyring?
[22:24] <nxvl_work> StevenK: i don't understand :S
[22:24] <mok0> RainCT: I have the packages in my ppa, but will upload to revu as soon as I finish my last merge
[22:25] <RainCT> TheMuso: hey. do you have a moment to explain me how this checksum stuff goes?
[22:25] <LordKow> drrr
[22:25]  * RainCT had understood (probably wrong) that the tarball is uncompressed before checking
[22:25] <LordKow> how can i add a package not in the repos to a pbuilder cache?
[22:25] <LordKow> no wonder this isnt getting anywhere =p
[22:26] <somerville32> LordKow, add it to the repos
[22:26] <StevenK> nxvl_work: At this point in the cycle, we are going to work on implementing the Approved specifications, will probably not want to pull in many new packages, and will begin focusing on stabilizing
[22:26] <RainCT> mok0: why not upload to Debian? :)
[22:27] <Ubulette> RainCT, what about the checksum ?
[22:27] <geser> LordKow: when I need to do this, I login into pbuilder and copy all needed files from outside into the pbuilder (it's a dir below /var/cache/pbuilder/build/) and build by hand
[22:27] <geser> as I don't need it that often I didn't look yet for a better solution like setting up a local repo
[22:27] <RainCT> bug 92939
[22:27] <LordKow> well doesnt pbuilder keep a cache of packages?
[22:27] <ubotu> Launchpad bug 92939 in libowfat "[can-not-install] file overwrite error" [Medium,Incomplete] https://launchpad.net/bugs/92939
[22:27] <nxvl_work> StevenK: what i don't understand/know is how are we going to implement the Approved specifications, by developing/changing the already merged/synced packages or adding new packages
[22:28] <geser> LordKow: yes, it does
[22:28] <LordKow> maybe i could sudo dpkg -i the custom package in the pbuilder environment, then when i log out it should be cached?
[22:28] <LordKow> then whenever i do pbuilder clean it should remove it
[22:29] <mok0> RainCT: Two reasons: first, I don't know any DDs, and I have gotten comfortable with the Ubuntu way of doing things. Second, Ubuntu is very popular with my colleagues, so I think it is more important to focus here first. I intend to try to get my packages into Debian at some later point, though.
[22:29] <StevenK> nxvl_work: It could be either or both
[22:29] <RainCT> Ubulette: if upstream published a .tar.bz2, will it have a different checksum each time it is converted to .tar.gz? or what is that comment (see ubotu above) about?
[22:29] <nxvl_work> StevenK: as i understand we are going to change/adapt/modify the merged/synced ones
[22:29] <tsmithe> persia, sorry, i've just returned to my computer, and have not enough backlog to see your answer, if there was any. sorry about any inconvenience
[22:30] <Ubulette> RainCT, yes, so do it only once per upstream version
[22:30] <RainCT> mok0: the first reason is no problem, just upload to mentors.debian.net and send a mail (you'll get a template for it) to the debian-mentors mailing list
[22:30] <persia> tsmithe: I've lost context, and don't know to which question you refer.
[22:31] <Ubulette> RainCT, 1st time, convert your tarball, then create your source package with -sa, then all the next ones (if any) with -si
[22:31] <StevenK> nxvl_work: Right.
[22:31] <nxvl_work> StevenK: so, whats the main item of the work now, testing and patching?
[22:31] <RainCT> mok0: and about 2, you can request the package from Debian to be synced into Hardy, so it shouldn't be any problem either :)
[22:32] <mok0> RainCT:  But we're in DIF now, right
[22:32] <StevenK> nxvl_work: For universe, the main item of work should be bug fixing, and submitting those bugs to Debian
[22:32] <persia> mok0: Yes, but that doesn't mean we can't request exceptions.
[22:32] <RainCT> Ubulette: and why does it change, shouldn't it be the same if it's compressed again? :S
[22:33] <LordKow> http://blog.madism.org/index.php/2006/06/27/93-pbuilder-custom-configurations <3 blogs
[22:33] <mok0> When you say "upload to mentors.." is that using dput etc?
[22:33] <LordKow> weird i cant ctrl+c pbuilder during unpacking of deps
[22:33] <RainCT> mok0: yes, but it shouldn't be much of a problem, or at least I got packages synced in the late Gutsy cycle (not much before feature freeze)
[22:33] <RainCT> mok0: yes, there instructions are on the website
[22:34] <Ubulette> RainCT, did you just bunzip2+gzip or did you touch the inside tar too ?
[22:34] <RainCT> s/there/the
[22:34] <RainCT> Ubulette: the first
[22:35] <Ubulette> RainCT, hmm. anyway, you never have to re-up a tarball again so checksum should never be a problem
[22:35] <RainCT> mok0: if you want to get it trough REVU first I'm not telling you to don't do so, but getting it directly into Debian makes more sense to me
[22:35] <mok0> So, I have a chain of dependencies (libraries).  I imagine it needs to be done from "the bottom"...
[22:36] <mok0> RainCT: I see your point
[22:36] <RainCT> Ubulette: the problem (?) is that it'll get into Debian some day.. see the comment in https://bugs.edge.launchpad.net/ubuntu/+source/libowfat/+bug/92939
[22:36] <ubotu> Launchpad bug 92939 in libowfat "[can-not-install] file overwrite error" [Medium,Incomplete]
[22:38] <Ubulette> RainCT, oh, you're doing 0ubuntu1.. unless you convince debian to use your tarball, you're indeed looking for troubles
[22:40] <tsmithe> persia, well, i'm off to bed; so i'll ask again tomorrow :)
[22:40] <persia> tsmithe: Ask what?
[22:40] <tsmithe> 1. if there are pdfs without sources in my package, do i have to remove them to comply with dfsg?
[22:40] <tsmithe> 2. on revu for mscore: "11) Missing copyrights on the demos: they should be GPL or explicity PD"
[22:40] <tsmithe> what makes you think they aren't copyright Werner Schweer, like most of the rest of the package?
[22:41] <persia> tsmithe: 1) Yes for GPL 2) There's no documentation: it needs something
[22:42] <persia> tsmithe: More for 2) is that most of the code has copyright attribution, and it would be good to tell users whether they can use the demos as a base for everything, or just GPL stuff.
[22:42] <TheMuso> RainCT: What checksum stuff?
[22:43] <tsmithe> also, persia, the "qm" files.. they aren't built from source, but they are in a l10n related dir, so maybe they are the sources? i'm not sure what they are
[22:43] <TheMuso> RainCT: Oh that.
[22:43] <TheMuso> RainCT: What do you not understand?
[22:43] <mok0> Are there any important differences to be aware of when packaging for Debian vs. Ubuntu??
[22:44] <tsmithe> persia, and how about the "mid" and font files?
[22:44] <persia> tsmithe: They aren't built from source?  That's odd.  They are binary Qt translation files.  They should be built from source.
[22:44] <imbrandon> persia: thats intresting ( re: pdf ) as most* of the pdf's i create ARE the source
[22:44] <RainCT> TheMuso: why it gets a different checksum each time you compress it? (I just contacted Debian's maintainer, btw)
[22:45] <RainCT> mok0: not that I'm aware of
[22:45] <mok0> RainCT: Do you need to strip Ubuntu stuff from changelog?
[22:45] <imbrandon> persia: i'm not doubting that is policy , but do you have any pointers that state that or should i google ?
[22:46] <geser> imbrandon: how do you edit the PDFs?
[22:46] <tsmithe> persia, well, they are just distributed like so in the clean upstream release
[22:46] <imbrandon> geser: either with acrobat or nano
[22:46] <RainCT> mok0: like what? didn't you say they are new packages?
[22:46] <TheMuso> RainCT: Well, packages in Ubuntu?Debian use orig tarballs in .gz format. Once you bzip2 -d to decompress the .tar.bz2, and re-gzip it, the checksum is changed, and it is never the same if done more than once.
[22:46] <geser> imbrandon: you can write PDFs with nano from scratch?
[22:47] <nxvl_work> imbrandon: hi!
[22:47] <persia> tsmithe: For .mid, I like using abcmidi or midge to generate them, but there are lots of different sequencers available with easy save formats.  I don't know much about fonts.
[22:47] <imbrandon> geser: not 100% , i either create them in ps or acrobat
[22:47] <nxvl_work> imbrandon: i was looking for you, this have been busy days
[22:47] <mok0> RainCT: I am thinking of trying out with one of my packages that have already made it into Ubuntu
[22:47] <imbrandon> nxvl_work: heya
[22:47] <imbrandon> nxvl_work: yea busy days
[22:47] <persia> imbrandon: In which case the ps would be the source
[22:47] <imbrandon> persia: ps == photoshop
[22:47] <imbrandon> in this case
[22:48] <tsmithe> persia, but can i leave the shipped .mid files in there? (same goes for qm files and fonts)
[22:48] <persia> imbrandon: confusing.  I tend to think of ps == postscript by default.
[22:48] <mok0> RainCT: Then I could try uploading right away :-)
[22:48] <RainCT> mok0: ah ok. this was discussed on the mailing list some days ago, and it isn't clear what to do..
[22:48] <geser> imbrandon: then the photoshop file is the source or do you delete it after you created the PDF the first time and edit the PDF directly after that?
[22:48] <nxvl_work> imbrandon: so, as now we are on debianFreezy and i have been working on merges, have you a new task?
[22:48] <imbrandon> heh point is what about pdf ( espicialy now that its an iso standard ) that are creaed by scratch
[22:48] <TheMuso> RainCT: So its important that if we push the new version into Ubuntu, that Debian has to use the same tarball.
[22:48] <persia> tsmithe: You can leave all of it if you can reconstruct.  I know the archive admins complain about pdf files.  I don't know if they complain about fonts or midi files.
[22:49]  * persia points at pdfedit as well
[22:49] <RainCT> mok0: (remember to add a version-1 entry with "unstable" instead of hardy to the changelog)
[22:49] <mok0> RainCT: I guess the Maintainer: field is different
[22:49] <imbrandon> geser: well there normaly is no .psd created the way i do it, e.g. open ps, file->new doc  , create away, save ( as pdf )
[22:49] <tsmithe> hmm, well, i think i'll leave everything, excepting the pdfs, and see what the archive admins say. i'll include copyright info as appropriate, of course.
[22:49] <persia> imbrandon: How do you edit it later?
[22:50] <RainCT> mok0: if it has any useful information I'd keep it. if it's just a "initial commit", drop it
[22:50] <imbrandon> persia: open with acrobat / photoshop or nano
[22:50] <RainCT> mok0: yep, it should be your name & mail
[22:50] <imbrandon> depending on how much of a change i need to make
[22:50] <CheGuevara> is the keyring in revu resynced at 12 GMT ?
[22:50] <persia> tsmithe: That's easiest, but definitely plays on the possibility that the given archive admin doesn't know the preferred source format for something.
[22:51] <imbrandon> persia: pdfs arent write only, only when viewed with a viewer are they read only
[22:51] <imbrandon> err s/write/read
[22:51] <mok0> RainCT: So, how will I communicate with the DDs? The IRC channel is completely inactive
[22:51] <imbrandon> any editor should be able to edit any pdf
[22:51] <imbrandon> just some make it easier
[22:51] <persia> imbrandon: I just don't find it as easy as modifying SVG  or DocBook or the like, and recreating a PDF.
[22:51] <geser> mok0: are you on the correct network?
[22:52] <mok0> irc.oftc.net?
[22:52] <imbrandon> persia: correct, its not easy , but doable, and some tools like acrobat make it easy
[22:52] <persia> imbrandon: Anyway, I've seen the archive admins reject PDFs without source.
[22:52] <RainCT> mok0: their IRC channel is on irc.oftc.net, but communication is primary by mail
[22:52] <nxvl_work> i see 350 connected users on debian-devel
[22:52] <imbrandon> persia: right, i dont doubt it , i was just wondering if there was exceptions in the cases where its verifiable that the pdf IS the source
[22:53] <geser> mok0: yes, and I see activity in #debian-devel in the last hour
[22:53] <imbrandon> kinda like CrystalSVG icon set the PNG is the source type thing
[22:53] <persia> imbrandon: I don't know.
[22:53] <imbrandon> persia: okies
[22:54] <imbrandon> i would have never guessed pdfs wouldent be considered source, since like html they are mostly just markup
[22:54] <nxvl_work> imbrandon: did you have a new task or should i continue with FTBFS?
[22:54] <geser> imbrandon: if you can convince the archive-admins that you edit your PDFs with nano they should get accepted
[22:55] <imbrandon> geser: i dont regularly but there are other floss tools too like gnupdf and pdfedit and commercial ones acrobat and photoshop that all create them natively
[22:55] <geser> nxvl_work: it's still possible to merge but you need a reason now, like security fixes, important bug fixes, etc.
[22:55] <imbrandon> but i have on ocassion :)
[22:56] <imbrandon> nxvl_work: yea i would work on bug fixing from LP now and gettign to know LP and the sponsores queue intmately
[22:56] <nxvl_work> geser: yes, but i as a mentee task isn't so active
[22:56] <nxvl_work> imbrandon: i mean a new task for me :P
[22:57] <imbrandon> nxvl_work: well honestly you are at the level you could probably pick your own tasks and just come to me for oversight if you dont know the proper way to see it to completion but i'd be happy to still come up with a "task" if you really wish'
[22:57] <geser> nxvl_work: there is also NBS or unmet deps which needs fixing
[22:58] <nxvl_work> geser: yep i'm working on them :D
[22:58] <imbrandon> geser: yup thats what hes been doing the last weeks
[22:58] <imbrandon> :)
[22:58] <imbrandon> brb one sec
[22:58] <nxvl_work> imbrandon: i will be happy to recieve new task so i can put goals
[22:59] <geser> nxvl_work: come back for the next task, when all unmet deps are fixed :)
[22:59] <nxvl_work> heh
[22:59] <nxvl_work> :D
[22:59] <nxvl_work> does that happends ever?
[23:00] <imbrandon> heh no
[23:00] <geser> I didn't witness it till now
[23:01] <imbrandon> nxvl_work: really you have worked with librarys normal packages, all the qa pages, lp, irc and bugmail, really now its just lots of practice
[23:01] <nxvl_work> on saturday i will give a workshop and a quick talk about packaging here in peru
[23:01] <nxvl_work> :D
[23:01] <imbrandon> nice
[23:01] <imbrandon> :)
[23:01] <nxvl_work> imbrandon: ok, si i'm kind on my own putting goals?
[23:02] <nxvl_work> if you think i'm ready, then i will give a try
[23:02] <imbrandon> nxvl_work: yea really its at that point in the game :) but i'm still here for anything you have questions with along the way and such
[23:03] <imbrandon> ( as are many of the rest of us as i'm sure youve seen ) hehe
[23:03] <nxvl_work> i just want to know how to check for bugs, just picking packages and suscribing to them or browsing, or there is other ways, like category browsing on LP
[23:03] <mok0> RainCT: Do I need to upload binary+source debs?
[23:04] <imbrandon> nxvl_work: well some of the lower links on the qa page link to LP pages with patches and such, those are good to preuse
[23:04] <imbrandon> peruse*
[23:04] <imbrandon> like ...
[23:04] <imbrandon> https://launchpad.net/ubuntu/+bugs?field.tag=patch
[23:05] <imbrandon> and
[23:05] <imbrandon> https://launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_contact=&field.bug_commenter=&field.subscriber=&field
[23:05] <imbrandon> wow
[23:05] <imbrandon> thats a long url, but linked on the QA page
[23:05] <RainCT> mok0: no, just dput the source
[23:05] <mok0> RainCT: OK, good, I don't have a sid pbuilder
[23:06] <geser> nxvl_work: an other task which needs to be done now (after DIF): monitor debian-devel-changes for interesting fixes (like security) and put them into hardy (sync or merge)
[23:07] <nxvl_work> debian-devel-changes as in maillinglist?
[23:08] <RainCT> mok0: http://mentors.debian.net/cgi-bin/maintainer-intro
[23:08] <geser> nxvl_work: yes, or the webarchive or the RSS feed if you like them more
[23:08] <mok0> RainCT: yeah, saw it, it says: "dput mentors cream_0.32-2_i386.changes"
[23:08] <LordKow> TheMuso, im working on setup up a local repo since i test a lot of deps that are not in the repos yet
[23:08] <nxvl_work> geser: i will take a look on them
[23:09] <nxvl_work> thnx
[23:09]  * nxvl_work hugs geser and imbrandon
[23:10] <geser> nxvl_work: I've seen CVE fix on it right now: linux-ftpd-ssl and CVE-2007-6263
[23:10] <ubotu> The dataconn function in ftpd.c in netkit ftpd (netkit-ftpd) 0.17, when certain modifications to support SSL have been introduced, calls fclose on an uninitialized file stream, which allows remote attackers to cause a denial of service (daemon crash) and possibly have unspecified other impact via some types of FTP over SSL protocol behavior, as demonstrated by breaking a passive FTP DATA connection in a way that triggers an error in the server's SSL_ac
[23:12] <ember> bug #176175
[23:12] <ubotu> Launchpad bug 176175 in linux-ftpd-ssl "Please merge linux-ftpd-ssl_0.17.18+0.3-9.1 into Hardy" [Wishlist,In progress] https://launchpad.net/bugs/176175
[23:12] <geser> good
[23:13] <TheMuso> LordKow: ok
[23:15] <geser> ember: if you want to do the motu-swat team a favour, could you also check if other releases are also affected and prepare debdiffs?
[23:16] <geser> ember: at least gutsy needs the fix but the other releases probably too
[23:18] <LaserJock> heh, Google Summer of Code hits Bourne Ultimatum
[23:18] <StevenK> LaserJock: Ponies!
[23:18] <LaserJock> dude!
[23:19] <LaserJock> I got *3* hours of sleep last night and my advisors want me to have a final report tomorrow morning
[23:19] <LaserJock> it *ain't* gonna happen today
[23:19] <LaserJock> on the other hand, if people have any good suggestions they are welcome to send them to me
[23:19] <LaserJock> I'm almost half way done with the Ponies
[23:27] <tsmithe> should my get-orig-source rule create the new tarball in the current directory or ..?
[23:27] <ember> it affects gutsy geser
[23:27] <ember> i'm checking others
[23:28] <LaserJock> tsmithe: I think .. but I'm not positive
[23:29] <mok0> RainCT: One package uploaded to Debian. Now, waiting for a sponsor... :-)
[23:29] <Ubulette> tsmithe, yes, current, that's were the user will expect it
[23:30] <tsmithe> Ubulette, ah but if a user is running, in the current package sources directory (which would have been extracted from the previous orig tarball), then they'd expect it to be where the previous tarball is/was; in ../
[23:31] <Ubulette> tsmithe, and please, don't work in ../tmp, think about the poor users that will work in tmp.
[23:31] <tsmithe> yes, i've changed that :)
[23:31] <Ubulette> tsmithe, no, depends on what they use to build afterwards
[23:31] <LaserJock> ah, but /tmp is so much fun
[23:31] <LaserJock> ;-)
[23:31] <tsmithe> hehe
[23:32] <tsmithe> thing is, as LaserJock is a MOTU, i tend to err towards his advice, to store the file in ..
[23:32] <tsmithe> even though i've just changed it to make it easier to just leave it in .
[23:32] <StevenK> LaserJock: More so when /tmp is a RAM fs
[23:32] <LaserJock> tsmithe: isn't that what Ubulette said?
[23:32] <tsmithe> it is?
[23:32] <tsmithe> "Ubulette> tsmithe, yes, current, that's were the user will expect it"
[23:32] <LaserJock> oh wait
[23:32] <LaserJock> current = . , I missed that
[23:32] <tsmithe> StevenK, could you help me out?
[23:32] <Nafallo> that's the whole idea why it's fun in the first place, right?
[23:33] <LaserJock> tsmithe: *I* would expect it to be in .. as that's where the .orig.tar.gz goes, but . would work as well I guess
[23:33] <LaserJock> tsmithe: personally I'd find some other packages that do that and see what they do or maybe ask persia
[23:33] <Nafallo> ~/devel/results
[23:34] <Nafallo> what are we talking about?
[23:34] <tsmithe> the wiki examples tend to use ..
[23:34] <tsmithe> that's what i'm sticking to, and i'll upload my new package like that, then go to bed
[23:34] <LaserJock> Nafallo: where a get-orig-source rule should put the tarball
[23:35] <Ubulette> .. may not be writable to the user while . sure is
[23:35] <StevenK> tsmithe: Hum? Context?
[23:35] <LaserJock> umm, .. should be writable
[23:35] <LaserJock> if they've unpacked the source package
[23:36] <tsmithe> StevenK, get-orig-source: do i want to store the new orig tarball in . or ..? i'm thinking .., which seems ever the more sensible to me
[23:37]  * LordKow crosses fingers
[23:37]  * LordKow pets gnunet
[23:37] <Ubulette> debian policy says: "This target fetches the most recent version of the original source package from a canonical archive site (via FTP or WWW, for example), does any necessary rearrangement to turn it into the original source tar file format described below, and leaves it in the current directory. "
[23:37] <StevenK> And how can you know .. is writable?
[23:38] <Ubulette> ... "and leaves it in the current directory"
[23:38] <tsmithe> Ubulette, oh ok
[23:39] <tsmithe> if people call debian/rules get-orig-source in the directory of the package sources, then they're going to be cluttering up the sources dir, rather than the directory above where the orig tarball usually is
[23:39] <tsmithe> that's all
[23:39] <LaserJock> tsmithe: I agree, but debian policy is god so ...
[23:39] <tsmithe> yep
[23:40] <tsmithe> well, it's easy enough to change, just uncomment a "mv" in the makefile
[23:41] <ember> geser:
[23:42] <LordKow> TheMuso, gnunet builds properly if libdialog is built w/ -fPIC
[23:42] <TheMuso> LordKow: How do you set up libdialog to build with -fPIC
[23:42] <LordKow> TheMuso, one of the first few lines in rules
[23:42] <TheMuso> LordKow: Could you be more specific please?
[23:44] <LordKow> TheMuso, debian/rules: -CFLAGS = -g -Wall ; +CFLAGS = -g -Wall -fPIC
[23:44] <LordKow> that will do it for ALL archs but that is fine
[23:44] <TheMuso> LordKow: Ok thanks.
[23:46] <LordKow> TheMuso, and thats dialog NOT gnunet
[23:46] <LordKow> gnunet is fine
[23:47] <TheMuso> LordKow: Yep I understand.
[23:47] <LordKow> k
[23:49] <TheMuso> LordKow: thanks for your help
[23:49] <Nafallo> LaserJock: ah. I would expect .. :-)
[23:49] <LordKow> TheMuso, np
[23:50] <LordKow> yay fixed the libxine cluster___ for myself