[00:00]  * NCommander usually uses dpatch
[00:00] <persia> NCommander: I really don't care.  I use what's there, or what the Maintainer likes, or what whoever is reviewing a new package on Mentors likes.
[00:01]  * persia is likely the least good person to ask about patch system preferences, having only one strong opinion: it doesn't make sense to have a patch system and changes outside debian/ in diff.gz.
[00:01] <NCommander> ah
[00:01] <NCommander> That bugs the crap out of me
[00:01] <NCommander> I think its against policy now
[00:05] <persia> It ought be, if it's not.  I don't mind if someone does just diff.gz patches (although it's nicer when they have a VCS), but mixing is just evil.
[00:06] <NCommander> persia, its usually older ones that aren't
[00:06] <NCommander> But there is virtually no oversight with DD package submissions
[00:06] <persia> That's why we have REVU: helps get team review of everything.  While there is the occasional package that misses REVU, most things have at least two sets of eyes, and sometimes four or five before they get uploaded.
[00:08] <NCommander> Because no MOTU can directly upload to incoming, right?
[00:08] <persia> Well, anyone can, but anyone who does is likely to have someone else ask them about it.
[00:09] <persia> Questions like "Who did the second ACK for that?" or "Why didn't you put it on REVU?".  Nobody likes trying to come up with an answer, so we just use REVU.
[00:10] <persia> REVU logs all the uploads and comments to a public list, so it's easy to audit against -changes mail.
[00:10] <NCommander> Cool
[00:10] <NCommander> I actually think debian should adopt that system
[00:10] <NCommander> But man, people would go apeshit if anyone every suggested it
[00:11] <devfil> NCommander: Debian uses mentors.debian.net
[00:11] <persia> There was some talk about it, both the REVU code and the process.  Last I knew it was stalled.
[00:11] <NCommander> I have NEVER seen a DD use that
[00:11] <devfil> NCommander: if a DD don't use it is a problem, but mentors exists
[00:11] <persia> I've seen DDs in collaborative teams upload to VCS and ask for comments before uploading, which is at least an example of good process.
[00:12] <NCommander> There just isn't any oversight
[00:12] <NCommander> But the DD process is so rigid, it weeds out a lot of .... lesser developers
[00:13] <NCommander> So my changes will go on REVU, and then intro intrepid?
[00:13] <persia> NCommander: Maybe.  It tries.  Personally, I find agressive peer review of most changes to be almost as good in terms of patch quality.
[00:13] <persia> Nope.  Your changes go to the sponsors queue, where a second person looks at them, and uploads.
[00:13] <persia> MOTU upload patches like that directly.
[00:14] <persia> The changes are then posted, and as all the packages are team-maintained, we all have an interest in fixing any broken uploads (no NMU barrier).
[00:14]  * NCommander looks forward to some of his FTBFS fixes going
[00:14] <NCommander> This is the third one today (not counting the giveback)
[00:15] <devfil> persia: no maintainer in ubuntu is a great thing, in Debian I see a lot of package not updated because the maintainer is away
[00:15]  * NCommander is guility of that >.>;
[00:16] <persia> devfil: Yes, but no Maintainer in Debian is a bad thing: Ubuntu relies on the Debian maintainers to develop good relationships with upstream.  We do in some special cases (like you with WX), but in most cases, we're too busy chasing all the little bugs to concentrate properly on each package.
[00:16] <NCommander> What I never get is how some packages seem to be not buildable on normal linux systems
[00:16] <NCommander> And usually require one or two big patches
[00:17] <persia> NCommander: Different envionment used upstream (e.g. Solaris).
[00:17] <NCommander> I mean with Debian packages
[00:17] <persia> Yes, as do I.
[00:17] <NCommander> i.e., nginx
[00:17] <NCommander> It requires IOV_MAX to be defined
[00:17] <NCommander> But its not defined on Linux
[00:17] <persia> I thought nginx upstream used Mac OS X.
[00:17] <NCommander> I fixed it by aliasing it to the equivelent preprocessor macro (UIO_MAXIOV)
[00:17] <NCommander> But the package is in debian stable
[00:18] <NCommander> and it built on unstable without such a fix
[00:18] <NCommander> I don't get it ...
[00:18] <persia> Check the m68k logs?
[00:18] <NCommander> maybe-successful
[00:19] <NCommander> It always bugs me
[00:19] <NCommander> Oh, hrm
[00:20] <NCommander> very weird
[00:21] <NCommander> hrm, oh I see
[00:22] <NCommander> YOu need to define __need_IOV_MAX it appears to get it
[00:22] <NCommander> Must be a change in glibc
[00:23] <NCommander> do any of you run intrepid directly?
[00:24] <nhandler> NCommander, I run Intrepid directly
[00:24] <persia> Many of us, and those that don't have intrepid chroots for testing.
[00:24] <NCommander> I'm running the chroot
[00:24] <NCommander> I ran into issues when I ran gutsy directly
[00:30]  * NCommander uploads nginx
[00:32]  * NCommander reviews the list of FTBFS again
[00:34]  * NCommander waits patiently for one patch to just reach revu ;-)
[00:35] <persia> REVU?  On what are you waiting?
[00:36] <NCommander> You said that someone will likely put the updated package files to REVU for review ...
[00:37] <persia> No.  NEW package go to review.  Current packages get reviewed by the sponsors.  Other people watch -changes, and complain if there is a bad upload. (well, some people both sponsor and watch changes, but...)
[00:38] <NCommander> ack
[00:38] <persia> Err.  NEW packages go to REVU.  Other packages get reviewed.
[00:38]  * NCommander hides under his desk for being an idiot :-)
[00:38]  * persia gets confused by homonyms again
[00:38] <NCommander> ...
[00:38] <NCommander> Five diet cokes
[00:38] <NCommander> I think I can kiss sleep goodnight
[00:39] <NCommander> So, instead, I'm waiting for one of my packages to get reviewed, and someone to smite me and tell me to try again ;-)
[00:43] <NCommander> I'm going home, see you all laptop
[00:43] <NCommander> ...;
[00:43] <NCommander> later
[00:44] <cody-somerville> NCommander, cya :)
[00:46] <nxvl> persia: why did you delete last line of the wiki?
[00:46] <nxvl> persia: to much attention for you?
[00:46] <nxvl> :p
[00:48] <sistpoty> persia: looking at /srv/uploads/rejected, maybe a keying sync would be adequate (together with moving the .changes files back to /srv/uploads)?
[00:48] <sistpoty> ;)
[00:55] <sistpoty> cody-somerville: oh, sorry, I just finished going through the key-teams thread, and I doubt I'll have a summary before going to sleep
[00:55] <cody-somerville> sistpoty, How far away is that?
[00:56] <sistpoty> cody-somerville: quite a bit... I just finished pasting any significant bit (and reading through it)
[00:56] <cody-somerville> I meant, how far away is going to sleep?
[00:57] <sistpoty> cody-somerville: actually going to sleep is in the next half hour
[00:57] <sistpoty> cody-somerville: but as I haven't really structured plain comments yet, I don't think I'll be able to this during that timeframe
[00:58] <cody-somerville> Okay.
[00:58] <cody-somerville> Do you want to aim for gobbying it tomorrow?
[00:59] <sistpoty> cody-somerville: I'll try... but actually I'm not certain I'll do it
[00:59] <sistpoty> cody-somerville: bad thing is, that I'll be mostly afk from somewhen tomorrow afternoon to sunday evening (utc+2 pov)
[00:59] <sistpoty> (we have 10 year class meeting this weekend)
[01:01] <sistpoty> cody-somerville: not too sure how best to proceed actually... if you come up with s.th., I guess it might be better to just sent it to -motu...
[01:01] <sistpoty> (sorry again)
[01:02] <cody-somerville> ok
[01:14]  * sistpoty goes to bed now... cya
[01:23] <udienz-> sistpoty: is revu server re-sync again?
[01:30] <NCommander> What are SRU bugs?
[01:33] <cody-somerville> NCommander, SRU stands for "Stable Release Updates". You can find more information regarding SRUs at https://wiki.ubuntu.com/StableReleaseUpdates
[01:36] <Drk_Guy> REVU hasn't synced
[01:37] <NCommander> cody-somerville, Thank you :-)
[01:38] <cody-somerville> NCommander, np
[01:38] <NCommander> cody-somerville, I just migrated from Debian to Ubuntu, and spent most of the afternoon fixing FTBFS ;-)
[01:38] <cody-somerville> NCommander, Awesome :)
[01:38] <cody-somerville> NCommander, did you push your changes upstream where appropriate?
[01:39] <NCommander> I filled bug reports with Debian if that's what you mean
[01:39]  * cody-somerville nods,.
[01:39] <NCommander> I got a rather angry email saying not to bug him about FTBFS's on Ubuntu :-/
[01:40] <NCommander> I'd just want to get some review on my debdiffs
[01:40] <persia> Some Maintainers are like that, although most are happy to adopt.  In many cases, it also FTBFS in Debian (always good to check), which can help get them adopted.
[01:40] <NCommander> I'm fairly sure I did it all right
[01:53] <NCommander> Can I simply debootstrap an i386 chroot on aamd64 system, or do I need to do something stupid?
[01:55] <persia> NCommander: You can debootstrap both i386 and lpia on amd64
[01:55] <NCommander> What is lpia?
[01:56] <persia> Low Power Intel architecture.  It's a low-power memory-limited i686 with no VMX, etc.
[01:56] <NCommander> Google tells me its the libertarian party of iowa, but I don't think thats right ;-)
[01:56] <NCommander> That sounds like the Asus EEE and friends
[01:56] <NCommander> (aka Intel Atom based machines)
[01:57] <persia> Chips that it runs on today are Intel A100, Intel A110, and Intel Atom.  For userspace, it's not really that different than i386.  The kernel is a little different.
[01:57] <persia> Well, most Eee s are actually VIA C7-M, which is a i586 based chip, and can't boot an lpia kernel.
[01:57] <NCommander> i586?
[01:57] <NCommander> Ew.
[01:58] <NCommander> I'm suprised
[01:58] <persia> There's a few i586s out there still.  Probably some i486s too, although I'm not sure Ubuntu supports those.
[01:59] <persia> I know we don't support real i386s (and never have).
[01:59] <NCommander> I think Ubuntu compiled targetting i386 like Debian
[01:59] <NCommander> Oh
[01:59] <NCommander> Hrm
[01:59] <NCommander> No clue then
[01:59] <persia> No, even in the beginning it was i486.  Anyway, I don't think lenny will run on a real i386 without some significant tinkering.
[01:59] <NCommander> Which leads into the next question, what specifically is a softfreeze?
[02:01] <persia> During a soft freeze, we avoid uploading anything that ends up on one of the images for the test.  For this freeze, it's Ubuntu, Kubuntu, Xubuntu, Edubuntu, and Ubuntu Server.  Ubuntu Studio, Ubuntu Mobile, and Mythbuntu aren't participating in the Alpha for one reason or another.
[02:01] <NCommander> So that means things like FTFBS fixes aren't going to move?
[02:15] <persia> NCommander: Only for things that end up on the CDs.  The Freeze ought be ending soon anyway.
[02:15] <NCommander> The CDs is just main, or main and select universe?
[02:16] <persia> select main and select universe.
[02:16] <NCommander> ah
[02:20] <NCommander> Can I cast a pointer on a i686/32-bit as unsigned long?
[02:20] <NCommander> (that's the fix for this package on amd64, but I don't want to then cause a FTBFS on i686 ;-))
[02:20] <persia> I believe so.
[02:21] <persia> Anyway, we don't have i686, just i586 and lpia, neither of which is quite an i686.
[02:21] <NCommander> Close enough ;-)
[02:26] <RAOF> NCommander: If you're going to do pointer arithmetic, intptr_t is the winning type.
[02:26] <NCommander> intptr_t?
[02:27] <RAOF> It's an int which is guaranteed to be big enough to hold a pointer.
[02:27] <NCommander> Should I just use that inplace of the cast for unsigned long?
[02:27] <RAOF> Presumably you need a bit more than just an unsigned long cast, though?
[02:28] <RAOF> You need to actually change the destination type?
[02:28] <RAOF> Or were they doing something strange like "unsigned long ptr = (int)the_pointer;"?
[02:30] <RAOF> Of course, casting to unsigned long isn't portable; that will definately fail on win64, for example.
[02:30] <NCommander> neither is intptr_t
[02:31] <RAOF> intptr_t should be supported by any C89 (C99?) compiler.
[02:31] <NCommander> Well, it was doing just a unsigned int cross
[02:31] <persia> C99 I'd think.
[02:31] <NCommander> and it works for me now
[02:33] <emgent> hello people
[02:33] <RAOF> Howdie.
[02:35] <NCommander> ROAF: thanks for that hint, it works great :-)
[02:36] <RAOF> Care to work out why mcs segfaults while compiling evolution-sharp on AMD64 in a clean chroot for me, then? :)
[02:37] <NCommander> ROAF: If you can work on reviewing my FTBFS fixes ;-)
[02:42] <Hobbsee> oh yeah, motu meeting
[02:45] <emgent> Hobbsee: ? :)
[02:45]  * Hobbsee forgot about it, but wasn't here anyway
[02:45] <emgent> Who is emma?
[02:46] <Hobbsee> you don't want to know
[02:47] <Hobbsee> either way, she can come and lurk now
[02:47] <Hobbsee> emgent: we've had a fair bit of trouble with her in userland.
[02:49] <crimsun> hmm?  As in being obnoxious, or..?
[02:51] <Hobbsee> crimsun: yeah, mainly.  prattling on about how irseek is so evil, because it's in the channel, ignoring ithe calls that she's offtopic, arguing for hours any time she gets told off or banned, and kept advertising her channel to users.
[02:52] <Hobbsee> whihc, oddly enough, people were reporting as abuse.
[02:53] <Hobbsee> she caused enough trouble to get an #*ubuntu*-wide channel ban.
[02:54] <emgent> argh
[02:54] <RAOF> I need to make xserver-xgl build again.  In order to do this, I need to include the mesa source somewhere.  The .orig.tar.gz would be more appropriate than in the .diff, right?
[02:55] <RAOF> Oh, crap.  That'd mean I'd need to include the appropriate copyright stuff.  Urgh.
[02:55] <Hobbsee> emgent: so, she's partially reformed.  She still sticks random stuff in channels, like ':)', and doesn't contribute terribly useful, and still argues for hours when she gets told off, though.  But it seems there's progress, so she can lurk.
[02:55] <Hobbsee> s/useful/usefully/
[02:56] <emgent> understand :)
[02:57] <crimsun> Hobbsee: hmm, if this is the same 'emma', I'll have a face-to-face chat, or have someone speak to her.
[02:58] <crimsun> we're all in the same city
[02:58] <Hobbsee> oh, interesting.  could have used your help a couple of months ago
[02:58] <NCommander> RAOF, what was that package you wanted me to check on?
[02:59] <RAOF> NCommander: evolution-sharp.  That wasn't serious, though I'd _love_ you to find out the reason.
[02:59] <crimsun> Hobbsee: heh, I'm kinda scarce these days, so I'm not useful.  :)
[02:59] <RAOF> It's awkward and annoying, and probably a mono bug.
[02:59] <NCommander> RAOF, are you a MOTU by any chance?
[02:59] <RAOF> Yah.
[03:01] <NCommander> RAOF, if I fix it, will you review my pending FTBFS fixes ;-)
[03:01] <RAOF> Absolutely.  How many of them?
[03:01] <NCommander> 4 or 5
[03:01] <NCommander> I lost count ;-)
[03:01] <NCommander> I didn't have anything to do this afternoon ...
[03:02] <RAOF> I'll certainly look at them if you fix evolution-sharp :)
[03:02] <NCommander> Building GCC on m68k is a slow process
[03:02] <RAOF> Heh.
[03:02] <RAOF> I'll possibly look at them anyway, but after breakfast :)
[03:02] <NCommander> RAOF, 7-10 days on average for m68k
[03:02] <NCommander> The error I see evolution-data-server is too new O_o?
[03:03] <RAOF> NCommander: You're looking at the wrong packages, then.  You're after evolution-sharp 0.17.4-0ubuntu1
[03:03] <RAOF> Where mcs segfaults on amd64 only.
[03:03] <NCommander> the buildload on qa.ubuntuwire.com is old then
[03:03]  * NCommander looks on amd64
[03:03] <NCommander> link to your buildlog?
[03:05] <RAOF> It was on launchpad, but apparently it's being rebuilt?
[03:05] <RAOF> What's happening there?
[03:05] <NCommander> Where on launchpad
[03:05] <NCommander> (I use the qa page)
[03:05] <NCommander> (but it seems to sometimes lag on newer packages)
[03:05] <NCommander> *grumbles* it did successfully build on unstable
[03:06] <RAOF> launchpad.net/ubuntu/+source/evolution-sharp
[03:06] <RAOF> No, I don't think it did; they have 0.17.1.
[03:06] <NCommander> I don't see failure logs
[03:06] <RAOF> It's quite possible that the same package _will_ build on unstable, though...
[03:06] <RAOF> NCommander: Yeah.  For some reason it's getting rebuilt.
[03:06] <RAOF> Wait a couple of minutes, and it'll fail.
[03:07] <RAOF> https://edge.launchpad.net/ubuntu/+source/evolution-sharp/0.17.4-0ubuntu1/+build/666561
[03:07] <RAOF> There we go!
[03:07] <NCommander> oooh
[03:07] <NCommander> What a misirble failure
[03:09] <NCommander> RAOF, what's your timezone?
[03:09] <RAOF> GMT+10
[03:10] <RAOF> Moar pancakes!
[03:10] <ion_> gief
[03:10] <NCommander> heh
[03:10] <NCommander> -5 GMT here
[03:11] <ion_> :%s/GMT/UTC/g
[03:13] <RAOF> Hm.  It seems something's filing automated FTBFS bugs, but not doing it correctly.
[03:13] <RAOF> I posit the recently-reopened: https://bugs.edge.launchpad.net/ubuntu/+source/evolution-sharp/+bug/194456 as a symptom.
[03:20] <Hobbsee> RAOF: when was that closed?
[03:20] <RAOF> In Hardy, methinks.
[03:21] <RAOF> Or, rather, it wasn't visible when I checked the bugs yesterday.
[03:21] <RAOF> Which, I assume, means it was closed.  I belive that hardy's evolution-sharp did build from source.
[03:21] <NCommander> ROAF: Any idea what's causing this FTFBS?
[03:21] <Hobbsee> activity log doesn't show it being closed.
[03:22] <RAOF> Oooh, never noticed that button.
[03:22] <Hobbsee> yeah, i remember seeing a uvfe for it, and approving it - but i wouldn't bet that bug got closed as well
[03:22] <RAOF> Hm.  I wonder what happened, then.
[03:22] <RAOF> I really wasn't visible yesterday!
[03:22] <NCommander> UVFE?
[03:22] <RAOF> NCommander: No, I really dont' have any good ideas.
[03:22] <Hobbsee> NCommander: upstream version freeze exception
[03:23] <NCommander> What have you tried?
[03:26]  * NCommander is right now thinking connecting gdb to mcs is the easiest way to find where the bug is
[03:29] <RAOF> I've tried that, but mono is not very amenable to gdb.
[03:30] <NCommander> It should at least show you where the SIGSERV is though o_O;
[03:30] <RAOF> I've got a core file if you'd like to check :)
[03:35] <NCommander> That would be handy
[03:35] <NCommander> I'm reading tips on using GDB with mono
[03:37] <NCommander> RAOF, I'm probably going to guess a pointer is getting mutated somewhere
[03:37] <NCommander> Just suprising its only happening on amd64
[03:37] <RAOF> Right.
[03:38] <RAOF> Also surprising: only happens in a clean chroot.  I can build it just fine in my Intrepid install.
[03:38] <NCommander> My chroot isn't clean
[03:38] <NCommander> (I have some cruft in it)
[03:39] <NCommander> and it still SIGSERVed
[03:39] <ion_> SERV?
[03:40] <RAOF> NCommander: http://cooperteam.net/core
[03:40] <NCommander> *SIGSEGV
[03:40] <NCommander> This backtrace is real pretty
[03:41] <NCommander> But it looks like its tripping a bug in pthreads ....
[03:41] <NCommander> pthread_cond_wait@@GLIBC_2.3.2
[03:41] <NCommander> WTF?
[03:41] <RAOF> That's not necessarily where it died, though.
[03:41] <RAOF> That could just be where some non-segfaulting thread was when mono died, right?
[03:42] <NCommander> It's always dying in the same place
[03:42] <NCommander> EVen after running it a bunch of times
[03:42] <NCommander> Sometime makes a thread, and bing, diad
[03:42] <NCommander> *dead
[03:42] <NCommander> I just don't get why its @@GLIBC_2.3.2
[03:43] <NCommander> libc6-dbg gets me symbols, right?
[03:43] <RAOF> Yeah.  Or libc6-dbgsym.  Doesn't really matter which.
[03:46] <NCommander> At least there is a mon-dbg package
[03:50] <NCommander> well, installing symbols makes a lot more interesting debug data
[03:53] <NCommander> RAOF, it's a memcpy() call that's triggering the code to go boom
[03:54] <RAOF> Hm.  Another data point: that package builds just fine in sid.
[03:54] <RAOF> It might be time to start looking at ubuntu-applied mono patches.
[03:55] <NCommander> I'm trying to localize where in the native code its oblierating itself
[03:55] <NCommander> maybe its worth building mono sans patchs and see if this builds
[03:56] <RAOF> Quite possibly.
[03:57] <NCommander> Argh
[03:57] <NCommander> I can't see what the arguements are to memcpy
[03:57] <RAOF> :(
[03:57] <NCommander> What's the command to make it load symbols for a library
[03:57] <NCommander> (I haven't used GDB in awhile)
[04:03] <NCommander> What. The. ****.
[04:03] <NCommander> It just built
[04:03] <NCommander> I cd'ed into evolution and typed make
[04:03] <NCommander> and
[04:03] <NCommander> ... it built
[04:03] <RAOF> Yeah, it does that.
[04:03] <NCommander> wtf O_O;
[04:03] <RAOF> Sometimes it builds, sometimes it doesn't.
[04:04] <RAOF> Although it seems to _always_ fail in automated environments.
[04:04] <Drk_Guy> this is pissing me off
[04:04] <NCommander> Sounds like a *shiver* thread locking issue
[04:04] <NCommander> It always builds if I cd into the evolution folder
[04:05] <RAOF> Maybe it's a path thing?
[04:05] <NCommander> Maybe
[04:05] <NCommander> I'm tweaking the rules file to figure it out
[04:05] <RAOF> Because I found strange things happening running the compile command manually.
[04:06] <RAOF> mcs <stuff goes here> generated/*.cs dies, mcs <...> generated/Addresswhatever.cs died, cp generated/Addresswhatever.cs .; mcs <...> Addresswhatever.cs didn't segfault.
[04:06] <NCommander> man
[04:06] <NCommander> It's really not happy
[04:06] <RAOF> Yeah.
[04:07] <RAOF> There's some sort of madness happening.
[04:07] <RAOF> Hm. Maybe it's the length of the command line?
[04:07] <NCommander> The max command line on Linux is 128kb
[04:07] <RAOF> Does mono amd64 know about that? :)
[04:08] <NCommander> Hrm
[04:08] <NCommander> Maybe it just randomly managed to build on Debian
[04:08] <NCommander> A random fluke
[04:09] <RAOF> I don't think so.
[04:09] <NCommander> The Debian version is older it seems
[04:09] <NCommander> according to the changelog
[04:09] <RAOF> Oh, it is.  But I'm building the new package in a sid chroot.
[04:10] <NCommander> If that doesn't fail
[04:10] <RAOF> It doesn't.
[04:10] <NCommander> THen it's either an issue with the evolution API or our mono
[04:10] <NCommander> ****
[04:10] <NCommander> Any ideas?
[04:10] <RAOF> Oooh, that's a fair point; we have a different evolution API, too.
[04:11] <NCommander> If it was real time code that was dying this would be easier
[04:11] <RAOF> I'm going to install some Sid mono packages in an Intrepid chroot, see if that flies.
[04:11] <NCommander> But this is the equivelent debugging GCC
[04:14] <NCommander> I'm currently running --trace on mcs
[04:14] <NCommander> Seeing if I can catch where the compiler bombs
[04:17] <NCommander> RAOF, the bug doesn't occcur when mcs is in ttrace mode
[04:19] <NCommander> RAOF, and the freaking trace log is 2.1GB O_O;
[04:20] <NCommander> RAOF, ping
[04:23] <RAOF> NCommander: :(
[04:23] <RAOF> Builds fine with sid's mcs.
[04:24] <NCommander> d'oh
[04:24] <NCommander> At least we ruled out the evolution API
[04:24] <RAOF> Right.
[04:24] <NCommander> and tells us the problem is specifically with mcs
[04:24] <NCommander> Now we play the patch elimiation game
[04:24] <RAOF> Yeah.
[04:25] <NCommander> Want to check out my FTFBS fixes as a break, I'll work on seeing if I can figure out what patch is doing it
[04:25] <RAOF> Win.
[04:25] <RAOF> They're in the u-u-s queue?
[04:26] <NCommander> u-u-s?
[04:26] <RAOF> Ubuntu universe sponsors
[04:26] <NCommander> I added them to the universe queue
[04:26] <NCommander> Expect for the one which was a main package
[04:26] <RAOF> Right.
[04:26] <NCommander> should be
[04:26] <NCommander> mcurs, purelibc, and ngix
[04:27] <NCommander> er
[04:27] <NCommander> nginx
[04:27] <NCommander> RAOF, I also submitted a fix for libnet-ssleay-perl, but I don't think your a core developer
[04:27] <RAOF> True.
[04:27] <NCommander> (and we're in a soft freeze)
[04:28] <NCommander> All that experience as a debian-porter is paying off
[04:28] <NCommander> (pity its not paying off on my way to be a DD, but eh)
[04:29] <RAOF> Hm.  Those fixes should really be attached to the bug as debdiffs.
[04:29] <RAOF> Unless it's also a new upstream version?
[04:30] <NCommander> I uploaded the debdiffs O_o;
[04:30] <RAOF> You uploaded the .diff.gz
[04:31] <RAOF> Which isn't quite the same; a debdiff (generated by debdiff, oddly enough ;)) is generally a nice, small, reviewable patch against the existing package.
[04:31] <NCommander> Whoops
[04:31] <NCommander> I can fix that >.<;
[04:31] <NCommander> I never generated those before, when someone said debdiff, I thought they meant the diff file autogenerated
[04:32] <RAOF> !debdiff
[04:32] <RAOF> Oooh, that's a bit of an oversight :)
[04:32] <NCommander> yeah
[04:32] <NCommander> Whoops
[04:33] <NCommander> Let me generate those debdiffs
[04:34] <NCommander> I apologize
[04:34] <RAOF> No problem at all.
[04:35] <NCommander> I'm getting weird output fron debdiff
[04:36] <NCommander> oh wait
[04:36] <NCommander> THat's right
[04:39] <NCommander> RAOF, I'm generating them now
[04:42] <NCommander> RAOF, https://bugs.edge.launchpad.net/ubuntu/+source/dmucs/+bug/247767
[04:44] <NCommander> RAOF, https://bugs.edge.launchpad.net/ubuntu/+source/nginx/+bug/247745
[04:48]  * NCommander feels like an idiot over the debdiff thing >.<
[04:53] <NCommander> RAOF, ?
[04:56] <NCommander> ick
[04:57] <NCommander> I think I found the patch that broke the camels back
[04:59] <vorian> NCommander: i believe RAOF was reffering to the lack of a "debdiff" factoid in ubottu as the oversight, not what you are working on :)
[04:59] <emgent> heya nxvl :)
[04:59] <NCommander> I uploaded the actual diff.gz filees >.<;
[04:59] <NCommander> So Now I properly uploaded real debdiffs
[04:59] <vorian> no sweat :)
[05:00] <NCommander> I feel like an idiot though
[05:00] <vorian> excellent
[05:00] <NCommander> Why?
[05:00] <vorian> whoa! no need to feel that way
[05:00] <NCommander> WHat, I'm from Debian
[05:00] <NCommander> I'm assuming the usual pose someone should take when they screw up and the sponsor attacks you :-P
[05:01] <vorian> haha
[05:01] <vorian> you won't get attacked here
[05:01] <NCommander> But I think I found the issue with evolution-sharp
[05:01] <NCommander> Someone commented out an entire function so mono would work on a liveCD
[05:01] <NCommander> in one of the patchs
[05:02] <NCommander> I think this was RAOF's plan, get me to work on evolution-sharp and he can run away in horror :-P
[05:03] <NCommander> vorian, care to check my now fixed debdiffs ;-)
[05:03] <vorian> dmucs?
[05:04] <NCommander> yeah, purelibc, nginx, and libnet-ssleay-perl (which I don't think you can check)
[05:04] <NCommander> ^as well
[05:04] <vorian> sure
[05:04] <NCommander> I got busy ;-)
[05:04] <NCommander> THanks
[05:04] <NCommander> It's amazing seeing my patches go somewhere
[05:05] <NCommander> I'm now interested in beginning the MOTU process
[05:05] <RAOF> NCommander: I'm back, and I'll pick off whatever vorian doesn't get to.
[05:05] <NCommander> And I don't have to go get my key signed :-P (drove 500 miles to get it done)
[05:05] <NCommander> RAOF, I think I found the problem
[05:05] <vorian> i'm looking at dmucs
[05:06] <RAOF> I'll pick up ngnix, then.
[05:06] <NCommander> I'll keep working on evolution-sharp ;-)
[05:10] <NCommander> ./build-csproj: line 180: gawk: command not found
[05:10] <NCommander> I think I found a bug in mono's build-deps
[05:11] <RAOF> That shouldn't be possible, but it's worth checking.  That's from your build log?
[05:11] <NCommander> Yeah
[05:11] <NCommander> It didn't scuttle the build though
[05:12] <RAOF> Ah.  Optional build-dep?
[05:12] <NCommander> I think the script just didn't take in account that gawk could be missing, and thus didn't return -1 to break make
[05:14] <NCommander> It doesn't appear in other build logs, just when I build the package with dpkg-buildpackage
[05:16]  * NCommander waits for news on his package fixes
[05:25] <NCommander> RAOF, I isolated the patch that breaks mono on evolution-sharp
[05:25] <RAOF> NCommander: Wooo!
[05:26] <RAOF> I think I may have found a simpler solution for the ngix FTBFS, too :)
[05:26] <NCommander> THere are simpler ones
[05:26] <NCommander> THat's the right one
[05:26] <NCommander> or a right one ;-)
[05:26] <RAOF> The right one isn't to #include <limits.h>?
[05:27] <NCommander> anyway, if dont_check_proc_self_exe.dpatch is removed from mono, evolution-sharp now compiles
[05:27] <NCommander> RAOF, that didn't work
[05:27] <NCommander> You have to define an addition preprocessor macro to make that work.
[05:27] <RAOF> Heh.
[05:27] <NCommander> you actually need to include stdio
[05:27] <RAOF> Right.
[05:27] <NCommander> with said macro
[05:27] <NCommander> #define need_IOV_MAX or something like that
[05:29] <NCommander> RAOF, the proc patch is incredibly nasty
[05:29] <RAOF> Some header defines that, but you're right, __USE_XOPEN needs to be defined before IOV_MAX gets pulled in.
[05:29] <NCommander> It disables root folder checking in mono
[05:29] <NCommander> Yeah
[05:29] <NCommander> And that does a lot of other things
[05:29] <NCommander> So I think its simpler to properly alias it just to the value the kernel is compiled with
[05:29] <RAOF> I therefore sign off on your patch :)
[05:30] <NCommander> THank you
[05:30] <NCommander> So what should I do about this mono patch
[05:30] <NCommander> Its required (supposidity) to allow mono to work on a livecd
[05:30] <NCommander> But it breaks our build, and probably other packages
[05:30] <RAOF> File a bug against mono, saying that this patch breaks building evolution-sharp on AMD64 in some circumstances.
[05:31] <NCommander> RAOF, how long were you working on that for?
[05:32] <RAOF> The evolution-sharp, or the nthingy?
[05:32] <NCommander> the former
[05:32] <RAOF> Evolution-sharp, since yesterday pretty much.
[05:32] <NCommander> Ow
[05:32] <RAOF> Not _too_ long.
[05:32] <NCommander> Yeah
[05:32] <NCommander> But still
[05:32] <NCommander> It's C#
[05:32] <NCommander> ow
[05:34] <NCommander> RAOF, https://bugs.edge.launchpad.net/ubuntu/+source/mono/+bug/247782 - if you wish to add yourself
[05:34] <NCommander> *sigh*
[05:35] <NCommander> check for typos BEFORE clicking submit -_-;
[05:35] <RAOF> It's editable :)
[05:35] <NCommander> I'l have evolution-sharp fixed once this is taken care of ;-)
[05:35] <NCommander> So consider that FTBFS resolved ;-)
[05:36] <RAOF> nginx uploaded.  Thanks for your contribution.
[05:36] <NCommander> sweet
[05:36] <NCommander> Which contribution?
[05:36] <RAOF> nginx.  Also your evolution-sharp contribution, too :)
[05:36] <NCommander> sweet
[05:37] <NCommander> My first bug fix actually makes it into Ubuntu ^_^
[05:37] <NCommander> (I did notify upstream)
[05:37] <RAOF> Excellent.  Which particular upstream?  Debian, or nginx?
[05:37] <NCommander> Debian
[05:38] <RAOF> Excellent.
[05:38] <RAOF> Even better.
[05:38] <NCommander> reportbug is awesome
[05:38] <RAOF> Moderately so, yes.
[05:38] <NCommander> Just wish I could directly send mail to the debian servers
[05:38] <NCommander> Oh well
[05:38] <NCommander> Were there any issues with the patch?
[05:39] <RAOF> With the nginx patch?  No.
[05:39] <NCommander> I only got to do a NMU on Debian very rarely because finding a sponsor for a NMU is near impossible
[05:40] <RAOF> Right.  I think this is where Ubuntu's "shared responsibility" model works better.
[05:40]  * NCommander is working the debian developer process
[05:40]  * NCommander is not holding his breath however
[05:40] <RAOF> Yeah.  I hear that takes years :)
[05:40] <NCommander> I'm a m68k port
[05:40] <NCommander> (*porter
[05:40] <NCommander> (who also does hurd and kfreebsd part time)
[05:40] <RAOF> Hence building m68k gcc.
[05:40] <NCommander> Building GCC on m68k takes years
[05:41] <NCommander> rofl ;-)
[05:41] <RAOF> Woah.  hurd too?
[05:41] <NCommander> yeah
[05:41] <StevenK> Try OpenOffice or Java
[05:41] <NCommander> It's also why I have a good knack for fixing packages
[05:41] <NCommander> StevenK, those are fine
[05:41] <NCommander> distcc is a wonderful thing
[05:41] <StevenK> Really?
[05:41] <StevenK> You can't distcc gcc?
[05:41] <NCommander> I think we build openoffice in 3 days
[05:41] <NCommander> No
[05:41] <NCommander> It builds itself
[05:41] <NCommander> It first builds a mini-gcc
[05:41] <NCommander> ANd then does the rest of the build with that
[05:42] <StevenK> Ah
[05:42] <NCommander> THe worst part is the GCC release team pushes patches about once a week
[05:42] <NCommander> But it takes ~10 days to build GCC on m68k
[05:42] <NCommander> You see the problem.
[05:42] <StevenK> Hah. Yes. Motorola need to release a faster m68k chip. :-)
[05:42] <warp10> Hi all
[05:42] <NCommander> StevenK, Coldfire
[05:42] <NCommander> But its not ABI compatiable with m68k
[05:42] <RAOF> I count only 2 m68k machines you'd need dedicated to building gcc :)
[05:43] <NCommander> I run five m68k buildds ...
[05:43] <NCommander> >.>;
[05:43] <NCommander> I think I have the equivelent power of an i686 at 700Mhz
[05:43] <StevenK> NCommander: So it doesn't count. :-)
[05:43] <RAOF> Dedicate two to gcc, and they can stagger the builds :)
[05:43] <NCommander> StevenK, Nope
[05:43] <NCommander> RAOF, We usually loose three, because one handles gcj, another does gfortan, and the other does gcc proper
[05:44] <NCommander> But when you have 22 buildds
[05:44] <NCommander> It really isn't so bad
[05:44] <RAOF> Man, m68k sounds like a barrel of laughs :)
[05:44] <NCommander> It's faster then hurd
[05:44] <NCommander> Building glibc on hurd on a dual core processor 2.16Ghz took 24 hours
[05:44] <RAOF> Hurd boots? :)
[05:45] <NCommander> Building glibc on m68k (with distcc) I think takes about 18
[05:45] <NCommander> RAOF, I got it running on real hardware
[05:45] <StevenK> NCommander: You're a masochist, aren't you? :-P
[05:45] <NCommander> and a laptop to boot
[05:45]  * RAOF doesn't really get the point of hurd.
[05:45] <NCommander> Now THAT'S fun.
[05:45] <NCommander> StevenK, no. I don't run an RPM based distro ;-)
[05:45] <StevenK> Haha
[05:45] <vorian> NCommander: any interest in finding some manpages for dmucs?
[05:46] <vorian> :)
[05:46]  * NCommander disappears faster then hurd can panic
[05:46] <vorian> it only needs 5
[05:46] <NCommander> *grumbles*
[05:46] <NCommander> Isn't it susposed to have the manpages coming from Debian?
[05:46] <StevenK> NCommander: Hurd panics?
[05:47] <NCommander> StevenK, I got it to corrupt its own file system by just idling
[05:47] <StevenK> Whee!
[05:47] <NCommander> It's actually not that bad
[05:47] <NCommander> If you use the right hardware, its pretty stable
[05:47] <NCommander> I've never managed to unintentionally bring mach down
[05:48]  * RAOF tries to reconcile  "not that bad" with "corrupt its own filesystem by idling"
[05:48] <ion_> raof: :-)
[05:48] <NCommander> vorian, *sigh*, got a link to a guide to writing your own manpages
[05:49] <NCommander> RAOF, uh .... I ran linux in the 1.x days?
[05:49] <NCommander> and freebsd 2.x?
[05:49] <NCommander> for an 0.3, its not bad
[05:49] <ion_> ncommander: I tend to use asciidoc to write manpages.
[05:49] <RAOF> I've used docbook2man before, that works too.
[05:50] <NCommander> I only wanted to fix the FTBFS, not write documentation >.<;
[05:50] <NCommander> *grumble grumble*
[05:50]  * NCommander looks up how to use the damn thing
[05:51] <ion_> Source: http://gitweb.heh.fi/?p=ion/apt-mark-sync.git;f=man/apt-mark-sync.1.txt;hb=HEAD, result: http://gitweb.heh.fi/?p=ion/apt-mark-sync.git;f=man/apt-mark-sync.1;hb=HEAD
[05:52] <ion_> Also, http://gitweb.heh.fi/?p=ion/apt-mark-sync.git;f=man/Makefile;hb=HEAD might be handy.
[06:11] <NCommander> argh
[06:11] <NCommander> Can't get the name section to show up right
[06:11] <vorian> NCommander: found one
[06:12] <NCommander> For what?
[06:12] <vorian> https://wiki.ubuntu.com/PackagingGuide/Howtos/PODManpage
[06:12] <vorian> easy(er) manpage writing
[06:12] <NCommander> THanks
[06:12] <NCommander> I was trying to do it with nroff
[06:12] <vorian> (for the future of course)
[06:12] <NCommander> Your not going to make me write dmucs's manpages?
[06:13] <vorian> no
[06:13] <NCommander> bah, I already put a good dent in it -_-;
[06:13] <NCommander> I was trying to make the formatting look right
[06:19] <NCommander> pod2man looks kinda weird
[06:29] <NCommander> RAOF, if your still alive, would you like to look at my purelibc patch?
[06:55] <vorian> keep up the good work NCommander
[06:55]  * vorian sleeps
[06:58] <NCommander> THanks
[09:59] <AnAnt> Hello, can someone REVU this swt-gtk upload: http://revu.tauware.de/details.py?package=swt-gtk
[12:07] <RainCT> msg sebner uhm.. why was there a boson rebuild?
[12:08]  * Laney throws a / at RainCT 
[12:08] <RainCT> Laney: :)
[12:11] <DktrKranz> RainCT, be careful when sending love messages with /msg, initial / is very important to keep privacy ;)
[12:31] <sebner> DktrKranz: second package is now also in the new queue \o/
[12:32] <DktrKranz> sebner, Y. R. B.
[12:32] <sebner> DktrKranz: HRHR
[12:32] <devfil> lol
[12:33] <vorian> sebner: nice work with almanah :)
[12:34] <sebner> vorian: thanks for uploading :)
[12:35] <vorian> :)
[12:36] <DktrKranz> vorian, brand new MOTU and already pushed crack from sebner? bad guy :)
[12:37] <sebner> DktrKranz: think about the new possibilities. he could also become a SOTS
[12:37] <vorian> :o
[12:37] <DktrKranz> vorian, RUN!
[12:38]  * vorian sprints away
[12:39] <sebner> DktrKranz: Y. R. B :P
[12:47] <emgent> good morning
[12:47] <sebner> emgent: \o/
[14:13] <NCommander> morning world
[14:14] <geser> Hi NCommander
[14:14] <NCommander> hola geser :-)
[14:15] <NCommander> Is there a nice list of FBFTS? (looking at the qa page I was linked to, its not updated it real-time ;.;)
[14:16] <stgraber> ubuntuwire has that IIRC (or is that what you are referring as not up to date) ?
[14:16] <NCommander> Yeah
[14:16] <geser> it's updated once daily
[14:16] <NCommander> Ah
[14:16] <nhandler> NCommander, Try harvest: http://daniel.holba.ch/harvest/sourcepackages.html
[14:17] <stgraber> Last update: 2008-07-12 02:03:41 +0000 (updated daily at 02:00 UTC)
[14:17] <nhandler> It has a ftbfs column
[14:17] <geser> but you can grab the source for it and run it yourself (takes around 5 min to run)
[14:17] <NCommander> neat
[14:17]  * NCommander should see if I can get buildd.net's scripts to run against Ubuntu
[14:17] <NCommander> That page was/is my best from for dealing with autobuilders on Debain
[14:18] <wgrant> I can always run it more frequently if required.
[14:19] <NCommander> Hola wgrant :-)
[14:19] <NCommander> wgrant, I was told to talk to you if I wanted to help with HPPA FTBFS
[14:20] <nhandler> NCommander, the list on harvest was last updated about 5 hours ago
[14:21] <wgrant> NCommander: Really? I don't find that likely.
[14:22] <NCommander> I think it was you, but my morning coffee still hasn't reached /dev/head, so maybe not
[14:22] <geser> doesn't lamont care about HPPA?
[14:23] <wgrant> geser: He was my first thought, yes.
[14:23] <ScottK-palm> nixternal: Did you see gnomefreak's comment about making sure the .so is removed (re libflashsupport)?
[14:24] <ScottK-palm> geser: lamont's the guy for hppa.
[14:25] <gnomefreak> Nicke_: libflashsupport causes most of the crashes out side of profile corruption, extensions, addons. if its flash crash removing libflashsupport.so fixes 80% (just an example i didnt measure it) of flash crashes
[14:25] <gnomefreak> ack
[14:25] <gnomefreak> Nicke_: not you that was fro nixternal
[14:27] <ScottK-palm> gnomefreak: Please try and catch up with crimsun or maybe TheMuso and get some expert advice.
[14:27] <gnomefreak> ScottK-palm: i will most likely monday
[14:28] <ScottK-palm> It may be we need to abandon the backport until the release gets more mature.
[14:28] <ScottK-palm> See you later.
[14:28] <gnomefreak> ScottK-palm: before that i would rather pull libflashsupport to see if it clears problems up to where its a usable plugin
[14:36] <NCommander> Does the 3-clause BSD license meet Debian FSG/Ubuntu's standard?
[14:36] <hefe_bia> Hi all! I am about to upload a new version of my REVU packages. Should I use standards version 3.8.0.1 or 3.8.0 ?
[14:37] <sebner> hefe_bia: it's fine when you use 3.8.0
[14:37] <hefe_bia> sebner: thanks
[14:39] <NCommander> sebner, does this copyrtight file look right? (I noticed it didn't include the right license)
[14:40] <NCommander> er http://paste.ubuntu.com/26892/
[14:40] <sebner> NCommander: sry, haven't used BSD license so far
[14:41] <NCommander> That's alright
[14:41] <NCommander> Second question, do you know how to get rid of the "Compatibility levels before 4 are deprecated." warnings?
[14:41] <nhandler> NCommander, update the compat file
[14:43] <NCommander> nhandler, What's the current compat level?
[14:44] <nhandler> NCommander, I don't know. I would search the Debian Policy to find out.
[14:45] <slytherin> NCommander: at least 5. Check the version of debhelper mentioned in control file
[14:48] <NCommander> slytherin, there isn't a versioned requirement on debhelper
[14:48] <slytherin> NCommander: then 5 should be ok unless you are using anything specific to debhelper 6
[14:49] <NCommander> it builds with compat == 1 :-)
[14:59] <bdrung> vorian: ping
[14:59] <vorian> bdrung: hi
[15:00] <bdrung> vorian: bug #247725: "The only change made by Ubuntu was a rebuild. So we can safely sync."
[15:00] <bdrung> vorian: http://changelogs.ubuntu.com/changelogs/pool/universe/g/gxmms2/gxmms2_0.7.0-1build1/changelog
[15:01] <vorian> ah, excellent
[15:03] <hefe_bia> REVU commenting seems broken ... :(
[15:07]  * NCommander finally clears all the lintian warnings on this package
[15:08] <wgrant> hefe_bia: Do you get an error?
[15:09] <hefe_bia> wgrant: yes. A python traceback. http://paste.ubuntu.com/26899/
[15:10] <wgrant> hefe_bia: Can you please try again?
[15:10] <wgrant> I touched some of the code earlier, but it seems it was the deployment that went wrong.
[15:10] <hefe_bia> wgrant: still same error
[15:17] <NCommander> Another day, another FTBFS patch filed :-)
[15:17] <hefe_bia> just strange that it seems to be able to access the database for the other stuff... But /me doesn't know about revu code ;)
[15:17] <sebner> NCommander: great =)
[15:18] <NCommander> sebner, care to review ;-)
[15:18] <wgrant> hefe_bia: Indeed, it is very very strange.
[15:18] <NCommander> https://bugs.edge.launchpad.net/ubuntu/+source/transproxy/+bug/247886
[15:19] <NCommander> Is REVU powered by a dak installation, or is it something custom built?
[15:19] <wgrant> NCommander: It is custom built.
[15:19] <sebner> NCommander: I'm no motu (yet) ;)
[15:19] <NCommander> Darn, if it was dak, I have some experience with that beast ;-)
[15:21] <NCommander> morning emgent, Tonio_
[15:22] <NCommander> laptop is telling me to reboot
[15:22] <NCommander> brb
[15:23] <slytherin> NCommander: Add your email address and descriptions to the patches. Note down the patches added in changelog.
[15:28] <NCommander> So I take it no sponsors in here today?
[15:28] <slytherin> NCommander: ﻿Add your email address and descriptions to the patches. Note down the patches added in changelog. And was there any need to change prefix in rules file?
[15:29] <AnAnt> Hello, can someone REVU swt-gtk , I just done a new upload today: http://revu.tauware.de/details.py?package=swt-gtk
[15:29] <NCommander> slytherin, I'm in the changelog, I don't understand wha you mean by descriptions
[15:30] <slytherin> NCommander: edit the patch you added and add description at the starting. Also note down which patch is new and why it was added in debian/changelog
[15:30] <NCommander> The Resolved FTBFS line isn't clear enough?
[15:31] <slytherin> NCommander: ok that is fine, but add patch name there
[15:31] <NCommander> I did add a description to the patch
[15:31] <slytherin> AnAnt: I am not a developer but I will try to find some time to basic review.
[15:32]  * NCommander adds his name too
[15:32] <AnAnt> ok
[15:32] <NCommander> slytherin, package building now in pbuilder
[15:32] <slytherin> AnAnt: about the other package you were trying to fix, don't remember name (something starting with am), you will need to use Sun JDK for compilation.
[15:33] <AnAnt> slytherin: monajat ?
[15:33] <slytherin> AnAnt: yes
[15:33] <AnAnt> slytherin: you mean, it can't be built using gcj ?
[15:33] <slytherin> ﻿NCommander: And why did you change PREFIX in debian/rules?
[15:33] <AnAnt> slytherin: is it because the awt lib ?
[15:33] <slytherin> AnAnt: That looks to be case from build log.
[15:34] <AnAnt> slytherin: I asked the upstream to try to find out the reason
[15:34] <NCommander> slytherin, so dh_installdirs could be used. Once the compat was set to five, it broke using tmp
[15:34] <AnAnt> slytherin: I dunno why he's using awt although he's using swt
[15:34] <slytherin> NCommander: Ok.
[15:35] <AnAnt> slytherin: but there is an awt package for gcj
[15:35] <slytherin> NCommander: now once you update debdiff, suscribe ubuntu-universe-sponsors
[15:35] <NCommander> If there is a better way to do it that takes advantage of dh_installdirs, I'd love to hear it
[15:35] <AnAnt> libgcj8-1-awt
[15:35] <slytherin> Can you point me to latest build log?
[15:36] <NCommander> slytherin, thank you for your help ;-)
[15:37] <AnAnt> slytherin: http://launchpadlibrarian.net/15965071/buildlog_ubuntu-intrepid-i386.monajat_1.0-0ubuntu1~ppa11_FAILEDTOBUILD.txt.gz
[15:38] <slytherin> AnAnt: sun.awt.VerticalBagLayout looks to be Sun specific API
[15:39] <wgrant> hefe_bia: It's fixed now.
[15:40] <AnAnt> I see
[15:41] <slytherin> AnAnt: Also java.awt.SystemTray is only available in java 6. You can try compiling the package with openjdk. But I still think sun.awt will give you trouble.
[15:42] <AnAnt> slytherin: it does build with openjdk
[15:42] <AnAnt> slytherin: I was trying to make it work with gcj
[15:42] <AnAnt> slytherin: to put it in Debian too
[15:43] <slytherin> AnAnt: Have you tried building it with openjdk using pbuilder chroot?
[15:43] <AnAnt> slytherin: yes, I build using pbuilder
[15:43] <slytherin> AnAnt: openjdk will land in Debian soon, hopefully
[15:44] <AnAnt> slytherin: I heard there is a problem in openjdk & sun's jdk, that they don't work on all archs, yet gcj does
[15:44] <AnAnt> something like that
[15:44] <NCommander> slytherin, I look forward to that day; no more nightmare with Java packages on Debian! ;-)
[15:44] <AnAnt> people here (& on debian mentors too IIRC) encouraged me to try make apps build using gcj
[15:46] <slytherin> AnAnt: right, as of now openjdk is known to work only on i386 and amd64. a PowerPC port is available but no idea how well it works
[15:47] <slytherin> AnAnt: Try contacting upstream and ask them not to use sun specific apis and to make systray functionality optional.
[15:47] <AnAnt> slytherin: doesn't gcj support java 6 ?
[15:48] <slytherin> AnAnt: no
[15:48] <AnAnt> I see
[15:48] <AnAnt> well, it is made to be a systray applet
[15:49] <AnAnt> so cannot make that optional I think
[15:50] <NCommander> slytherin, I thought openjdk worked on sparc, I mean, Sun does use the sparc architecture a lot ;-)
[15:52] <slytherin> NCommander: I think they want to have their own JDK on sparc.
[15:52] <NCommander> I was under the impression OpenJDK -> JDK 7 when it was finished
[15:54] <NCommander> slytherin, are you a MOTU or a core-dev?
[15:55] <warp10> Hi all!
[15:55] <slytherin> NCommander: none. :-)
[15:55] <NCommander> slytherin, DD?
[15:55] <NCommander> (you have uncanny knowledge of how to make a patch shine ;-))
[15:55] <slytherin> NCommander: Nope.
[15:56] <NCommander> Ok then, I give. I have no idea what you are ;-)
[15:56] <slytherin> NCommander: when you encounter many packages with no patches containing no description at all or changelog without reason why a patch was added, you learn to take care of it yourself. :-)
[15:57] <NCommander> Sounds about right ;-)
[15:57] <slytherin> NCommander: I am just a java programmer by day and ubuntu enthusiast all the time. Planning to become MOTU in an year or so. :-)
[15:57] <NCommander> slytherin, maybe you can answer me this then, at what point should I consider applying for Contributing developer. I understand you probably should ask for MOTU when people start telling you are ready
[15:57] <NCommander> Oh
[15:57] <NCommander> d'oh
[15:57] <hefe_bia> wgrant: thanks, it works now.
[16:00] <hefe_bia> No MOTUs here today?
[16:00] <cody-somerville> I'm here
[16:02] <hefe_bia> :) Just seemed so because of NCommanders patch discussion
[16:05] <hefe_bia> cody-somerville: Care to have a look at tomboy-blogposter or gebabbel on REVU? I think I have incorporated the suggestions from yesterdays discussion.
[16:06] <alex-weej> there's a mixture of 0.23.3 and 0.23.1 versions of empathy stuff in the archives. i suspect it's what's giving me trouble installing it.
[16:06] <slytherin> alex-weej: which repositories? hardy?
[16:06] <alex-weej> Intrepid
[16:06] <alex-weej> in synaptic, when a version is labelled as (Now), that means it's currently installed right?
[16:07] <slytherin> alex-weej: yes
[16:07] <alex-weej> for the "empathy" package, i have 2 candidates, one of them is 0.23.3 (now) from the telepathy PPA from Hardy and the other is 0.23.1 (Intrepid)
[16:07] <alex-weej> BUT
[16:07] <alex-weej> the package isn't installed!
[16:07] <alex-weej> and i don't even have the PPA active anymore
[16:08] <alex-weej> but there is still, e.g. libempathy-gtk-common at 0.23.3 in the archives
[16:08]  * slytherin has to rush for dinner
[16:15] <AnAnt> Hello, is the "Creative Commons Attribution-Noncommercial-Share Alike 3.0 " license considered free ?
[16:16] <slytherin> AnAnt: I think so. AFAIK, only CC-BY-SA license is considered Free.
[16:16] <AnAnt> that's noncommercial
[16:17] <AnAnt> the reason I ask is because it says:
[16:18] <AnAnt>      * Noncommercial. You may not use this work for commercial purposes.
[16:27] <hefe_bia> user switching killed my X session !?
[16:33] <LucidFox> emgent, a bit late, but congratulations on your MOTUship!
[16:34] <emgent> thanks LucidFox :)
[17:18] <c_korn> hello. I want to add a file to a package which is not automatically moved to debian/tmp/usr/bin. what do I have to change to make include this file into the package?
[17:25] <kpirc> I have uploaded first attempts for packages for 'modglue' and 'cadabra' (a symbolic computer algebra system) to REVU. How do I get this reviewed?
[17:28] <udienz-> !ping #ubuntu-motu admin
[17:28] <udienz-> oh...
[17:28] <slytherin> udienz-: what are you trying to do?
[17:28] <slytherin> kpirc: just wait. Someone will review it at some point of tme
[17:29] <udienz-> slytherin: i can't login into revu.ubuntuwire.com, i try to recover my password but i got messages "There is no REVU account for udienz@ubuntu.com, yet."
[17:31] <slytherin> udienz-: Are you using same email address as you used when creating package?
[17:31] <kpirc> slytherin: ok, thanks.
[17:31] <udienz-> slytherin: yes
[17:32] <slytherin> udienz-: I am not developer so can;'t help you musch
[17:33] <udienz-> slytherin: nope, maybe i must waiting for a while?
[17:38] <sebner> warp10: around?
[17:38] <warp10> sebner: here, for a few minutes more
[17:39] <sebner> warp10: I saw you filed a bug for asunder in debian(wnpp) are you packaging it? if not I'd do it (I started some minutes ago with it)
[17:40] <sebner> hi RainCT
[17:40] <warp10> sebner: I am packaging it indeed, and I have almost finished it (just waiting for an answer from the upstream developers)
[17:41] <sebner> warp10: ok, np
[17:42] <warp10> sebner: fortunately, there soooo many needs-pacaking tagged bug in LP :)
[17:42] <sebner> warp10: /me can't find them xD
[17:45] <warp10> sebner: really? I see 974 of them :)
[17:46] <warp10> sebner: BTW, whatever DktrKranz I saying to you about me: please, don't believe him! :P
[17:46] <sebner> warp10: maybe you have magic powers or you can use the launchpad search right xD
[17:46] <warp10> sebner: https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=needs-packaging
[17:46] <sebner> warp10: lol, thanks for the link!
[17:47] <warp10> sebner: my pleasure!
[17:47]  * sebner hugs warp10 
[17:47]  * warp10 hugs back sebner
[17:47] <DktrKranz> warp10, I'm not saying anything, I'm just writing
[17:48] <warp10> DktrKranz: mmm... fair enough :)
[18:11] <goshawk> hi, where can i find the list of package section of ubuntu?
[18:12] <goshawk> sections
[18:13] <RainCT> goshawk: file:///usr/share/doc/debian-policy/policy.html/ch-archive.html#s-subsections
[18:17] <goshawk> ah... it's the same of debian one
[18:17] <goshawk> ok
[18:18] <slytherin> goshawk: what did you expect?
[18:19] <goshawk> maybe another one... i thought it was the same, but now i have references :)
[18:45]  * hefe_bia got alpha2 running on vmware :D
[18:46]  * slytherin hates arch:all packages form Debain contrib. :-(
[18:46] <slytherin> s/Debain/Debian
[18:48] <foolano> hi
[18:49] <slytherin> foolano: hi
[18:49] <foolano> what should i do if wanted to have a stable and unstable ppa? create two separated teams?
[18:50] <cody-somerville> foolano, that or two packages
[18:51] <foolano> cody-somerville: thx
[18:51] <slytherin> foolano: you can simply have two different package names.
[18:51] <foolano> but i want user to automatically upgrade from the stable branch
[18:53] <foolano> isnt it clearer to have separated ppas?
[18:53] <slytherin> foolano: sure, have two teams or two persons with PPA
[18:54] <foolano> ok thx a lot
[19:02] <nijaba> Hello, I would need some guidance on how to fix the debian/copyright of http://revu.ubuntuwire.com/details.py?package=limesurvey
[19:03] <ScottK> foolano: Are you using the installed package installed config files for Postfix with ebox or do you use your own?
[19:06] <hefe_bia> nijaba: Let me have a quick look...
[19:07] <nijaba> hefe_bia: thanks :)
[19:12] <foolano> ScottK: our own. For now I just made some changes from the debian sarge version to make it work with hardy and release a package which can be tested for our users. I still have to check the conf you use for intrepid to base our conf on that.
[19:13] <ScottK> foolano: I'm working with lamont to add some helper scripts to the Postfix package to make external management easier.
[19:13] <foolano> and I still have to nag you with some questions releated to that. I should start working on that in a week
[19:13] <ScottK> I'm about to go out now, but we should takl about what you'd need.
[19:13] <ScottK> Sure.
[19:14] <foolano> ScottK: cool
[19:14] <ScottK> main.cf can be manipulated via postconf pretty well.
[19:14] <ScottK> It's adding stuff to master.cf that's missing.
[19:14] <hefe_bia> nijaba: I'm not sure whether it is reasonable to include the License Preamble for every of the included or derived from packages, but you'll have to at least give a pointer to the licenses in /usr/share/doc for the other licenses (GPL, LGPL, Apache...)
[19:15] <foolano> ScottK: I'll show you what changes we make to those files
[19:15] <nijaba> hefe_bia: ah, ok, I see what is needed now.  Thanks a lot.
[19:15] <ScottK> foolano: Would you email me?
[19:16] <foolano> ScottK: yeah, if that's fine for you
[19:16] <ScottK> Yes.
[19:16] <ScottK> I'll be back later, but have to go schlep teenagers across town.
[19:17] <hefe_bia> nijaba: glad to help
[19:17] <foolano> ScottK: ok, thanks
[19:19] <hefe_bia> reading emmet's comment on nijaba's packages... Are there template files for README.source for the common patch systems?
[19:20] <nijaba> hefe_bia: I made one up for quilt, I could add it to a page if that could be usefull.  my seach on *.ubuntu.com or *.debian.org did not turn anything
[19:21] <hefe_bia> nijaba: That would be cool as I use quilt, too and just realized my packages aren't 3.8.0 ready, too ;)
[19:22] <nijaba> hefe_bia: what do you think of emmet's comment #7?  I think he understood the simlinks the wrong way aroung.  the link is from /usr/... to /etc, not the other way around
[19:22] <nijaba> so the orig file is the one in etc and is installed as conf file
[19:26] <hefe_bia> nijaba: Is he referring to the postinst script? I see links made with ln -s file /etc/.../file
[19:26] <nijaba> hefe_bia: aha, maybe, let me check that.  thanks again
[19:27]  * hefe_bia has to go now. Guests are here ...
[19:32] <nijaba> just created https://wiki.ubuntu.com/PackagingGuide/README.source if anyone cares
[19:41] <slytherin> nijaba: Please move it to other namespace if possible and include the url from https://wiki.ubuntu.com/PackagingGuide/Complete.
[19:42] <nijaba> slytherin: what namespace would you suggest?
[19:42] <slytherin> nijaba: same as other urls like control, copyright are using. I think it is Howto/topic.
[19:43] <slytherin> nijaba: Edit the complete guide page and you will know.
[19:50] <nijaba> slytherin: ok, changed to README.sourceHowTo and update https://wiki.ubuntu.com/PackagingGuide/Lists/PatchingTips to point to it. Is this proper?
[19:51] <slytherin> nijaba: let me check
[19:53] <slytherin> nijaba: fine. I still think you should also include it from 'Complete' page
[19:53] <nijaba> slytherin: but the complete page is a collection of includes, if I am not mistaking
[19:54] <slytherin> nijaba: yes, so simply add your page to the list at appropriate place
[20:35] <Drk_Guy> Can someone help out?
[20:35] <Drk_Guy> I'm having a weird error with dpkg-source
[20:36] <Drk_Guy> dpkg-source: aviso: el directorio fuente './wine-1.1.1~winehq0~ubuntu~8.04~3DMark-1~ppa-1' no es <sourcepackage>-<upstreamversion> 'wine-1.1.1~winehq0~ubuntu~8.04-1~3DMark-1~ppa'
[20:43] <Drk_Guy> Guys...
[20:43] <Drk_Guy> This is a lil bit uncool, can anyone help?
[20:43] <cody-somerville> Well, I can't read spanish or I'd try to help you ;]
[20:44] <Drk_Guy> cody-somerville, I can help out in that
[20:44] <Drk_Guy> It is telling that "source dir is not <sourcepackage>-upstreamversion>
[20:46] <cody-somerville> DreamThief, The directory name needs to match <sourcepackage>-<upstreamversion>
[20:46] <cody-somerville> Anyhow, sorry but I gotta jet :)
[20:47] <Drk_Guy> Ok
[20:47] <Drk_Guy> But it is "wine-1.1.1~winehq0~ubuntu~8.04~3DMark-1~ppa-1" isn't it accordingly named=?
[20:48] <cody-somerville> Check the changelog and see :)
[20:49] <Drk_Guy> changelog's name is the same
[20:49] <Drk_Guy> I just added that 3DMark because i'm patching it
[20:50] <cody-somerville> the upstream version, not package version
[20:50] <cody-somerville> what is the name of the source tarball?
[20:51] <Drk_Guy> cody-somerville, wine_1.1.1~winehq0~ubuntu~8.04.orig.tar.gz
[20:51] <Drk_Guy> I used YokoZar's one
[20:51] <Drk_Guy> Official winehq's ubuntu mantainer
[21:12] <YokoZar> Drk_Guy: The directory needs to be the package version WITHOUT the last -foo at the end (usually -1 or -0ubuntu1 or similar)
[21:13] <YokoZar> so blah-blah-foo-2-2-1ubuntu1 would be in directory blah-blah-foo-2-2
[21:14] <Drk_Guy> YokoZar, Gonna try removing the -1 out of ppa-1
[21:14] <Drk_Guy> Thanks YokoZar, i'm gonna be a sub-mantainer of wine
[21:14] <Drk_Guy> XD
[21:15] <Drk_Guy> YokoZar, Still, it's the same
[21:21] <Drk_Guy> YokoZar, you there?
[21:46] <sebner> nhandler: congratulations :)
[21:46] <nhandler> Thank you sebner