[00:00] <NCommander> Can not upgrade
[00:00] <NCommander> An upgrade from 'jaunty' to 'intrepid' is not supported with this tool.
[00:00] <NCommander> Thats a new error
[00:01] <jmarsden> NCommander: Maybe "an upgrade from jaunty to intrepid is a downgrade" would be a better error message? :-)
[00:02] <NCommander> update-manager obviously isn't fully aware of Jaunty at this time
[00:02]  * NCommander uses aptitude
[00:13] <RainCT> good night
[01:00]  * ScottK smites a user and doesn't feel a bit guilty.
[01:00] <ScottK> (-devel-discuss)
[01:00] <directhex> mono_2.0-1_i386.changes uploaded successfully to localhost
[01:02] <ajmitch> now people can stop complaining so much
[01:02] <ajmitch> to experimental?
[01:03] <directhex> ajmitch, aye
[01:03] <directhex> ajmitch, of course, 2.0.1 is out do they still get to complain
[01:03] <ajmitch> heh
[01:03]  * ajmitch saw that someone is wanting to package portable.net again
[01:03] <ajmitch> I really don't think it's that useful
[01:04] <directhex> apps need to make use of the new deps following the latest package split though
[01:04] <directhex> ajmitch, hanska? I told him not to bother
[01:04] <ajmitch> there's so much that just won't run
[01:07] <jdong> *glares at nspluginwrapper*
[01:07] <jdong> stupid untraceable segfaults
[01:07] <directhex> nspluginwrapper sucks *so bad*
[01:07] <jdong> any pointers on how to figure out more than "??? () in /lib32/libc.so.6"?
[01:07] <directhex> if only we had a rich media plugin with actual source, with actual amd64 versions
[01:08] <directhex> on a completely unrelated note, anyone for moonlight packages?
[01:08] <ajmitch> those sort of things generally indicate missing debug symbols, but I'd assume you have those installed
[01:08] <jdong> directhex: sigh you and your mono rhetoric
[01:08] <jdong> *ducks*
[01:08] <jdong> ajmitch: are there debug symbols for ia32-libs?
[01:08] <crimsun> (swfdec isn't so bad)
[01:08] <ajmitch> directhex: you want people to package moonlight, or test packages?
[01:08] <ajmitch> jdong: no idea
[01:08] <directhex> ajmitch, well, i have packages ready already for 0.8.1, but it's not so useful right now
[01:08] <ajmitch> why not?
[01:09] <directhex> doesn't work on many sites. 1.0 should have "full" silverlight 1.0 compatibility... unfortunately SL2 was released recently & many sites have updated to target it
[01:09] <ajmitch> chasing a moving target is fun
[01:09] <directhex> especially for a young project
[01:10] <directhex> 1.0 is branched though
[01:10] <ajmitch> yes, it's not so bad for flash
[01:10] <directhex> it does do *something* though - http://www2.apebox.org/wordpress/wp-content/gallery/00-single/moonlight.png
[01:11] <directhex> initial support for SL2 should arrive relatively quickly - the first major chunk of code, the silverlight classlib, is already provided by mono; the second major chunk of code, the silverlight widget toolkit, was released by MS under a free software license to help accelerate SL development
[01:13] <directhex> so the moon devs "just" need to pull it all together & bugfix it to death
[01:14] <ScottK> Right, but many of us will consider 'doesn't support $DRMSCHEME' a feature (doesn't matter much that's it's MS').
[01:16] <directhex> i suspect building against ffmpeg rather than letting it download the binary codecs from microsoft.com is a pretty good way to guarantee it won't support drm
[01:17] <ScottK> OK.  Then maybe I don't understand what silverlight is about.
[01:17] <jdong> isn't that also a pretty good way to guarantee it isn't legal in NA?
[01:17] <jdong> ScottK: it's basically the .NET equivalent of Macromedia Flash.
[01:17] <ScottK> Ah.
[01:17] <jdong> rich multimedia/UI applet system
[01:17] <ajmitch> what did you think it was?
[01:17] <ScottK> OK.
[01:17] <jdong> ajmitch: probably a media format
[01:17]  * ScottK thought it was MS DRM thing.
[01:18] <jdong> it's primarily used these days for streaming video, i can see the misconception
[01:18] <ScottK> Shows how much attention I pay.
[01:19] <directhex> jdong, libavcodec's in main.
[01:21] <jdong> directhex: which isn't legal in the US.
[01:21] <jdong> directhex: if you notice, no North American Linux vendor dares ship with MP3, MPEG4, etc decoders deriving from libavcodec.
[01:21]  * jdong points at the $50 fluendo codec pack
[01:23] <directhex> jdong, talk to siretart. someone decided ffmpeg was worth putting in main, albeit with some elements removed
[01:23] <jdong> directhex: hey I was in favor of that too
[01:24] <jdong> directhex: I'm just pointing out, that, technically you cannot use it in the US due to GPL incompatibility with the patent/royalty terms for the codecs being decoded
[01:24] <jdong> is Bob at home going to care? Probably not. But any Linux product or business deployment of Linux should probably care.
[01:25] <directhex> which is why upstream don't distribute binaries built against ffmpeg
[01:26] <directhex> but ubuntu *does* build things against ffmpeg, hence the rather large rdepends list
[01:28] <jdong> I guess fundamentally, it's whether or not Ubuntu *cares* about software patent laws in one particular jurisdiction.
[01:28] <jdong> my gut feeling to that is, no. the archive should care about redistributability according to software licenses, not silly particular laws in each jurisdiction.
[01:29] <directhex> you'd be lucky to escape with anything beyond /bin/true in the archive if you started trying to follow the rules for 300+ countries on every package
[01:29] <directhex> and even that would be touch and go
[01:29] <jdong> directhex: exactly
[01:30] <jdong> I think where we draw the line between main and multiverse's -unstripped variant is the presence of patent-covered encoders. I think legal history shows that when you use an encumbered encoder without paying the royalty, that's when "they" start caring.
[01:30] <jdong> but, if you look at Novell or Redhat "stripped" ffmpeg, it's literally down to PCM/WAV, ogg vorbis, and theora.
[01:30] <directhex> so i got confused. was that a "yay!" or a "boo!" to linking moonlight against ubuntu's ffmpeg?
[01:31] <jdong> directhex: I don't know, to be honest. I'd like that to be a personal "yay" but maybe a boo to commercial Ubuntu users.
[01:31] <jdong> directhex: is it not possible to make it a choice which to use?
[01:32] <directhex> jdong, the alternative, which i suspect would receive a more negative response (ironically), would be to disable media support, and rely on the plugin offering you to agree to a microsoft eula and download some .so files from microsoft.com
[01:32] <directhex> jdong, could i package both? i dunno, might need to run configure/make twice, or have a second source package
[01:32] <directhex> and the ms media pack is i386/amd64 only
[01:32] <jdong> directhex: eep the archive admins typically don't like the 2-source-package approach. Does ffmpeg offer the same spectrum of codec support as the binaries? (I bet not)
[01:33] <jdong> directhex: if this is going to affect watching populare Silverlight streaming media sites, then I'd say it's important to at least offer the choice of MS binary codecs
[01:33] <directhex> jdong, in my tests, ffmpeg-from-main has complete support for the 9 codecs required by silverlight except for one rarely-used audio codec
[01:34] <directhex> jdong, but it's possible the ms media pack would also enable drm-protected media playback (urgh), which obviously ffmpeg won't do
[01:34] <directhex> i'd need to ask upstream
[01:35] <jdong> directhex: as much as I hate DRM-protected media, it's probably going to create more unrest in the userbase if we don't support it :(
[01:35] <jdong> I don't think we personally gain much from a "DRM sucks so we don't support it on purpose" outlook
[01:35] <directhex> jdong, i suspect people will burn effigies of me either way
[01:36]  * jdong agrees :)
[01:36] <directhex> on a related note, who feels like syncing mono from experimental? ^_^
[01:36] <directhex> hang on, it'll still be in NEW
[01:36]  * wgrant incinerates directhex.
[01:37] <directhex> wgrant, i prefer the term "immolates"
[01:38] <directhex> i've asked upstream. silverlight 1.0 has no DRM capability, so moonlight doesn't either. so we only lose one audio codec by linking ffmpeg instead of using the ms media pack
[01:38] <directhex> silverlight 2.0 reopens the question
[01:40] <superm1> can you not drop in place a codec pack and have that used though, or does it really have to be linked?
[01:40] <directhex> jdong, http://wiki.debian.org/Teams/DebianMonoGroup/Moonlight#head-269adabf77c0d3971046e1d0b1413878912bf0cb
[01:41] <directhex> superm1, the codec pack is designed to drop in-place, but my understanding is it requires the plugin to have been explicitly built without ffmpeg support - you can't have ffmpeg AND mscodecs in the same plugin
[01:41] <superm1> oh that's going to be annoying
[01:41] <superm1> fallback support would be nice...
[01:42] <directhex> i know. it's an open question really
[01:42] <directhex> for now... i dunno. once 1.0 is tagged & i have a tarball to work with, i'll muck about with the possibilities
[01:43] <directhex> i'm trying to make this a first-class package. all the special debian/control values for Ubufox and everything
[01:47] <jdong> superm1: agreed, it'd be REALLY nice if it can fallback to one or the other
[01:47] <directhex> perhaps two packages then, even if it means messy mangling of the source package. one could get listed by the plugin finder as "Novell Moonlight (evil binary codec support)" and one as "Novell Moonlight (freedom-loving joy edition)" or somesuch
[01:47] <jdong> i.e. like the gstreamer pluggable infrastructure
[01:47] <jdong> directhex: yeah I think in this case it's not a bad idea to offer two alternatives
[01:47] <superm1> directhex, at least until fallback support is in the plugin itself, i think that would be a good solution
[01:47] <jdong> one built with MS codec support, one with ffmpeg linking
[01:48] <directhex> is running ./configure and make twice in one package acceptable?
[01:48] <jdong> at least a couple packages in the archive do this.
[01:48] <superm1> i've seen it before in some package
[01:48] <directhex> names would help
[01:49] <jdong> one of the media apps does this for static and non-static versions of its library...
[01:49] <jdong> trying to think of which
[01:53] <superm1> i thought some app did it for a gui and non gui version of itself too
[01:53] <superm1> again not much help though since i dont remember :)
[01:53] <crimsun> vlc used to.
[01:54] <crimsun> it was a royal PITA, and I'm very glad that's no longer the practise.
[01:54] <jdong> crimsun: hey while I have you here, have you looked into that pulseaudio suspend/resume issue/workaround?
[01:55] <crimsun> 202089?
[01:55] <crimsun> if so, yes, hyperair and I chatted about it last night
[01:55] <jdong> crimsun: yeah that's the one
[01:56] <crimsun> my concern is that it's not sufficient, and it needs more testing to verify that it doesn't reintroduce 8.04's suspend-on-idle race
[01:56]  * jdong nods
[01:57] <crimsun> (the race concerns multiple audio devices, one of which is external, usually usb-audio, so when loading/enabling module-suspend-on-idle, module-alsa-s{ink,ource} bomb)
[01:57] <jdong> I was bitten by that bug after hibernate yesterday, pidgin immediately found it amusing to swap the system to death
[01:57] <jdong> hmm shame I don't have multiple audio devices or external ones so I can't really test that personally
[02:02] <gouki> When submitting an ITP, is there something that needs to be done on Ubuntu side? Add the link to the bug on LP or REVU, or something like that?
 moon allows both
 it defaults to using mscodecs if available
 but it wont prompt you to install the mscodecs unless you reach a site with a missing codec
