[00:03] <Drk_Guy> lol
[00:03] <Drk_Guy> I'm not going to compile Songbird as it is already on GetDeb.net
[00:03] <Drk_Guy> thus, that packaging request should be deleted
[00:04] <RAOF> Drk_Guy: GetDeb.net =/= Universe.
[00:04] <Drk_Guy> RAOF, Still, GetDeb.net is official cannonical site, why wouldn't you use it?
[00:04] <RAOF> Wherever did you get that impression?
[00:05] <Drk_Guy> Yup
[00:06] <Drk_Guy> Should i compile VDrift?
[00:06] <RAOF> That's not an answer to the question "Why do you think GetDeb.net is an official Canonical site"?
[00:06] <Drk_Guy> 1.5 hours of uploading
[00:06] <Drk_Guy> Real good
[00:06] <Drk_Guy> RAOF, Idk, it's kinda hunch
[00:06] <ion_> ≠
[00:07] <crimsun> I just rolled in my grave.
[00:07] <null_vector> Hello motu
[00:07] <ion_> crimsun: :-)
[00:07] <RAOF> Drk_Guy: GetDeb.net is very, very much not in anyway endorsed by Canonical, MOTU, or God.
[00:07] <RainCT> hi null_vector
[00:07] <Drk_Guy> Still, VDrift uses scons, so i would have to edit rules, and i'm too lazy to do that
[00:07] <Drk_Guy> RAOF, God?, lawl
[00:07] <null_vector> RainCT: got your email.  thanks
[00:07] <RainCT> yw :)
[00:08] <RainCT> so, I'm really of now... good night
[00:08] <RAOF> Drk_Guy: In fact, "highly recommended against" would be a more accurate portrayal of our position.
[00:08] <null_vector> night
[00:08] <Drk_Guy> RAOF, So you suggest NOT using GetDeb, right?
[00:08] <Drk_Guy> RAOF, Why?, their DEB's are fine
[00:08] <null_vector> lol
[00:09] <RAOF> Drk_Guy: Absolutely.
[00:09] <RAOF> Because their debs are _not_ fine.
[00:09] <RainCT> now that I was starting to don't dislike getdeb, RAOF comes and awakes my distrust again :P
[00:09] <RAOF> Or, at least, there's no way to distinguish between the bad and the good.
[00:09] <Drk_Guy> RAOF, Dirty checkinstalls?
[00:09] <RAOF> Possibly.  Also: breaking upgrades, etc.
[00:11] <Drk_Guy> RAOF, A GetDeb OpenArena deb made some updates to refuse being installed
[00:11] <RAOF> Absolutely possible.
[00:11] <RAOF> The question is: do you trust random uploaders with root access to your box?
[00:11] <Drk_Guy> RAOF, So, i'd better use PPA's/Repos/REVU
[00:12] <ion_> I don’t understand why the getdeb folks don’t just direct their effort to Ubuntu universe.
[00:12] <Drk_Guy> RAOF, I haven't heard of real bad things against GetDEb
[00:12] <Drk_Guy> RAOF, Except of your critiscism obviously
[00:12] <RAOF> ion_: Because our quality standards impede the fresh flow of packaging.
[00:12] <RAOF> :)
[00:12] <null_vector> random ppa's are just as bad *g*
[00:13] <RAOF> Drk_Guy: PPAs suffer the same problems as GetDeb.
[00:13] <RAOF> Either way, you're giving root access to some guy on the internet :)
[00:13]  * Drk_Guy is hungry, going to something to eat
[00:16] <Drk_Guy> RAOF, Huh?, PPA's are dev_script'd
[00:16] <Drk_Guy> RAOF, You upload src, they compile
[00:16] <RAOF> Indeed.
[00:17] <RAOF> I publish a deb with 'rm -rf /' in the preinst.    All the maintainer scripts run as root.
[00:17] <Drk_Guy> I know
[00:18]  * Drk_Guy is going to do a second wish list DEB, gimpshop
[00:19]  * Drk_Guy finds linux WAY EASIER than windows
[00:23] <Drk_Guy> RAOF, is editing rules hard?
[00:23] <RAOF> They're just makefiles.
[00:26] <Drk_Guy> RAOF, Huh?
[00:26] <RAOF> debian/rules is just a makefile.
[00:26] <Drk_Guy> RAOF, lol, should i use the one provided by dh_make?
[00:26] <RAOF> You should probably read the packaging guide.
[00:26] <RAOF> !packagingguide
[00:27] <Drk_Guy> RAOF, I read it dude
[00:27] <Drk_Guy> lol
[00:27] <Drk_Guy> I just have some soft spots to cover
[00:31] <RAOF> So, starting with the rules file provided by dh_make isn't a bad idea.  But you'll certainly need to edit it.
[00:33] <ion_> dh_make still doesn’t seem to know how to generate a debhelper 7 rules file. I recommend using either cdbs or dh 7 instead of the old dh rules.
[00:34] <RAOF> Well, yes.  Unless you'd like it to be backportable.
[00:34] <Drk_Guy> ion_, cdbs?, ok, i'll give it a try
[00:34] <ion_> raof: Well, dh 7 could be backported. ;-)
[00:34] <RAOF> jdong would kill you :)
[00:36] <Drk_Guy> ion_, Ok, so dh_make, and then edit control to include cdbs as build-depend, right?
[00:36] <ion_> dh_make already adds cdbs as a build-dep. See dh_make --help
[00:37]  * Drk_Guy notices something weird, his ppa is http 404, and wine hasn't compiled after one hour of uplaoding
[00:37] <Drk_Guy> ion_, ok
[00:48] <Drk_Guy> This is weird, apt-cache show gimp won't show needed devel packages
[00:49] <azeem> Drk_Guy: why should it?
[00:49] <Drk_Guy> azeem, I need it for a control file
[00:50] <Drk_Guy> azeem, I mean, i want to make a gimpshop package, but i don't have the required devel libs names
[00:50] <azeem> right, but apt-cache show gimp displays the run-time dependencies, not the needed devel packages
[00:50] <stgraber> Drk_Guy: try: apt-cache showsrc gimp
[00:51] <stgraber> showsrc is for source packages and show build-deps
[00:51] <Drk_Guy> azeem, ok
[00:52] <Drk_Guy> stgraber, that worked, but, does the control file tells the package name, or the dir's name does that?
[00:53] <ion_> Better take a look at gimpshop’s own build-dependencies, from configure.{in,ac}, README etc.
[00:53] <azeem> does what?
[00:53] <stgraber> in control you have first the part describing the source package then one section for each binary package
[00:53] <stgraber> (not sure I understood the question though)
[00:54] <Drk_Guy> stgraber, i mean, what determines package name, dir or control file?
[00:54] <azeem> what is "dir"?
[00:54] <Drk_Guy> ion_, It has almost no documentation, and the dir i extracted shows up something very similar to gimp's source dir
[00:54] <azeem> besides, there's source package name and binary/binaries package name(s)
[00:54] <Drk_Guy> ion_, besides standard gimp docs, there's nothing else
[00:55] <ion_> The package name is determined from the control file for both source and binary packages.
[00:55] <azeem> Drk_Guy: maybe it's some gross hack that shouldn't get packaged then
[00:55] <Drk_Guy> azeem, gimpshop is a hack by itself, figure it out from the name
[00:55] <Drk_Guy> ok ion_ thanks
[00:55] <Drk_Guy> ion_, configure.in is a lil bit confusing ;)
[00:56] <azeem> if this is your first package, something as complicated as gimp is maybe too ambitious
[00:57] <Drk_Guy> azeem, It's not my first
[00:57] <Drk_Guy> azeem, I've succesfully done a wine package with 3DMark patch
[00:57] <Drk_Guy> As well as the tut's hello package ;)=
[01:00] <Drk_Guy> Should i use gimp's or gimpshop's changelog?
[01:00] <azeem> as upstream changelog?
[01:02] <Drk_Guy> I'm using gimpshop's included changelog
[01:06] <Drk_Guy> What should i put into copyright, taking in account someone hacked original gimp?
[01:07] <azeem> what copyright?
[01:07] <Drk_Guy> debian/copyright
[01:07] <azeem> the original debian/copyright, plus the copyright of the modifications I guess
[01:08] <RAOF> It should contain all the copyright information for all the files in the package.
[01:08] <RAOF> http://www.debian.org/doc/debian-policy/ch-source.html may help you.
[01:10] <persia> Drk_Guy: Just as a side note, we generally discourage the packaging of duplicated code: if this is indeed just a hack from the same source (rather than an interface overlay using the same libgimp, etc.), it may be considered unsuitable from a maintenance viewpoint (-security, -updates, etc.)
[01:11] <Drk_Guy> persia, then what should i do?
[01:11] <persia> Drk_Guy: Towards which goal?
[01:12] <Drk_Guy> persia, I mean, it is on a wish list, and i put it as "In progress"
[01:12] <azeem> what is "it"?
[01:13] <Drk_Guy> I mean, the bug is "in progress"
[01:13] <azeem> which bug?
[01:13] <Drk_Guy> Bug 114109
[01:15] <persia> Drk_Guy: Well, you can research it a bit more: if it's full of duplicate code, you can set it back to "New" or "Confirmed" with a note saying that packaging is difficult due to duplicated code with gimp.  If you really want it, and this is the case, you can work with upstream.  If there isn't lots of duplicated code, then you ought just keep going.
[01:15] <azeem> well, just because something is on a somebody's wishlist doesn't mean it makes sense to add it to the Ubuntu archive
[01:15] <Drk_Guy> persia, http://plasticbugs.com/?page_id=294 affirms it's just a GUI hack, to make GIMP photoshop-ish
[01:15] <persia> azeem: I disagree with that: I think everything on everyone's wishlist should be in the archive, although this takes a bit of work to get every upstream to play nice.
[01:16] <persia> Drk_Guy: OK.  How is it organised?  If it's an overlay that needs the gimp libraries to build, it ought be fine.  If it's a dirty hack, it needs coordination with upstream or to be left for later.
[01:18] <Drk_Guy> persia: it is just a different-GUI hack
[01:18] <Drk_Guy> I mean, the menus are re-organized
[01:18] <persia> Drk_Guy: Is there a lot of duplicated code?
[01:19] <Drk_Guy> I don't really know, the folder reads gimp-2.2.11
[01:19] <Drk_Guy> lol
[01:19] <persia> Drk_Guy: Well, intrepid has gimp 2.4.6, so I doubt that the version of gimpshop you're investigating is compatible.
[01:20] <Drk_Guy> persia, the changelog is really distorted and it's way large to organize it
[01:20]  * persia marvels at gutsy-backports having 2.4.6 and hardy-backports having 2.4.5.
[01:20] <persia> Drk_Guy: It sounds like you've found a hard one.  Maybe pass on this for now, and pick something else?
[01:21] <Drk_Guy> persia, i think i'll set it back to New or confirmed
[01:21] <Drk_Guy> :P
[01:32] <Drk_Guy> persia, I'm trying to compile Mediainfo, but it has an sh to compile itself, should i edit control to run the sh?
[01:34] <azeem> control?
[01:35] <Drk_Guy> azeem, debian/control
[01:35] <azeem> how would debian/control run the sh?
[01:36] <Drk_Guy> azeem, idk, the SH is there
[01:36] <Drk_Guy> in the src's root
[01:36] <azeem> what?
[01:36] <Drk_Guy> and it has various subdirs
[01:36] <azeem> I neither what you mean with "idk", nor with "SH"
[01:36] <Drk_Guy> SH is a script, idk is i dont know
[01:36] <Drk_Guy> ;)
[01:37] <azeem> that doesn't answer my question
[01:38] <Drk_Guy> azeem, i have a dir with the src, but in that dir, there is a script to compile it, along with directories with other programs
[01:38] <azeem> ok
[01:38] <azeem> what does that have to do with debian/control?
[01:39] <Drk_Guy> I mean, normally, it is configure-make-make install
[01:39] <Drk_Guy> But this soft has an auto-compile script
[01:40] <azeem> Drk_Guy: debian/control only contains meta-data, it doesn't have much to do with how packages are built
[01:40] <Drk_Guy> lol, sorry, it's debian/rules
[01:43] <Drk_Guy> azeem ...
[01:43] <azeem> ?
[01:43] <Drk_Guy> Any ideas?
[01:44] <azeem> figure out which rules are mandated in debian/rules, and where calling that shell-script-to-build-things would fit
[01:45] <Drk_Guy> :(
[01:48] <RAOF> Drk_Guy: In order to work that out, you'd want to be looking at the debian policy link I gave earlier.
[01:48] <Drk_Guy> lol
[01:49] <RAOF> http://www.debian.org/doc/debian-policy/ch-source.html - the rules section lists all the mandatory targets of a debian/rules file, and what they're meant to do.
[01:49] <Drk_Guy> lol RAOF, i'm going to continue trying tomorrow
[02:10] <rootvzla> hi nxvl
[02:14] <nxvl> hi!
[02:15] <ion_> Eh. getdeb.net: “© 2008 Canonical Ltd. Ubuntu and Canonical are registered trademarks of Canonical Ltd.
[02:15] <ion_>     * Mirrors
[02:15] <ion_> Whoops. Well, anyway.
[02:15] <ion_> No wonder people think it’s blessed by Canonical.
[02:17] <RAOF> Owch.
[02:27] <TheMuso> Thats bad.
[02:35] <persia> It's always been that way.
[02:35] <nxvl> persia: i send you and e-mail an hout ago or something, did you got it?
[02:35] <persia> nxvl: Possibly.  I don't check my email that frequently.
[02:36] <nxvl> :D
[02:37] <persia> nxvl: re: https://wiki.ubuntu.com/MOTU/Mentoring/NewModel ?
[02:37] <nxvl> persia: i'm for your splitting-the-mentoring-program idea and added some bits on it
[02:37] <nxvl> persia: yep, exactly
[02:38] <persia> Nice write up.  Best to work with the mentoring team on that, rather than me :)
[02:38] <nxvl> persia: i'm part of the mentoring team
[02:39] <nxvl> persia: i just wanted you to check it since you made the first suggestion
[02:42] <bddebian> Heya gang
[02:42] <nxvl> \o\ |o| /o/
[02:42] <persia> nxvl: My main interest was in shortening mentoring cycles.  With the current model, a mentoring period can last over a year, which ties up a mentor for a fairly long time.  Having a clear end (whether timeframe or target) helps with this.
[02:43] <nxvl> got dammit i hate library changes between ubuntu and debian
[02:43] <nxvl> ugh!
[02:44] <nxvl> persia: yes, also we don't have any idea of how is it going between mentors and mentees
[02:44] <nxvl> there is no monitoring on the process
[02:45] <nxvl> also, as i write it on the wiki, senior contributor have more time and energy to help new people than old developers
[02:45] <Hobbsee> hey bddebian!
[02:45] <bddebian> Hi Hobbsee
[02:50] <persia> nxvl: I don't think it's useful to say "MOTU aren't allowed to mentor completely new people".  That said, depending on where each of us is on the path, anyone a few steps beyond is capable of being a great help.
[02:51] <nxvl> persia: yes, that's true, i should clear that
[02:52] <nxvl> persia: i tryed to meant that we should allow senior contributors to join the program
[02:57] <persia> nxvl: I'm all in favour of allowing more people to help with things :)
[02:59] <nxvl> persia: yes, that's the idea i just didn't cleared it enought :D
[03:57]  * ScottK is still waiting for some evidence that the mentoring program is a net plus to the project.
[04:02] <RAOF> Hm.  Why is lintian complaining about old-fsf-address?
[04:07] <ion_> Because of... the old FSF address? :-)
[04:07] <RAOF> Nope.
[04:07] <persia> RAOF: Are you sure?  Sometimes it's embedded somewhere.
[04:07] <RAOF> Not in the file that lintian is complaining about.
[04:08] <persia> Does the file have the address twice?  I've seen that a couple times.
[04:09] <RAOF> http://pastebin.com/f543c0963
[04:10] <RAOF> That is /usr/share/doc/$PACKAGE/copyright, the file lintian is complaining about.
[04:11] <RAOF> Urgh.  Typo; 20110-1301 != 20110-1307
[04:12] <persia> lintian isn't smart enough to trick you :)
[04:14] <RAOF> No, but it's dumb enough to perplex me :)
[04:34] <AnAnt> is rainCT here ?
[04:35] <ScottK> He's almost certainly sleeping right now.
[04:35] <AnAnt> hmmm, I need help about this: http://revu.tauware.de/details.py?package=webstrict
[04:35] <AnAnt> he says: The Maintainer field must have an @ubuntu.com address.
[04:35] <persia> AnAnt: Which part?
[04:36] <AnAnt> I thought that having the maintainer field as a mailing list on launchpad was fine
[04:36] <persia> It's supposed to be an ubuntu mailing list for teams<EMAIL_ADDRESS>[04:37] <AnAnt> but we don't have such an address
[04:37] <persia> I thought there was a policy in place that helped avoid this sort of confusion: maybe ping jcastro if you can to help sort it (but not at this hour).
[04:39] <persia> I suspect that if you fixed everything else, that might not be a blocker.
[04:39] <AnAnt> persia: btw, regarding swt-gtk, when I should I file the sync request ? after mozillateam uploads a new xulrunner package that contains xulrunner-dev ?
[04:39] <persia> AnAnt: When the Debian package compiles and runs in Ubuntu with no further source modifications.
[04:40] <AnAnt> persia: that means I should wait for new xulrunner first
[04:40] <persia> AnAnt: If that is the planned solution, yes.
[04:41] <AnAnt> persia: problem is that I dunno when they will do so, I asked them and they said: when there's a new upstream release
[04:46] <persia> AnAnt: The other option is to prepare a changed source package for now.
[04:47] <ScottK> AnAnt: What RainCT says about the general policy is correct.  For your packages, I'm willing to forgo that rule (I have in the past).  If you get to where that's the only thing stopping an upload, let me know.
[04:50] <AnAnt> ScottK: thanks
[04:50] <ion_> Anyone feel like reviewing http://revu.tauware.de/details.py?package=compcache-setup? Thanks.
[04:51] <RAOF> Hm.  How much is broken on PowerPC?
[04:51] <AnAnt> regarding webstrict, I think it is possible to put release tarballs on launchpad, in that case there is no reason for get-orig-source, nor mention the bzr in copyright (rather mention the launchpad project page maybe)
[04:52] <RAOF> Or, rather, how surprised should I be that evolution-sharp FTBFS on PPC due to dependency problems?
[04:52] <coppro> how long must a package usually wait in REVU for a comment?
[04:54] <AnAnt> persia: the package is prepared & on REVU since a few days
[04:55] <persia> AnAnt: If you can get a release file published, your get-orig-source becomes a trivial call to uscan.
[04:55] <AnAnt> persia: you mean , I still need a get-orig-source ?
[04:55] <persia> RAOF: http://qa.ubuntuwire.com/ftbfs/
[04:55] <RAOF> coppro: An indeterminate period of time; once it's up, you probably want to poll in here about once a day.
[04:56] <persia> AnAnt: I think every package should have a get-orig-source.  Where there's an easy to access upstream, it's just a call to uscan --force-download.
[04:56] <persia> coppro: It varies widely: between 5 minutes and 5 months.
[04:56] <persia> RAOF: Or more specifically, less broken than anything else in ports.
[04:57] <RAOF> Oh, _ninjas_.  Please, gmcs, please don't segfault on the buildd.
[04:58] <AnAnt> persia: the swt-gtk package is prepared & on REVU since a few days
[04:59] <AnAnt> persia: that's reply to the other option you mentioned
[05:01] <coppro> ah, well then
[05:01] <coppro> i haven't really been doing the polling part
[05:01] <coppro> so, anyone up for REVUing?
[05:06] <foka> freeflying, Hi!
[05:06] <freeflying> foka: hey
[05:07] <freeflying> foka: REVU is something like mentors.debian.net
[05:07] <AnAnt> freeflying: yup
[05:07] <foka> freeflying, Cool.
[05:08] <RAOF> coppro: It's a good idea to include a link to your package, too.
[05:09] <coppro> ok, http://revu.ubuntuwire.com/details.py?package=libmk4
[05:13] <persia> foka: You just joined revu-uploaders?
[05:14]  * persia syncs the keyring anyway, in case the answer is yes, and to be sure to get a turn
[05:19] <foka> persia, Yes, I did some weeks ago, but this is the first time I begin looking into it.  :-)
[05:19] <freeflying> persia: I think foka also wanna to be MOTU :)
[05:19] <foka> freeflying, in the future, maybe.  :-)
[05:20] <foka> freeflying, It is better to start from the beginning and do it step by step.  :-)
[05:21] <freeflying> persia: foka is a experienced DD, he just don't know where to start :)
[05:25] <persia> foka: Welcome.  We use REVU a little differently than mentors.
[05:25] <persia> REVU is for NEW packages, but for update candidates (bugfixes, etc.) we prefer debdiffs attached to bugs, and subscribing the sponsors queue.
[05:27] <foka> persia, Thank you for your warm welcome!
[05:29] <foka> persia, Yes, I intend to upload two new packages for Ubuntu (which are not in Debian yet).  One is "sunpinyin", a CDDL/LGPL smart Chinese pinyin input method engine by Sun Microsystems, packaged for Debian by "Tchaikov" (Kov Chai) and which I sponsored uploaded for Debian, currently in the NEW queue.
[05:29] <foka> persia, Another that I am packaging is called novel-pinyin by a local Chinese Novell developer and is packaged for OpenSUSE 11.
[05:30] <persia> foka: Do you think they'll in NEW for long?  It's often easier to just sync once they get through Debian NEW.  On the other hand, if you want more time for testing/integration, REVU works, but it often takes at least as long as Debian NEW.
[05:30] <freeflying> persia: those two packages have some issue, maybe rejected by ftp-master
[05:30] <foka> freeflying, Not yet rejected.  :-)
[05:31] <foka> freeflying, Still being discussed and remedied.
[05:31] <persia> freeflying: Even more likely to get rejected from REVU then :)
[05:31] <freeflying> foka: yes, I mean maybe
[05:31] <freeflying> persia: :)
[05:32] <foka> persia, Brief background info: the issue relates to the "statistical data" generated by gathering about 150MB of Chinese text from on-line website.
[05:33] <persia> At runtime?  At build-time?  At packaging-time?
[05:33] <foka> persia, The resulting statistical data is CDDL/LGPL'ed.
[05:33] <foka> persia, Sun provides the statistical data in lm_sc.t3g.{i386,sparc}.
[05:34] <foka> persia, Sun provides the statistical data in the file data/lm_sc.t3g.{i386,sparc}.
[05:34] <foka> persia, It is not gathered/built/analysed at runtime or build-time.
[05:34] <persia> Oh, that sounds reasonable, although I'm not an archive-admin :)
[05:36] <foka> persia, So yes, Debian FTP master was asking further information about these files (as well as the pinyin phrase data, which thankfully we do have the source, elsewhere, just not packaged yet).  Kov Chai (the packager) replied a few days ago, and I added my take earlier today, now awaiting reply.  :-)
[05:37] <foka> persia, So, in most cases, you would prefer packages to be in Debian first, and then sync with Ubuntu, except for Ubuntu-specific packages?
[05:38] <persia> Ideally, yes.
[05:38] <persia> Note that there are about 1000 packages currently in Ubuntu that aren't in Debian, in part because nobody familiar with Debian processes has tried to get them in.
[05:39] <persia> It's always better when a package is in Debian, because that means that all Debian derivatives can use the same package, and there's more sharing of patches.
[05:39] <foka> persia, I see.  Maybe I can help do that, integrating these packages back to Debian.  :-)  (is that called Utnubu?)
[05:40] <persia> It also means there is a specific maintainer, which makes it easier for upstream to contact someone, and improves cooperation between upstream and the distributions.
[05:40] <persia> foka: Utnubu could definitely use some help.  I've seen very little activity from that team recently.
[05:41] <persia> On the other hand, unless someone can be found to be the maintainer, pushing it into Debian to sit in the hands of Debian QA isn't ideal.
[05:41] <foka> persia, Hmm... very true.
[05:41] <persia> For novell-pinyin and sunpinyin, I don't think this issue exists, which is why I think Debian is the right place.
[05:41] <freeflying> foka: another issue, ubuntu has moblin support, the data of sunpinyin is a bit big for them
[05:42] <persia> freeflying: Well, some builds have moblin support.  We also have some very large packages.  It depends on the target environment for each flavour.
[05:44] <freeflying> persia: the you n will suggest  not to build sunpinyin for lpia? :)
[05:44] <persia> freeflying: No, I suggest building it for all architectures.  I wouldn't expect the ubuntu-mobile seed to use it.
[05:45] <persia> Or with large data, likely better to have arch: any for the data anyway.
[05:45] <freeflying> persia: the problem is sunpinyin is an IM engine of scim, it performs  better than scim-pinyin
[05:46] <persia> freeflying: Last I checked, there was no SCIM in ubuntu-mobile at all (or at least not exposed in the UI).  I might be mistaken, as I didn't try an installation with an appropriate locale.
[05:46] <persia> I still think it's worth doing for lpia: there's plenty of press about non-mobile devices using those chips.
[05:47] <freeflying> persia: thanks
[05:53] <nxvl> ScottK: around?
[05:55] <ScottK> Yes.
[05:57] <ScottK> nxvl: ^^^
[05:57] <nxvl> ScottK: i take a look today at the mysql-gui-tools issue
[05:58] <nxvl> ScottK: it's a library problem
[05:58] <nxvl> ScottK: i have already send seb128 a mail for discussing it
[05:58] <ScottK> OK.  Great.
[05:59] <ScottK> This is what I'd expect a MOTU to do, is pursue the problem to the end and not leave the package FTBFS.
[05:59] <nxvl> it's a problem with the migration from libgail to libgtk2.0-0
[06:02] <foka> persia, I agree.  :-)  Besides, it is large, but not that large.  Probably about 40MB.
[06:35] <dholbach> good morning
[06:35] <nxvl> good morning
[06:35] <nxvl> dholbach: i have send you an e-mail
[06:35] <nxvl> dholbach: about the mentoring programm
[06:35] <nxvl> program*
[06:36] <dholbach> hi nxvl
[06:36] <dholbach> nxvl: I noticed :)
[06:37] <nxvl> D:
[06:37] <nxvl> :D
[06:40] <AstralJava> Morning Nicholas, Daniel. Interesting topic, and came to my mind to ask, are there guidelines for mentoring programme, or are they usually/always just individual deals between the mentor and the actor?
[06:41] <nxvl> StevenK: ping
[06:41] <StevenK> nxvl: ?
[06:41] <dholbach> AstralJava: https://wiki.ubuntu.com/MOTU/Mentoring
[06:41] <nxvl> StevenK: how is the libiw patch applied in netapplet?
[06:42] <Hobbsee> magic
[06:42] <nxvl> Hobbsee: yeah, it seems it does
[06:42] <StevenK> nxvl: I'm going to need a little more information than that. :-)
[06:42] <nxvl> AstralJava: is your patch
[06:42] <AstralJava> dholbach: Thanks. :)
[06:43] <nxvl> i can't build it and it seems to be a lib related problem
[06:43] <AstralJava> Yeah I sort of figured as much, but was wondering whether any stricter guidelines had been put in place.
[06:44] <nxvl> AstralJava: nope
[06:44] <nxvl> AstralJava: i'm trying to write something up
[06:45] <AstralJava> nxvl: Oh that's nice. I should subscribe to the page dholbach linked to, or is it going on someplace else?
[06:46] <nxvl> dholbach: btw, sorry about the avalanche of mails about emgent :P
[06:46] <nxvl> AstralJava: i use to write thing on a local file, then discuss it, and then upload it
[06:46] <nxvl> :D
[06:47] <nxvl> AstralJava: but if you want you can ping me from time to time to see if i've got something
[06:47] <nxvl> AstralJava: because now we are working on something else, which may change a little bit how things work
[06:47] <nxvl> AstralJava: so i will wait until we decide about it
[06:47] <AstralJava> nxvl: Not a prob. Chatting about it here is fun, but to catch the end result, it's going into the wiki, right?
[06:48] <nxvl> yup
[06:48] <nxvl> someday
[06:48] <nxvl> :D
[06:49] <AstralJava> nxvl: And yes, I'd like to be part of the process, if possible. I've got experience from a similar phenomenon at real work situations. Hence the interest in this too.
[06:50] <AstralJava> nxvl: ...and I've already got a great mentor too, with whom I can hopefully talk more in depth about it.
[06:50] <ScottK> AstralJava: Then mentoring program itself is optional.
[06:50] <ScottK> There are also people here who will help most anyone when they have time.
[06:50] <AstralJava> ScottK: So I understand. I still think it won't hurt in developing it. :)
[06:51] <AstralJava> ScottK: And yes, I've noted that hanging around here somewhat before getting a mentor, can provide all the mentioned information.
[06:51] <AstralJava> People are so friendly and open around here.
[06:52]  * ScottK worries that if people only talk to their mentor, they will get a narrow view.
[06:52] <AstralJava> But it would be interesting to see whether it could be taken onto a new level.
[06:52]  * ScottK also worries it's almost 2AM here.
[06:52] <ScottK> Good night.
[06:52] <AstralJava> I understand that, but not willing to go down that direction.
[06:52] <AstralJava> G'night.
[06:52] <nxvl> ScottK: guidelines, as i'm proposing will be just a document to check and follow if you feel like to, if not, there is no problem
[06:53] <nxvl> ScottK: i don't want to write a policy, just suggestions on how can it be
[06:55]  * nxvl goes to bed too
[06:55] <nxvl> (but with the laptop :P)
[06:55] <AstralJava> Sleep tight, but not too tight with the machine. :)
[06:55] <nxvl> heh
[06:55] <SoylentGrun> nxvl,  the ports aren't for direct human interfacing
[06:55] <nxvl> just moving from working place
[06:55] <nxvl> not going to sleep
[06:55] <nxvl> :D
[06:56] <nxvl> SoylentGrun: huh?
[06:56] <AstralJava> You _don't_ wanna get into that. Trust me. :)
[06:56] <warp10> Hi all
[06:56] <nxvl> hi!
[06:57] <AstralJava> Hello.
[06:59]  * nxvl is about to kill seb :D
[07:02] <nxvl> StevenK: i'm talking about your patch
[07:02] <nxvl> StevenK: on netapplet 1.0.8-1ubuntu3
[07:03] <StevenK> nxvl: I'd have to checkl
[07:03] <StevenK> s/\(check\)l/\1/
[07:08] <ion_> Ew. I hate that RE dialect. :-)
[07:08] <nxvl> RE are kewl
[07:16] <nxvl> i'm going to bed
[07:17] <nxvl> dholbach: after reviewing the wiki page please send me your comments/suggestions please
[07:17] <nxvl> bye all, read you later
[07:19] <dholbach> nxvl: I'm not sure I'll get to it
[07:19] <dholbach> I have a lot of stuff to do today and will clear out to holidays later today
[07:19] <dholbach> but I'll try
[07:31] <RAOF> Hows about this for fun: pbuilder build evolution-sharp results in mcs segfaulting during the build; pbuilder-login ; aptitude install --without-recomments pbuilder ; /usr/lib/pbuilder/pbuilder-satisfydepends ; dpkg-buildpackage works.
[07:31] <ion_> Well, it’s not as if software is deterministic.
[07:32] <StevenK> RAOF: Woot
[07:32] <RAOF> Oh, and I think this is amd64 specific.
[07:32] <RAOF> Yup; builds everywhere but AMD64.
[08:02] <mcquaid> i'm curious why there is no replacement for gstreamer0.10-gl in hardy
[08:03] <mcquaid> I see here: https://bugs.launchpad.net/debian/+source/gstreamer0.10/+bug/227770
[08:03] <mcquaid> it says Drop the OpenGL plugin. This will go to a new source package named        gst-plugins-gl once we have mesa >= 7.1 somewhere.
[08:03] <mcquaid> but what about for hardy?  I grabbed this package here: https://launchpad.net/ubuntu/hardy/i386/gstreamer0.10-gl
[08:04] <mcquaid> even though it's status says deleted.  installed it manually. set it to glimagesink and the test is ok but then seg faults
[08:04] <mcquaid> anyway even with this package installed i can't get brightness working in totem-gstreamer
[08:07] <RAOF> Well, we'll probably get something in Intrepid, given we've now got mesa 7.1.
[08:08] <RAOF> As for hardy, that plugin probably won't be making a re-appearance.  It was never particularly stable in my experience, anyway.
[08:10] <mcquaid> yeah it's not working well. jsut a shame I can't use totem then
[08:10] <mcquaid> as nvidia dropped full xv long time ago
[08:10] <mcquaid> can't adjust brightness contrast etc without opengl playback
[08:10] <mcquaid> i assume this must affect a lot of users
[08:11] <RAOF> I wouldn't think so.  People needed to go out of their way to use that plugin.
[08:11] <RAOF> Also, in what way do nvidia not support Xv?
[08:12] <mcquaid> no i know people wouldn't go out of their way for that plugin.  I mean there are lots of nvidia users, and I assume a lot of people would like to be able to adjust their video brightness
[08:12] <mcquaid> as of geforce 6 series and up there is no full xv
[08:12] <mcquaid> you can't adjust brightness contrast etc
[08:12] <RAOF> Hm...
[08:12] <RAOF> Really?  I never noticed.
[08:12] <mcquaid> i think an exception is the 6800 but thats about it
[08:13] <mcquaid> have a recent nvidia? try an adjust vid settings in any player using xv, no dice
[08:14] <mcquaid> but in the meantime, i guess i'll stick with mplayer/vlc or whatever, just rather use totem but it's not that big a deal i guess
[08:15] <RAOF> Doesn't nvidia-settings expose those controls?
[08:25] <RAOF> Nyargh!
[08:25] <RAOF> Ok, how can I do this: I need to debug why mcs is segfaulting.
[08:26] <RAOF> Unfortunately, it doesn't segfault in any interactive medium.  It segfaults on the buildds, in sbuild, and pbuilder.  It _doesn't_ segfault when running 'dpkg-buildpackage' from a pbuilder-login with the exact same build-deps installed.
[08:27] <mcquaid> no nvidia-settings doesn't. it adjusts global brightness not for xv anymore
[08:28] <mcquaid> the hardware simply can't do it anymore, even in windows.  the windows drivers forces a d3d layer for video now
[08:29] <DktrKranz> RAOF: have you a build log handy?
[08:29] <RAOF> DktrKranz: http://launchpadlibrarian.net/15943548/buildlog_ubuntu-intrepid-amd64.evolution-sharp_0.17.4-0ubuntu1_FAILEDTOBUILD.txt.gz is a good one
[08:29] <slangasek> RAOF: tried redirecting stdin/stdout of the process?
[08:30] <RAOF> (a) Which proceess, and (b) with what goal.  Redirect to where?
[08:30] <slangasek> the segfaulting one
[08:31] <slangasek> to see if it behaves differently when invoked non-interactively
[08:31] <slangasek> so you could do this just by redirecting the input/output of dpkg-buildpackage itself
[08:33] <RAOF> And you'd redirect stdin to... /dev/null?
[08:33] <slangasek> yes
[08:41] <RAOF> Hm.  That segfaults.  But now it segfaults interactively, too.
[08:42] <RAOF> Strangeness.
[08:48] <slangasek> heh
[08:49] <RAOF> But, like all good mono backtraces, the core is useless.
[09:16] <porthose> this is a file header snip it of an app I am looking at, shouldn't the copyright holder be the upstream author (or who ever modified the code last) and not FSF?
[09:16] <porthose> http://pastebin.com/d25df84af
[09:18] <persia> porthose: Depends on what the author wants.  In many jurisdictions, the author may assign copyright to any entity.
[09:19] <porthose> persia: ok cool that explains it thx :)
[09:19] <persia> I suspect that the file was adopted from an automake distributed depcomp, and so upstream was only modifying the work, rather than creating new work.
[09:21] <porthose> persia: how would you handle that in debian/copyright?
[09:21] <persia> porthose: List that file as Copyright FSF, with the license information.
[09:22] <porthose> k thx you have been a great help :)
[09:48] <AnAnt> Hello, I am trying to package a java app, trying to build using gcj
[09:48] <AnAnt> now, I got this error when building: Error: JAVA_HOME is not defined correctly.
[09:48] <AnAnt> can someone give me an example of a java app that builds using gcj ?
[09:48] <AnAnt> I tried looking at swt-gtk, but it uses cdbs
[09:50] <bSON> hi
[09:51] <AnAnt> hello
[09:51] <bSON> is it possible to add descriptions in multiple languages to a control file?
[09:52] <AnAnt> dunno
[09:53] <AnAnt> but I will tell you about another file called templates
[09:53] <AnAnt> if a field is translatable, it will be prefixed with _
[09:53] <AnAnt> ie: _Description
[09:54] <AnAnt> then the translations are in debian/po/
[09:54] <bSON> ah cool, thanks :)
[09:54] <AnAnt> dunno if that is applicable in control though
[09:54] <bSON> i'll try it
[10:05] <Ademan_> what's the policy for packages that have been updated in debian?  can we use them or do we first need the permission from the package maintainers?  Would we even want the debian verison of the source package? or would it be best to start with the existing (old old) ubuntu package and work from there?
[10:06] <RAOF> Ademan_: The policy is basically "make it possible to take as much as possible from debian".
[10:06] <persia> Ademan_: We generally try for the optimax of being close to Debian and fixing all the bugs.
[10:06] <slytherin> !tell Ademan_ about merge
[10:06] <persia> Which package are you looking at now?
[10:06] <Ademan_> specifically nginx
[10:07] <Ademan_> http://packages.debian.org/source/sid/nginx   they've got the latest stable
[10:07] <Ademan_> oh wait, even they're a minor revision off
[10:07] <Ademan_> hehe
[10:07] <persia> Ademan_: There's no Ubuntu variation in nginx: unless it causes isses for puppetmaster, we probably want the sync.
[10:08] <persia> Ah, and it probably won't, as it's just Suggests :)
[10:08] <Ademan_> i'm totally unfamiliar with puppetmaster
[10:08] <Ademan_> unless it's the package i just found hehe
[10:08] <persia> Ademan_: You're not alone :)
[10:09]  * Ademan_ should google first ask questions later
[10:09] <Ademan_> how does puppetmaster interact with something like upstart? there seems to be *alot* of overlapping functionality
[10:11] <persia> Heaps and heaps of it.
[10:13] <sistpoty|work> hi folks
[10:15] <Ademan_>  -1 indicates debian patches, correct?
[10:15] <Ademan_> where -ubuntu1 would be ubuntu packages
[10:15] <Ademan_> patches*
[10:16] <persia> Ademan_: There's never -ubuntu1.
[10:17] <persia> -1, -2, -3, -4 are revision codes in Debian.
[10:17] <persia> From those, ubuntu sets codes, so -0ubuntu1, -1ubuntu17, -4ubuntu2, etc.
[10:17] <Ademan_> ah
[10:17] <Ademan_> alright, thanks
[10:18] <Ademan_> anywho, point is, as far as i can tell from the merging docs nginx meets the criteria for a sync
[10:18] <persia> Now, There are also special NMU uploads in Debian, which can get revisions like -2.3 (3rd upload by non-maintainer after 2nd upload by maintainer)
[10:19] <persia> Ademan_: It's syncable, as it has no real rdepends (but test puppetmaster), but you might want to wait if there is a new upstream waiting to be packaged in Debian.
[10:19] <Ademan_> is there a good way to determine that short of contacting the package maintainers?
[10:20] <persia> Didn't you say that upstream had a newer version than Debian?
[10:20] <Ademan_> indeed
[10:20] <persia> Then you've already determined it.
[10:21] <Ademan_> oh sorry i read that as, if they're working on it or not
[10:21] <persia> Oh, check the BTS to see if there is an upgrade bug.
[10:27] <Laney> Who runs ubuntuwire? It looks like the rcbugs list is out of date (Ubuntu versions are linking to ones that have been superseded)
[10:27] <Ademan_> persia: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=429922  is the most relevant thing i could find, and it's rather old
[10:29] <persia> Ademan_: You and I have different definitions of old :)  That only got fixed in May.
[10:30] <Ademan_> persia: where does it say that? the only dates i can find are from 2007
[10:31] <persia> Well, all the right information is listed there for the maintainer.
[10:31] <persia> Ademan_: 0.6.x entered unstable on 2nd May 2008, according tohttp://packages.qa.debian.org/n/nginx.html
[10:31] <Ademan_> ah
[10:32] <Ademan_> indeed
[10:33] <persia> You could open another bug, but I don't think that maintainer works that way.  Which change from 0.6.32 do you seek?
[10:34] <Ademan_> nothing really i suppose, just rather concerned about having anything web-facing completely up to date
[10:35] <persia> Only think I see that might matter is the character escaping in the access log, but that's fairly minor.
[10:35] <persia> s/k/g/1
[10:35] <ion_> /1? What dialect is that?
[10:36] <persia> ion_: Standard: replace the first instance
[10:36] <geser> isn't that default?
[10:36] <persia> geser: I suppose it is.
[10:36] <Ademan_> probably depends on the flavor of regex
[10:37] <ion_> Just curious. I’d like to know which regexp engine supports the 1 flag.
[10:37] <persia> Ademan_: Perhaps, but for sed/awk/vi it is default, and I likely oughtn't bother typing it (although I always do, for some reason).
[10:38] <Ademan_> i haven't the slightest clue why, but i have really never used awk
[10:39] <persia> awk is great!  If you have any delimited file, you can perform arbitrary processing on each line: you search for something, and then (maybe) send some output for matches.
[10:39] <persia> I suppose you can do the same in perl, python, ruby, etc. but it's likely fewer lines of code in awk.
[10:39] <persia> (not that anyone will be able to read the code or anything...)
[10:42] <Ademan_> lol
[10:42] <Ademan_> not like anyone can read perl...
[10:43] <persia> Ademan_: The difference is that the more lines one adds to a perl script, the more likely that it becomes slightly readable.  The opposite is true in awk.
[10:44] <Ademan_> haha
[10:45] <ion_> :-)
[10:49] <geser> persia: unless the additional lines change one of the special $ variables (the short notations ones like $(, $), $\, etc.)
[10:51] <Ademan_> egh
[10:51] <Ademan_> perl's internal variables are awesome for speed
[10:51] <Ademan_> hell for readabilityh
[10:52] <Ademan_> especially for non-perl-people
[10:52] <Ademan_> it's one of the few languages that a decent programmer can't always look at and figure out what's going on
[10:56] <\sh> Ademan_: hmmm?
[10:57] <\sh> everybody should read perl
[11:00] <ion_> Yeah, just like everybody should read m68k asm.
[11:01] <sistpoty|work> what's wrong with m68k asm?
[11:02] <ion_> Should there be something wrong with it?
[11:02] <sistpoty|work> I don't think so *g*
[12:10] <mouz> If a bug has status 'Fix Committed', should I always find it under https://launchpad.net/ubuntu/intrepid/+queue (under any of the queue states)? I ask because the patch in bug 223882 is not applied in the version I find under that URL.
[12:10] <persia> mouz: Fix Committed is one of the more confusing states, and seems to mean different things to different people :(
[12:11] <persia> Personally, I think the answer to your question should be "Yes", but it may not be.
[12:12] <persia> In this case, I think the patch is committed upstream somewhere: tracking down which git repo and following it through to released is work worth doing.
[12:13] <slytherin> Queue is just for new source and binary packages right? Or does every package go there?
[12:14] <persia> slytherin: Every upload goes there.  There are several states: NEW, UNAPPROVED, APPROVED, and DONE.
[12:14] <persia> Each source package and each binary package goes through each state.
[12:14] <slytherin> hmm
[12:14] <persia> If the source or binary package already exists, it skips NEW.
[12:14] <persia> If there's no archive freeze, it skips UNAPPROVED
[12:14] <persia> APPROVED -> DONE happens about once an hour.
[12:14] <slytherin> By the way, 'Fix Commited' is really confusing state. Many people use it to indicate that fix was commited upstream which is not very useful IMHO
[12:15] <persia> Different people use it for different things.  I heard a rumor that it might go away, but I'm not sure.
[12:18] <wgrant> persia: s/APPROVED/ACCEPTED/
[12:18] <wgrant> There is of course also REJECTED.
[12:18] <persia> wgrant: Thank you.
[12:18] <wgrant> slytherin: Those people should be advised to stop doing it.
[12:18] <wgrant> Because it is wrong.
[12:18] <persia> And, yes, there's REJECTED, but ideally that's always empty :)
[12:21] <mouz> wgrant: according to https://wiki.ubuntu.com/Bugs/Status it is not really wrong
[12:21] <wgrant> mouz: Then that page is wrong.
[12:21] <mouz> :)
[12:22] <persia> mouz: Read that page again carefully:  "For an upstream project...".  That means bugs against the upstream project, not bugs against Ubuntu.
[12:22] <wgrant> That page says nothing of the sort, as persia says.
[12:44] <emgent> hello
[12:48] <sebner> emgent: \o/
[12:59] <persia> So, MOTU Meeting in a couple minutes in #ubuntu-meeting.  Everyone please join.
[12:59] <sistpoty|work> <- will be afk for at least half an hour... important coffee break ^w^w meeting
[13:00]  * sebner -> dinner
[13:01] <persia> timing, timing, timing...
[13:04] <geser> cody-somerville: are you attending the motu meeting to present your topic?
[13:08] <dushara> Hello
[13:12] <EdgeAU> Hello All, I reported a bug with the package ivman a couple of months ago and supplied a patch written by somebody else (and tested by me) and nothing has been done about it. How can I help get the patch into the next version of the package?
[13:13] <hefe_bia> I have a question: How do I mark contributions from multiple authors in a debian changelog?
[13:13] <broonie> hefe_bia: dch will do this for you automagically.
[13:14] <hefe_bia> even if its for the same revision?
[13:14] <broonie> yes
[13:15] <broonie> gnome-volume-manager has an example of the results in 2.22.0-1
[13:15] <broonie> (this is assuming you all use dch individually)
[13:16] <persia> Or at least that the changelog is well formatted at the time of anyone's call to dch :)
[13:16] <hefe_bia> ah, ok. No I do include a patch from someone else
[13:16] <persia> hefe_bia: If it's just a patch, I usually say "Thanks to $(NAME)" in the changelog.
[13:17] <broonie> hefe_bia: "Applied patch from John Doe to <do whatever>"
[13:17] <broonie> zlib has plenty of examples of that sort of thing in the changelog
[13:17] <hefe_bia> persia: ok. that answers my question :)
[13:21] <EdgeAU> How do I get a patch applied for the next version of a package?
[13:23] <hefe_bia_> EdgeAU: See https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue
[13:25] <EdgeAU> hefe_bia: Thanks, Will Do!
[13:30] <EdgeAU> hefe_bia: The thing is, I didn't write the patch: I found it on the Debian bugtracker so I don't feel comfortable submitting it like that and I don't have enough programing experience to review it manually (but I do know that it works great!)
[13:31] <persia> EdgeAU: If you've applied the patch, and it works for you, that's most of the review.  If you do the work to make a candidate upload for a sponsor, they'll likely look at it again, and reject if it's truly gross.
[13:32] <dushara> Hi all, I'd like to maintain the the following package: https://launchpad.net/ubuntu/+source/ttf-sinhala-lklug how do I go about it?
[13:33] <EdgeAU> So Should (try :) ) and make a debdiff from the patch(never done it before) and then submit it as a comment to my bug report and then subscribe ubuntu-universe-sponsors to it?
[13:36] <persia> dushara: We tend to avoid package-specific maintainers, as we believe in group maintenance of packages.  Any help you could provide to get all the bugs fixed in ttf-sinhala-lklug would be hugely appreciated.
[13:36] <geser> EdgeAU: yes, that would be perfect and increase the possibility to see it uploaded without much waiting
[13:36] <persia> I'd recommend reviewing https://wiki.ubuntu.com/MOTU/Contributing.
[13:39] <dushara> persia: I don't think there are any bugs in that package. It's just not included in Ubuntu that's all. I'm involved in a localisation group. That package was developed by the debian maintainer of the group. I've been asked to manage the Ubuntu packing.
[13:40] <persia> dushara: Oh, that's easy then.  It's already in Debian?
[13:41] <EdgeAU> After I have done that should I copy my original bug report (and the patch I found) over to the project's SF page (coz I'm guessing the patch won't auto-magically swim upstream :) )
[13:41] <persia> EdgeAU: Helping the patch swim upstream would be good.  Upstream is in the best position to do a proper code review.
[13:41] <EdgeAU> OK
[13:42] <RainCT> dushara: So what exactly do you want to do? It is already in Ubuntu (Launchpad indicates that version 0.5.3-1 is in Intrepid) and there are generally (even though not always) no changes required for a Debian package to work in Ubuntu.
[13:43] <persia> RainCT: Good find.
[13:44] <persia> dushara: You'll want to subscribe to the bug reports for the package, and as they arrive, work with your team to get them fixed.
[13:45] <persia> If you have patches for the development release, those can be submitted directly (although syncing from Debian is always good).  If you have patches for older releases, these need to be prepared especially for Ubuntu.
[13:47] <RainCT> persia: I find it's a somewhat common misconception amongst people new to Ubuntu's development processes, that packages from Debian need to be in some way "converted" to work in Ubuntu, when what they really want is a sync or a backport
[13:47] <persia> RainCT: Sometimes, although in this case the upstream team is assigning people to work with each distribution, and we should help them to understand how we work to facilitate the interaction.
[13:49] <RainCT> persia: I haven't said the opposite :)
[13:49] <dushara> RainCT: yes. I'm not entirely sure of how new packages are managed.
[13:54] <dushara> ttf-sinhala-lklug is in sid (debian). I believe it was imported to Ubuntu when the process was automatic. I just assumed that there was more work needed.
[13:55] <RainCT> dushara: Well, most packages are just taken directly from Debian. When a new development version starts packages which weren't modified in Ubuntu (both, new versions and completely new packages) are automatically 'copied over' (synced) from Debian for the first months (until "DebianImportFreeze"), and after that syncs can be requested manually as described on https://wiki.ubuntu.com/SyncRequestProcess.
[13:56] <RainCT> dushara: when someone reports a bug in Ubuntu, we can either wait for Debian to fix it and sync the package after that (or manually merge it, if the package that's in Ubuntu was already modified) or fix it ourselves for Ubuntu (and usually forward the patch to Debian so that once it's integrated there we can sync again and don't need to merge new revisions)
[13:57] <persia> Or prepare a fix, upload to Debian, and request a sync (where possible).
[14:00] <hefe_bia> I have updated debdiffs on bug 223812 after discussion with another patch submitter. This should fix three bugs now. Anybody willing to take a look?
[14:01] <dushara> ok. BTW the pkg in launchpad is version 0.5.3-1, I've been given a tarball for version 0.5.4. Should it be updated?
[14:04] <RainCT> dushara: best would be to update the package in Debian and then request a sycn from there
[14:04] <RainCT> *sync
[14:05] <persia> dushara: Due to the nature of the relationship between Debian and Ubuntu, you'll want to work very closely with the person maintaining the package in Debian.
[14:05] <dushara> ok. I've also uploaded a couple of other packages scim-wijesekera (mine) and scim-sayura. These aren't in debian at the moment, but I expect they would be. Was it a mistake uploading them?
[14:06] <dushara> persia: We're part of a common dev group.
[14:06] <nijaba> Hello... Any volunteer for a revue of http://revu.ubuntuwire.com/details.py?package=limesurvey ?
[14:06] <persia> Yeah: no point uploading to both Debian and Ubuntu: better to sync.
[14:08] <dushara> RainCT, persia: Thanks very much for your help.
[14:17] <persia> OK.  Meeting is over.
[14:17] <persia> Now, there's work to do.  Anyone who would be willing to help with NBS, watch files, or ubuntu-local upstream syncs: please let me know if you want help.
[14:18] <hefe_bia> evand: ping
[14:19] <AstralJava> watch files are nice, I can help with that. What's NBS?
[14:19] <persia> AstralJava: Not-Built-From-Source.
[14:20] <persia> But watch files it is :)
[14:20] <AstralJava> Heheh. :)
[14:21] <persia> So, http://qa.ubuntuwire.com/uehs/no_watch.html lists a bunch of packages that don't have watch files.  All of these are either Ubuntu-local or orphaned in Debian.
[14:21] <persia> In many cases, a basic watch file can be generated from debian/copyright, and these are made available in the Watch Wizard column.
[14:22] <persia> All of these packages need someone to add the watch file.  When doing so, it's a good idea to look for new upstreams, fix bugs, etc. as usual.
[14:22] <AstralJava> Right, sounds like good practice.
[14:22] <persia> As a number of these packages are orphaned in Debian, it may be that the BTS already has a watch file submitted as a patch, or other fixes, which would be good to adopt.
[14:23] <persia> So, basic workflow: download the package source.
[14:23] <persia> Check the BTS and LP for bugs.
[14:23] <persia> Verify upstream, and check for a new version.  Update if you like (it's OK not to update, if there's no good reason to update).
[14:23] <persia> Make sure there is a watch file in the new source.
[14:23] <persia> Upload.
[14:24] <persia> Ask here if you need help with regular expressions, version mangling, etc.
[14:25] <persia> The easy ones have "watch" in the Watch Wizard column, and have the current upstream.
[14:25] <AstralJava> Great. I made notes, and will begin working after the Finnish baseball match I'm going to see soon. :)
[14:25] <persia> (e.g. danpei)
[14:25] <ompaul> persia, pm
[14:27] <evand> hefe_bia: sorry about that, it's on my todo list for today
[14:28] <hefe_bia> evand: no problem. Just wanted to say I'm here if more discussion is needed. Might be at work later, but I'll try to be online there, too.
[14:29] <evand> ok
[14:48] <cody-somerville> I dunno about you guys but that was a long 15-20 minutes, lol
[14:51] <bdrung> vorian: ping
[14:57]  * hefe_bia heads for work now. cya
[15:06] <bdrung> is it enough to add a sync request to bug #246299 or should i open a seperate bug report?
[15:10] <persia> bdrung: I'd make a separate report, and add a comment there that you expect whichever package needs it to be fixed by the sync (and list the sync bug number)
[15:20] <cody-somerville> persia, How did the meeting wrap up? Sorry I had to jet.
[15:22] <persia> cody-somerville: With a conclusion that we would discuss things more, as the questions weren't clear.
[15:23] <cody-somerville> persia, Would it help if I wrote an official proposal?
[15:23] <hefe_bia> re
[15:24] <persia> cody-somerville: sistpoty|work volunteered to try to take the existing mail information and meeting discussions and write up a summary of points: he likely wouldn't complain about assistance.
[15:24] <cody-somerville> persia, okay. I'll follow up with him. Did anyone agree to do meeting minutes?
[15:24] <sistpoty|work> cody-somerville: what persia wrote...
[15:25]  * cody-somerville nods.
[15:25] <persia> cody-somerville: emgent volunteered to do minutes early.
[15:25] <cody-somerville> Okay, I gotta jet again (busy day).
[15:25]  * cody-somerville waves.
[15:25] <persia> If you want something to do, you can do the announcements for the next meeting.
[15:25] <sistpoty|work> cody-somerville: I'll send you a draft tonight for you to further refine, ok? Or would you rather like to start with a proposal?
[15:25] <cody-somerville> persia, Okay :)
[15:26] <cody-somerville> sistpoty|work, How about we touch base in a bit and we can figure out what works best? It might be best for you to start as I'd like the summary to be as objective as possible.
[15:26]  * cody-somerville runs.
[15:26] <persia> cody-somerville: Thanks
[15:47] <nixternal> OK, who put the new Flash stuff in *-updates or whatever? it is utter garbage, bad move imho
[15:47]  * emgent does not agree with Persia
[15:48] <persia> emgent: Which are you disagreeing with?
[15:48]  * freeflying
[15:49] <laga> nixternal: has the beta version for flash 10 hit the repos?
[15:50] <DktrKranz> nixternal: only -backports
[15:52] <sebner> DktrKranz: beta1 or beta2?
[15:53] <DktrKranz> sebner: dunno, I don't use it. version is <IP_ADDRESS>+<IP_ADDRESS>5ubuntu1~hardy1
[15:53] <DktrKranz> sebner: congrats for your first package from scratch :)
[15:53] <sebner> DktrKranz: hmm seems beta2 to me
[15:53] <sebner> DktrKranz: rofl. YOU uploaded it and now you congratulate me? xD
[15:54] <DktrKranz> sebner: ah... was it me? I don't remember
[15:54] <DktrKranz> :)
[15:55] <sebner> DktrKranz: xD xD xD
[15:55] <sebner> DktrKranz: but thanks xD
[15:56] <nixternal> DktrKranz: do you know of a bug report for the new flash so I can make my mark and tell them to remove it?
[15:56] <freeflying> sorry, type wrong
[15:56] <nixternal> all of my news sites don't like the new flash, they say "invalid version of flash"
[15:56] <sebner> nixternal: it has hit the backports and you already want to remove it? ^^
[15:56] <nixternal> and lets not forget the 92% CPU spike in Xorg and Firefox with the new version
[15:56] <nixternal> sebner: it is garbage, so yes
[15:57] <sebner> nixternal: with intrepid it's running good except some graphical issues
[15:57] <nixternal> Adobe even stated, or someone in the labs, to not use the version out due to problems
[15:57] <nixternal> well, it is straight crap in Hardy
[15:57] <nixternal> can't watch my weather dangit :)
[15:57] <DktrKranz> nixternal: bug 235135
[15:57] <sebner> nixternal: maybe but beta10 is a lot more better then stable 9
[15:58] <nixternal>  6493 root      20   0  487m 143m 6388 R   41  7.1  15:38.00 Xorg
[15:58] <nixternal> yay, that is idle
[15:58] <DktrKranz> keep it away from proposed, then :)
[16:33] <sebner> siretart: so no neighbor bonus ,hmm? :P
[16:33] <AnAnt> Hello, is gcj java 5 or even 6 compatible ?
[16:35] <DktrKranz> sebner: stop bothering sponsors and become a DD yourself! :)
[16:35] <persia> AnAnt: I think it's different: that it has some JDK 6 functions, but doesn't have others in both 5 and 6.  Someone in #ubuntu-java might know better.
[16:35] <sebner> DktrKranz: lol, hmm I have not intention to become a DD. You're my only hope :P
[16:35] <siretart> sebner: I didn't see the package yet
[16:37] <sebner> siretart: if that's the only problem =)  http://mentors.debian.net/debian/pool/main/h/hitori/
[16:38] <siretart> much better
[16:39] <siretart> sebner: 1. have you considered contributing that game to the debian games team?
[16:40] <siretart> sebner: 2. I don't feel comfortable updating config.{guess,sub} as side effect. I'd prefer to put it in a diffent make target and only call it by hand
[16:41] <AnAnt> persia: no one answering there
[16:41] <AnAnt> persia: btw, you even done a java package ?
[16:42] <sebner> siretart: I never contributed to debian before so I just know about debian mentors
[16:42] <AnAnt> can someone help  me with this please: http://launchpadlibrarian.net/15946661/buildlog_ubuntu-intrepid-i386.monajat_1.0-0ubuntu1%7Eppa10_FAILEDTOBUILD.txt.gz
[16:43] <siretart> sebner: that's no problem. I never used debian mentors either
[16:43] <sebner> ^^
[16:44] <siretart> sebner: the build dependency on autotools-dev seems redundant to me
[16:44] <persia> AnAnt: I've never done a java package.  Someone might answer later, or you could try a different day.
[16:44] <DktrKranz> sebner: debian mentors require a fee... 500 euros per upload should be fine, give them to me, I'll send them to SPI
[16:45] <sebner> DktrKranz: you racist bastard! :P
[16:46] <DktrKranz> indeed
[16:46] <persia> !ohmy | sebner
[16:46] <sebner> persia: ^^
[16:46] <geser> AnAnt: I'm not a java expert but try if you can set the source level to 5.0 (but don't ask my how to do it). You could also try #ubuntu-java for help.
[16:46] <DktrKranz> persia: it's not an offence, it's a sketch
[16:47] <persia> DktrKranz: Yes, but it shows up as "bad words" in logs, which isn't ideal...
[16:47] <AnAnt> geser: thanks
[16:48] <sebner> persia: wasn't there yesterday something similar with Hobbsee ,...?
[16:48] <persia> sebner: Perhaps.  I may have missed it.
[16:48] <sebner> persia: np, I'll be quiet in future =)
[16:48] <DktrKranz> It was, similar one.
[16:48] <DktrKranz> but joking context too :)
[16:49] <persia> sebner: Noooo!  Don't be quiet.
[16:49] <sebner> persia: hrhr, I mean with bad words
[16:49] <DktrKranz> sebner: you can also use y. r. b. model :)
[16:49] <persia> Ah.  Thanks :)
[16:49] <sistpoty|work> so I'm not allowed to write checkinstall here? *g*
[16:50] <persia> !ohmy | sistpoty|work
[16:50] <sebner> !ohmy | sistpoty|work
[16:50] <sebner> damn
[16:50] <sebner> :P
[16:50] <sistpoty|work> heh
[16:50] <sebner> is suse also a bad word?
[16:50] <DktrKranz> sistpoty|work: I got BSOD on Debian... please don't do it again!
[16:50] <DktrKranz> :)
[16:50] <persia> Whatever happened to that project to create a wizard to generate more policy-compliant packages and obsolete checkinstall anyway?
[16:50] <sistpoty|work> heh
[16:51] <sistpoty|work> persia: you mean debhelper v 5? or cdbs?
[16:51] <DktrKranz> persia: autoapt?
[16:51] <DktrKranz> (or similar)
[16:51] <geser> zero-install?
[16:52] <sistpoty|work> geser: zero-install is a different league imho, as it acts solely in user-space
[16:52] <persia> sistpoty|work: Neither: there was talk about writing a python-gtk "MOTU-in-a-box" last September or October, although I've forgotten about it until now.  Sort of a make-dpkg + GUI wizard.
[16:52] <sistpoty|work> ah
[16:52] <DktrKranz> why we should waste time if we already have checkinstall?
[16:52] <sebner> checkinstall \o/
[16:53] <sistpoty|work> !ohmy | DktrKranz
[16:53] <sistpoty|work> :P
[16:53] <sebner> persia: poor log readers ;)
[16:53] <persia> DktrKranz: Speaking as someone who has read the checkinstall code, I'll just say that it doesn't count as something we have.
[16:53] <sebner> *reader
[16:53] <sistpoty|work> seems like bad words are now all over this place *g*
[16:53] <DktrKranz> -ETOOMUCHBADWORDS
[16:53] <sistpoty|work> heh
[16:54] <DktrKranz> ubottu will go in stack overflow soon
[16:54] <sebner> persia: just like kids :P
[16:54] <sebner> ubottu: n00b
[16:55]  * DktrKranz needs to look at some of these terms...
[16:55] <DktrKranz> got them :)
[16:56] <sistpoty|work> nice, so ubottu teaches bad words to DktrKranz *g*
[16:56] <DktrKranz> \o/
[16:56] <sebner> lol
[16:56] <sebner> bad ubottu
[16:57] <sebner> uhh
[16:57] <sebner> !ohmy | ubottu
[16:57] <sebner> hehe
[16:57] <persia> Umm.  ftp://rtfm.mit.edu/pub/ still has useful content, even though it seems banned.
[16:57] <DktrKranz> now I can go out and insult people with new words I've just learned
[16:58] <DktrKranz> mh... we could tell lintian to complain with "write that *** manpage" instead of the current message
[17:12] <slytherin> AnAnt: still there?
[17:12] <LucidFox> If a bug is about incorrect build-dependencies, should I tag it as "ftbfs" or "unmetdeps"?
[17:13] <persia> LucidFox: FTBFS
[17:13] <slytherin> LucidFox: Does it FTBFS?
[17:13] <LucidFox> yes, because some build-dependencies are not written in debian/control
[17:13]  * persia notes that slytherin's question is likely more pertinent than my answer :)
[17:14] <slytherin> LucidFox: then it is sure FTBFS. :-)
[17:16]  * sistpoty|work heads home... cya
[17:18] <slytherin> AnAnt: GCJ has generics support. See if for some reason source is being set to 1.4. The place to look for is build.xml (unlikely) or in rules file.
[17:19] <LucidFox> I remember how I once triaged someone else's FTBFS as wishlist...
[17:21] <slytherin> can I find ppa name form a build log?
[17:21] <geser> slytherin: see the output of apt-get update at the beginning of the log
[17:22] <LucidFox> why not just use openjdk?