[02:05] <directhex> superm1, seems it already does what we need :)
[02:19] <zul> james_w: around?
[02:22] <nhandler> What files should I attach to a bug report requesting that a package be upgraded to a new upstream release? This isn't a merge/sync request from Debian.
[02:22] <woody86_> any body have problems updating their packages after upgrading to 9.04? I try to do a partial upgrade, but then it says "Can not upgrade. An upgrade from 'jaunty' to 'intrepid' is not supported with this tool"
[02:22] <directhex> nhandler, ideally, a new diff.gz ;)
[02:23] <nhandler> directhex: Do they still want the interdiff?
[02:23] <directhex> nhandler, god knows. i lost track of which diffs to use when. i found the easy option was just to work on debian
[02:24] <nhandler> directhex: That is why I am asking here. I can't even find the wiki page that talks about this anymore
[02:26] <nellery> nhandler: it's just the .diff.gz
[02:27] <NCommander> hey persia
[02:27] <nhandler> Thanks nellery. By any chance do you have a link to the wiki page that mentions this? I know it exists, I just don't know where it is (I lost my bookmarks after the upgrade)
[02:27] <nellery> nhandler: sadly no, I figured this out from irc
[02:30]  * persia goes off to find the documentation of interdiff, and update it.  Please attach debdiff for the same upstream version, or a merge, and diff.gz for a new diff.gz
[02:32] <directhex> s/new diff.gz/new upstream version/ ?
[02:32] <persia> Yes.
[02:33] <directhex> bedtime.
[02:34] <nhandler> Night directhex
[02:36] <persia> Anyway, hints for submission to the sponsoring queue are at https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue (and now actually say the right thing)
[03:22] <nhandler> I just put together a quick script that lists how many packages each Developer still needs to sync/merge from Debian. It gets its list from DaD's last Ubuntu uploader field. Enjoy: http://nhandler.servehttp.com/merges.pl
[03:24]  * persia points out that merges aren't strictly assigned, and that just because one isn't listed doesn't mean one's work is done : UEHS lists *lots* of packages.
[03:28] <nhandler> persia: I am aware of that. However, the person listed as the last Ubuntu Uploader is the one who usually gets first dibs at performing the merge/sync. If they do not wish to carry out this task, they are able to comment on it on DaD, and someone else will take care of it for them.
[03:30] <lifeless> nhandler: of course, this then means that folk that are overloaded have to comment on huge numbers of packages to say they can't do stuff?!
[03:31] <nhandler> lifeless: It isn't a requirement. However, it makes it clear to other people that that person is not planning on performing the merge.
[03:35] <lifeless> nhandler: but that clarity is only needed because you're asserting that the last toucher has some sort of lock
[03:35] <lifeless> Ubuntu doesn't have maintainer locks though, so -> I am confused
[03:36] <nhandler> lifeless: I never said they had a lock. However, in most documents regarding merges, it does say that you should contact the last ubuntu uploader prior to performing the merge. This implies that they do have first dibs on the merge (like I stated)
[03:37] <crimsun> I've had reservations about that guideline; it tended to introduce latency in previous merge cycles
[03:38] <wgrant> I think that convention is being ignored more and more, fortunately.
[03:38] <nhandler> wgrant: Last cycle, they sent out an email telling people to ignore that convention (I think after DIF).
[03:40] <ScottK> It was right about DIF.
[03:41] <ScottK> OTOH I've seen people who don't understand packages dive in and do bad merges.  If someon who is familiar with a package is going to do it, they should be able to.
[03:48] <NCommander> Unpacking OO.o build tree - [ go and have some coffee ] ...
[03:48] <NCommander> That's not a good sign for the time this build will take ...
[03:50] <ScottK> NCommander: Work on my library problem while you wait ...
[03:50] <wgrant> NCommander: You have reached a new level of insanity.
[03:50] <NCommander> wgrant, I'm building it on a 733Mhz processor :-)
[03:50] <wgrant> And another.
[03:51] <NCommander> I wonder if LTS+1 will be out by time it finishes
[03:51] <NCommander> wgrant, with only 256MB of RAM
[03:51] <wgrant> Oh, then it'll be quick.
[03:51] <wgrant> ... to be OOM-killed.
[03:51]  * NCommander has 4GB of swap
[03:52] <lifeless> how does the build go again? malloc(4000000000);
[03:52] <wgrant> lifeless: No; that's too quick.
[03:52] <NCommander> Anyone want to take estimates to when it finishes building?
[03:52] <wgrant> lifeless: It malloc(1)s lots of times.
[03:53] <ScottK> NCommander: I predict it won't finish.
[03:53] <NCommander> Probably
[03:53]  * ScottK once tried to build Eclipse on a similar machine.
[03:53] <ScottK> It died.
[03:53]  * NCommander did build Eclipse on this
[03:53]  * NCommander build OOo on an m68k
[03:53] <NCommander> *built
[03:54] <NCommander> The build time was something like 3-4 weeks
[03:54] <NCommander> But it compiled from source!
[03:54] <wgrant> Why would one want to build OOo on m68k?
[03:54] <NCommander> To be a release architecture on Debian, you need 98% of the archive built, and 95% up-to-date
[03:55] <NCommander> and we have a few free buildds
[03:55] <NCommander> :-)
[03:55]  * NCommander notes we scare the Gentoo m68k users
[03:56] <NCommander> wgrant, w.r.t. to sanity, I'm hoping I hit the insane counter upper limit, and it rolls into sanity
[03:57] <NCommander> O_o;
[03:58] <NCommander> the diff is over 100MB :-/
[03:58] <NCommander> compressed
[03:59] <NCommander> WOO, ./configure is running
[04:24] <NCommander> ScottK, O___o, I didn't know we allowed non-MOTU to be mentors
[04:24] <nhandler> NCommander: UCD's are allowed to be mentors in the Junior Mentoring Program
[04:25] <nhandler> I believe you need to be a MOTU to be a mentor in the senior mentoring program
[04:25] <NCommander> That seems like a *really* bad idea since we have no bar to measure what UCDs actually know
[04:25] <NCommander> nhandler, see Scott's message to the list, and my follow up
[04:26] <wgrant> NCommander: What's so chaotic about pulseaudio being removed?
[04:26] <NCommander> it took ALSA with it
[04:27]  * nhandler is reading the messages now
[04:28] <ScottK> NCommander: I found the deadly symbol in libspf2.
[04:28] <NCommander> 1. what, and 2. how?
[04:28] <ScottK> __libc_subinit
[04:28] <nhandler> NCommander: Personally, I don't think there should be rank restrictions on who can be a mentor. If someone is willing to teach and has the knowledge, that should be enough. Maybe we should create a quiz to verify that the mentors know what they are talking about (for non-MOTUs)
[04:28] <NCommander> ScottK, O_o;
[04:28] <ScottK> Found a reference to private libc symbols starting with __libc (thanks to Google) and then grepp'ed the source.
[04:29] <wgrant> nhandler: If the mentors know what they're talking about, why aren't they MOTU?
[04:29] <NCommander> Ah
[04:29] <nhandler> wgrant: You need more than knowledge to become a MOTU
[04:29] <ScottK> NCommander: Any chance you could look at it and see if you can come up with an appropriate patch to avoid that?
[04:29] <NCommander> nhandler, the only exception I could see are people who are DDs, and haven't been here that long, but those are few and far between, and even then, I'd perfer that they be MOTU so we know that they're aren't going to teach invalid packaging techniques
[04:30] <NCommander> ScottK, you know, this library the freaking bastard child from hell :-P!
[04:30] <ScottK> nhandler: Yes, but right now apparently the rule is there is no actual requirement for any technical knowledge at all.
[04:30] <NCommander> Oooooh
[04:30] <ScottK> NCommander: It's a "Learning experience".
[04:30] <NCommander> Ew
[04:30] <nhandler> ScottK: That is true. They are assuming that UCDs know what they are talking about
[04:30] <nhandler> That is why I suggested a quiz
[04:30] <NCommander> The reason this uses an internal glibc symbol is because it uses an internal glibc library
[04:31] <ScottK> nhandler: And that's the flaw.  UCD is not somehting you get for technical expertise.  "They know because they are UCD" is a logical falacy.
[04:31] <crimsun> it's a good idea to have some sort of DM/DD/MOTU guideline for mentoring.  that said, there have been mentors who are no longer MOTU or DM/DD.
[04:33] <NCommander> ScottK, yeah, I think I can fix this
[04:33]  * NCommander pukes
[04:33] <nhandler> There is no way to keep people from teaching. We have a large forum community of people trying to "teach" each other. We do not restrict who is able to teach there.
[04:33] <nhandler> The only nice thing about the Mentoring Program is that it takes care of the hassle of hunting down a person who knows about MOTU-related activities
[04:33] <ScottK> nhandler: Agreed, but it's different if we say, "Here is your official mentor.  Listen to him."
[04:33] <nhandler> But what makes it "official"
[04:33] <fabrice_sp_> Hi. I was looking at Bug #284910, and it appears to be because of libtool. Why Debian version is 1.5.26 and ubuntu one, 2.2.4? Is there a way to use  the Debian version in Ubuntu?
[04:34] <fabrice_sp_> (It's a FTBFS in Intrepid)
[04:34] <ScottK> nhandler: It's the MOTU mentoring program.
[04:34] <nhandler> For instance, persia helped teach me the basics of patching when I first got into development. I never went through the mentoring reception. I still consider him my mentor (even though it wasn't official)
[04:35] <persia> nhandler, You were registered in that program, and when we lost touch, I sent a note saying that it had ended, although I've been glad to see you back, and with your work since then.
[04:35] <nhandler> persia: I was? I never remember sending them an email
[04:36] <ScottK> nhandler: That's great.  That's the kind of mentoring I'm in favor of.
[04:36] <persia> nhandler, You didn't : you asked me, and I fed your name to them because we were already in touch, and I didn't have time for more people.
[04:37] <NCommander> ScottK, ok, I think I got it
[04:37] <ScottK> NCommander: Cool.
[04:38] <nhandler> persia: Ok, but the difference is, you started mentoring me, and then you informed the reception about that (so that they knew you couldn't mentor anyone else). I didn't actually go through the reception to get you
[04:40] <ScottK> NCommander: You're MOTU now and it's in Universe, so go for it.
[04:41]  * NCommander hates mucking around with auto****
[04:42] <ScottK> B.S.  You love it and you know it.
[04:43] <persia> nhandler, Sure, but you also showed up in this channel a couple times, and were clearly looking for someone, and that happened to be the same week the Mentoring Program started, so it's a bit of a special case.  Had there been a program then, you probably would have signed up.
[04:43] <ScottK> Had there continued to be no program he probably would have gotten help just fine too.
[04:44] <nhandler> persia: I did not realize the mentoring program was just starting up then. And ScottK, you are correct, I probably would have continued without the program. But it was nice having a mentor.
[04:48] <persia> nhandler, Whether there is a MOTU Mentoring Program or not doesn't necessarily affect that.  If I remember correctly, you had looked at one of the bugs I'd offered to mentor as a starting point.  Whether self-selected LP declaration of mentoring is any better than a matching spreadsheet is unknown.
[04:50] <persia> Given the number of people who seem to want to find a mentor before they do any work, I'm not tempted to throw away the Mentoring Program, but so far it's not shown itself to be significantly better than what proceeded it.
[04:50] <ScottK> persia: One way I think it's almost certainly different is that when a perceived authority says to a new person, "Here is your official mentor", said new person is much more likely to assume they know what they are talking about.
[04:51] <nhandler> persia: That is true. I started with one of the bugs you had offered to mentor. This method has 1 advantage. Usually, if a person is offering to mentor someone on a bug, it means that that person knows how to fix the bug and is willing to teach someone else how to do that.
[04:51] <ScottK> persia: How many people want to wait because there exists a program to provide mentors and so that's thought to be the appropriate path?
[04:51] <nhandler> Well, I'm too tired to think straight any more. I'm off to bed.
[04:51] <ScottK> Good night.
[04:52] <persia> ScottK, unquantifiable, although both before and after there was such a program, some people would ask for a mentor and weren't satisfied with "here's some bugs, ask here if you get stuck".
[04:53] <ScottK> True, but I've always considered if you aren't a bit of a self-starter you won't be around here for long anyway.
[04:53] <persia> I'd say that there are several groups of folk: those that just do, those that want a mentor,and those that are trying to figure out the best way to get started.  No idea about percentages though.
[04:55] <persia> Well, you don't have to be a self-starter, but you do need to have some reason to be doing.
[04:56] <ScottK> Fair enough.
[04:56]  * persia would actually prefer a wider variety of motives to be working on Ubuntu :)
[04:59] <jmarsden> For me it's hard to be at all consistent without an external "reason to be doing", so far... I'm active for a week or two and then Real Life comes along and I stay away for weeks... which is why I'm still not even a contributor, never mind a MOTU :-)
[05:02] <ScottK> jmarsden: Yes, but stick with it and you'll get there.
[05:02] <ScottK> We all come and go to some degree.
[05:03] <jmarsden> Yes, I intend to ... if I had a month's vacation to do nothing but this stuff, I'd be there now :-)
[05:03] <ScottK> ;-)
[05:05] <ScottK> Do we have a spot on the wiki for little tips and tricks?
[05:05]  * ScottK just ran into a situation with a package that now builds in Jaunty and believes it should depend on a non-existant package called glibc_private.
[05:06] <lifeless> sweet
[05:06] <ScottK> It turns out this means that the package is building against private glibc symbols and this is no longer allowed, so the package is built uninstallable on purpose.
[05:06] <ScottK> So the trick is to find said symbol and make it go away.
[05:06] <lifeless> yay binary uploads to debian
[05:07] <wgrant> It was never allowed.
[05:07] <ScottK> OK.  It no longer works.
[05:07] <wgrant> Right.
[05:07] <ScottK> This package has been in Ubuntu since a very long time and the offending bits are there from the beginning.
[05:07] <wgrant> Eww.
[05:08] <persia> You might put it under recipes.  All the other tips&tricks seem to have gone.
[05:08] <ScottK> So the trick that I eventually discovered is that private glibc symbols all start with __glibc and so if you know that, you can grep the source.
[05:08] <ScottK> persia: I looked at that page and the description didn't seem to fit.
[05:08] <ScottK> It talked about ways to use tools MOTU use regularly.
[05:09] <jmarsden> ScottK: Well, I suppose MOTU's use grep pretty regularly :-)
[05:10] <ScottK> True.
[05:10] <ScottK> But it's certainly not a common situation.
[05:10] <jmarsden> Agreed.
[05:10] <jmarsden> Would adding it under "Other packaging tasks" on https://wiki.ubuntu.com/MOTU/TODO work??
[05:11] <persia> Well, grepping for various constrctions is common.  You could just use __glibc as an example.
[05:11] <ScottK> OK.
[05:11] <ScottK> I can do it that way.
[05:11] <persia> Well, grepping for various constrctions is common.  You could just use __glibc as an example./  That might be a good candidate location.
[05:12]  * persia curses the up arrow
[05:12] <persia> That was supposed to say "where did stefanlsd7s excellent guide go..."
[05:34] <ScottK> Since it's now policy not to mention maintainer change in debian/changelog, someone might want to make a better example for this https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff
[05:51] <nellery> why not mention the update-maintainer script?
[05:57] <ScottK> I think that'd be a little confusing for an example of how to apply a debdiff.
[05:57]  * ScottK goes to bed.
[06:42] <dholbach> good morning
[06:44] <slytherin> dholbach: Good morning. :-)
[06:45] <dholbach> hi slytherin
[07:01] <iulian> wgrant: May I take the maxima merge too?
[07:01] <iulian> Morning dholbach, slytherin.
[07:01] <dholbach> hiya iulian
[07:01] <wgrant> iulian: Go ahead. It should build now.
[07:02] <iulian> OK, thanks.
[07:02] <stefanlsd> anyone else handing out merges :)
[07:03] <slytherin> stefanlsd: will you do jigdo merge? I did last merge but I will not get time for next 24 hours.
[07:03] <stefanlsd> slytherin: will have a look at it :)
[07:08] <gouki> good morning everyone.
[07:09] <jmarsden> gouki: Good evening (it is 11:10pm in California)
[07:10] <geser> good morning dholbach, slytherin
[07:10] <dholbach> hi geser
[07:11] <gouki> jmarsden, hehe. I just woke up. It's 7:10AM. It's raining like hell, and I bet it's pretty sunny there :)
[07:11] <slytherin> geser: good morning
[07:11] <iulian> gouki: UK?
[07:11] <jmarsden> gouki: Well, it's pretty dark here, at 11pm :-)  It was sunny earlier
[07:12] <gouki> iulian, close. Two to the left .. Portugal.
[07:12] <iulian> Ahh
[07:12] <gouki> jmarsden, d'ohh! Indeed.
[07:13] <gouki> Submitted an ITP but still didn't receive the bug number ... :S
[07:15] <slytherin> [OT] - Has anyone purchased AVM FritzBox router? If yes, how good is it?
[07:21] <iulian> wgrant: Should I close bug #242243 in the changelog? It has been fixed in Debian.
[07:21] <wgrant> iulian: Please do, if it does actually build.
[07:22] <iulian> wgrant: I'm building it now.
[07:35] <geser> slytherin: re bug 295539: what's the advantage of building it for jvm 1.4?
[07:41] <soren> NCommander: Around?
[07:42] <stefanlsd> slytherin: merged if you would like to review it. It also built ok. - Bug #296648
[07:42] <NCommander> soren, for some defintions of around
[07:42] <soren> -> /msg
[07:47] <iulian> wgrant: I'm waiting for a response from bug #285420. Looks like it's the same as Debian bug #480308.
[07:47] <iulian> wgrant: In the mean time I'm looking for a fix.
[07:49] <iulian> wgrant: If he confirms that is the same bug I will do the merge because it's fixed in Debian.
[07:49] <iulian> And maybe we can backport it to Intrepid.
[07:52] <iulian> Bug #261056 needs investigation as well.
[07:56] <iulian> wgrant: Or we can upload the new version to Jaunty and ask the reporters to test it to see if they still have the problems?
[07:56] <iulian> Hey DktrKranz.
[07:57] <DktrKranz> morning iulian
[07:57] <DktrKranz> morning *
[07:58] <wgrant> iulian: Upload to Jaunty, backport to Intrepid, get people to test, then work out where the problem lies, SRU it.
[07:59] <wgrant> I forgot the "work out where in the 53KLOC gcl diff the bug is".
[08:02] <iulian> wgrant: OK
[08:08] <slytherin> stefanlsd: Looks fine to me. But I am not a MOTU so can't sponsor it. 2 comments. 1. There is another bug for move to libdb4,6. Make sure you also add that bug in changelog. 2. I was thinking if we should update ubuntu mirror list. Need comment on that from someone. Probably ask in #ubuntu-devel.
[08:09] <slytherin> geser: re: libjogl-java, no specific advantage. But I think we should target 1.4 unless the app/lib specifically needs JRE 1.5 or higher.
[08:39] <iulian> wgrant: Hmm, when I try to build maxima it fails with unmet dep (pbuilder-satisfydepends-dummy: Depends: gcl (>= 2.6.7-44) but it is not installable), even though I updated my Jaunty pbuilder.
[08:40] <iulian> I see that Jaunty has gcl version 2.6.7-45, it should have worked.
[08:40] <iulian> Am I missing something?
[08:41] <wgrant> iulian: It failed on !(hppa|ia64)
[08:42] <wgrant> Which probably means it needs a giveback.
[08:42]  * wgrant does so.
[08:53] <iulian> wgrant: Where did you see that?
[08:54] <wgrant> iulian: https://edge.launchpad.net/ubuntu/+source/gcl/2.6.7-45
[08:54] <wgrant> But it all just failed again.
[08:54] <wgrant> WTF
[08:54] <wgrant> Since when do things succeed only on the most obscure archs!?
[08:54] <persia> It's the new plan for ia64 domination
[08:55] <DktrKranz> gcl? /me hides
[08:55] <iulian> Huh
[08:55] <wgrant> DktrKranz: I'm hiding further away.
[08:55] <wgrant> Bug #43150 was enough to keep me away for life.
[08:55] <DktrKranz> wgrant: I found a way to fix it
[08:55] <wgrant> DktrKranz: How?
[08:56] <wgrant> Oh.
[08:56] <wgrant> It's in the dep installation.
[08:56] <wgrant> I see.
[08:56] <DktrKranz> a combination of black magic, voodoo and some inner-african rituals
[08:56] <wgrant> I can't connect to launchpadlibrarian.net from here for some reason.
[08:56] <wgrant> Ah, no, just lag fooling me into thinking it was deps.
[08:56] <DktrKranz> but main point is some applications are still failing
[08:56] <wgrant> Arfgergerhgear;ogi ewfgewrouf ewf
[08:56] <wgrant> It has its own binutils, doesn't it?
[08:56] <DktrKranz> don't remember which ones, but they seem racy
[08:57] <DktrKranz> yes
[08:57] <wgrant> NCommander!
[08:57] <DktrKranz> he already trie
[08:57] <DktrKranz> d
[08:57] <NCommander> wgrant, ?
[08:57] <wgrant> Oh, this is still that same issue?
[08:57] <DktrKranz> NCommander: gcl \o/
[08:57] <wgrant> NCommander: gcl needs to die.
[08:57] <NCommander> Oh good
[08:57] <NCommander> We have concurrence
[08:57] <DktrKranz> NCommander: or your beloved 14Mb .diff.gz
[08:57] <NCommander> I just say we delete it, and all its rdepends
[08:57] <NCommander> They haven't worked since Gutsy AFAIK
[08:58] <wgrant> But maxima rocks :(
[08:58] <wgrant> maxima works fine.
[08:58] <iulian> Indeed.
[08:58] <NCommander> Can we compile it reliably :-)?
[08:58] <wgrant> We could previously.
[08:59] <DktrKranz> NCommander: we have something to do for jaunty, hooray!
[08:59] <NCommander> Does this mean getting rid of gcl?
[08:59] <DktrKranz> cruft-busters hat on? ;)
[08:59] <NCommander> WOOOOOOOOOO
[09:00] <wgrant> We can't get rid of gcl... but maybe it could be made a bit less crap.
[09:00] <NCommander> yes.
[09:00] <NCommander> Please.
[09:00] <wgrant> How do other distros do it?
[09:00] <NCommander> gcl has been unmaintained for awhile
[09:00] <DktrKranz> I'd like to see gentoo
[09:00] <NCommander> DktrKranz, not packaged AFAIK
[09:00] <persia> Aren't there other CL implementations we could use?
[09:00] <wgrant> cmucl
[09:00] <NCommander> The Debian guy seem to decided that updating binutils was worth dumping in the diff
[09:00] <DktrKranz> gah!
[09:00] <DktrKranz> gentoo is good
[09:01] <DktrKranz> and most of their fixes applies here
[09:01] <NCommander> They don't ship ada last time I checked either :-)
[09:01] <wgrant> The workaround for 43150 was to use cmucl to build it instead of gcl. It apparently worked fine.
[09:01] <NCommander> So if we can use cmucl vs gcl
[09:01] <DktrKranz> heh, ada :)
[09:01] <NCommander> I say we transition out gcl
[09:01] <persia> Then let's keep using cmucl until either it works, or it doesn't.
[09:01] <wgrant> Let's first see what Fedora does.
[09:02] <persia> (where "it" is confusingly supposed to reference "gcl")
[09:02] <DktrKranz> what about fixing gcl to build, then test other applications as well?
[09:02] <DktrKranz> it's broken now
[09:02] <DktrKranz> so it won't harm much
[09:03] <DktrKranz> in my ppa history there's already a working tentative
[09:03] <DktrKranz> but some rdepends are racy
[09:05] <NCommander> so I guess we transition things?
[09:05] <NCommander> DktrKranz, we have six months to make everything settle
[09:08] <persia> Something as core as a compiler ought get sorted in the next couple weeks though, or there'll be great pain later.  This is LTS+2: we're not supposed to break the world quite as badly this time, as theoretically the big transitions are complete for this extended cycle.
[09:09] <NCommander> I personally think shipping a broken compiler is a greater risk
[09:09] <NCommander> It could easily break without warning, and it has on compiling other packages
[09:09] <NCommander> i.e. axiom
[09:10] <persia> Right.  I'm not advocating shipping a broken compiler, just not expecting that we have six months to make everything settle.  It's more like 4 before freezes start to bite, and for something this big, it's better to get the issue well understood pre-UDS.
[09:12] <NCommander> Oh, of course
[09:12] <NCommander> BUt I think its something we at least need to put on the road map
[09:17] <DktrKranz> Debian seems not affected, or just marginally
[09:17] <DktrKranz> I saw a bug reporting a failure similar to ours, but it has been marked as wontfix there
[09:18] <DktrKranz> since Debian buildds are fine with gcl
[09:18] <DktrKranz> so, it's probably racy just here
[09:19] <persia> Could be that Ubuntu buildds run with DEB_BUILD_OPTS=parallen=n+1
[09:19] <DktrKranz> not sure, it fails in pbuilder too
[09:20] <persia> But not in sid pbuilder?
[09:20] <DktrKranz> no
[09:20] <persia> Ah.  Ugly that.
[09:20] <DktrKranz> I tried to disable every CFLAGS/LDFLAGS
[09:21] <DktrKranz> no improvements
[09:21] <DktrKranz> btw, is there a place I can find buildd configuration?
[09:21] <wgrant> infinity's mind!
[09:22] <DktrKranz> is that FOSS?
[09:22] <DktrKranz> or bzr-gettable?
[09:22] <wgrant> You can probably acquire a chroot if you need to, but that's probably not too useful.
[09:22] <wgrant> File an LP bug.
[09:22] <wgrant> bzr get lp:~adconrad
[09:22] <wgrant> Done.
[09:23] <persia> heh
[09:23] <NCommander> so w.r.t. to gcl, what do we do?
[09:23] <wgrant> Panic.
[09:24] <DktrKranz> 404: not found
[09:26] <NCommander> Oh ****
[09:26] <wgrant> Woah. X crashed.
[09:26] <NCommander> wow, gcl's magic is quite powerful!
[09:26] <wgrant> Hmmm.
[09:26] <wgrant> It seems it didn't actually crash; it shut down gracefully.
[09:26] <wgrant> No idea why.
[09:26]  * wgrant can't poke into gcl's internals for at least another couple of weeks.
[09:27] <DktrKranz> NCommander: I'd collect issues and file a spec about it
[09:27] <DktrKranz> and try to fix it the best we can
[09:27] <wgrant> No, no, file a Brainstorm idea. Brainstorm rules all now, it seems.
[09:27] <stefanlsd> heh. latest version from 2005 08 10
[09:28] <DktrKranz> wgrant: never look at it, TBH ;)
[09:28] <DktrKranz> but if it useful to have this done, I'm a big supporter of it
[09:29] <wgrant> No, it's entirely useless.
[09:29] <wgrant> But everything for UDS had to go through it.
[09:31] <DktrKranz> really?
[09:32] <NCommander> ???
[09:40] <DktrKranz> btw, gcl seems it has just 4 r-bdependencies
[09:40] <persia> That doesn't seem insurmountable.
[09:40] <DktrKranz> so, it can be easier to test if everything is fine
[09:41] <DktrKranz> (I did reverse-build-depends gcl | wc -l, please correct me)
[09:41] <persia> reverse-build-depends is arch-specific, and apt-cache specific, but otherwise trustworthy.
[09:44] <DktrKranz> I did it on i386, I guess it collect most (if not all) of them
[09:47] <slytherin> geser: One more point about libjogl-java. It compiles with GCJ as well. Hence it makes sense to compile for target JVM 1.4.
[09:48] <persia> slytherin, Any good ideas about restoring some semblence of jre-independence for users?  I seem to remember a number of bugs about both -headless not being enough so, and then users getting gcj on top of that.
[09:50] <slytherin> persia: users getting gcj is because of libraries having -gcj in recommends. I am not sure about 'exact' difference between -jre and -jre-headless, so I can't comment on that.
[09:53] <persia> slytherin, Right.  It's just that you're recommending building libjogl-java to target 1.4, and referencing GCL compatibility as a benefit, so I wondered if you had ideas as to how to reduce total install footprint when supporting gcj.
[09:57] <slytherin> persia: we could update these -gcj recommends to have them only for arch where openjdk is not available. Because as a user of i386, openjdk gives me more compatibility with Sun Java than GCJ. So I don't want GCJ to be installed. But for users for other arch, where openjdk is not available, having these -gcj packages installed by default makes sense.
[09:59] <persia> slytherin, Hrm.  There ought be a way to do that as part of the meta packages, rather than on a per-package basis.  Probably needs more thought.
[09:59]  * persia adds it to the list of meditation topics
[10:01] <slytherin> persia: is it possible to configure the system such that it will ignore a particular recommends A if it pulls a dependency B?
[10:02] <siretart> slytherin: you could pin the package A to priority 0
[10:15] <slytherin> siretart: Yes I can. But as I said the decision is to be made based on if it pulls dependency B (constant). So it can not be per package A (variable).
[10:17] <siretart> slytherin: I don't think apt's dependency resolver can do this. you might want to look at the apt sources though (beware, it's C++)
[10:23] <iulian> wgrant: In this case what should we do with maxima?
[10:24] <wgrant> iulian: Does the versioned build-dep look like it really needs to be that tight?
[10:24] <iulian> wgrant: Let me check again the debian changelog. It said something about the version.
[10:25] <wgrant> Remember that we often tighten build-deps just so we don't have to stagger uploads to get it built against a new one.
[10:25] <wgrant> When it might not actually need that to build properly.
[10:26] <emgent> wgrant: o/
[10:28] <Hobbsee> NCommander: do some more backports, please!
[10:28] <iulian> wgrant: * Bug fix: "No such file or directory", thanks to Lucas Nussbaum (Closes: #474909). Build-dep against latest gcl
[10:28] <NCommander> Hobbsee, why?
[10:28] <wgrant> Grrgergefqwefweafwe
[10:29] <wgrant> iulian: Give up for now, I guess.
[10:29] <iulian> wgrant: We are going back to your bug.
[10:29] <iulian> Right.
[10:32] <DktrKranz> iulian: gcl is broken in Ubuntu, I had a working gcl some times ago, but I can't guarantee for rdepends
[10:32] <DktrKranz> and I'm sure it won't fix it
[10:32] <iulian> Yup
[10:33] <DktrKranz> I'd like to fix it, or at least make it less broken
[10:34] <DktrKranz> GNAT was fine in hardy-updates, but better fix gcl during development
[10:37] <iulian> Indeed, it's better to make it less broken or fix it entirely. If we're planning to get rid of it, we're also going to lose some of the good applications, including maxima.
[10:38] <iulian> Or if there is a way to make it build with something else.
[10:39] <DktrKranz> maxima FTBFS since ages, IIRC
[10:39] <DktrKranz> I identified the right version
[10:39] <wgrant> I couldn't merge maxima during Intrepid, right.
[10:39] <DktrKranz> it was -46 that broke it, IIRC
[10:40] <DktrKranz> but I noted in in the bug report
[10:40] <wgrant> Broke what? maxima, or gcl?
[10:40] <iulian> wgrant: Yea, that was because of debian bug #474909
[10:40] <DktrKranz> maxima
[10:40] <wgrant> iulian: Yep.
[10:44]  * DktrKranz is going to file a spec to keep track of the issues
[10:46] <iulian> DktrKranz: You're not working on openct merge, aren't you?
[10:46] <iulian> If you're no, can I have it?
[10:46] <DktrKranz> iulian: I've already done it
[10:46] <DktrKranz> IIRC
[10:46] <iulian> Hmm, let me check again.
[10:46] <DktrKranz> and it took me about two hours to testbuild it ;)
[10:47] <iulian> Ahh, right.
[10:47] <iulian> Huh, I haven't fixed anything today.
[10:47] <DktrKranz> not sure if I forwarded to debian, BTS was unreachable yesterday
[10:47] <Spatman> Hey, i about to get in to Debian packaging. and i at the control file. What shoud i fill in in the "Section:"
[10:47] <DktrKranz> I'll have a look today
[10:49] <iulian> Spatman: http://packages.ubuntu.com/jaunty/
[10:49] <iulian> Spatman: You might want to have a look at the Debian policy as well.
[10:49] <persia> Spatman, http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections
[10:49] <iulian> There you go.
[10:53] <iulian> wgrant: May I have the powersave merge?
[10:54]  * iulian confirms that he is a little bit annoying.
[10:54] <wgrant> iulian: Of course.
[10:54] <Hobbsee> iulian: i doubt wgrant's attached to that
[10:54] <Hobbsee> ah, he's back
[10:54] <wgrant> I can't do anything for a couple of weeks.
[10:54] <wgrant> And I've been wanting to get rid of that since late Edgy.
[10:55] <NCommander> RId of what?
[10:55] <Hobbsee> iulian: you can pick up my couple of universe merges, if you want.
[10:55] <wgrant> Get rid of my TIL status for powersave.
[10:55] <Hobbsee> wgrant: yeah, I think you took that one off me originally, thanks ;)
[10:55] <iulian> Free merges!
[10:55] <iulian> wgrant, Hobbsee: Thanks.
[10:56] <Hobbsee> iulian: I have a suspicion that at least one of them is still a manual merge (differing tarballs).  Either that, or they should be syncs.
[10:56] <Hobbsee> unless i'ts a dh_icons change
[10:57] <iulian> Ah-ha, OK.
[10:57] <Hobbsee> or i've forgotten :P
[10:57]  * Hobbsee remembers trying to get them into a syncable state before
[10:58] <Spatman> Want is a most in the Control when making a packaging?
[11:00] <persia> Spatman, Rather than looking at documentation, you may do well to examine the source of several existing packages, and use those as a basis.
[11:02]  * iulian just noticed that gEdit opens in approximately one minute (?)
[11:02] <wgrant> iulian: Disable the File Browser Pane plugin. A fix is in the works.
[11:03] <iulian> wgrant: Disabled.
[11:03] <Spatman> persia, okej thanks
[11:04] <iulian> Anyway, I don't use it (vim ftw). It was just... weird.
[11:18] <directhex> dpkg-source: info: building mono using existing mono_2.0.orig.tar.gz
[11:31] <Spatman> Some one have a good guide how to make the rule file when making a Debian file to ubuntu?
[11:32] <persia> Spatman, Do you mean converting from Debian to Ubuntu, or creating something from scratch?
[11:34] <Spatman> Persia, i am making from scrathc
[11:34] <persia> !packaging
[11:35] <persia> See the packaging guide linked there.
[11:41] <porthose> persia: FYI just got conformation, RFE granted for ampache :)
[11:42] <persia> \o/ Getting closer every day.
[11:48] <directhex> dpkg-deb: building package `libmono-corlib2.0-cil' in `../libmono-corlib2.0-cil_2.0-1_all.deb'.
[11:56] <weboide> dholbach: I've posted the diff.gz and .dsc (what I find weird is the diff.gz is only a diff for the debian directory) is that alright?
[11:57] <iulian> wgrant: It's done. Would you like to review it?
[11:57] <dholbach> weboide: yes, that's fine - the debdiff you posted also contained changes that were introduced upstream, with the .diff.gz and .dsc it will be easy to just apply the packaging changes that are necessary
[11:58] <weboide> dholbach: so in fact, you don't need the upstream changes because it's taking them "automatically"?
[11:58] <wgrant> iulian: I've not got time now, sorry.
[11:58] <iulian> wgrant: Sure, no problem.
[11:59] <dholbach> weboide: if I download the .tar.gz from the upstream page, applying the .diff.gz (just by runnin dpkg-source -x bla.dsc) should be fine :)
[11:59] <weboide> okay, good to know, thanks dholbach :)
[11:59] <dholbach> rock on!
[11:59]  * iulian subscribed u-u-s.
[12:02] <iulian> Is there anyway I can remove a project from launchpad?
[12:02] <wgrant> iulian: You can request that an ~admin deactivate it, which is basically the same.
[12:04] <iulian> OK, thanks.
[12:48] <gouki> I submitted an ITP but still didn't receive the bug number like it said I would ... :S Any idea?
[12:51] <mok0> gouki: You submitted to Debian?
[12:55] <gouki> mok0, yes, using reportbug.
[12:56] <mok0> gouki: how long ago? BTS can be slow
[12:56] <gouki> mok0, I would say 12 hours now, or close to that.
[12:56] <mok0> gouki: did you search for it on bugs.debian.org?
[12:57] <gouki> mok0, yes, no luck there either.
[12:57] <mok0> gouki: did you use reportbugs from an ubuntu system?
[12:57] <gouki> mok0, yes, but I changed the configuration to point to Debian BTS
[12:58] <mok0> gouki: that's what I was getting at :-)
[12:58] <gouki> mok0, heheh
[12:58] <mok0> gouki: does your mail account use a grey-listing filter?
[12:59] <DktrKranz> gouki, did you receive a copy of your bug report? reportbug should CC your address
[12:59] <gouki> mok0, good idea! :P
[12:59] <gouki> DktrKranz, I did receive a copy yes.
[13:00] <mok0> But that would be a copy from your own mail server...
[13:00] <mok0> DktrKranz: but he didn't get a reply from the BTS
[13:01] <DktrKranz> sure, but I usually see server settings are misconfigured, so no mail in CC too
[13:01] <Hobbsee> mok0: did you change the smtp settings on it?
[13:01] <mok0> Hobbsee: errr? on what?
[13:01] <mok0> Hobbsee: you need to ask gouki
[13:02] <Hobbsee> oh, gouki, sorry.
[13:02]  * gouki is looking at the junk folder, to see if it's there. BRB
[13:02] <Hobbsee> mok0: you're the same colour on my system, and similar length names...
[13:03] <mok0> Hobbsee: OK, I did change SMTP server on thunderbird this morning, but how can you tell?
[13:04] <Hobbsee> mok0: no, i meant in the conf for reportbug.
[13:04] <Hobbsee> mok0: it uses a conf that works for people using an @ubuntu.com email address - or at least, did when I last touched it.
[13:04]  * mok0 emerges on other side of confusion
[13:05] <gouki> Hobbsee, no, I didn't change SMTP settings, but I got a copy of the message I sent, so I believe the email was delivered.
[13:05] <Hobbsee> ah, right.
[13:05] <gouki> The bug number reply, however, I did not receive. I'm checking the spam folder, recommended by mok0. Might be in there.
[13:06] <mok0> Hobbsee: In .reportbugs, my smtp-host is set at bugs.debian.org
[13:07] <mok0> gouki: we'll just use the Socratic method until you work it out :-)
[13:09] <gouki> mok0, hehe! Seems to be working alright so far :P
[13:15] <mok0> gouki: did you submit the bug report to the wnpp package?
[13:16] <gouki> mok0, yes.
[13:19] <mok0> gouki: what is the topic of your ITP?
[13:21] <gouki> mok0, ITP: banihstypos -- A simple game to practice typing faster
[13:22] <directhex> there is only one typing tutor game worth playing
[13:22] <gouki> directhex, that's your opinion.
[13:23] <mok0> It's called "terminal" ;-)
[13:23] <directhex> mok0, nope, but it's the only one with zombies. http://en.wikipedia.org/wiki/The_Typing_of_the_Dead
[13:25] <DktrKranz> porthose, was it you who asked me to merge slidentd?
[13:27] <mok0> Heh, someone wants to package mother
[13:28] <mok0> "an object relational mapper with strong introspection"... that's my mom rigth there...
[13:28] <gouki> LOL
[13:29] <mok0> gouki: I don't see your package though... did you make a tyop when specifying the smtp host?
[13:30] <gouki> mok0, but would I receive a copy of the email if the SMTP host was wrong?
[13:30] <mok0> gouki: because your local mail server would know how to return a CC to you, but then it would fail sending the original message
[13:31] <mok0> gouki: ... and it would send a report back to you from "mailer-daemon" or something
[13:31] <gouki> mok0, let me check my reportbug configuration file.
[13:31] <azeem> hi mok0
[13:32] <mok0> azeem: hi
[13:32] <azeem> mok0: what are your plans with qutemol?
[13:32] <mok0> azeem: I have gotten it to work on intrepid
[13:32] <mok0> azeem: it's in my PPA
[13:33] <azeem> I saw
[13:33] <azeem> too late for doing the porting effort myself, though
[13:33] <mok0> azeem: I am not sure about the status of the program... maintenance-wise
[13:33] <porthose> DktrKranz: yes, I haven't done anything  yet, life has been getting in the way lately
[13:33] <azeem> mok0: are you interested in maintaining it in Debian?
[13:34] <azeem> mok0: also, I think the vcg stuff needs to be sorted out
[13:34] <DktrKranz> porthose, no problem. just to make sure to avoid managing it myself, thanks ;)
[13:34] <mok0> azeem: It depends whether upstream will keep maintaining it
[13:34] <mok0> azeem: ... and I am not sure about that
[13:35] <mok0> azeem: qutemol only uses a fraction of the vcg stuff
[13:35] <azeem> yeah
[13:35] <azeem> though meshlab also needs it, but they seem to just copy things over when doing a release
[13:35] <DktrKranz> BBL
[13:35] <mok0> azeem: what are your thoughts?
[13:35] <mok0> azeem: their releases are somewhat a mess
[13:35] <azeem> mok0: I'd prefer to lobby upstream into doing vcg releases, or at least trying to
[13:35] <azeem> yeah
[13:36] <azeem> mok0: I found a 5.0.1 release or so on the nano-engineer website
[13:36] <mok0> azeem: are YOU interested in maintaining the package in Debian?
[13:36] <azeem> mok0: I'm certainly interested in having it in Debian
[13:36] <mok0> azeem: I suppose you think that vcg should be packaged separately
[13:37] <azeem> well, it would be best I think
[13:37] <azeem> but if upstream is really uncooperative, it's better to have it in the qutemol tarball than not having qutemol at all
[13:37] <mok0> azeem: I think it depends on how many other packages would use it
[13:37] <azeem> probably only meshlab for the time being
[13:38] <azeem> their community-building efforts seem to not very great
[13:38] <azeem> +be
[13:38] <mok0> azeem: no :-)
[13:39] <mok0> azeem: I've emailed them some time ago, never received an answer...
[13:39] <azeem> hrm
[13:39] <mok0> azeem: could try again
[13:39] <azeem> they were quite responsive earlier this year when people packaged meshlab
[13:39] <gouki> mok0, the SMTP was wrong (it was set to a Ubuntu SMTP only accepting from @ubuntu, like Hobbsee said). Changing to my own server now.
[13:39] <azeem> mok0: I'd like to have qutemol maintained by the Debichem team; do you want to join there and group-maintain it?
[13:39] <mok0> azeem: ah ok sounds good
[13:40] <mok0> azeem: sure. I am in the science team and in the med-team, but debichem is something else?
[13:41] <azeem> well, that's all rather a mess right now
[13:41] <mok0> azeem: hehe
[13:41] <ScottK> gouki: bugs.debian.org was down for some time yesterday.  Dunno if that relates.
[13:41] <azeem> debichem mostly does chemistry, med mostly does biochemistry, and debian-science does everything else, sometimes overlapping
[13:41] <gouki> ScottK, I sent around 1AM UTC.
[13:42] <azeem> mok0: debichem uses a svn repo, is that a problem for you?
[13:42] <ScottK> IIRC that's when it was down.
[13:42] <mok0> azeem: as long as it gets done, I guess that's the most important thing. Is debichem using SVN/GIT/CVS/BZR ??
[13:42] <mok0> ah
[13:42] <mok0> azeem: no
[13:42] <azeem> there's #debichem on this network btw, we could continue discussin it over there
[13:42] <mok0> azeem: although I wish the teams would converge on SOMETHINNG
[13:43] <mok0> azeem: 1 min
[13:43] <mok0> azeem: I'm over there now
[14:15] <\sh> whois bobby R. ward?
[14:38] <emgent> evening
[14:38] <nhandler> Good morning emgent
[14:59] <RainCT> Hey
[15:01] <nhandler> Hey RainCT
[15:03]  * RainCT tries to remember which packages he was asked to review yesterday
[15:07] <persia> RainCT, Just do them all :)
[15:08] <handschuh> qq: can I have 2 Hompage-Fields in debian/control (one under Source and one unter Package)?
[15:08] <nhandler> handschuh: Unless they are different, I would just put it under Source (if it applies to all of the packages)
[15:08] <RainCT> persia: you could do some, too :)
[15:09] <handschuh> nhandler: thanks again!
[15:09] <nhandler> You're welcome handschuh
[15:16] <persia> RainCT, Yeah.  I probably ought :)
[15:21] <bddebian> Heya gang
[15:27] <iulian> Hello bddebian.
[15:28] <bddebian> Hi iulian
[15:30] <leonel> are the  merges for jaunty open ???
[15:32] <persia> leonel, Yes, although it's early enough in the cycle we're not sniping much.  If you've run out of your own, UEHS is always a good palce to look for upgrades.
[15:34] <leonel> persia: UEHS ??
[15:34] <leonel> me goes google ..
[15:34] <gouki> porthose, RainCT: As requested, I have uploaded the package to my PPA. Should I add a link in the REVUDays wiki or REVU comment?
[15:34] <persia> leonel, http://qa.ubuntuwire.com/uehs/
[15:34] <leonel> persia: found it :)
[15:35] <DktrKranz> gouki, AFAIK, Jaunty PPAs are CHROOTWAIT now, so you could receive failures
[15:35] <persia> leonel, I'd recommend starting with the packages we *know* to be out of date.  Those either need updates, or some reason why they shouldn't be updated, or a recommendation to drop them from Ubuntu.
[15:35] <persia> 90% of the time, it's an update.
[15:35] <gouki> DktrKranz, thank you for the heads up.
[15:36] <leonel> thanks  persia
[15:45] <RainCT> gouki: yes, please do so (if it builds) :)
[15:46] <gouki> RainCT, sure thing.
[15:47] <gouki> RainCT, and you meant the Wiki or REVU comment?
[15:47] <RainCT> gouki: wiki
[15:47] <gouki> OK
[15:56] <RainCT> Uhm.. Are new package uploads not send to ubuntu-motu@ anymore or is it just that I'm deleting them without noticing it? :P
[16:06] <nhandler> RainCT: Were they ever sent to ubuntu-motu? I thought they were always on the XXX-changes mailing lists
[16:07] <persia> Whenever an Ubuntu developer receives a notification that Soyuz has accepted a new package into NEW, they are expected to forward it to ubuntu-motu@ to advise the rest of us that we now have to maintain the package.
[16:08] <persia> Often people s/NEW/REVU/ when forwarding when packages are pushed from REVU.
[16:09] <persia> This is essential to ensure that 1) we have the opportunity to review/discuss new packages that we're being asked to maintain, and 2) that the package review process remain implementation independent to allow for experimentation with processes towards general improvement.
[16:09] <persia> (this doesn't mean that REVU isn't still the recommended method, just that it's not nice to tell people they can't do anything else if they *really* want).
[16:38]  * RainCT finishes writing a quick & ugly howto on how to write "real" manpages.. https://wiki.ubuntu.com/PackagingGuide/Howtos/RoffManpage
[16:39] <mok0> RainCT: Ever look into asciidoc?
[16:40] <RainCT> mok0: Why should I? troff (or nroff or groof or whatever it's called! :P) is easy enough, and doesn't need to be "compiled" nor anything
[16:41] <RainCT> (uhm.. looks nice, though :))
[16:43] <sebner> RainCT: your wiki site is great. "real" manpage ftw!
[16:44] <mok0> RainCT: It could be easier for other packagers
[16:45] <RainCT> mok0: write a howto then ;)   (I wrote one for POD time ago, btw, which is the easiest format I've seen so far)
[16:45] <mok0> RainCT: But I like your template... But maybe "Joe Hacker" should be "Joe Sixpack" :-P
[16:45] <RainCT> heh
[16:47]  * persia recommends the well exercised J. Random Hacker
[16:47]  * mok0 seems to remember a prime minister "Jim Hacker"...
[16:48]  * DktrKranz suggests "Steve A. B@llmer"
[16:48] <mok0> "Yes, Prime Minister" anyone?
[16:48] <RainCT> DktrKranz: argh! are you sure we want such stuff in the repos?
[16:48]  * sebner winks DktrKranz 
[16:49] <DktrKranz> RainCT, an incentive to change who did merges!
[16:49] <mok0> What stuff?
[16:49] <RainCT> mok0: written by the name DktrKranz said *g*
[16:49] <mok0> Ah. Time to go home :-(
[16:49] <slytherin> mok0: yes, my father liked that series a lot. :-)
[16:50] <sebner> Steve Gates!? xD
[16:50] <mok0> slytherin: I just purchased the DVDs for the first season. Pure gold
[16:50] <slytherin> I am planning to purchase it sometime next month.
[16:50] <DktrKranz> sebner, their child ;)
[16:51] <sebner> DktrKranz: female? :P
[16:51] <mok0> slytherin: go for it, highly recommended
[16:51] <DktrKranz> sebner, don't even think about her
[16:51]  * sebner hides
[16:52] <slytherin> mok0: wasn't it "Yes Minister" before it became "Yes, Prime Minister"?
[16:52] <jpds> slytherin: It was, then the guy became Prime.
[16:53] <slytherin> :-)
[16:55] <mok0> Yep, they needed someone stupid that they could control :-)
[16:55] <mok0> ... or so they thought
[16:55] <DktrKranz> democracy is weird
[16:56] <mok0> DktrKranz: any better ideas?
[16:56] <bddebian> Optimus Prime?
[16:57] <DktrKranz> Thanks Debian
[16:58] <mok0> errr Master of the Universe?
[17:00] <mok0> Any git gurus around?
[17:01] <DktrKranz> mok0, some times ago I used it quite well
[17:02] <DktrKranz> but I'm not up-to-date with recent git
[17:02] <mok0> DktrKranz: Just wondering how I can avoid a merge of a new upstream screwing up the new source files
[17:03] <mok0> DktrKranz: It kinda tries to merge the old and new source files, but I only want it to merge in the debian/ dire
[17:03] <DktrKranz> you can specify which files to merge
[17:03] <DktrKranz> as much as bzr does
[17:04] <DktrKranz> I used cogito do to that, but new UI should do the same
[17:04] <mok0> DktrKranz: I just did git-merge upstream
[17:04] <DktrKranz> gic
[17:05] <DktrKranz> git-commit should do the trick
[17:05] <mok0> DktrKranz: It writes that the given files "need merge"
[17:05] <DktrKranz> mh...
[17:05]  * DktrKranz needs to install new git, then
[17:06] <mok0> DktrKranz: ... and they have the >>>>  [17:06] <DktrKranz> did you solve conflicts?
[17:06] <mok0> DktrKranz: I think git now implements the stuff that cogito used to add
[17:06] <mok0> DktrKranz: I don't want to solve conflicts, I want the new files to override the old ones
[17:07] <mok0> DktrKranz: So when I do a git diff upstream, I only see the debian/
[17:09] <iulian> Hmm, why do you keep the debian/ directory in the upstream branch?
[17:09] <DktrKranz> mok0, git-pull --rebase ?
[17:09] <mok0> iulian: I don't
[17:10] <DktrKranz> rebasing is dangerous, though
[17:10] <mok0> iulian: I keep debian/ in the ubuntu branch, which is branched off upstream sometime in the past
[17:11] <jpds> iulian: It should be maintained seperatly (at least, that's how I prefer it).
[17:11] <mok0> jpds: I don't think you can do that in git
[17:13] <iulian> I do maintain a couple of packages in git.debian.org and I do have two branches, one which contains the upstream source code and the other one the debian directory.
[17:14] <mok0> iulian: how can you only have debian/
[17:14] <mok0> ?
[17:14] <mok0> iulian: the other one ADDS debian/ right?
[17:14] <iulian> mok0: Ahh, I don't. I have the debian/ and the source code in a separate branch.
[17:15] <mok0> iulian: that's what I have
[17:15] <iulian> The upstream branch contains only the source code.
[17:15] <mok0> iulian: I have committed the new upstream release to branch "upstream", and I am trying to merge
[17:16] <slytherin> anybody from MOTU SRU around?
[17:16] <iulian> mok0: And git checkout master && git merge upstream doesn't work?
[17:16] <huats> ScottK: are you around ?
[17:17] <mok0> iulian: at the moment I am stuck because it keeps asking me to merge
[17:17] <DktrKranz> slytherin, yes
[17:18] <iulian> mok0: I usually git add the new upstream release to the upstream branch and from there I merge it with master.
[17:18] <slytherin> DktrKranz: can you please evaluate bug 294753.
[17:18] <iulian> mok0: Or whatever your 'master' branch is called.
[17:18] <iulian> mok0: Ah, ubuntu in this case.
[17:18] <huats> persia: are you around ?
[17:18] <mok0> iulian: that is exactly what I am attempting to do
[17:19] <mok0> iulian: right now it tells me "You are in the middle of a conflicted merge"
[17:19] <slytherin> huats: why exactly are you searching persia for?
[17:20] <huats> slytherin: hey
[17:20] <mok0> iulian: but the merge I was attempting was in another branch that I deleted
[17:20] <iulian> Hmm
[17:20]  * mok0 cries wuuaaaahhh
[17:20]  * persia suspects it has something to do with mentoring
[17:20] <huats> I am searching to talk with him regarding his last mail on the motu/non motu mentoring  thread....
[17:20] <huats> persia: well guessed :)
[17:20] <DktrKranz> slytherin, what if /etc/alternatives/java is different from OpenJDK, any issues?
[17:21] <huats> persia: how are you ?
[17:21] <persia> huats, Well enough.  What's your thoughts on the matter?
[17:22] <slytherin> DktrKranz: I tried with openjdk and GCJ, the proposed solution works fine. I will check with Sun JDK. I am also going to forward the bug to Debian before processing it as SRU candidate.
[17:22] <iulian> mok0: You only have two branches: 'ubuntu' and 'upstream' now?
[17:22] <mok0> iulian: ah, git reset
[17:22] <huats> persia: I think there is something unclear there :)
[17:22] <huats> persia: I am very surprised of the current definition of U-U-C
[17:22] <DktrKranz> slytherin, sounds safe enough, it was already fixed in Jaunty?
[17:22] <persia> huats, What's surprising about it?
[17:22] <iulian> mok0: Does that fix it?
[17:23] <mok0> iulian: yes, I have a branch "upstream" with the latest upstream version committed
[17:23] <slytherin> DktrKranz: it is not. That is why I said I will forward it to Debian. I just wanted someone from motu-sru to comment if it is worth it.
[17:23] <mok0> iulian: git reset got me out of the trap
[17:23] <huats> persia: Regarding how to become uuc : "through participation in the development community and interaction with Ubuntu Developers"
[17:23] <mok0> iulian: now the repo is in the state I expect
[17:23] <DktrKranz> slytherin, it's worth a SRU upload
[17:23] <iulian> mok0: Cool.
[17:24] <persia> huats, Yes.
[17:24] <DktrKranz> but please document the procedure in a TEST CASE
[17:24] <huats> which clearly insists on the technical development part
[17:24] <mok0> iulian: ok, I make a branch off upstream called "test"
[17:24] <persia> huats, Hrm?  How?
[17:24] <DktrKranz> so everybody can easily test things, because someone could not be comfortable with java packages
[17:24] <huats> persia: (anyway I will reply to the list, since I was away all day long)
[17:25] <mok0> iulian: oops thats wrong
[17:25] <persia> huats, I'm not understanding what you're saying.
[17:25] <huats> persia: hum
[17:25] <huats> :)
[17:25] <huats> persia: I will answer to the list :)
[17:25] <iulian> mok0: What would you like to do now?
[17:25] <huats> so that everybody will be able to participate :)
[17:25] <persia> huats, The threshold for UUC is essentially that for Ubuntu Membership.  It's a result of how the CC asked MC to administer membership grants when MC asked to decouple this from MOTU.
[17:26] <mok0> iulian: merge the OLD ubuntu branch (old code + debian/) into the NEW upstream branch (w/o debian/)
[17:27] <bmm> Anybody willing to comment on http://revu.ubuntuwire.com/details.py?package=metalink , I'm online to respond
[17:27] <persia> huats, MC only accepts candidates from those who choose to interact with the development community,and contribute through activities of value to the development community.  These aren't limited to development, but also include developer documentation, developer training, etc.
[17:27] <huats> but from my point of view, u-u-c is a step toward motuship, granted after some technical development....
[17:27] <huats> persia: that is the definition of membership
[17:27] <huats> from MY understanding, the uuc is limited to development...
[17:27] <persia> It's certainly a common step towards MOTUship, but not a required step.
[17:28] <huats> sure it is not required
[17:28] <persia> Also, it's about interaction with the development community, not development directly, although most of what the development community does is development, so there's usually some development.
[17:28] <persia> The big difference is that I don't look at all the bugs the user closed in changelogs and review the debdiffs
[17:29] <persia> (well, honestly, I usually only look at 15-20 patches)
[17:29] <mok0> iulian: I got some conflicts doing "git-merge upstream"
[17:29] <huats> sure
[17:29] <iulian> mok0: If you have the "upstream" branch with the latest version committed and want to merge with the "ubuntu" branch, you can checkout the "ubuntu" branch and merge "upstream"
[17:29] <persia> I'm not sure about the specific criteria for other MC members, but it's probably similar.
[17:29] <mok0> iulian: that's what I have done
[17:29] <mok0> iulian: I got some conflicts
[17:30] <iulian> mok0: So, you'll have the new version committed to the ubuntu branch without the debian/ directory.
[17:30] <iulian> mok0: Bleah
[17:30] <mok0> iulian: ys
[17:30] <mok0> yes
[17:31] <iulian> What kind of conflicts?
[17:32] <mok0> iulian: CONFLICT (content): Merge conflict in vcg/vcg/complex/trimesh/append.h
[17:32] <iulian> mok0: This is the the source code, right?
[17:32] <mok0> iulian: why would I get a conflict in a file that's based off the old version? No edits by me
[17:32] <mok0> iulian: yes, source coded
[17:33] <iulian> mok0: Hmm, try to remove the current upstream version from the ubuntu branch, but not the debian/ dir and then try to merge.
[17:33] <huats> persia: from my understanding (of a non MC member of course), uuc is granted for develpment activities. If someone has done quite some documentation stuffs (by instance), and want to get the membership it is handled by the CC (or the various boards right now)
[17:33] <mok0> iulian: ok sounds like a good idea
[17:34] <mok0> iulian: ah, it's too smart to get fooled like that
[17:34] <iulian> Heh, thought so.
[17:34] <huats> and I tend to think I am not the only one with that opinion since, regarding all the uuc applications are development oriented... (from my point of view again)
[17:34] <nhandler> huats: I think most other people are under that impression as well. I know of several people who were very active with documentation. They applied for membership through the regional councils.
[17:35] <iulian> mok0: Did you push it somewhere?
[17:35] <mok0> iulian: and now it thinks I have deleted all the files
[17:35] <persia> huats, Depends on the class of documentation.  Someone who cleaned up the Packaging Guide while spending time here would probably be better known to developers, while someone who was working with the docteam would be better known there (and the docteam would probably recommend them to an RMB).
[17:35] <mok0> iulian: no I am working off a temporary branch
[17:35] <huats> persia: sure
[17:35] <mok0> iulian: hopefully I can get back somehow :-)
[17:36] <persia> huats, Anyway, that's just an example.  The point being that what's checked is a sustained and significant set of contributions to Ubuntu.  This doesn't mean that someone's technical abilities are reviewed.
[17:36] <iulian> mok0: You didn't commit, right?
[17:37] <huats> persia: I understand your point
[17:37] <persia> The key requirement for application for UUC vs. other sorts of Membership is really the involvement with the development community, as the entire community is large enough that often we know such candidates better than the RMBs.
[17:37] <mok0> iulian: no no
[17:37] <mok0> iulian: I wont commit until I've got what I want
[17:37] <huats> exactly
[17:37] <iulian> mok0: Try git config branch.ubuntu.merge refs/heads/ubuntu
[17:38] <iulian> mok0: Then git checkout ubuntu && git merge upstream
[17:38] <mok0> iulian: what will that do?
[17:38] <slytherin> is it just me or are there others who many a times find that package changelogs in Debian are less verbose?
[17:38] <iulian> mok0: Please paste the .git/config file to a pastebin.
[17:39] <persia> huats, So, I have deep confidence that any UUC knows who is who, and how to interact with developers.  I'm not necessarily confident as to whether they know how to develop (if I was, I'd rather have them as MOTU).
[17:39] <huats> I understand your point
[17:39] <mok0> iulian: http://pastebin.com/f32ecd428
[17:40] <persia> huats, So, that aside, what do you think about the suggestion of centralising teaching the basics?  Do you guys still impose the "cannot mentor someone with the same native language" rule?
[17:40] <iulian> mok0: Ah, right, you didn't push it to a remote branch.
[17:40] <mok0> iulian: no
[17:40] <mok0> iulian: this is all for my own pleasure :-P
[17:40] <huats> persia: the thing is that (from my point of view) a uuc should know 'enough' to help a new contributor to start...
[17:41] <huats> and it is such a good experience for the uuc to help someone...
[17:41] <persia> Sure, and most UUC do know enough to start.  Do you think it's better that they not do it here?
[17:42] <mok0> iulian: got it now
[17:42] <iulian> mok0: What did you do?
[17:42] <thiagoss> I've been trying to put a postinstall script into my .deb, so the user can configurate some stuff after installing my program. I've read through the maintainer guide, but I can't understand how to do it. Could someone help me?
[17:43] <mok0> iulian: I cheated :-) I think you need to resolve the conflicts, but I just extracted the new tarball on top of the directory, and did "git add" to the conflicting files
[17:43] <huats> persia: the 'not same native language" is a rule that we try to push
[17:43] <persia> thiagoss, Short answer, add debian/$(package).postinst
[17:43] <mok0> iulian: then I did "git commit -a" and when I now do a diff to "upstream" I only see files in debian/
[17:43] <thiagoss> persia, as simple as that?
[17:44] <thiagoss> great! I've added postinst only =P
[17:44] <persia> thiagoss, Well, it depends on how your debian/rules is constructed, but usually.  It's worth reading http://women.debian.org/wiki/English/MaintainerScripts to make sure you get it right though.
[17:45] <huats> persia: there have been lots of discussions to try to creates mote links between mentoring and classrooms
[17:45] <persia> Right, which is a good thing.
[17:45] <iulian> mok0: I've never played with git locally.
[17:45] <huats> but nothing has really happened yet
[17:46] <huats> it is something that I have planned to talk to with james_w at the UDS
[17:46] <iulian> mok0: I also couldn't have the source code + the debian/ in a branch and in another only the source code.
[17:46] <mok0> iulian: It's no different I think
[17:46] <iulian> mok0: I've done this remotely and it worked very well.
[17:47] <mok0> iulian: you can if the debian/ one is branched from the source code one
[17:47] <persia> huats, My primary interests on this topic are 1) getting more developers, 2) making sure developers get good advice, and 3) avoiding duplication of effort.
[17:47] <mok0> iulian: but you need to keep those two branches separate, and only merge from "upstream" -> "debian"
[17:48] <huats> persia: I can clearly see your points :)
[17:48] <persia> huats, I certainly don't mean to say that the work being done isn't valuable, only that I think it's worth revisiting what is expected from a mentor before we decide to set any criteria for anything.
[17:48] <iulian> mok0: I've done that adding the source code to both branches and then the debian/ to the master branch.
[17:48] <mok0> iulian: I was confused because to the conflicts.
[17:48] <huats> and I completly agree with you on the 3 points
[17:49] <persia> huats, To me, the first step is about understanding how we work, and is essentially a social thing.  The second step is again understanding how the developer is planning to work and be established, and is again a social thing.
[17:49] <huats> persia: I am really surprised by the mentor who has done the 'error'
[17:49] <mok0> iulian: ah, ok, but I don't think you need two copies of the sources
[17:49] <iulian> mok0: I usually import the new upstream version to the 'upstream' branch and then merge it with master.
[17:49] <persia> I'd like to see more links between mentoring and classroom, as I think they are complimentary, but I really think most of the mentoring role is social rather than technical.
[17:50] <iulian> mok0: To have the same uptream version in both branches.
[17:50] <mok0> iulian: I was confused by the conflicts. Turns out it was some kind of CVS added stuff ($Log:$
[17:50] <persia> Yeah, that specific mentor made a mistake, and it's unfortunate, but it's likely happened before (whether formally or not), and will likely happen again.  The goal is just to have a process that doesn't encourage it.
[17:50] <iulian> mok0: Ahh, cvs...
[17:50] <mok0> iulian: I think you only need one copy of the sources, in one branch, then the other branch only adds debian/
[17:51] <huats> persia: absolutly
[17:51] <mok0> iulian: it should merge transparently
[17:51] <huats> persia: it is unfortunate
[17:51] <huats> and the goal is to avoid that...
[17:51] <huats> there is already a kind of mentoring program
[17:51] <iulian> mok0: Well, that's not the way I work.
[17:51] <huats> which is a good start
[17:51] <mok0> iulian: I guess the CVS modification of the source code means that the new version is not simply based on the old one
[17:52] <mok0> iulian: anyway, thanks for your help and the discussion!
[17:52] <iulian> mok0: Don't mention it.
[17:53] <thiagoss> persia, thanks! that worked perfectly!
[17:53] <iulian> I'm always available to talk about git.
[17:54] <persia> huats, Well, I think you're doing yourself a disservice to say "a kind of mentoring program".  It is one.  You guys just have to find a way to define it that's complementary to other recruitment and training efforts, which will surely come in time.  Now that the backlog is cleared, I'm guessing there's a bit more time to concentrate on infrastructure and process.
[17:54] <persia> thiagoss, Don't forget that if you're using debhelper, you probably want #DEBHELPER# in your script :)
[17:55] <huats> I was saying 'a kind' since it is not compulsery, and that only the big lines are defined...
[17:55] <huats> but I think many things are said !
[17:55] <gouki> Want to package this: http://homepage.univie.ac.at/l.ertl/swiggle/ but no mention of the license. No license = no package, right?
[17:55] <persia> heh.
[17:55] <huats> :)
[17:56] <iulian> gouki: Mail upstream and ask to provide a license to the package.
[17:56] <joaopinto> gouki, no license = contact the author to add an open source license :)
[17:56] <persia> Personally, I'm happy it's not compulsary, as I think there are lots of different types of people, but as you manage it, you'll surely either find a process that works, or determine that you need some other structure.
[17:56] <huats> persia: what about having a session at the UDS on that topic ?
[17:56] <gouki> iulian, joaopinto - no answer from upstream :S
[17:56] <huats> persia: I think it is important enough to have one
[17:57] <iulian> gouki: That's bad...
[17:57] <huats> to talk of a possible infrastructure...
[17:57] <persia> huats, We could, but I'm not sure the number of interested parties are large enough, especially as only a minority of MOTU make it to UDS each year.
[17:58] <huats> persia: sure
[17:58] <persia> I think we'd do better to discuss it on the ML, and if it's still not clear at UDS (remember, that's almost at Alpha 2 this cycle), maybe have a hallway/evening conversation.
[17:58] <huats> persia: but, by instance, a meeting can be a point where we can start to write down a few ideas to discuss later on the ML
[17:58] <huats> sounds good to me
[17:59]  * persia would rather do it the other way : meeting -> ML sounds like "let's put this off a month"
[17:59] <huats> (I mean your proposal sounds good to me)
[17:59] <huats> :)
[17:59] <persia> Well, my proposal for getting a proposal :)  I suspect you've issues with my actual proposal, but that's why we have a ML :)
[17:59]  * gouki would like to go to a UDS :(
[18:00] <persia> gouki, Well, this one is kinda short notice.  What are you doing in May?  There's likely to be one then, and maybe you can schedule some free time to make it.
[18:00] <persia> Anyone's welcome to come to UDS (although it is sometimes pricey).
[18:01] <gouki> persia, yeah, that's the problem. I could find some time to go, but traveling and all the rest make it pretty pricey (at least for now).
[18:03] <persia> gouki, Yep.  Maybe there will be one nearer to you one of these cycles.
[18:04] <directhex> a UDS in oxford would be convenient, kkthx
[18:04] <iulian> Indeed
[18:05] <persia> I think there was one in britain some years back.  Could happen again.
[18:05] <ScottK> huats: Around now.
[18:05] <gouki> One in Spain would be awesome! I would get to leave my country, by car :)
[18:05] <huats> hey ScottK
[18:05] <sebner> ScottK: if interested, my revu comments will be ready in ~1 hour
[18:06] <iulian> persia: That would be great. The next UDS will be in Europe, am I right?
[18:06] <huats> I have been talking with persia regarding your email on the mentoring issue
[18:06] <ScottK> iulian: That's the general pattern.
[18:06] <huats> (btw I have accepted your email on the list)
[18:06] <ScottK> huats: I think persia's mail on the topic is a step in a good direction.
[18:07] <huats> I will answer on the list directly (with my mentoring receptionist hat on :))
[18:07] <huats> ScottK: as I said (or at least, as I act) I am clearly in favor of refining the mentoring processes
[18:07] <huats> to go to a better schema
[18:07] <ScottK> OK.
[18:08] <webtech_m33> Scottk: any luck with a backport of clamav 0.94.1 for hardy?
[18:08] <ScottK> webtech_m33: Still waiting for it to get uploaded to Debian.
[18:08] <ScottK> It was supposed to be uploaded over the weekend, but it didn't get done.
[18:08] <huats> ScottK: I think, the main issue here, might be the definition of uuc
[18:08] <ScottK> huats: I think persia's mail is a good basis for this.
[18:09] <ScottK> huats: UUC is an Ubuntu Member who got membership through the MC.  That's it.
[18:09] <webtech_m33> Scottk: is there a place i can download it from, before it gets upload to debian - ubuntu
[18:10] <ScottK> webtech_m33: Not really.  The 0.94.1RC that's in Intrepid is not very different from the final.
[18:10] <huats> ScottK: since from my point of view (and many people) it is the way to get ubuntu membershio through development involvment, with of course the samed standard than for the motuship
[18:10] <persia> ScottK, Well, in fairness, there is a high correlation between achieving membership through UUC and having done some package maintenance.
[18:10] <huats> soryy with a different standard I mean...
[18:11] <ScottK> persia: True, but there is no standard of knowledge or experience required.
[18:11] <huats> (lower requirements)
[18:11] <persia> huats, The difference in standard is precisely the technical review.
[18:11] <ScottK> Exactly.
[18:11] <persia> ScottK, Absolutely.
[18:11] <a|wen> any reason why debian would want to not use dh_icons while we want to? ... i'm doing a merge where this is the only ubuntu-specific change
[18:11] <huats> the whole question might be : no technical review at all, or a lower review to get uuc ?
[18:12] <ScottK> a|wen: Because the Debian Menu system doesn't use it, so they might view it as irrelevant.
[18:12] <persia> a|wen, Depends on the maintainer.  Check the BTS : there ought already be a patch waiting for the maintainer to review.
[18:12] <persia> huats, At least I don't perform any technical review.  I check IRC logs, wiki work, other things linked from the wiki page, loose volume of uploads, bug discussions, etc.
[18:12] <ScottK> huats: No technical review at all.  Development experience gets discussed, but that's only what makes MC an appropriate venue to consider the membership application.
[18:13] <ScottK> No one has ever not been made a UUC due to technical issues.
[18:13] <huats> ScottK: but due to development involvement
[18:13] <a|wen> persia, ScottK: no bug report ... and the last changelog entry (from debian) contains "add a commented call to dh_icons"
[18:13] <persia> And that won't happen : membership is specifically a recognition of social interaction.
[18:14] <ScottK> huats: Involvement yes, but no particular technical knowledge needed.
[18:14] <persia> a|wen, That sounds intentional then.  Just uncomment it, as the Ubuntu package won't install cleanly without either reloading the session, calling dh_icons, or the user taking manual action.
[18:14] <ScottK> webtech_m33: They are actually working on it as we speak (in Debian).
[18:15] <a|wen> persia: i'll keep the change then, thx
[18:15] <huats> ScottK:  and do you think a particular knowledge is needed for mentoring in the junior program ? (that is a question not a blaming way :))
[18:15] <slytherin> a|wen: you may also want to check what is the debhelper versing being used. dh_cions is available in debhelper > 5.0.51.
[18:16] <huats> honestly I think that someone who has acheived the junior program in the mentoring process... and thus who become a uuc, can explain the basics...
[18:16] <persia> a|wen, Specifically, both Ubuntu and Kubuntu rely on the iconcache to display icons in the menus, etc.  Debian does for certain types of GNOME and KDE desktop environments, but that's certainly not as much the default for Debian as it is for Ubuntu.
[18:16]  * persia isn't sure if Xubuntu relies on the XDG iconcache
[18:16] <ScottK> huats: I'd start with knowing enough to not recommend novice developers upgrade to Jaunty right now.
[18:16] <a|wen> slytherin: debhelper >= 5.0.51 is specified in controls
[18:16] <persia> huats, I don't disagree that most of them could, but I think it's a waste of their time to do it individually and privately.
[18:17] <huats> ScottK: I am very very surprised by that ....
[18:17] <persia> Ubuntu is what it is in large part because of the team collaboration.  We should use and reinforce that.
[18:17] <huats> persia: I see your point clearly
[18:17] <ScottK> huats: As persia has suggested redefining the role as a social role, I think it's reasonable for UUC to do that.
[18:17] <slytherin> a|wen: good then. I believe that diff has to be maintained. I remember same experience where Debian maintainer refused to adopt the change.
[18:17] <huats> ScottK: I will contact the mentor you mentioned to have his side of the story
[18:18] <persia> Note that I *don't* mean to exclude UUC from contributing to training : it's fun, and the best way to learn is to teach, I just think it ought be collboartive and separate from mentoring.
[18:18] <huats> ScottK: since I am very surprised by someone who is around for such a long time...
[18:18] <a|wen> slytherin: sadly, yes ... more "fun" for the mergers :/
[18:18] <ScottK> huats: That's good.  As I said in my mail to the list, I only have one side of the story.
[18:18] <slytherin> I believe that mentoring discussions should not happen in private. Rather mentors should encourage participation on this channel.
[18:18] <huats> ScottK: I know you were not blaming YET :)
[18:18] <huats> ;)
[18:18] <ScottK> huats: Regardless of the specifcs in this case, I think the way things have been working is not the best.
[18:18] <ScottK> slytherin: +1
[18:19] <Milyardo> :)
[18:20] <huats> From my point of view, a mentor is someone you can contact at the beginning or for his experiences
[18:20] <huats> in order to know who to contact
[18:20] <huats> by instance on a spedific problem
[18:21] <persia> RIght.
[18:21] <huats> but of course the usage of this channel and other team interactions medium is more than encouraged....
[18:22] <ScottK> huats: Historically the pattern in the mentoring program has been the opposite.
[18:22] <ScottK> It's one of my primary objections to it.
[18:22] <persia> The most common thing I said to any of my mentees was "Ask me that on #ubuntu-motu".  Some of them were reluctant to do so, but all are typically present here now, and active, which I think is a positive thing.
[18:22] <persia> Well, except for one who left Ubuntu, but he was here for a whlie in the meantime.
[18:23] <ssaboum> personnaly i uploaded packages, and don't actually know what to do now :-) but that's just me i guess
[18:24] <huats> ScottK: this is something that we need to emphasize (the usage of teams tools)
[18:24] <persia> ssaboum, It's precisely developers like yourself that make me happy that the mentoring program isn't mandatory.
[18:24] <persia> ssaboum, If you're bored, try tackling UEHS
[18:24] <ssaboum> why is that :-), (although i'm glad lol )
[18:25] <slytherin> ssaboum: you can find lot of stuff to do at qa.ubuntuwire.com
[18:25] <ssaboum> thanks :-)
[18:25] <persia> ssaboum, Because some people need an introduction to our culture, and others (like yourself) don't.  I prefer to cater to both sorts.
[18:26] <ssaboum> i get it
[18:28]  * slytherin just filed "move to universe bug of the day" :-)
[18:28] <persia> slytherin, How many days left?
[18:28] <a|wen> if the merges is a bump to a new upstream revision as well, is it enough to include the two debdiffs?
[18:29] <slytherin> persia: No idea. There are still about 10 packages. Some need sync before move to universe.
[18:29] <persia> a|wen, Could you give a specific example?
[18:29] <persia> slytherin, Only 10 left?  Nice work!
[18:29] <a|wen> persia: pkg knutclient ... we have 0.9.3 and 0.9.4 is merged in
[18:30] <persia> a|wen, Debian has 0.9.4?
[18:30] <slytherin> persia: Well, if more packages switch to openjdk after the lenny is released and move form contrib to main, there will be still lot of work to do.
[18:30] <a|wen> persia: yes
[18:30] <persia> a|wen, Just a debdiff against Debian will be fine.  Your sponsor can use that to evaluate it.
[18:31] <slytherin> a|wen: just a debdiff against Debian.
[18:31] <a|wen> persia, slytherin: thx
[18:34] <slytherin> persia: I have added 'killall sun-java5-*' to our roadmap. I will see what packages in jaunty currently have build/runtime dependency on sun-java5*
[18:35]  * persia heads off happily to celebrate the news
[18:36] <slytherin> what news?
[18:37]  * slytherin heads to bed.
[18:42] <persia> The news that we get to drop yet another binary package from multiverse.
[18:59] <mehdid> Hello all,
[18:59] <mehdid> I have some questions/remark about maintaining packages in ubuntu.
[19:00] <fabrice_sp> Hi. Can someone have a look at Bug #284910. It seems that libtool version is the root cause of the problem, but I'm a bit stuck
[19:00] <fabrice_sp> Hi mehdid: just ask
[19:01] <Yasumoto> Where can I find the latest Debian version of a package? (and hopefully download it?)
[19:01] <mehdid> I maintain some packages in Debian and noticed that the «why» package is affected by a serious bug in intrepid, fixed in debian lenny
[19:01] <RainCT> Yasumoto: http://packages.debian.org
[19:01] <mehdid> I don't know exactly how you guys work in Ubuntu but I would like to give some help ... at least for my packages
[19:02] <mehdid> So, what can I do ? and how ?
[19:02] <RainCT> mehdid: how serious is that bug?
[19:03] <mehdid> well why uses a cpulimit like program ... when proving a program, why uses cpulimit to fix a time limit
[19:03] <mehdid> and in 2.13-1 it uses a wrong syntax
[19:04] <Yasumoto> RainCT: that would make sense. Thanks :)
[19:04] <nellery> in Jaunty it is already 2.13-2
[19:04] <RainCT> mehdid: If the package is in Debian unstable and Ubuntu hasn't modified it, the new version will be atuomatically copied into the current Ubuntu development version, which right now is Jaunty (this is done for some months, until DebianImportFreeze; after that, syncs can be requested manually: https://wiki.ubuntu.com/SyncRequestProcess)
[19:04] <mehdid> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498485
[19:04] <nellery> http://packages.ubuntu.com/jaunty/why
[19:05] <mehdid> ok and what's about intrepid ?
[19:05] <RainCT> mehdid: and if the problem is important enough that it should be fixed in Intrepid then you can request a Stable Release Update for it (after the fix is in the development release) https://wiki.ubuntu.com/StableReleaseUpdates
[19:05] <mehdid> ok
[19:08] <RainCT> iulian: lintian complains about your description (possible-unindented-list-in-extended-description)
[19:08] <thiagoss> Can someone give me some help with debconf? I've read the tutorial in debconf but some things don't work.
[19:27] <RainCT> iulian: anyway, uploaded :)
[19:32] <huats> persia: and ScottK I need to leave right now
[19:32] <huats> but I will continue to answer your proposal persia later tonight :)
[19:38] <gouki> PPA seems to be working OK now.
[19:46] <gouki> Can I send an ITP manually, without using reportbug?
[19:47] <RainCT> gouki: yep, just send a mail to submit@bugs.debian.org and start the mail with "Package: wnpp" and "Severity: wishlist" (each on a list).
[19:47] <RainCT> but I think reportbug also send a mail to a ML or something for ITPs
[19:48] <ScottK> gouki and RainCT: ITP needs to go to debian-devel too.
[19:48] <ScottK> There's a specific right way to do it that is hard to get right except through reportbug.
[19:48] <directhex> dear lintian, please put down the crack pipe
[19:48] <ssaboum> :-)
[19:49] <laga> hum
[19:49] <directhex> grep timestamp /tmp/gdi/libgdiplus-2.0/config.guess
[19:49] <directhex> timestamp='2008-01-23'
[19:49] <laga> oops
[19:49] <directhex> E: libgdiplus source: outdated-autotools-helper-file pixman/config.guess 2003-06-17
[19:49] <ssaboum> nice, clear and so gentle
[19:49] <RainCT> ScottK: uhm.. I've never done this *g*
[19:49] <directhex> oh, hang on... wrong file.....
[19:52] <gouki> Any idea how I can ask reportbug to use a already written bug file then? Nothing on the manual.
[19:54] <ScottK> gouki: It'll eventually open up the draft bug in $EDITOR.  You can copy/paste then.
[19:54] <gouki> ScottK, OK. Thanks.,
[19:59] <fabrice_sp> Hi again. For package cantlr, I made a change to fix bug #290164 , that is not yet in Debian (Debian bug #504050). Should I wait for Debian to integrate it to request the sync or do the merge with the actual Debian version?
[20:03] <pochu> fabrice_sp: since it's been opened for a couple of weeks, I'd fix it in Ubuntu and sync later if possible
[20:04] <fabrice_sp> pochu: ok. I'll fill a merge request, and post my debdiff then. Thanks.
[20:17] <RainCT> uhm.. bluetooth isn't working anymore here (this is the first time I try on Intrepid) :/
[20:28] <iulian> RainCT: Thanks, I'll fix it next time.
[20:32] <Yasumoto> If someone has some time, can you look at this and let me know what else I should do to get this fix in? https://bugs.edge.launchpad.net/ubuntu/+source/libgnomecanvas/+bug/272316 thanks!
[20:35] <zul> persia: around?
[20:47]  * iulian goes to bed.
[20:47] <iulian> Good night.
[20:51] <DRebellion> Hey guys! If anybody's looking for something to revu, i've just uploaded monkeystudio for your viewing pleasure: http://revu.ubuntuwire.com/details.py?package=monkeystudio . Thanks in advance ;)
[21:05] <fabrice_sp> When subscribing U-S-u for a sync request, should I leave the bug as New or Confirmed?
[21:06] <james_w> fabrice_sp: New please
[21:06] <fabrice_sp> ok And the same for a merge request, with a debdiff?
[21:10] <james_w> fabrice_sp: no, that can be pretty much any status, triaged would be appropriate I believe
[21:31] <porthose> DktrKranz: just tested slidentd on jaunty and I get this
[21:32] <porthose> DktrKranz: 0, 0: ERROR:  UNKOWN-ERROR
[21:32] <porthose> DktrKranz: when trying to launch it
[21:33] <bmm> Is the "ask a maximum of once a day" a per package or per person rule??
[21:36] <RainCT> bmm: the rule is: "don't annoy" ;)
[21:36] <bmm> RainCT: ah, ok.. I won't :P
[21:37] <gouki> PPA built for i386 and amd64 .. No luck with lpia so far.
[21:41] <bmm> Anybody with time left over, there is a new upstream packaged here, ready for any and all comments: http://revu.ubuntuwire.com/details.py?package=ccbuild
[21:44] <gouki> bmm, bump the compat to 6 instead of 5?
[21:45] <bmm> gouki: ok
[21:50] <bmm> gouki: that means debhelper >= 6 and debian/compat=6 right?
[21:51] <DktrKranz> porthose, it seems not dietlibc-related. issue was from bug 86823
[21:51] <gouki> I just meant debian/compat to 6, actually bmm. Sorry for not being more explicit.
[21:51] <bmm> gouki: np
[21:55] <RAOF> Although if you bump debian/compat to 6, you'll _also_ want to build-depend on debhelper >= 6.
[21:56] <bmm> Do I? I have no idea really.
[21:56] <bmm> I would like to know, I was literally seconds away from pushing return on dput revu...
[21:56] <RAOF> Because debhelper < 6 obviously won't understand debhelper 6 compatibility :)
[21:57] <bmm> Ah, right, so both need to be updated then
[21:57] <crimsun> yes/win 68
[21:57] <crimsun> yes
[21:57] <crimsun> err, sorry
[21:57] <RAOF> (man debhelper gives the differences in what is different in each compatibility mode)
[21:57] <RAOF> crimsun: My, you win a lot :)
[21:59] <RAOF> Note that you might want to keep the compatibility level at 5; IIRC Hardy only has debhelper 5, so if you want the package to be backportable to the most recent LTS, you can't depend on debhelper >= 6.
[22:00] <pochu> isn't debhelper backported?
[22:01] <RAOF> Surely not?  Isn't that pretty much the definition of "break-the-world core functionality"?
[22:02] <RAOF> No, packages.ubuntu.com says you're right.  Debhelper 7 in hardy-backports.
[22:02] <bmm> Ah, so debhelper level is not a problem for backports? That's news to me.
[22:02] <ajmitch> RAOF: it's only bad if it's not backwards-compatible :)
[22:03] <RAOF> ajmitch: You mean, like introducing new bugs? :)
[22:03] <ajmitch> that'd never happen
[22:04] <RAOF> bmm: News to me, too.
[22:04] <nixternal> noisey in here
[22:04] <bmm> nixternal: actually pretty informative if you ask me ;)
[22:05] <nixternal> informative in this channel? with ajmitch and crimsun around? I don't believe it!
[22:05] <nixternal> THE TRINITIY!
[22:05] <bmm> So I should just push the debhelper compat to 7, as backports can handle that?
[22:06] <ajmitch> nixternal: sorry, I was never a member
[22:06] <nixternal> don't try and get out of it like someone else did
[22:06] <ajmitch> !nixternal
[22:06] <nixternal> damnit, that is still around
[22:06]  * nixternal tosses a stick at Hobbsee
[22:06] <pochu> bmm: also bump debhelper compat if you are using new features
[22:07] <bmm> pochu: I'm not using new features, level 5 even works. But if there is no reason to keep it low, I might as well push it up to 7, right?
[22:08] <nixternal> bmm: if you plan on backporting it, then no
[22:09] <RAOF> nixternal: As previously discussed, Hardy has debhelper 7.
[22:09] <bmm> nixternal: that was the informative part of the channel. Backports contain debhelper 7
[22:09] <RAOF> nixternal: Backports aren't an issue.
[22:09] <nixternal> nice, see what you miss when you take a break and work in RL
[22:09] <ajmitch> nixternal: how could you abandon us?
[22:10] <RAOF> bmm: I wouldn't bump debhelper compat unless I was actually using the new behaviour/features.  That said, I also wouldn't _object_ to bumping debhelper.
[22:10] <nixternal> ajmitch: $$$
[22:10] <ajmitch> sellout
[22:10] <nixternal> ajmitch: it is Open Source software that is paying me dude...no sellout here :)
[22:10]  * ajmitch would never be caught working for the Man!
[22:10] <ajmitch> :)
[22:11] <nixternal> paying me more than my proprietary days
[22:11] <ajmitch> oh alright
[22:11] <ajmitch> sign me up :)
[22:11] <nixternal> move to chicago dude...gotcha hooked up :)
[22:11] <ajmitch> hah
[22:11]  * ajmitch will start walking there tomorrow
[22:11] <nixternal> need someone to setup a buildd and mirrors for me :)
[22:12] <ssaboum> 'night everyone
[22:14] <ajmitch> nixternal: what do you do, anyway?
[22:14] <rrittenhouse> Does anybody here use Twitux + Ibex?
[22:15] <bmm> ROAF: ok, I'm going with V6 because of the manpage change thing.
[22:17] <nixternal> ajmitch: Linux development, platform development, application development.... do some python, some java, some bash, and unfortunately some yum and rpm for the time being
[22:17] <nixternal> v2 of our appliances will be ubuntu based though
[22:18] <ajmitch> sounds interesting
[23:01] <sparr> is this or #ubuntu the appropriate place for questions about problems with packages in ubuntu?
[23:04] <ScottK> sparr: This channel is about development and packaging stuff.  If you need help with a problem, #ubuntu is the place.
[23:04] <sparr> well, not so much help as reporting.  i dont expect to be able to fix the problem, but im not sure how to gather the information that i need to file a bug report
[23:05] <sparr> but thanks, ill ask there
[23:06] <ScottK> sparr: That sounds like you want #ubuntu-bugs then.
[23:07] <ScottK> We do have a lot of channels.
[23:45] <emgent> gouki: ping
[23:49] <gouki> ember, here.
[23:56] <gouki> ember, GTG! gouki@ubuntu