[17:23] <LucidFox> persia> I actually thought of such a GUI tool
[17:24] <LucidFox> But I think it would be best implemented as an Eclipse plugin
[17:24] <persia> LucidFox: It's been mentioned a couple times, but nobody ever writes it.  I'm not sure whether having it would be good, but it beats some of the things people use now.
[17:24] <slytherin> LucidFox: Out of all the java sdks available gcj is common denominator. Also most developers don't specify target VM versions and when compiled by a java 6 compiler it will be only compatible java 6 VM. Hence GCJ/Sun Java 5 should be preffered
[17:25] <slytherin> LucidFox: what tool are you talking about?
[17:25]  * persia points at bug #246349 as a possible change to that advice
 sistpoty|work: Neither: there was talk about writing a python-gtk "MOTU-in-a-box" last September or October, although I've forgotten about it until now.  Sort of a make-dpkg + GUI wizard.
[17:26] <slytherin> persia: Don't think so. Unless you want to keep only java 6 VMs in repository, people will complain that they get unsupported class version with certain packages.
[17:28] <persia> slytherin: From what I understand from reading the MIR, it will be used as a java 1.5 compatible runtime / build dependency instead of gij/gcj.  Doesn't it have a working compatibility mode?
[17:28]  * persia is uncertain
[17:29] <slytherin> persia: So you mean when you use openjdk compiler it will auto set source=1.5, target=1.5?
[17:30] <persia> slytherin: I'm not sure.  Ask the MIR composer, or maybe someone in #ubuntu-java knows (but it's extra quiet there today for some reason).
[17:37] <slytherin> persia: Is there any policy about what architectures should be supported for moving a package to main?
[17:41] <persia> slytherin: Not that I know about.  Why?
[17:42] <slytherin> persia: Regarding openjdk. AFAIK it is only available on i386, amd64
[17:42] <persia> slytherin: And sparc.  I suspect lpia is an easy port (but haven't looked carefully).
[17:42] <persia> Someone suggested a powerpc port recently, but it needs someone to work on it.
[17:43] <persia> I'm not sure about ia64, and hppa needs love anyway
[17:43] <slytherin> persia: hmm, I need to get my ibook charger fixed. :-(
[17:47] <slytherin> persia: Once I get that fixed I probably upgrade it to intrepid so I can see how much of java stack is usable on powerpc.
[17:48] <persia> slytherin: That'd be great!
[17:48] <slytherin> geser: That apt trick about build log worked, thanks. :-)
[18:02] <nijaba> Any taker for a little review of http://revu.ubuntuwire.com/details.py?package=limesurvey ?
[18:02] <slytherin> nijaba: What doe sthe app do?
[18:03] <nijaba> slytherin: it is an online survey tool
[18:03] <slytherin> nijaba: Ok. Was just curious. I am no MOTU, so can't do proper review.
[18:07] <NCommander> I'm trying to find a sponsor to help me update a package in Ubuntu
[18:07] <NCommander> I'm the debian maintainer of the package.
[18:09] <slytherin> NCommander: Then just file a sync bug in Ubuntu
[18:09] <sebner> NCommander: which package?
[18:09] <ramvi> I'm making Ubuntu eee. I used reconstructor for the last release, but it's not really doing it for me. What's a good way of remastering the ubuntu live iso? What's the "correct" way?
[18:09] <NCommander> sebner, cvsps
[18:09] <NCommander> It's not in Debian
[18:10] <NCommander> At least, not the updated version
[18:10] <sebner> NCommander: then update it in debian and we merge/sync it to ubuntu
[18:10] <NCommander> So I can't upload the package directly to ubuntu?, the main reason I'm doing it this way is I can't find someone to sponsor me
[18:11] <sebner> NCommander: well, you could just update it in ubuntu but in general the other way is better
[18:11]  * NCommander smacks head on desk a few times
[18:12] <NCommander> I'm also interested in joining MOTU, so I figure its a good way to get started
[18:13] <sebner> NCommander: cvsps-2.1.tar.gz   (most recent stable version)
[18:13] <sebner> 2.1 is in debian and ubuntu
[18:14] <NCommander> Yeah, I have a 2.1-5 I want to upload
[18:14] <NCommander> It has a patch which fixes a bug on amd64
[18:17] <K^> NCommander: report the bug to debian pts with tag patch
[18:17] <sebner> NCommander: ok, file a bug or patch it yourself. Here a nice video =) http://www.youtube.com/watch?v=SAxFpKBG-bU
[18:17] <tuxmaniac> Any idea who to be contacted for ubotu's presence in a loco channel?
[18:18] <tuxmaniac> we have a loco bug jam tomorrow and would like to have ubotu with us :-)
[18:18] <NCommander> No, no no, I already have the package built, and packaged with the patch
[18:19] <NCommander> Right now, its sitting on mentors.debian.org, since I can't find someone who is willing to sponsor the package
[18:19] <sebner> NCommander: that doesn't matter. File a bug and attach a debdiff (for ubuntu) then you have to subscribe ubuntu-universe-sponsors
[18:19] <NCommander> I see.
[18:19] <sebner> NCommander: but for ubuntu it's -4ubuntu1 and not -5
[18:20] <NCommander> Even if the same extact package is going to go back into Debian? (assuming I ever find a sponsor)
[18:20] <NCommander> (I'm sorry if I'm clueless, but I don't know too much about the MOTU process)
[18:20] <K^> tuxmaniac: https://edge.launchpad.net/ubuntu-bots
[18:21] <sebner> NCommander: yes
[18:21] <persia> tuxmaniac: Ask in #ubuntu-irc
[18:22] <K^> tuxmaniac: https://launchpad.net/ubuntu-bots
[18:22] <tuxmaniac> K^: thanks.
[18:23] <tuxmaniac> persia: thanks to you too
[18:23] <K^> tuxmaniac: np :)
[18:24] <NCommander> Ok, I made the changes to the changelog, built it, now I just need to make the diff
[18:25] <sebner> NCommander: don't forget to change the maintainer in debian/control
[18:25] <NCommander> Why change it the maintainer?
[18:25] <NCommander> I am the debian maintainer :-)
[18:25] <sebner> NCommander: We have other processes ;)
[18:26] <NCommander> Oh
[18:26]  * NCommander must learn
[18:26] <NCommander> I switched to Ubuntu on my laptop about a month ago, and love it :-)
[18:26] <NCommander> So I'm now interested in trying to begin the MOTU process (my DD application is stuck in limbo ;-))
[18:26] <persia> NCommander: If you're the Debian maintainer, you can get a special exception to the maintainer change.
[18:27] <sebner> NCommander: https://wiki.ubuntu.com/DebianMaintainerField
[18:27] <NCommander> persia, link?
[18:27] <sebner> persia: hmm?
[18:27] <persia> Generally, we change the maintainer to indicate that we're taking responsibility for the variance, and the Debian maintainer is not to blame.
[18:27] <persia> That said, if you want the responsibility, you can have it.
[18:27] <NCommander> The same changes are going int 2.1-5 as soon as someone sponsors the package in Debian
[18:28] <NCommander> But I've gone almost a month and no one seems to want to touch it; it passes linda and lintman so I dunno
[18:29] <NCommander> Ok, I signed the changes file, and I have the diff.
[18:30] <persia> Attach the debdiff to a bug against the package, and subscribe the sponsors.    You're not that deeply entrenched :)
[18:40] <NCommander> On debian, I run serveral m68k buildds
[18:40] <NCommander> So I handle more backend stuff then packaging ;-)
[18:40] <persia> Anyway, we have maintenance teams: the vast majority of the packages are maintained by MOTU, so if there are any bugs that bother you, and you have a fix, we'd like the solution.
[18:40] <NCommander> I like that system.
[18:40] <NCommander> I've seen packages that have bugs go a long time without being fixed
[18:41] <persia> NCommander: Works well for a derivative distro: we're not so close to upstream as Debian, which can cause confusion.  There's value in Maintainers, but there's also value in collaborative maintenance.
[18:41] <NCommander> yeah
[18:41] <NCommander> I like
[18:41] <NCommander> Its' just a pity Ubuntu PPC is dead :-/
[18:42] <persia> It's not dead.  It works fine.  It's the third best architecture we have (of 6).
[18:42] <NCommander> I thought Ubuntu supports only i386, amd64, and I think UltraSPARC
[18:42] <persia> Mind you, we've about 200 FTBFS for PPC right now, but that's why we have a PPC team.
[18:43] <persia> Nope.  i386, amd64, ppc, lpia, ia64, and hppa.
[18:43] <NCommander> I much rather work on FTBFS. I got started in Debian as a porter (active in m68k, kfreebsd, and hurd ;-))
[18:43] <sebner> NCommander: hurd ^^ not finished yet, hmm?
[18:43] <persia> http://qa.ubuntuwire.com/ftbfs is your page for tasks then :)
[18:43] <NCommander> oooooh shiny
[18:44] <NCommander> Anyone want m68k ubuntu?
[18:44]  * NCommander dives for cover
[18:44] <persia> We don't track hppa by default, because it's a bit behind.  If you've an hppa and want to help, that team would be *hugely* appreciative.
[18:44] <NCommander> If someone will give me SSH access to a hppa, I'd love to help
[18:44] <persia> NCommander: I think elmo would scream at the idea of managing so many buildds.
[18:44] <NCommander> We've ported hppa fixes to m68k
[18:44] <NCommander> persia, He did
[18:44] <NCommander> We just lost our w-b database
[18:44] <NCommander> We turned one of our porters into a human w-b ;-)
[18:45] <persia> NCommander: The difference being that in Ubuntu when he screams, there's no recourse.
[18:45] <NCommander> (my five buildds ran off a private w-b that I created myself ;-))
[18:45] <NCommander> In Ubuntu, no one can hear you bitch
[18:45] <persia> !ohmy | NCommander
[18:46] <NCommander> sorry
[18:46] <lukehasnoname> darnit persia
[18:46] <NCommander> In Ubuntu, no one can hear you *censored*
[18:46] <NCommander> my apologizes ;-)
[18:46]  * NCommander looks around
[18:47] <persia> Happens to everyone a couple times.  We just try to stay helpful, and inviting to everyone.
[18:47] <NCommander> I've got machines running ... kfreebsd-i386, mips, armel, powerpc, i386, I have half a hppa box (and by that, I mean half a logic board)
[18:47] <NCommander> m68k
[18:48] <persia> Well then, given the architecture overlap, there's only 350 FTBFSs you can fix :)
[18:48] <sistpoty> *checkinstall* :P
[18:48] <NCommander> ;-)
[18:48] <sebner> !ohmy | sistpoty
[18:48] <sistpoty> heh
[18:48] <sebner> :P
[18:48] <lukehasnoname> so what's this joke about checkinstall?
[18:48]  * persia should never have taken ohmy out of the cupboard :)
[18:49] <sebner> persia: hehe
[18:49] <NCommander> I've never seen any of these on the main page
[18:49] <persia> lukehasnoname: It's the least favorite of all the random ways people generate .deb packages from the viewpoint of people in this channel.
[18:49] <sistpoty> lukehasnoname: from earlier today... it's a bad word *g*
[18:49] <persia> NCommander: Any of which?
[18:49] <NCommander> THes archs
[18:50] <NCommander> Aside from amd64/i386
[18:50] <NCommander> (not coutning PPC since 6.04)
[18:50] <persia> Oh, yeah.  Canonical only supports amd64 and i386 for hardy, so the rest don't get as much advertisement.
[18:50] <lukehasnoname> Full Circle had an article on how to package
[18:50] <lukehasnoname> from source
[18:51] <NCommander> Well, they should at least link to it ;-)
[18:51] <NCommander> Meh, the only architecture I have is two PowerPC machines
[18:51] <NCommander> ANd one is half-dead
[18:51] <sistpoty> NCommander: we could use some help with powerpc :)
[18:52] <NCommander> I can see your FTBFS's
[18:52] <NCommander> How are you doing on actual compiling power?
[18:52] <sistpoty> hm?
[18:52] <NCommander> autobuilders
[18:52] <NCommander> I'm curious how many autobuilders your running
[18:53] <sistpoty> NCommander: https://launchpad.net/+builds might give you some clue
[18:53] <persia> NCommander: We're caught up except for hppa: see https://launchpad.net/ubuntu/+builds
[18:53] <NCommander> It looks like the main problem with hppa is more dep-waits then actual FTBFS
[18:53] <persia> Yeah, I think we've only 3 hppa buildds, and they're not so speedy :(
[18:54] <NCommander> I'll admit, I'm suprised there is no arm port
[18:54] <NCommander> I'd run it on my ARM box if there was
[18:54] <persia> Found it: https://launchpad.net/+builds/
[18:54] <sistpoty> NCommander: if you have a good entry point which package to retry on hppa, just announce it
[18:54] <NCommander> entry point?
[18:55] <persia> NCommander: specific package to rebuild sooner to try to get the stack to all compile.
[18:55] <sistpoty> NCommander: I mean a package that other packages are waiting on, which failed to build but should build now due to dependencies having been rebuilt
[18:55] <NCommander> Do you properly flag packages dep-wait on the buildd?
[18:55] <NCommander> (I'm an admin on buildd.net, I can see if I can get a copy of those scripts for your autobuilder system to list dep-waits and fun stuff like that :-))
[18:55] <sistpoty> NCommander: I guess wgrant might be able to give you more clue than I about this ;)I
[18:56]  * NCommander takes a stick and pokes wgrant
[18:56] <persia> Well, except that our build system is closed, so we don't really know how it works that well.
[18:56] <persia> he's in UTC+10, so unlikely to be awake now.
[18:56] <NCommander> Oh, canonical hosts it?
[18:56] <persia> Yep.  It's Soyuz from Launchpad.
[18:56] <NCommander> That explains it
[18:57]  * NCommander is used to users adminning their own buildds ;-)
[18:57] <NCommander> Actually, I have an ubuntu one setup so I can test my packages before uploading :-)
[18:57] <persia> We tend to run pbuilder or sbuild locally, although a few people have local buildds.
[18:58] <NCommander> I've managed to get pbuilder to trash the chroot to the point that I had to completely redo it
[18:58] <NCommander> which is why I perfer sbuild
[18:59] <persia> sbuild+LVM snapshots makes all the problems go away :)
[18:59] <NCommander> LVM doesn't work on m68k ;-)
[18:59] <persia> Aww...
[19:00] <NCommander> The m68k autobuilder network - Slightly slower then a i386!
[19:00] <NCommander> (building GCC takes about a week and a half :-P)
[19:02] <sebner> NCommander: O_o
[19:02] <persia> That's probably why there's no Ubuntu m68k port :)
[19:02] <NCommander> There is a reason why we have 20 buildds
[19:02] <NCommander> Actually
[19:02] <NCommander> 22 now
[19:02] <NCommander> I brought two online this week
[19:02] <NCommander> I think we're approaching the equivelent power of my low-end laptop :-)
[19:04] <zorglu_> q. im doing a ubuntu .deb for a network daemon of mine, and it got a /etc/init.d, it doesnt seems to start at boot time (as it is supposed to :), to which init level should i init it ?
[19:04] <zorglu_> i cant find the init.d for nfs and such to copy from it
[19:07] <persia> zorglu_: You're using dh_installinit ?
[19:08] <zorglu_> persia: nope, but the script is installed in /etc/init.d without issue and in /etc/rc2.d
[19:08] <NCommander> Looking at these buildd logs, your hppa issue is its not properly handling dependencies it seems
[19:09] <persia> NCommander: Quite possibly: we can assign higher priority to certain builds to tune that, but someone needs to determine the right order.
[19:09] <zorglu_> runlevel output 2 so i guess the script should be in rc2.d
[19:09] <NCommander> persia, Out of the box, buildd doesn't support it
[19:09] <NCommander> The general process goes something like this
[19:10] <NCommander> 1. Initalize a new w-b, import all non-arch-all packages
[19:10] <NCommander> 2. Build base system by hand, and make it so debootstrap works
[19:10] <NCommander> 3. Build packages, and then mark them dep-wait if the buildd fails (sbuild can't automatically detect this type of failure -_-)
[19:10] <zorglu_> rebooting again :) debugging /etc/init.d is fun
[19:11] <dirker> Hello, when trying to port the transmission package from debian to hardy, dh_clean always complains that the highest compat level it supports is 6. How can I fix that?
[19:11]  * NCommander would love to know how Canonical sets these up
[19:12] <NCommander> It doesn't look like they use sbuild ...
[19:12] <persia> dirker: Redo the packaging to use debhelper 6 instead of debhelper 7.
[19:12] <persia> NCommander: It is sbuild, but a different sbuild.
[19:12] <dirker> persia: Where would I start, will slight modification be enough?
[19:13] <NCommander> persia, weird. Anyone a big issue is that libgtk2 isn't built for hppa
[19:13] <dirker> persia: do you mean the debian/rules?
[19:13] <NCommander> Which is causing a nice domino effect of failures
[19:13] <NCommander> (every gnome package is failing)
[19:13] <persia> dirker: Without looking at the package, I'd probably start with hardy transmission, do a new upstream (if there is one), and rebase any additional patches.  Mind you, that's still not easy.
[19:13] <NCommander> libqt is also not buil;t
[19:15] <dirker> ah, debian/compat is where the 7 comes from.
[19:16] <persia> dirker: Yes, but debian/rules and debian/control are going to assume that: if you change it to 6, it will likely not build correctly.
[19:16]  * NCommander installs an intrepid chroot
[19:16] <dirker> persia: ok, I'll try to hack my way through, if I fail I'll stick with the 1.06 ubuntu scripts and adapt them
[19:18] <lukehasnoname> !patience | lukehasnoname
[19:19] <NCommander> I assume the process to fix a package that FTBFS is to just file a bug with another debdiff?
[19:21] <NCommander> Well, *that* explains why libnet-ssleay-perl didn't fail on Debain, but does on Ubuntu; no one ran the test suite on debian ;-)
[19:30] <persia> NCommander: Indeed, that is the procedure.  Bonus points for also sending your patch to the BTS.
[19:30] <NCommander> Debian BTS?
[19:30] <persia> Yep.
[19:30]  * NCommander looks for reportbug in Ubuntu
[19:31] <NCommander> It's handy my laptop runs amd64, I can help solve FTBFS fixes at work
[19:31] <NCommander> (its totally dead today, nothing to do)
[19:32] <NCommander> hola doko
[19:34] <NCommander> What do I change the maintainer for if its a Debian package?
[19:35] <persia> NCommander: Do you mean Why change the maintainer, or to what ought you change it?  Either should be answered from https://wiki.ubuntu.com/DebianMaintainerField
[19:36] <NCommander> I know why
[19:36] <NCommander> Its just the value of what its going to ;-)
[19:36] <persia> What is usually MOTU or Core-dev, depending on whether it is in universe or main.
[19:36] <NCommander> I'm already used to doing NMUs with a sponsor uploading
[19:37] <NCommander> It's pretty much the same expect replace dupload with a bug on launchpad
[19:37] <persia> Mostly, although we use different revision strings (e.g. -3ubuntu1), and mangle the maintainer.
[19:38] <NCommander> right
[19:38] <NCommander> But basically the same process
[19:38]  * NCommander try to remember how to pin a repo so I can simply apt-get -t intrepid source *pkg*
[19:38] <persia> Right.  So the new maintainer should be either "Ubuntu Core Developers<EMAIL_ADDRESS>or "Ubuntu MOTU Developers<EMAIL_ADDRESS>and you'll want to set XSBC-Original-Maintainer for the Debian Maintainer.
[19:38] <sebner> persia: ha! I posted him a link :P
[19:39] <NCommander> Someone should patch dpkg to recongize the BC-Original-Maintainer control field
[19:39] <persia> sebner: You did, and I copied it from scrollback :)
[19:39] <sebner> xd
[19:39] <persia> NCommander: "Original-Maintainer".  The B and C put it in binary and changes, respectively.
[19:39] <sebner> persia: uh, there are also Motu-mono and such things
[19:40] <persia> sebner: Yes, but one should only use those if one is a member and the team is accepting responsibility for it directly.
[19:40] <NCommander> X is used to tell dpkg to pass it to the other files, the the rest says where
[19:40] <NCommander> I'm suprised there is no built in patch to handle that
[19:41] <ScottK> sebner: Did you get a change to look at my Feisty/Guty port randomization question?
[19:41] <sebner> persia: /me had to use it because a sponsor complained
[19:41] <persia> ScottK: Did you want to add information about the new decision process to w.u.c/MOTU/Meetings ?
[19:41] <persia> sebner: Maybe a special package then.
[19:42] <ScottK> persia: I have not had a chance to think about it.  I do have it on my list.
[19:42] <persia> ScottK: Understood : I just reread the minutes for 6-27, and had forgotten to poke you :)
[19:42] <sebner> persia: hmm dunno xD
[19:43] <ScottK> persia: OK.  Probably tomorrow PM.
[19:43] <persia> ScottK: Thanks.
[19:55] <NCommander> Ok, I got a fix for the FTBFS, now to do the less fun part
[20:04] <lukehasnoname> for anyone who has a minute or two, glance over this how-to and yea or nay it
[20:04] <lukehasnoname> http://fullcirclemagazine.org/html/fcm12_howto1.htm
[20:04] <NCommander> and all fixed :-)
[20:05] <NCommander> checkinstall reminds me of cpack
[20:06] <NCommander> You should explain how you can use dh-prepare (or a similarly name scripted, I can't think of it off the top of my head) to automatically create the debian folder
[20:06] <AstralJava> dh_make
[20:06] <NCommander> thanks
[20:06] <persia> lukehasnoname: Nay
[20:06] <NCommander> Nah
[20:06] <NCommander> ... Nay
[20:06] <NCommander> the created package wouldn't fly on either debian or ubuntu
[20:07] <persia> And may well break the user's system
[20:07] <NCommander> See the Debian New Maintainers and Debian Packaging guide
[20:07] <NCommander> It's a pretty good document on how to build a proper package
[20:07]  * persia reads more carefully, seeing (and worst)
[20:07] <NCommander> I don't even think dpkg could handle an uppercase DEBIAN folder
[20:08] <persia> Yeah.  Definitely Nay.
[20:10] <persia> Not only does the automated section advocate checkinstall or things that use checkinstall (although it does say it's the worst), the manual way is exceedlingly likely to break the builder's system.
[20:10] <NCommander> argh
[20:10] <NCommander> What flag needs to be set to get reportbug to go to debian?
[20:10] <persia> --bts=BTS ?
[20:10] <NCommander> Thanks
[20:11] <NCommander> I'm filing a BTS bug against the FTBFS I fixed for ubuntu
[20:11] <persia> Lastly, it advocates getdeb.net, which has been the cause of several unfortunate users who had to reinstall.
[20:11] <NCommander> Does ubuntu support things like Closes?
[20:11] <persia> Yes.  (LP: #nnnnnn)
[20:13] <NCommander> Just to make sure 1.33.01-1 becomes 1.33.01-1ubuntu1, right?
[20:13] <persia> Yes.
[20:14] <NCommander> Sweet
[20:14] <lukehasnoname> persia: NCommander: Thanks. I was asking because I saw that earlier today, and I've been wanting to learn to package and maintain (for when I go back to college with internet). Short story, I've read that, some of the PackagingGuide on wiki, and Daniel H's video tutorials.
[20:14] <persia> And hopefully gets clobbered by 1,33,01-2 later (although there is a manual review process for these, to make sure patches aren't lost)
[20:14] <NCommander> Just to rebuild this package, and post the fix
[20:14] <NCommander> I'm a debian packager
[20:14] <NCommander> So I know the tools
[20:14] <NCommander> Just needed to learn the Ubuntu way of doing things
[20:14] <NCommander> If you have any generic packaging questions, ask me :-)
[20:14] <persia> lukehasnoname: The wiki and videos are OK.  Try to forget the FC article as much as possible.
[20:14] <NCommander> If you want to know something Ubuntu specific, don't ask me
[20:15] <NCommander> lukehasnoname, http://www.debian.org/doc/maint-guide/
[20:15] <slytherin> NCommander: Ubuntu way of doing things is not very different except in some cases like firefox. :-)
[20:15] <lukehasnoname> persia: Sad, because it was the simplest, quickest way :( I guess I'll have to not be lazy and actually learn.
[20:15] <NCommander> That's pretty much the bible for packaging for Debian-based systems
[20:15] <persia> lukehasnoname: Personally, I recommend working on bugfixing first: that allows one to get familiar with the packaging without having to do it from scratch.  After a while, you'll be confident about making a new package.
[20:15]  * NCommander waits for ubuntu-dev-tools to download
[20:15] <persia> lukehasnoname: It's not so bad: quick lesson:
[20:16] <slytherin> lukehasnoname: I second persia's opinion.
[20:16] <persia> First, unpack the upstream binary.
[20:16] <persia> s/binary/tarball/
[20:16] <slytherin> I have learned a lot by doing minor fixes to packaging.
[20:16] <persia> Second, move the tarball to foo_$(version).orig.tar.gz
[20:16] <persia> Third, create a debian/ directory
[20:17] <persia> Fourth, use dch --create to create an initial changelog, and put in the needs-packaging bug number
[20:17] <persia> Fifth, review all the source, and create debian/copyright
[20:18] <persia> Sixth, add a debian/control (I usually base this off another similar package), and make sure you have the right dependencies and build-dependencies.
[20:18] <NCommander> How can I tell what repo libnet-ssleay-perl-sis from
[20:18] <NCommander> universe or main?
[20:18] <cody-somerville> !info libnet-ssleay-perl-sis
[20:18] <persia> Seventh, Create a basic debian/rules.  There are some simple examples on the wiki.
[20:18] <persia> Eighth, debuild -S
[20:18] <persia> Done.
[20:18] <NCommander> I'd guess that means universe
[20:18] <persia> NCommander: I find rmadison to be the easiest method.
[20:19] <NCommander> rmadison?
[20:19] <slytherin> NCommander: rmadison
[20:19] <lukehasnoname> cool beans. I might take this and make a ShortPackagingGuide, haha
[20:19] <persia> e.g. $ rmadison libnet-ssleay-perl-sis
[20:19] <NCommander> Neat
[20:19] <udienz-> hi all
[20:19] <persia> You might need -u Ubuntu if you're not in an Ubuntu chroot or install.
[20:20] <slytherin> udienz-: Hi
[20:20] <persia> lukehasnoname: Note that I've skipped all the details: if you use my ShortPackagingGuide, you'll end up reading debian/policy fairly closely, and looking at lots of other debian/rules files.
[20:20] <udienz-> slytherin: hi...
[20:20] <lukehasnoname> true,.
[20:21] <persia> Still, it's all about creating four (yes four) files, two of which are typically short, one of which is often a simple makefile, and the last of which is mostly just notes from reviewing the source code.
[20:22] <udienz-> anyone can help me, i can't log in into revu.ubuntuwire.com, refer from https://wiki.ubuntu.com/MOTU/Packages/REVU/ i can login with my email but i can't login with my email
[20:22] <NCommander> anyone here have an amd64?
[20:23] <AstralJava> NCommander: Yes, why?
[20:23] <persia> udienz-: Have you already uploaded something?
[20:24] <udienz-> persia: yes i have upload twice
[20:24] <slytherin> udienz-: please note that launchpad id doesn't work there
[20:25] <persia> udienz-: Did you recover your password?
[20:25] <NCommander> AstralJava, I just submitted my first patch to fix a FTBFS on Ubuntu
[20:25] <udienz-> slytherin: mean i must login with my gpg email?
[20:25] <RainCT> udienz-: yes
[20:25] <NCommander> And I just wanted someone to see if someone could make sure I didn't make any bugs (I think I did it write, but I'm no MOTU)
[20:25] <udienz-> persia: yup and i got "There is no REVU account for<EMAIL_ADDRESS>yet."
[20:26] <slytherin> udienz-: yes, and recover password, it will give you encrypted password and instructions to decrypt it
[20:26] <NCommander> and what was the name of the group I should join for universe sponsors?
[20:26] <RainCT> udienz-: are your uploads on the front page?
[20:26] <persia> NCommander: You don't need to join the group to request sponsorship, it's those who offer sponsorship who join.
[20:26] <NCommander> oh
[20:26] <persia> Just subscribe ubuntu-main-sponsors or ubuntu-universe-sponsors to the bug.
[20:27] <udienz-> RainCT: currently not, i upload my package 3 hours ago
[20:27] <NCommander> Oh
[20:27] <NCommander> d'oh
[20:27] <NCommander> How do I do that O_o;
[20:27] <NCommander> er, persia
[20:28] <persia> NCommander: On the left side of the bug page there should be a link to subscribe someone else.
[20:28] <persia> udienz-: Which package?
[20:28] <NCommander> I subscribed the list
[20:29] <NCommander> Will it get notified of the original bug email, or do I need to post a comment
[20:29] <udienz-> persia: dodol-theme, docang-theme
[20:29] <RainCT> udienz-: are you in the Launchpad group revu-uploaders?
[20:29] <persia> udienz-: Found them.  Are you a member of revu-uploaders?
[20:30] <udienz-> RainCT, persia: yes
[20:30] <RainCT> udienz-: when did you join?
[20:30]  * persia resyncs the keyring
[20:30] <udienz-> RainCT: maybe 4/5 ago
[20:30]  * NCommander looks on how he can join revu
[20:31] <udienz-> my name appear at http://revu.ubuntuwire.com/uploaders.list
[20:31] <RainCT> NCommander: https://launchpad.net/~revu-uploaders
[20:31] <persia> udienz-: If you're there, then it oughtn't be rejected.  Did you use the same key?
[20:31]  * persia looks more carefully
[20:31] <NCommander> I'm a member
[20:31] <NCommander> But I just replaced my GPG key today
[20:32] <NCommander> But the keys just got synced so ...
[20:32] <persia> NCommander: And I'm just syncing now, so it ought be fine in 10 minutes or so :)
[20:32] <NCommander> Sweet
[20:32]  * NCommander looks on how he can get proper MOTU
[20:32] <persia> Hmmm.  Not binary uploads.
[20:32] <NCommander> It's fun, I actually saw my updated cvsps patch hit universe
[20:32] <udienz-> persia: no, i'm using different key
[20:33] <persia> NCommander: Spend several months working on Ubuntu and demonstrate sustained significant contributions, technical skill, and wisdom about managing the packages.  After that, it's just an email.  Generally I recommend handing around here doing stuff until a couple people prod you.
[20:33] <NCommander> prod me?
[20:34] <persia> udienz-: That's the issue then.  REVU membership is managed by GPG keys.  You need to use the same key to prove you are the same person.
[20:34] <persia> NCommander: people telling you that you should be MOTU or asking why you aren't yet.
[20:35]  * slytherin is waiting for that day. :-D
[20:35] <NCommander> Well, seeing an updated package already go into universe has inspired me to keep working on fixing FTBFS
[20:35] <NCommander> I'd help fix the HPPA ones if soneone would give me SSH access
[20:37] <NCommander> er oops
[20:37] <NCommander> The libperl package was a core package
[20:37] <NCommander> Argh
[20:37]  * NCommander reuploads the fix
[20:38] <udienz-> persia: thanks, i know my problem now! my gpg is not sync with my lp account :D, thanks persia
[20:38] <persia> udienz-: It's likely best to try to have just one GPG key, unless you've some special requirement.
[20:39] <sistpoty> sebner: I have 3d back! :)
[20:39] <udienz-> persia: okay *looking for delete other GPG*
[20:40] <sebner> sistpoty: how O_o
[20:40] <sebner> sistpoty: recent updates?
[20:40] <persia> udienz-: You can't delete a key once it's uploaded to the keyservers.
[20:40] <sistpoty> sebner: dist-upgraded one hour ago, and the installed nvidia-glx-177
[20:40] <sistpoty> sebner: of course changing /etc/X11//xorg.conf from nv to nvidia
[20:41] <sebner> sistpoty: why dist-upgrade? and can *you* tell me what's the difference between -173 and -177?
[20:42] <sistpoty> sebner: upgrade iirc only updates packages on the system... dist-upgrade will also remove old packages (if they conflict) and add new packages as per depends/recommends... not too sure though
[20:43] <sistpoty> sebner: and the difference between -173 and -177 is, that I can confirm that -177 works for a GeForce 8500 GT, while I haven't tested -173
[20:43] <persia> upgrade will drop old packages if there is a conflict.  Personally, I find `aptitude safe-upgrade` to be the least likely to break things (or update-manager).
[20:44] <sistpoty> sebner: oh, and I was stuck at a blank screen after restarting kdm after the upgrade, so I needed to reboot
[20:44] <sebner> sistpoty: well, it's kdm -> kde :P
[20:44] <lamont> NCommander: you were wanting to play with parisc ftbfs bugs?
[20:44] <NCommander> Yeah
[20:44] <NCommander> I'm working on the AMD64 ones out of boardem
[20:44] <NCommander> Just resolved the libnet-ssleay one
[20:45] <NCommander> and I see the problem with another FTBFS, so I hope to solve another one
[20:45]  * NCommander is using his years of knowledge as an m68k and hurd porter :-)
[20:45] <lukehasnoname> Is it ok (not going to break anything) if I use aptitude sometimes and apt-get other times?
[20:45] <NCommander> lukehasnoname, It should be fine
[20:45] <lamont> obviously seeing if the package is ftbfs in debian is a good early step (buildd.debian.org has links)
[20:45] <NCommander> lamont, I know ;-)
[20:45] <lamont> and then parisc stuff, a good starting point is http://www.parisc-linux.org/
[20:45] <bobbo> For abraca in Bug #246299 would the new version number be 0.2-2ubuntu3 or 0.2-2ubuntu2build1?
[20:46]  * NCommander is an active debian 68k porter :-)
[20:46] <sistpoty> persia: imho apt-get dist-upgrade should work ootb, everything else is a bug (apart from e.g. dependency loop in essential packages like we had with libc and dpkg for hardy)
[20:46] <lamont> I don't actually have any parisc boxen where I can make them available, though someone on one of the parisc lists probably does
[20:46] <ScottK> sistpoty: I agree.
[20:47] <sistpoty> ScottK: funny enough, the dependency loop wasn't fixed for a long time on sparc, leaving me to do nasty things on spooky by hand *g*
[20:47] <persia> sistpoty: Right.  upgrade-manager and aptitude dist-upgrade have handlers for those problems (update-manager's mechanism is easier to do right).  For any normal case, I think apt-get upgrade should do the right thing.
[20:47] <persia> (That's the difference between aptitude safe-upgrade and aptitude dist-upgrade: the latter gets more agressive about loop and confusing bits).
[20:48] <ScottK> mvo's update script is a set of work-arounds that ideally we would avoid.
[20:48] <persia> That requires lots more discipline than we've shown so far, but yes :)
[20:48] <ScottK> Of course this isn't an ideal world.
[20:48] <sistpoty> ScottK: yes, but it's not always possible on a packaging level (like dpkg dep on new libc and libc dep on new dpkg *g*)
[20:48] <ScottK> Pretty much by defintion everything in there is a representation of a bug.
[20:49] <ScottK> sistpoty: It's not worth the trouble to not special case some things.
[20:49] <persia> Yes, but sometimes solving the bug would be exceedingly painful (as in the libc/dpkg example).
[20:49] <ScottK> Exactly.
[20:50] <persia> Anyway, as much as I think update-manager is useful for these special cases, I've yet to find anything in the history of Ubuntu that aptitude dist-upgrade couldn't handle (maybe with a little prodding).  apt-get dist-upgrade doesn't want to break things (which is good), so sometimes has issues.
[20:51] <sistpoty> persia: it's afaict also meta-information (consider the case that ubuntu-desktop gets renamed)
[20:52] <persia> sistpoty: In update-manager, yes.  In aptitude, no.  Update manager has the meta-package keys, the "critical" package list that is always force-upgraded, and the list of packages to always remove unconditionally.
[20:52] <ScottK> There are issues with software raid and initramfs changes from one release to the next that need special casing too, AFAIK.
[20:52] <sistpoty> persia: yes, that's what I was pointing at
[20:53] <persia> ScottK: Maybe.  I haven't seen those bits, but I've mostly just looked at the front-end.
[20:53] <persia> (well, and python-apt, but not the bits in the middle)
[20:54] <NCommander> So are these ports of ubuntu being handled by canonical, or just being handled by interested users?
[20:54] <slytherin> geser: You recently uploaded libjdic-java, right?
[20:54] <ScottK> NCommander: They are community driven ports.
[20:54] <NCommander> With the w-b, and hardware being run by users, or canonical?
[20:54] <persia> NCommander: Well, Canonical provides all the infrastructure.  Canonical only really supports the packages in main for i386 and amd64 for hardy.
[20:55] <NCommander> ah, so say if I wanted to make Ubuntu/m68k, I have to convience Canonical to buy m68ks?
[20:55] <ScottK> If you want to get it into ports.ubuntu.com yes.
[20:55] <ScottK> It's FOSS, so you're free to go nuts on your own too.
[20:56] <persia> NCommander: Yes, but the person who makes that decision is on record being opposed.
[20:56] <NCommander> I was just using that as an example
[20:56] <NCommander> I'm not crazy enough to try it
[20:56] <NCommander> (yet)
[20:56] <persia> For some new cool arch with buildds that can complete a build cycle in reasonable time, it's mostly a matter of convincing the right people.
[20:57] <NCommander> I'm suprised then there is no SH4 arch port
[20:57] <geser> slytherin: yes
[20:57] <geser> slytherin: why?
[20:57] <slytherin> geser: just curious, I saw it on MoM.
[20:58] <geser> ah, I fixed a FTBFS by adding java-gcj-compat-dev to build-depends
[20:59] <sebner> geser kills the FTBFS bugs
[21:00] <NCommander> That's two in an hour
[21:00] <NCommander> Nice rate of bug killing
[21:00] <slytherin> geser: does it built? The debian version is a new upstream version and build dep changed to Sun Java 6 from Java 5
[21:01] <slytherin> geser: silly me, if you fixed FTBFS then obviously it is working.
[21:02] <geser> slytherin: the old version does now, I gave the new version a quick check and IIRC it FTBFS for a different reason now
[21:02] <NCommander> geser, What package?
[21:02] <slytherin> geser: Well, then I will investigate it. Do you mind if I try merging it?
[21:03] <geser> NCommander: libjdic-java
[21:03]  * NCommander looks at the log
[21:03] <geser> slytherin: no, go ahead
[21:04] <NCommander> geser, Which architecture?
[21:04] <geser> amd64, intrepid
[21:04] <NCommander> I dont' see a build failure on amd64
[21:04] <NCommander> but I'll give you a hand resolving it if you like
[21:05] <NCommander> (I was working on mas on amd64)
[21:06] <slytherin> NCommander: The version is repos doesn't FTBFS, it is the version he was trying to merge.
[21:06] <geser> NCommander: the new version isn't in Ubuntu yet
[21:06] <NCommander> Want a hand with it, or do you have it?
[21:08] <geser> slytherin: libjdic-java wants xulrunner-dev now
[21:09] <slytherin> geser: hmm, I am not going to take a look at it now. I guess I will try other merges. :-)
[21:09] <geser> :)
[21:10] <NCommander> merging?
[21:10] <NCommander> I assume that's when you merge the ubuntu and debian packages?
[21:11] <ScottK> Yes.  Take an updated Debian package and add needed Ubuntu diffs.
[21:11] <geser> NCommander: yes, applying the Ubuntu changes on the last Debian package
[21:11] <slytherin> nyes
[21:13]  * ScottK idly notes that the entire Java stack on hppa is totally broken and if someone were looking for a challenge ....
[21:14]  * sebner thinks that the entire java thing is b0rken xD
[21:15] <persia> ScottK: porting hotspont to parisc?  That's raw madness!
[21:15]  * slytherin kicks sebner for calling his favourite language broken
[21:16] <persia> s/spont/spot/
[21:16] <NCommander> anyone know a CPP flag that's only present when compiling AMD64 code?
[21:16] <sebner> huhu norsetto
[21:16] <sebner> slytherin: hrhr
[21:17] <ScottK> persia: I said it would be a challenge.
[21:17] <norsetto> sistpoty: Hi Supe..err Stefan; do you think somebody with superpowers can fix bug 225741 ?
[21:17] <norsetto> hi sebner
[21:17] <sebner> norsetto: tell me when you have time to review =)
[21:17] <persia> ScottK: It's even off the upstream roadmap!  Upstream would welcome a PPC port, but hppa is, well, hppa.
[21:18] <rohan> can i talk to the person who's backported flash player 10 to ubuntu hardy? i wanted to suggest that the dependency on "libflashsupport" must be removed, as kubuntu doesn't use pulseaudio
[21:19] <asac> rohan: isnt that an optional dependency?
[21:19] <sistpoty> hi norsetto
[21:19] <rohan> asac: it is, but aptitude installs it anyway
[21:20] <persia> rohan: You can block it: just ask aptitude to remove it, or use aptitude interactively.
[21:20] <asac> rohan: would the other option workj better?
[21:20] <rohan> ofcourse, i can tell it not to, but if kubuntu doesn't use pulseaudio, is it a nice idea to have people install it?
[21:20] <sistpoty> norsetto: I think it shouldn't be too hard to fix (might involve fiddling with autotools, haven't looked at the source package yet though).
[21:21] <rohan> installing libflashsupport has caused firefox to crash many times
[21:21] <rohan> before i realized that i don't even have pulseaudio
[21:21] <norsetto> sistpoty: well, the simplest I think would be to unexport LDFLAGS from debian/rules
[21:21] <sistpoty> norsetto: maybe infinity would be interested (as he's in uploaders from debian, though I guess nobse did the recent unstable uploads)
[21:21] <rohan> shouldn't libbflashsupport atleast depend on pulseaudio/
[21:22] <asac> rohan: please replace libflashsupport with the other option and tell us if it does what you want
[21:22] <slytherin> rohan: you are using a beta version from backport and you are afraid of crashes. :-)
[21:23] <rohan> asac: which other option?
[21:23] <asac> rohan: its a Depends: liflashsupport | something-else
[21:23] <asac> install something else
[21:23] <rohan> slytherin: no, even with the older flashplugin-nonfree, firefox crashed
[21:23] <asac> ;)
[21:23] <norsetto> sistpoty: they won't have this problem in Debian, its just our dpkg-buildpackage
[21:23] <rohan> asac: no, libflashsupport is a "Suggested" package
[21:24] <asac> then there is no problem ;)
[21:24] <asac> i think in flash 10 its a depends again
[21:24] <asac> if the backporter demoted it to suggested then its correct imo
[21:24] <sistpoty> norsetto: imho they *do* have this problem, it's just not a problem yet (which is that mysql-config gets generated with anything in LDFLAGS, whether its sane or not)
[21:24] <rohan> asac: but not correct for kubuntu users, who might inadvertantly install it and have their firefox crash
[21:25] <asac> rohan: libflashsupport was a suggest from the beginning
[21:25] <rohan> and i'm really really surprised why they chose not to use pulseaudio for kubuntu
[21:25] <norsetto> sistpoty: unless their change their defaults to !"", why would they have a problem!?
[21:26] <rohan> asac: ah ok, didn't know that
[21:26] <rohan> 01:55 < rohan> and i'm really really surprised why they chose not to use pulseaudio for kubuntu ---> anyone know why?
[21:26] <norsetto> sistpoty: ok, you mean that mysql-config shouldn't use the LDFLAGS passed to it during build at all
[21:27] <sistpoty> norsetto: yes, exactly... that's not the purpose of mysql-config
[21:27] <sistpoty> norsetto: with --libs it should give the *necessary library flags (and compile flags) to compile/link against mysql, not anything apart from that
[21:27] <norsetto> sistpoty: hmm, wonder if mysql-config will end as ffmpeg-config :-)
[21:28] <sistpoty> heh
[21:33] <slytherin> geser: Verification and ack needed, bug #247712
[21:34] <slytherin> geser: And please do it before someone from bug-squad start making useless changes like marking it wishlist etc.
[21:34] <norsetto> geser: and please make us some coffee while you are at it :-)
[21:36] <geser> norsetto: I don't drink coffee
[21:36] <norsetto> geser: who said we will offer it to you?
[21:36] <sebner> lol
[21:37] <sebner> geser: you're now norsettos slave :P
[21:37] <geser> norsetto: oh, motu has one of those coffee machines that can be controlled over the internet?
[21:37]  * slytherin passes cup of java to norsetto on geser's behalf. :-P
[21:38] <Mez> bddebian, ping
[21:38] <norsetto> sebner: be careful, you should know that geser its 2.1 m, weights 120 kg and its a black belt karate player ...
[21:38] <bdrung> bobbo: ping
[21:38]  * sebner hides
[21:39]  * sebner is 1.9m weights 70kg and can cry like a little girl xD
[21:39] <slytherin> norsetto: That description reminds me of Liu Kang from Mortal Kombat :-)
[21:39] <NCommander> rofl
[21:40] <NCommander> Man, I hate imake with a passion
[21:40] <persia> NCommander: Port it to something else.  Pass upstream :p
[21:40] <NCommander> Upstream appears to be dead
[21:40] <persia> Ah.  That makes it trickier then.
[21:41] <norsetto> NCommander: well, its your opportunity, become upstream and kill it :-)
[21:41] <geser> norsetto: Hacking Coffee Makers http://www.securityfocus.com/archive/1/493387
[21:41] <NCommander> TOo much effort
[21:41] <NCommander> Not enough reward ;-)
[21:42] <persia> NCommander: Umm.  You'd never have to troubleshoot imake-related FTBFS for the package again?  That's not a reward?
[21:42] <geser> norsetto: I don't remember that we already met :)
[21:42] <NCommander> I could just grab another package ;-)
[21:42] <NCommander> I don't get why this doesn't FTBFS on debian ...
[21:42] <norsetto> geser: hehe, and its even possible it violates the GPL ;-)
[21:46] <slytherin> geser: Do you need any inputs form me on that bug? I will hit bed soon.
[21:46] <NCommander> I could do a quick and dirty hack to fix this, or fix it the right way ...
[21:50] <geser> slytherin: about the dependency on sun-jdk: isn't it needed anymore? I can't find a hint in the debian changelog why we can drop it
[21:50] <slytherin> geser: It build with GCJ. I added a note at the end.
[21:51] <geser> ah, didn't expect to find the rationale at the end :)
[21:52] <slytherin> geser: Do you suggest adding rationale at the start for bugs henceforth?
[21:53] <geser> it's usually placed before the Debian changelog
[21:54] <slytherin> Ok
[21:57] <geser> I usually check if the Ubuntu changes (or the rationale) are mentioned in the Debian changelog and skip the rest if I've seen everything (especially when the changelog is longer)
[21:58] <slytherin> will keep in mind
[21:58]  * ScottK notes the existence of python-twitter and feels old.
[21:58]  * NCommander grumbles
[21:58] <NCommander> How bad of a hack would it be if I made it not use a platform specific function and had it use a generic one to get it to build?
[21:59] <slytherin> NCommander: Personally, I will not call it a hack, but a fix. :-)
[21:59] <NCommander> It will probably spur the project alive on all Ubuntu architectures
[22:00] <NCommander> It's a problem that the linux API it used seems to have changed
[22:00] <geser> slytherin: what about the runtime dependency? as even the changelog mentions that it doesn't run with gcj?
[22:01] <geser> slytherin: Depends: java-gcj-compat | java-runtime, will that pick a working one?
[22:02] <slytherin> geser: As far as I understand, previously it was using Sun specific API and hence needed SUn JDK/JRE. But now since it builds with GCJ should also run fine with it. If not then theer is always 'java-runtime' virtual package
[22:02] <geser> slytherin: if that's not a problem we can move it after the sync to universe
[22:03] <slytherin> geser: The package is very young in Debian unstable. We can keep a watch to see if any bugs appear about running with gij
[22:05] <NCommander> Ugh
[22:05] <NCommander> this package uses -Dlinux as a symbol
[22:05] <NCommander> *wimper*
[22:06] <sistpoty> as a symbol?
[22:07] <NCommander> Er
[22:07] <NCommander> as a macro
[22:07] <NCommander> sorry
[22:07] <NCommander> Out of it
[22:07] <NCommander> er, define
[22:07] <sistpoty> heh
[22:07] <NCommander> I'm debating giving up
[22:07] <sistpoty> why shouldn't it, that's not too uncommon
[22:08] <geser> slytherin: ACKed
[22:08] <NCommander> I thought lowercase linux was reserved
[22:08] <slytherin> geser: Thanks. :-)
[22:09] <NCommander> wait ... wtf
[22:09] <NCommander> Damn it
[22:09] <geser> slytherin: I've also asked the archive admins to move it to universe afterwards
[22:10] <NCommander> I think this is a bug in intrepid
[22:10] <NCommander> The asm/byteorder.h in intrepid doesn't compile it seems
[22:10] <slytherin> geser: Thanks for that. I was wondering if I would have to file bug for it.
[22:10] <sistpoty> NCommander: I can't think why it should be (true, you'd rather use uppercase letters for macros)... but OTOH I can't imaging any (core) library, having a symbol called "linux" in it
[22:11] <NCommander> I found my bug
[22:11] <NCommander> http://pastebin.ca/1069490 - diff between hardy and intrepid byteswap.h
[22:11] <NCommander> Breaks mas
[22:11] <NCommander> and probably anything that compiles byteswap
[22:13] <NCommander> or not
[22:13] <NCommander> ... *hits head on desk some more*
[22:15] <sistpoty> NCommander: doesn't reall seem to be a problem, as both are identical (unless s.th. depending on the header defines asm as s.th. else)
[22:16] <NCommander> I should say I found whats causing my problem
[22:16] <NCommander> The change in header file causes the package to self-destruct -_-;
[22:23] <NCommander> Bah
[22:23] <NCommander> I'll deal with this package later
[22:27] <sebner> gn8 folks
[22:28] <NCommander> night
[22:29] <slytherin> geser: Will you do me a favour. If you find blueyed before me tomorrow, please ask him to do sponsorship for batik.
[22:33] <geser> slytherin: sure
[22:33] <slytherin> geser: Thanks. Going now. Bye, see you sometime tomorrow.
[22:38]  * NCommander finishs another FTBFS
[22:40] <NCommander> which really wasn't an FTBFS
[22:53]  * NCommander fixes purelibc
[22:53] <NCommander> I'm on a roll today
[22:54] <persia> \o\ |o| /o/
[22:54] <NCommander> rofl
[22:54] <NCommander> Scary what I could do if I had a hppa box
[22:54] <NCommander> *shot a few hundred times*
[22:55] <persia> NCommander: Just FYI, if it doesn't need any source changes, and it's on those lists, you can ask in this channel for a rebuild.
[22:55] <persia> Or "give-back", as we tend to call it.
[22:55] <NCommander> heh
[22:55] <NCommander> give-backs are fun
[22:55]  * NCommander has had a buggy buildd take and give-back every ackage in the debian archive once
[22:56] <persia> Oops!
[22:56] <NCommander> THat was fun
[22:56] <NCommander> So two actual patches, and one give-back :-)
[22:57] <NCommander> How do I request a patch marked Not-For-Us for an architecture
[22:58] <persia> NCommander: Has to go in P-a-s (yes, the same P-a-s)
[22:58] <persia> So, same people, same email, same process.
[22:58] <NCommander> *groan*
[22:59] <NCommander> I'll let someone else deal with that headache
[22:59] <persia> It's just a quick email :)
[22:59]  * sistpoty wonders how a patch can be marked not-for-us
[23:00] <NCommander> sistpoty, You have to put in the patch the architecture to remove from the control file
[23:00] <NCommander> Or the package will never move from sid -> testing
[23:00] <NCommander> (on Debian)
[23:01] <NCommander> Ok, the bugs in launchpad
[23:01]  * NCommander waits for some kinda MOTU to upload them
[23:01] <persia> Wait.  What!  Arch-specific patches?  We don't like those.
[23:01] <sistpoty> NCommander: actually the architecture in control file will only cause a FTBFS on an architecture not listed in there
[23:02] <NCommander> No, I mean if its Architecture: any
[23:02] <NCommander> THen you need to change it to Architecture: any !amd64
[23:02] <NCommander> or uh
[23:02] <NCommander> SOmething like that
[23:02] <sistpoty> NCommander: yes, that's what p-a-s is for
[23:02] <NCommander> I thought it had to be both in the control file and p-a-s
[23:02] <sistpoty> NCommander: nonetheless it doesn't mean a *patch* is suitable for an architecture ;)
[23:03] <sistpoty> (as a patch is applied to the source package, not to a binary package)
[23:03] <NCommander> Point taken.
[23:03] <sistpoty> heh, I guess /me is picky tonight about right nomenclature *g*
[23:04] <NCommander> wow, my karma almost went double
[23:05] <persia> NCommander: That7s what contributing will do :)
[23:05] <NCommander> I'm out of universe FTBFS ;.;
[23:05] <NCommander> well, amd64 specific
[23:06] <persia> Well, go for main then.
[23:06]  * persia thought there was about 130, so being "out" seems extreme.
[23:06] <NCommander> persia, amd64 specific
[23:06] <NCommander> aka, only ones that fail on amd64 only
[23:07] <NCommander> Now I'm working on less specific ones
[23:07] <persia> NCommander: Well, there's still all the ones that also fail on amd64 ...
[23:07] <NCommander> Yeah
[23:08] <NCommander> I'm having fun with this
[23:08] <NCommander> I dunno why
[23:09] <NCommander> persia, any good FTBFS's I should fix
[23:13] <geser> NCommander: Arch: all packages are listed as i386 so you might want to look at those too (they will likely also FTBFS if you try them to build on AMD64)
[23:14] <geser> you might also want to look at packages in DEPWAIT and figure out why they are in DEPWAIT
[23:14] <persia> NCommander: pbuilder might be nice, ardour has an annoying scons issue, ggz-* is probably related, iscsitarget is likely another kernel ABI change, kfreebsd-6 might be an interesting challenge, I'd like nemiver to work again, someone was asking about nginx earlier.
[23:15] <NCommander> I'll work on pbuilder, that may be important ;-)
[23:15] <NCommander> E: Unable to find a source package for pbuiler
[23:15] <NCommander> Argh
[23:16] <geser> add a "d"
[23:16] <NCommander> whoops
[23:16] <NCommander> It's getting that time of the day
[23:17] <NCommander> time to get some dinner
[23:17] <geser> NCommander: there is also a question about gambas2 on amd64 (https://answers.edge.launchpad.net/ubuntu/+source/gambas2/+question/38874). The upstream homepage mentions that it now works also on 64bit.
[23:19] <geser> persia: the pbuilder DEPWAIT is because dvipdfmx is in universe and needs either a promotion to main or get removed from depends of texlive-tetex
[23:19] <geser> texlive-xetex
[23:20] <persia> geser: Ah.  I was just picking likely package names.
[23:25] <NCommander> I thought pbuilder FTBFS
[23:30] <geser> NCommander: http://qa.ubuntuwire.com/ftbfs/ lists it as a FTBFS but when you look at the build log it's because of texlive-xetex not being installable
[23:30] <NCommander> Thanks
[23:31]  * NCommander looks at ardour
[23:31] <NCommander> What does that do specifically anyway?
[23:31] <geser> true, my memory was wrong as it's not a DEPWAIT but a FTBFS but the reason should be hopefully correct. It's some days since I looked into it in detail.
[23:33] <NCommander> ardour looks like an evil one
[23:34] <udienz-> persia: i cannot login into revu.ubuntuwire.com again. same case again :D my account not indentified
[23:35] <NCommander> nginix doesn't look like a bad one to fix
[23:36] <persia> udienz-: Yes.  You have to upload with the key that is registered with REVU.  After you've done that, you can recover the password for the email address for that key.
[23:36] <NCommander> SHould I upload my fixed patches to REVU
[23:36] <NCommander> packages
[23:37] <NCommander> Or just file reports
[23:37] <persia> NCommander: REVU is for team-review of packages before submission to NEW.  If you're working on existing packages, no reason to use REVU.
[23:37] <NCommander> ah
[23:37] <NCommander> cool
[23:38] <NCommander> Its essentially the NEW Incoming, right?
[23:38] <NCommander> ^REVU Is
[23:38] <NCommander> Broken, my grammar is. Fix it, I must.
[23:39] <udienz-> persia: i have done upload 3 packages at motu, maybe i'm waiting for syncronizing?
[23:40] <persia> NCommander: REVU is like mentors, except only for pre-NEW packages.
[23:40] <persia> udienz-: You've uploaded with the GPG key in the uploaders keyring?
[23:41] <NCommander> persia, ah
[23:42] <udienz-> persia: mean motu keyring? no, i've uploaded with my keyring
[23:43] <persia> udienz-: OK.  You have a key listed on the REVU uploaders keyring, right?
[23:44] <udienz-> persia: right, but with my old keyring :D
[23:45] <persia> udienz-: Do you still have control of that secret key.
[23:45] <udienz-> persia: yup
[23:45] <persia> udienz-: Then use that key to upload.
[23:46] <udienz-> persia: okay..
[23:49] <NCommander> bugger
[23:49] <NCommander> If I have to add a patch system to a package, is there any preference?
[23:50] <RainCT_> good night
[23:51] <NCommander> ping motu ;-)
[23:52] <persia> NCommander: First, make sure there's no patches in the diff.gz.
[23:52] <NCommander> didn't see any aside from the debian folder
[23:52] <persia> Then, check other packages by the same Maintainer to see if they have a preference (easier to get in Debian if one uses the patch system the Maintainer prefers).
[23:53] <persia> If those don't give guidance, and it's CDBS, use simple-patchsys.
[23:53] <NCommander> Nope, no CDBS
[23:53] <persia> If none of those give you a patch system, pick your favorite.
[23:54] <NCommander> *grumbles*
[23:57] <NCommander> persia, you use dpatch or quilt
[23:57] <persia> NCommander: Yes.
[23:59] <NCommander> persia, No, I mean what do you perfer?