[00:00] <mok0_> Man we are nerds :-)
[00:04] <LaserJock> mok0_: yep
[00:04] <RainCT> good night
[00:04] <mok0_> night
[00:04]  * jdong cries
[00:05]  * RainCT hugs jdong :P
[00:05] <jdong> Eclipse is telling me there's 2^32-1 possible constructors to java.Exception
[00:05] <jdong> guess that's a good excuse to use my own laptop and not these lab stations
[00:07] <slangasek> your laptop is 64-bit and will give you 2^64-1 possible constructors?
[00:08] <jdong> slangasek: perhaps :D. Because I don't see ANY Exception constructors that I like
[00:32] <steveire> LaserJock: mok0_: Still here. I was away, just read back. The previous version in gutsy backports was 1.1.8-2ubuntu2~gutsy1. The hardy version was 1.1.10-1ubuntu1. I should have named it 1.1.10-1ubuntu1-1~0ppa1?
[00:32] <mok0_> steveire: yep
[00:32] <LaserJock> hmm
[00:32] <LaserJock> what package is this?
[00:33] <LaserJock> mok0_: that wouldn't have helped in this case
[00:33] <mok0_> LaserJock: no?
[00:33] <steveire> libxine
[00:34] <mok0_> sorry
[00:34] <steveire> 1.1.10-1ubuntu1~gutsy1~ppa1?
[00:34] <mok0_> steveire  1.1.10-1~0ppa1 if you ported 1.1.10-1 from debian
[00:35] <steveire> it was from hardy. Same thing?
[00:36] <mok0_> not if the convention for backports is what LaserJock said ^^^
[00:36] <LaserJock> I have a thought
[00:37] <LaserJock> the Hardy version is not 1.1.10-1ubuntu1
[00:37] <LaserJock> it's 1.1.10-1build1
[00:37] <mok0_> Ah, the Build distribution :-)
[00:37] <StevenK> No, build1 is a no-change rebuild
[00:38] <LaserJock> so that means that the base version was 1.1.10-1
[00:38] <LaserJock> steveire: does that make sense?
[00:40]  * Hobbsee wonders hwere the current policy on UVFe's are, including those of native packages
[00:40] <steveire> LaserJock: You''re right. The version is 1.1.10-1. So I should have done 1.1.10-1~gutsy1~ppa1?
[00:40] <mok0_> So a rule for PPA owners could be: find the base version-release, append ~0ppaX to that
[00:40] <steveire> Oh right that one.
[00:41] <steveire> Why is it a bad thing to assume a backport will exist?
[00:41] <Hobbsee> !uvfe
[00:41] <ubotu> Sorry, I don't know anything about uvfe - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[00:41] <Hobbsee> !uvf
[00:41] <ubotu> uvf is Upstream Version Freeze.  For an exception, see https://wiki.ubuntu.com/FreezeExceptionProcess#head-9523bc4076ff011324d67cddc97969ec609618d6
[00:41] <Hobbsee> persia: ping?
[00:41] <mok0_> steveire: I don't think it's bad
[00:41] <LaserJock> steveire: the problem is that you don't know if it's gonna be a -backport or not
[00:42] <LaserJock> if you did 1.1.10-1~gutsy1~ppa1 it implies that 1.1.10-1~gutsy1 exists
[00:42] <mok0_> But you want to make sure (like you said, steveire) that IF it appears in the archives, that version will take presedence
[00:43] <mok0_> LaserJock: right
[00:43] <steveire> LaserJock: Isn't the alternative going to be a version bump to a major release? so 1.1.10-1~hardy1. mok0_Exactly.
[00:44] <steveire> cool, thanks for the info. making a lot more sense now.
[00:52] <mok0_> ScottK: ping
[01:14] <neskiem> does anyone have any free time to look at a package on REVU?
[01:18] <mok0_> neskiem: url?
[01:18] <neskiem> http://revu.tauware.de/details.py?package=ttf-lg-aboriginal
[01:19] <mok0_> neskiem: I am not a motu but I can take a quick look
[01:20] <neskiem> mok0_: thanks
[01:21] <mok0_> neskiem: is this package in debian?
[01:22] <neskiem> mok0_: no it is not, but i would like it to be at some point
[01:22] <mok0_> neskiem: ok
[01:23] <neskiem> mok0_: i based it on the packaging from ttf-sil-gentium by Nicolas Spalinger
[01:24] <stdin> if it's not in debian it should be -0ubuntu1
[01:24] <mok0_> neskiem: good idea
[01:25] <mok0_> neskiem: debian/changelog: like stdin said, release is -0ubuntu1
[01:26] <mok0_> neskiem: open a needs-packaging bug in LP, and close that bug number in the * initial release line
[01:27] <mok0_> distribution: intrepid
[01:28] <stdin> that name is going to take some getting used to...
[01:28] <mok0_> debian/control: get rid of the empty Pre-Depends: etc.
[01:29] <mok0_> binary package, get rid of maintainer, priority, version, provides
[01:30] <stdin> and Uploaders
[01:30] <mok0_> Use universe ! maintainer convention
[01:30] <mok0_> ubotu, ! maintainer > neskiem
[01:31] <mok0_> copyright: license is found in /usr/share/common-licenses/GPL-3
[01:32] <mok0_> get rid of debian/docs
[01:33] <mok0_> debian/rules: I don't think you need to delete debian/files
[01:33] <mok0_> (in the clean rule)
[01:33] <mok0_> what is debian/TODO???
[01:34] <mok0_> neskiem: I'll paste those comments in REVU for your reference.
[01:34] <neskiem> mok0_: i think that was me thinking I would have stuff TODO eventually but I don't need it
[01:34] <mok0_> neskiem: ok. (get rid of it :-))
[01:37] <neskiem> mok0_: thanks for the comments
[01:37] <mok0_> neskiem: np
[02:00] <bddebian> Heya gang
[02:14] <mok0_> bddebian: gang's asleep
[02:15] <bddebian> mok0_: So I've noticed :-)
[02:15] <mok0_> pretty boring around here if you ask me
[02:59]  * jetscreamer waves buhbye
[03:16] <KasimirGabert> I'm having troubles uploading to REVU, would somebody have time to help me?  The file appears to upload correctly through dput, but nothing happens; I receive no email, and I see no uploaded file
[03:19] <toresbe> hey guys
[03:20] <toresbe> I've got a problem with the wine package in Hardy
[03:20] <toresbe> it segfaults
[03:20] <toresbe> on all EXE files I feed it.
[03:20] <RAOF> toresbe: Known issue.  Let me see if I can find the bug.
[03:21] <toresbe> RAOF: cheers
[03:22] <RAOF> You'd be looking at bug #191575, the second bug on Wine's bugpage :)
[03:22] <ubotu> Launchpad bug 191575 in wine "wine segfaults on winecfg" [High,Confirmed] https://launchpad.net/bugs/191575
[03:23] <Hobbsee> ah yes, that thing.  that's annoying
[03:24] <RAOF> Hobbsee: Want something more annoying?  I suggest trying bug 194214 :)
[03:24] <ubotu> Launchpad bug 194214 in compiz "Keys get "stuck" down" [Undecided,New] https://launchpad.net/bugs/194214
[03:25] <toresbe> yep, I'm reading it
[03:25] <toresbe> How do I pin a certain package to a certain repository?
[03:26] <RAOF> toresbe: I suggest reading the documentation for "aptitude forbid-version" :)
[03:26] <toresbe> I'm talking about the preference settings in /etc/apt/preferences
[03:26] <RAOF> (Add the Gutsy winehq repository; aptitude forbid-version wine=0.9.55-0ubuntu1)
[03:27] <toresbe> fine, I'll use forbid-version. :)
[03:27] <toresbe> thanks!
[03:27] <RAOF> Has the advantage that aptitude *will* upgrade to a (hopefully) fixed version.
[04:28] <Hobbsee> debian bug #466956
[04:28] <ubotu> Debian bug 466956 in compiz-core "compiz-core: Program committed suicide" [Important,Open] http://bugs.debian.org/466956
[04:29] <emgent> back
[04:31] <RAOF> Hobbsee: Uuuum, WTH is that doing on the BTS?
[04:35] <Hobbsee> RAOF: some guy on crack, already been told numerously not to do that
[04:35] <RAOF>  That sucks.
[04:35] <RAOF> Also, unsupported kernel.
[04:36] <Hobbsee> heh
[04:37] <LucidFox_> Hobbsee, please restart build for https://launchpad.net/ubuntu/+source/celestia/1.5.0-0ubuntu1 on hppa
[04:39] <Hobbsee> LucidFox_: done
[04:39] <LucidFox_> thanks!
[04:39] <Hobbsee> you're welcom
[04:39] <Hobbsee> e
[04:47] <ScottK> mok1: Pong.
[04:54] <RAOF> Is there any reason at all for debreaper to be in Ubuntu?  It seems to be simply a duplicate apport with the added bonus of reporting Ubuntu bugs on Debian's BTS.
[04:56] <StevenK> RAOF: I just saw the description. Kill it, and ask for it to be blacklisted in the bug
[05:00] <RAOF> Oh, someone has already filed that bug, but not followed through.
[05:00] <StevenK> RAOF: Bug number?
[05:01] <RAOF> bug 193662
[05:01] <ubotu> Launchpad bug 193662 in debreaper "RM: debreaper sends crashes running Ubuntu to Debian" [Undecided,New] https://launchpad.net/bugs/193662
[05:02] <bddebian> Anyone know how to fix the Distribution.Simple does not export 'compilerPath' issues?
[05:20] <AnAnt> persia: I think the status of bug #191662 should be Fix released
[05:20] <ubotu> Launchpad bug 191662 in ubuntume-gdm-themes "New package for ubuntume-gdm-themes" [Wishlist,Fix committed] https://launchpad.net/bugs/191662
[06:42] <LucidFox> What will happen if two versions of the same package are building at the same time for the same architecture?
[07:13] <z5000man> I gotta problem with my Gutsy Gibbon install, can someone help?
[07:14] <RAOF> Support for Gutsy is in #ubuntu.
[07:14] <z5000man> thanks
[07:37] <lifeless> ajmitch: mapwow.com
[07:37] <lifeless> ajmitch: *good* crack
[08:12] <warp10> Good morning!
[08:42] <dholbach> good morning
[08:42] <LaserJock> anybody know how to remove files from a CVS tree that are not actual in the repo?
[08:42] <LaserJock> morning dholbach
[08:42] <dholbach> hey LaserJock
[08:49] <LaserJock> grrr
[08:50] <LaserJock> man CVS just doesn't make sense
[08:53] <slomo_> LaserJock: hm? you want to remove files from a CVS tree that are not in the repository? "rm"? :)
[08:53] <slomo_> hrm
[09:04] <\sh> moins
[09:48] <db-keen> what do I call a package of documentation intended for developers?
[09:48] <db-keen> foo-doc-dev?
[09:48] <db-keen> foo-dev-doc?
[09:59] <siretart> libfoo-doc?
[10:01] <db-keen> siretart: but the main package is not libfoo, it is foo and is intended for end users
[10:20] <slytherin> db-keen: foo-doc
[10:21] <db-keen> slytherin: but I already have foo-doc
[10:21] <db-keen> foodoc is the documentation for end users
[10:21] <slytherin> db-keen: what does it contain?
[10:21] <slytherin> What kind of documentation?
[10:21] <db-keen> I'm trying to package additional documentation intended for developers
[10:21] <db-keen> API docs, papers about program design, etc.
[10:22] <slytherin> db-keen: Why do you think documentation for end users and developers need to be in separate packages?
[10:23] <db-keen> I suppose they don't have to, but it seems like a reasonable split
[10:23] <db-keen> foo, foo-dev, and foo-doc could all be in the same package
[10:23] <slytherin> db-keen: or if you still want to have to packages how about foo-help for users and foo-doc for developers.
[10:23] <db-keen> but it's a logical split between them
[10:24] <db-keen> is foo-help a policy-compliant name?
[10:24] <db-keen> I've always used foo-doc.
[10:25] <slytherin> db-keen: I don't believe there is any policy about package names. gimp has a corresponding gimp-help. By the way which package are we talking about?
[10:27] <db-keen> I had just assumed -doc was policy, being so standard
[10:27] <db-keen> slytherin: one not in Ubuntu. I missed the Feature Freeze :(
[10:28] <slytherin> Ok
[10:31] <siretart> db-keen: here is not much point in unnecessarily splitting arch:all packages, unless we are talking about several hundreds of MB of space savings
[10:37] <murrayc_> Hi. I have a package that needs reviewing/fixing/doing-properly. It's gnome-lirc-properties - a GUI for remote control configuration. Would someone like to take a look? https://bugs.launchpad.net/ubuntu/+bug/192368
[10:37] <ubotu> Launchpad bug 192368 in ubuntu "Please add gnome-lirc-properties" [Wishlist,Confirmed]
[11:03] <mok0_> Who the fsck is this Valyander, he's subscribed to every LP bug I've looked at?
[11:06] <murrayc_> What's a "native package"?
[11:07] <mok0_> murrayc_: It's a package written especially for Ubuntu (Debian)
[11:07] <slytherin> murrayc_: Few comments. 1. Your program expects that a file '/etc/lirc/hardware.conf' which I believe is part of lirc package, but your package doesn't have a dependency on lirc. 2. A .changelog.swp has made its way in debian directory, remove it
[11:08] <dholbach> murrayc_: a native package is a package where all the source + the changes to make it build in debian/ubuntu are in one tarball
[11:09] <dholbach> murrayc_: non-native packages use upstream's original tarball and call it <software>_<upstreamversion>.orig.tar.gz
[11:09] <tbf> murrayc_: ping
[11:09] <murrayc_> So how would I avoid that? I just followed a how-to on ubuntu.com
[11:09] <murrayc_> tbf: Hi.
 murrayc_: Few comments. 1. Your program expects that a file '/etc/lirc/hardware.conf' which I believe is part of lirc package, but your package doesn't have a dependency on lirc. 2. A .changelog.swp has made its way in debian directory, remove it
[11:09] <murrayc_> I wonder what that .changelog.swp is.
 murrayc_: non-native packages use upstream's original tarball and call it <software>_<upstreamversion>.orig.tar.gz
[11:10] <dholbach> murrayc_: dch creates it when you're still editing it
[11:10] <tbf> murrayc_: vim's swapfile
[11:10] <slytherin> murrayc_: It is created by vi
[11:10] <murrayc_> ah.
[11:10] <tbf> it's really strange that debuild packages hidden files
 murrayc_: a native package is a package where all the source + the changes to make it build in debian/ubuntu are in one tarball
[11:10] <tbf> ...like swap files, or .git repos
[11:10] <slytherin> murrayc_: another thing, your source package should be gnome-lirc-properties_0.1.0.orig.tar.gz and you should remove debian/ directory from it.
[11:10] <dholbach> murrayc_: if you rename the upstream tarball, then add all the debian/ bits, then call debuild -S it will create a .diff.gz for you and it'll be non-native
[11:11] <dholbach> murrayc_: be sure to use a version like    <upstreamversion>-<ubuntu revision>  in debian/changelog too
[11:11] <dholbach> murrayc_: as mok0_ said above: they are often used for stuff written specifically for Ubuntu (where there's no clear 'specifically released' upstream tarball)
[11:11] <murrayc_> That's odd. /debian is not in our upstream tarball: http://ftp.gnome.org/pub/GNOME/sources/gnome-lirc-properties/0.1/
[11:12] <dholbach> murrayc_: if you rename the upstream tarball to gnome-lirc-properties_0.1.0.orig.tar.gz, then add the debian stuff, then rebuild the source package (debuild -S -sa) you should be fine
[11:12] <murrayc_> dholbach: And will it then be correct in future by just doing uupdate?
[11:12] <dholbach> if the debian/watch file is set up properly it should, yes
[11:12] <murrayc_> dholbach: Thanks. I'll try that now.
[11:12] <dholbach> rock on!
[11:13] <dholbach> nice to see you guys here :)
[11:13] <hellboy195> dholbach: ahoi there ;)
[11:13] <dholbach> hey hellboy195
[11:14] <murrayc_> I like to avoid doing packaging usually.
[11:14] <murrayc_> It's like talking French. I can just about do it, but it's not pretty.
[11:14] <dholbach> hehe :-)
[11:15] <mok0_> dholbach: I'll format your native/non-native explanation and put it in UbuntuDevelopment/FAQ
[11:16] <dholbach> mok0_: thanks a lot for that
[11:24] <db-keen> What's the difference between /usr/share/pixmaps and /usr/bin/icons ?
[11:31] <hellboy195> db-keen: my ubuntu hasn't got a /usr/bin/icons. Normally there are the binaries of applications ,..
[11:31] <db-keen> whoops, I mean /usr/share/icons
[11:31] <proppy> oy
[11:32] <Iulian> Hey
[11:35] <murrayc_> dholbach: So you mean, rename the upstream tarball to gnome-lirc-properties_0.1.0.orig.tar.gz, extract it, put the debian/ directory in that directory and th rebuild the source package (debuild -S -sa)?en
[11:36] <dholbach> murrayc_: yes
[11:36] <persia> Hobbsee: Not then
[11:36] <persia> AnAnt: Please feel free to close your bugs manually if you forgot to close them in the changelog
[11:37] <persia> LucidFox: The build with the higher version wins when the publisher runs
[11:37] <Hobbsee> persia: ?
[11:37] <Hobbsee> ScottK: i've found the answer
[11:38] <persia> (09:41:25) Hobbsee: persia: ping?
[11:38] <persia> (this is why I don't like to play virtual table tennis)
[11:40] <Hobbsee> oh right.  i thougth that was a strange pong
[11:41] <norsetto> buenos dias a todo el mundo
[11:42] <warp10> Hola norsetto!
[11:42] <norsetto> warp10: Hola el membro!
[11:43] <proppy> oy norsetto
[11:43]  * norsetto hopes it doesn't sound in Spanish as it does in Italian
[11:43] <warp10> norsetto: ROTFL
[11:43] <norsetto> proppy: goede morgen mijnheer!
[11:43] <proppy> norsetto: I'm not german !
[11:43] <proppy> norsetto: are you attending fosdem ?
[11:43] <norsetto> proppy: yes, that was dutch ;-)
[11:44] <proppy> norsetto: ahah
[11:44] <norsetto> proppy: nope, how are you btw, long time no see
[11:44] <proppy> are there motu attending FOSDEM ?
[11:44] <proppy> *or hopefull*
[11:44] <norsetto> proppy: there is huats that I know
[11:44] <proppy> norsetto: nice thanks you
[11:46] <proppy> will ask him about that when he come by
[11:47] <norsetto> proppy: he was in yesterday evening, I think he pops in pretty late usual
[11:47] <proppy> norsetto: thanks for the tip
[11:50] <proppy> norsetto: and you how are you, are you a successfull and beloved mentor ? :)
[11:51] <norsetto> proppy: all my pupils are like you, so you can guess the answer ;-)
[11:51] <proppy> aouch :|
[11:53] <norsetto> proppy: do you want by any chance to have a look at bug 194112?
[11:53] <ubotu> Launchpad bug 194112 in no-ip "package is not upgraded on hardy upgrade" [Low,Confirmed] https://launchpad.net/bugs/194112
[11:54] <proppy> looking
[11:58] <proppy> grepping debian policy for virtual package howot
[12:10] <norsetto> proppy: if you want to look for some examples just do an "apt-cache search dummy"
[12:10] <proppy> norsetto: thanks
[12:10] <norsetto> proppy: the only thing of relevance in the policy (I think) is 7.5.2
[12:12] <proppy> oups update-maintainer removed the maintainer field of control :(
[12:15] <Laney> Is there any document explaining how shlibs:Depends works? I got the build-dep for a package and didn't have all the right deps
[12:17] <Laney> Oh no hang on, that's not the build-depends ;)
[12:19]  * norsetto -> lunch
[12:25] <proppy> I attached a patch to bug 194112
[12:25] <ubotu> Launchpad bug 194112 in no-ip "package is not upgraded on hardy upgrade" [Low,Confirmed] https://launchpad.net/bugs/194112
[12:25] <proppy> feel free to review
[12:25] <proppy> norsetto:
[12:49] <zul> hello
[12:58] <proppy> hi zul
[13:00] <murrayc_> dholbach, slytherin: I uploaded a new (hopefully now non-native) gnome-lirc-packages package. Could you look again, please?:
[13:00] <murrayc_> s/gnome-lirc-packages/gnome-lirc-properties
[13:00] <slytherin> murrayc_: where?
[13:01] <murrayc_> sorry
[13:01] <murrayc_> https://launchpad.net/~openismus-team/+archive
[13:01] <dholbach> murrayc_: sorry, I'm quite busy right now - I hope you don't mind if somebody else takes a look right now
[13:01] <murrayc_> ok. thanks.
[13:04] <slytherin> murrayc_: What are all .ex files? I believe those are example files, right? I guess you won't need All of them.
[13:05] <murrayc_> slytherin: Such as ./debian/emacsen-install.ex? I have no idea what they are.
[13:06] <murrayc_> I'll remove them.
[13:07] <slytherin> murrayc_: How did you create this package?
[13:08] <murrayc_> slytherin: With dh_make, using the cdbs option. Which seemed to be the kosher way to do things.
[13:09] <norsetto> proppy: I think provides is not necessary anymore since there is a dummy-package now, so it should just be conflicts/replaces
[13:09] <slytherin> murrayc_: Do you mind if I do the changes to your package and send you modified package? But I won't be able to do it right now, I will do it over weekend.
[13:10] <norsetto> proppy: I'm not sure if we need to version the conflicts/replaces, can you perhaps test it?
[13:10] <murrayc_> slytherin: I would be immensely thankful if you did that. Could you add a note here saying that you plan to do that? https://bugs.launchpad.net/ubuntu/+bug/192368
[13:10] <ubotu> Launchpad bug 192368 in ubuntu "Please add gnome-lirc-properties" [Wishlist,Confirmed]
[13:10] <slytherin> murrayc_: There is no need to add a note, if someone else does it before me, even better. :-)
[13:11] <murrayc_> Unfortunately it's a bit rushed because we hope to get into hardy. The note would just be to let the others know that it's not going unnoticed.
[13:12] <murrayc_> Feel free to email me if I'm not online. Thanks.
[13:13] <proppy> norsetto: you're right
[13:13] <proppy> looking at Package: gaim-guifications' scontrol
[13:13] <slytherin> murrayc_: I am not a developer, so it won't matter. :-)
[13:14] <proppy> it seems that it versions Replace and Conflict and do not add a Provide clause
[13:14] <murrayc_> slytherin: You are more clueful than me though. Thanks.
[13:14] <norsetto> proppy: ok, and the version should be << X right? Where X is the version in gutsy in this case
[13:16] <norsetto> proppy: hmmm, no, it should be <= then, otherwise it won't work
[13:17] <proppy> gaim-guification specify Conflicts: gaim-guifications (<< 2.14-2)
[13:18] <proppy> where 2.14-2 is the version where is transitional package was introduce
[13:18] <norsetto> proppy: yes, iy should be (<< ${source:Version})
[13:19] <norsetto> proppy: the only problem is that this way the transitional package has to be manually removed, but I think we can't do it otherwise
[13:20] <proppy> but as the transitional package depends upun noip2
[13:20] <proppy> and noip2 conflict with the transitional package
[13:20] <proppy> it will get removed right ?
[13:25] <norsetto> proppy: not if we version the conflicts
[13:26] <proppy> how it's << and not <=
[13:26] <proppy> you're right
[13:26] <proppy> what about putting <= then ?
[13:27] <ScottK> Hobbsee: I'm interested in your answer.
[13:27] <norsetto> proppy: it won't work
[13:27] <norsetto> proppy: apt will just say that there is an unresolvable conflict
[13:27] <proppy> norsetto: ok
[13:28] <norsetto> proppy: which is one of the two things which happen in the bug as you can see
[13:30] <norsetto> proppy: you can test it if you make a gutsy chroot with no-ip and dist-upgrade
[13:31] <proppy> norsetto: bug updated with a new debdiff
[13:31] <proppy> bug 194112
[13:31] <ubotu> Launchpad bug 194112 in no-ip "package is not upgraded on hardy upgrade" [Low,Confirmed] https://launchpad.net/bugs/194112
[13:32] <norsetto> proppy: just a little typo, it should be noip2 not no-ip2 (in the dummy package description), otherwise looks good. If you test it is even better ...
[13:33] <proppy> norsetto: debootstraping gutsy
[13:34] <proppy> norsetto: nice sight (for the typo)
[13:35] <proppy> (btw the way there are .DS_Store files in the orig tarball)
[13:35] <norsetto> proppy: remember that you need to add the new package to your local cache to have it picked when you dist-upgrade
[13:35] <norsetto> proppy: no idea what they are, do you?
[13:38] <kirkland> zul: howdy, you around?
[13:38] <norsetto> dholbach: "... for requesting someone participation *cease* participation ..." :-)
[13:38] <zul> of course
[13:38] <kirkland> zul: I'm looking at Bug 194318
[13:38] <ubotu> Launchpad bug 194318 in php5 "strtotime doesn't support 64 bit timestamps" [Undecided,New] https://launchpad.net/bugs/194318
[13:38] <kirkland> fixed in upstream PHP
[13:38] <dholbach> norsetto: this is not my day *brown paper bag*
[13:38]  * nijaba just lurking around
[13:38]  * dholbach -> dogwalk
[13:38] <norsetto> dholbach: hehehe
[13:38] <zul> kirkland: yep you know where to find the patch?
[13:38] <proppy> norsetto: these are files autogenerated by macosx
[13:39] <RainCT> dholbach: are you happy with bug 191905?
[13:39] <ubotu> Launchpad bug 191905 in alexandria "[sync-request] Please sync alexandria 0.6.2 from the alexandria-team PPA" [Medium,Confirmed] https://launchpad.net/bugs/191905
[13:39] <kirkland> zul: snapshots here http://snaps.php.net/
[13:39] <kirkland> zul: i could dig the specific patch out of CVS
[13:39] <zul> kirkland: yep however since its one patch I would get it from the php-cvs mailing list
[13:39] <kirkland> would that be better than rebasing?
[13:39] <kirkland> zul: gimme a minute, let me find it
[13:39] <proppy> norsetto: http://en.wikipedia.org/wiki/.DS_Store
[13:39] <zul> kirkland: sure...
[13:39] <dholbach> RainCT: i'm about to leave for a dogwalk and lunch now - can you ask somebody else to look at ti?
[13:39] <proppy> norsetto: I've never done that added a package to the local cache
[13:39] <dholbach> it
[13:40] <kirkland> zul: looks like it's a total of 3 small patches
[13:40] <kirkland> zul: 1) http://marc.info/?l=php-cvs&m=120367364419375&w=2
[13:41] <kirkland> zul: 2) http://marc.info/?l=php-cvs&m=120367365119401&w=2
[13:41] <proppy> norsetto: cp *.deb chroot/var/cache/apt ?
[13:41] <kirkland> zul: 3) http://marc.info/?l=php-cvs&m=120367371119481&w=2
[13:41] <zul> kirkland: yep but those are different brances head/5.2/and 5.3
[13:42] <RainCT> dholbach: I'm asking you as you had some concerns about it.. But no hurry from my side (I'm not interested in the package) :)
[13:42] <proppy> norsetto: bug 194112 updated
[13:42] <ubotu> Launchpad bug 194112 in no-ip "package is not upgraded on hardy upgrade" [Low,Confirmed] https://launchpad.net/bugs/194112
[13:42] <norsetto> proppy: I'm afraid is a bit more difficult than that (not much though)
[13:42] <kirkland> zul: oh, gotcha
[13:42] <zul> kirkland: you should be fine with the 5.2 branch
[13:42] <kirkland> zul: I see
[13:42] <kirkland> zul: yep, okay
[13:42] <kirkland> zul: so on my hardy machine, I "apt-get source php5"
[13:43] <zul> correct
[13:43] <kirkland> wget http://marc.info/?l=php-cvs&m=120367371119481&q=raw
[13:44] <kirkland> zul: strike that wget
[13:45] <dholbach> RainCT: just re-subscribe ubuntu-universe-sponsors
[13:45] <kirkland> zul: actually, just add quotes, & got me ;-)
[13:45] <zul> heh
[13:46] <proppy> norsetto: do you want me to attach the log of the test ?
[13:46] <zul> kirkland: then apply the patch and make a diff
[13:47] <norsetto> proppy: could be nice
[13:47] <kirkland> zul: yep
[13:47] <kirkland> zul: doing that now
[13:47] <zul> coolio
[13:47] <zul> so you have the patch?
[13:47] <proppy> norsetto: that's free when launching command from an emacs *shell :)
[13:48] <\sh> has anyone tried to print on a dell 3110cn printer? I didn't find any reference for it on lp.org / cups.org
[13:48] <norsetto> proppy: believe it or not I hardly know what emacs is too
[13:49] <bddebian> Heya gang
[13:50] <proppy> norsetto: nice quote
[13:50] <norsetto> bdebian: heya gang-ster
[13:50] <norsetto> bddebian: heya gang-ster
[13:50] <bddebian> Heh hi norsetto
[13:51] <kirkland> zul: patch not applying cleanly, investigating
[13:51] <zul> ok
[13:52] <norsetto> proppy: this: http://www.debian.org/doc/manuals/apt-howto/ch-basico.en.html#s-dpkg-scanpackages tells you how to make a local repo
[13:52] <proppy> norsetto: reproducing the upgrade failure now
[13:54] <kirkland> zul: CVS id tag string doesn't match
[13:54] <kirkland> zul: ours from 2007/07/20
[13:55] <kirkland> zul: theirs is against 2007/12/31
[13:55] <zul> ergh
[13:55] <zul> I just edit the file manually since its only like 3 lines
[13:55] <kirkland> zul: is it bad to cherry pick just the code we need?
[13:55] <zul> no
[13:56] <proppy> norsetto: thanks for the link thought
[13:57] <kirkland> zul: okay, so i jammed those 3 lines in
[13:58] <kirkland> zul: what about the 1-liner comment from the developer who fixed this?
[13:58] <kirkland> zul: I'd just as soon apply that to NEWS too
[13:58] <zul> we will just mention that in the debian/changelog
[13:58] <kirkland> zul: so leave out the NEWS line?
[13:58] <zul> yep
[13:59] <kirkland> zul: okay, u da boss
[14:00] <zul> kirkland: ok so next mv the patch to the debian/patchs directory
[14:00] <kirkland> zul: let me grab my notes for generating a debdiff
[14:00] <zul> patches even
[14:00] <zul> sure
[14:00] <proppy> norsetto: dist-upgrade failed with E: Internal Error, Could not perform immediate configuration (2) on tzdata
[14:00] <proppy> r
[14:01] <kirkland> zul: go ahead with your instructions...  move the patch to the debian/patches dir, name accordingly?
[14:01] <zul> yep
[14:01] <zul> add it to the series file that is there
[14:01] <norsetto> proppy: ah!
[14:01] <kirkland> number it toward the end?
[14:01] <zul> sounds like a good idea :)
[14:02] <kirkland> mv 1.patch 122-fix_64bit_time.patch
[14:02] <zul> excelente
[14:02] <kirkland>  echo 122-fix_64bit_time.patch >> series
[14:03] <kirkland> zul: I should probably tell kees that I skipped this step on another debdiff he approved of mine....
[14:03] <kirkland> zul: now this isn't a cleanly applying patch
[14:03] <kirkland> zul: so is it misleading to put it in as-is here?
[14:03] <zul> oh crappers...
[14:03] <kirkland> zul: make a new clean patch?
[14:04] <zul> yeah you will have to find out why its not applying cleanly
[14:04] <zul> probably due to Error
[14:04] <zul> whoops...i meant 108-64_bit_datetime.patch
[14:04] <proppy> *stuck*
[14:04] <kirkland> zul: it's the cvs string id that's not matching
[14:05] <kirkland> zul: we have an older snapshot
[14:05] <zul> yeah can you post your patch somewhere?
[14:05] <\sh> hmm....xvidcap is neither in debians nor ubuntus archive...wow
[14:05] <kirkland> than the one that the php-cvs list diffs
[14:06] <zul> kirkland then I would do a cp -rp php-5.2.4 php-5.2.4.orig apply the patch and do a diff -Naur
[14:06] <kirkland> zul: http://pastebin.com/m17780603
[14:06] <kirkland> zul: sure, I can do that
[14:06] <zul> kirkland: easier
[14:10] <kirkland> zul: okay, here's what I'm doing
[14:10] <kirkland> mkdir php5.orig
[14:10] <kirkland> cd php5.orig
[14:10] <kirkland> apt-get source php5
[14:10] <kirkland> cd ..
[14:10] <kirkland> cp -a php5.orig php5.new
[14:10] <kirkland> a pair of identical trees, now
[14:11] <kirkland> vi ./php5.new/php5-5.2.4/ext/date/lib/timelib.h
[14:11] <kirkland> (add 3 lines of significance)
[14:11] <zul> kirkland: nope this is what I would do mkdir source ; tar -zxvf ../php-<version>.orig.tar.gz ; cp -rp php-<version> php-<version>.orig ; edit the file ; diff -Naurp php-<version>.orig php-<version> > patch
[14:13] <kirkland> zul: that works too
[14:14] <kirkland> zul: okay, http://pastebin.com/m165132cf
[14:14] <kirkland> clean, simple patch
[14:14] <zul> kirkland: sweet
[14:15] <kirkland> zul: is there a standard # of subdirs that should be stripable?
[14:15] <kirkland> for that series of patches?
[14:15] <proppy> norsetto: I'm afraid I don't manage to do a dist-upgrade
[14:15] <proppy> norsetto: it keeps failing on tzdata configuration
[14:15] <norsetto> proppy: its ok, just subscribe u-u-s
[14:15] <zul> kirkland: not sure
[14:16] <kirkland> zul: I'll make it match the other XXX_* patches in that dir
[14:16] <sistpoty|work> hi folks
[14:17] <ScottK2> Hello sistpoty|work.
[14:17] <bddebian> Heya sistpoty|work
[14:17] <sistpoty|work> hi ScottK2 and bddebian
[14:17] <kirkland> zul: okay, it looks okay by me
[14:17] <zul> kirkland: ok brb I need to help my wife for a sec
[14:17] <kirkland> k
[14:18] <proppy> norsetto: np thanks a lot for guiding me on this one
[14:18] <norsetto> proppy: was a pleasure, but please keep looking in the bug tracker for more ;-)
[14:19] <proppy> are sync request to late for hardy ?
[14:20] <proppy> (if it's a new package)
[14:20] <proppy> (in debian unstable, but not in hardy)
[14:22] <sistpoty|work> proppy: you'll need a featurefreeze exception (and a good reason, why this exception should be granted)
[14:24] <proppy> sistpoty|work: there is no good reason apart the awesomeness of that piece of software (http://packages.debian.org/sid/shoes)
[14:25] <zul> kirkland: back
[14:25] <kirkland> zul: okay, I updated the changelog
[14:25] <kirkland> with debchange --increment
[14:25] <zul> ok what did you put?
[14:25] <kirkland> i'm getting the build dependencies now
[14:25] <zul> sweet...
[14:26] <kirkland> apt-get build-dep php5
[14:27] <kirkland> zul: changelog entry here: http://pastebin.com/m431bdee9
[14:27] <hmu> hi evrybody
[14:27] <zul> kirkland: looks good to me
[14:27] <sistpoty|work> proppy: still quite a number of open bugs: http://code.whytheluckystiff.net/shoes/report/1, so *shrug*... you can of course file an exception request, but I won't make any promises if it will get ack'd or rej'd
[14:28] <kirkland> zul: dpkg-buildpackage -rfakeroot -uc -us
[14:28] <frenchy> How does the whole FF thing work?  What if I've got a fix for a bug but it's in an upstream version, with some new minor features?
[14:28] <ScottK> frenchy: Then you have to ask for an FFe.
[14:29] <ScottK> frenchy: It'll likely get approved in such a case.
[14:29] <proppy> sistpoty|work: yep shoes is at its very early stage, so I guess it can wait hardy+1
[14:29] <sistpoty|work> :)
[14:30] <zul> kirkland: now you basically sit back and get a coffeee
[14:30]  * kirkland is ready for a coffee
[14:30] <zul> I need coke
[14:30] <kirkland> zul: back in 5?
[14:30] <frenchy> ScottK: Awesome, now I assume that if there are no new features then you can just do a sync request, right?
[14:30] <ScottK2> kirkland: Minutes or hours depending on the size of the package.
[14:31] <ScottK2> frenchy: Yes, but you need to (in addition to the usual debian/changelog entry) also include the new upstream changelog entries in the request.
[14:31] <zul> kirkland: sure..ill be here
[14:32] <frenchy> ScottK: Ta.  That clears it up.
[14:34] <proppy> norsetto: looking a MOTU/TODO seems a lot of bug are already taking care of
[14:34] <proppy> norsetto: (I mean bitesize one)
[14:34] <ScottK2> proppy: You can always search LP for bugs tagged bitesize.
[14:37] <proppy> ScottK2: searching
[14:42] <pochu> nxvl_work: hi, will you request a FF exception for terminator 0.7.1, in case it works fine?
[14:47] <zul> kirkland: still building?
[14:48] <proppy> lets try bug 179614
[14:48] <ubotu> Launchpad bug 179614 in xcdroast "xcdroast requires icedax but not installed" [Medium,Confirmed] https://launchpad.net/bugs/179614
[14:49] <kirkland> zul: yeah
[14:49] <kirkland> zul: I had a mistake, something I didn't understand...
[14:49] <zul> oh?
[14:49] <kirkland> the patch as it stands in the debian/patches dir is what will be applied at build time
[14:49] <kirkland> I had already applied the patch
[14:49] <kirkland> and put it in debian/patches
[14:49] <kirkland> so it was doubled up
[14:50] <zul> ah whoops..
[14:50] <kirkland> and that was causing a build failure
[14:50] <kirkland> so i backed it out
[14:50] <kirkland> and sent it building again
[14:50] <zul> ok good
[14:51] <kirkland> zul: it's rolling through gcc'ing now
[14:52] <zul> goody
[14:53] <proppy> the debian bts already provide a patch that fix the issue
[14:54] <proppy> should I apply the patch to a specific ubuntu revision
[14:54] <proppy> or wait for the debian package to be published ?
[15:00] <tbf> is there some explaination of lintian error messages somewhere?
[15:00] <man-di> tbf: lintian -I
[15:00] <man-di> -i sorru
[15:00] <man-di> sorry
[15:01] <proppy> debdiff attached to bug 179614
[15:01] <ubotu> Launchpad bug 179614 in xcdroast "xcdroast requires icedax but not installed" [Medium,Confirmed] https://launchpad.net/bugs/179614
[15:01] <norsetto> proppy there is no cdda2wav in hardy so just add the dependency to icedax
[15:02] <tbf> man-di: ah, thank you
[15:02] <norsetto> proppy: and add the source of the patch to changelog
[15:03] <tbf> hmm.... how do i prevent this warning? package-installs-python-pyc
[15:03] <tbf> ...since it is automake that installs those files
[15:03] <man-di> tbf: dont put them into the binary package
[15:03] <brettalton> Can someone help me understand the process in making a .deb? I want to compile KohanaPHP into a .deb. The install process should be similar to phpMyAdmin where it installs to /usr/share/kohanaphp
[15:04] <tbf> man-di: i am not aware that i __explicitly__ put them
[15:05] <man-di> tbf: do you have an install or package.install file?
[15:05] <proppy> norsetto: I've applied the debian patch
[15:05] <proppy> norsetto: wich replace cdda2wav by icedax
[15:05] <norsetto> proppy: yes, so just quote where the patch is coming from in the changelog
[15:06] <tbf> man-di: no
[15:09] <man-di> tbf: okay, then you install them implicitely
[15:09] <man-di> tbf: I dont know much about python but shouldnt it be possible to disbale the compilation of pyc files?
[15:09] <kirkland> zul: okay, build done
[15:09] <kirkland> zul: now debdiff?
[15:10] <zul> kirkland: yep
[15:11] <tbf> man-di: well, when running "make install" manually it makes very much sense to install those pyc files
[15:11] <zul> since you do have access to the archive yet the next thing to do would attach the debdiff to the bug and subcrive ubuntu-main-sponsors
[15:11] <man-di> tbf: not in your case
[15:11] <man-di> tbf: I mean, not in a debian package
[15:12] <zul> s/do/dont/g
[15:13] <proppy> bug 179614 updated norsetto, should I subscribe u-s-s ?
[15:13] <ubotu> Launchpad bug 179614 in xcdroast "xcdroast requires icedax but not installed" [Medium,Confirmed] https://launchpad.net/bugs/179614
[15:13] <sistpoty|work> tbf: then you can either patch the makefile(.in/.am?) to not install these or remove these in debian/rules again
[15:13] <norsetto> proppy: yes
[15:14] <norsetto> proppy: I would really add the author though, not just a reference to the bts
[15:15] <proppy> both or only the authors ?
[15:15] <norsetto> proppy: both is fine, but just the author would do
[15:17] <tbf> sistpoty|work: yes, seems i should mess arround in debian/rules
[15:19]  * norsetto thinks its cookie time
[15:19] <zul> kirkland: and when you get a chance submit the bug to debian
[15:20] <kirkland> zul: yeah, i'll need a couple of pointers on that too...  hold that thought though
[15:22] <proppy> norsetto: patch updated u-s-s suscribed
[15:24]  * proppy looking for more https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=bitesize
[15:24] <kirkland> zul: so now I moved over all of the deb's i just built
[15:24] <kirkland> zul: I want to test my deb's
[15:24] <zul> okies
[15:25] <Laney> Hrm, if i'm patching aclocal.m4, is it appropriate to call autoconf in the patch rule?
[15:25] <zul> sudo dpkg -i php5-cgi should be sufficient
[15:25] <kirkland> zul: erg........
[15:26] <mathiaz> kirkland: if you're testing php5, you should run the unit tests.
[15:26] <kirkland> zul: i built the packages on my i386 system
[15:26] <kirkland> mathiaz: sure, point me to 'em
[15:26] <kirkland> zul and i were just talking about that
[15:27] <mathiaz> zul: https://code.launchpad.net/qa-regression-testing
[15:27] <slicer> Wohoo! I got my first bug report. .. Erm.. Is there a "maintainer's guide to bug reports" somewhere? I've assigned it to myself; should I also set it as "in progress" as long as I'm investigating what's going on?
[15:27] <mathiaz> kirkland: ^^
[15:27] <kirkland> zul: so i'll rebuild on amd64
[15:27] <zul> sounds good
[15:27] <ScottK> slicer: In Progress can mean both triaiging (investigating) and working on a fix, so that's reasonable.
[15:28] <emgent> debian #465567
[15:28] <ubotu> Debian bug 465567 in cacti "please apply various patches from cacti.net" [Grave,Fixed] http://bugs.debian.org/465567
[15:28] <mathiaz> kirkland: the qa-regression-testing has a directory for php5
[15:28] <slicer> ScottK: Roger that.
[15:28] <proppy> norsetto: btw I updated juce package in revu
[15:28] <mathiaz> kirkland: it keeps a list of the test outputs for each version of php5 published in ubuntu.
[15:28] <kirkland> mathiaz: i'm reviewing now
[15:29] <mathiaz> kirkland: it also has instructions on how to run the tests.
[15:31] <norsetto> proppy: good, we will have it in hardy+10
[15:34] <proppy> norsetto: foxy ferret+12 would be just fine :)
[15:41]  * proppy wonders what will happend to release name when the 'z' letter will be reached
[15:42]  * InsClusoe suggests Zestful Zebra
[15:44] <slicer> Ok, another bug marking question. The bug reported is due to a bug in libqt4-sql on amd64, which has already been reported. How do I mark "my" bug as depending on that one being fixed?
[15:47] <proppy> InsClusoe: +1 ?
[15:48] <InsClusoe> proppy: Taken.. :)
[15:48] <ScottK> mok2: You have mail.
[15:48] <emgent> heya people
[15:48]  * mok2 looks
[15:50] <mok2> ScottK; I agree
[15:50] <ScottK> OK.
[15:51] <proppy> InsClusoe: wonders what will it after Z thought :)
[15:51] <mok2> ScottK: who is good to consult on the i18n stuff?
[15:52] <ScottK> mok2: Dunno.
[15:52]  * ScottK knows he isn't the one though.
[15:52] <mok2> ScottK: I've never bothered with that stuff.
[15:53] <mok2> ScottK: I have another one on LP for motu-release, did you see it?
[15:53] <LaserJock> mok2: what do you need for i18n?
[15:53] <mok2> bug  194219
[15:53] <ubotu> Launchpad bug 194219 in collectd "[needs-merge] collectd  (4.3.0-1)" [Undecided,Incomplete] https://launchpad.net/bugs/194219
[15:54] <mok2> LaserJock: I need someone to explain it to me :-)
[15:54]  * InsClusoe is so worried about the future. Proppy is a doomsday cult follower. :-)
[15:54]  * mok2 wonders why he's not mok0 as usual...
[15:54] <Laney> Can anyone take a look at my patch on bug #188489?
[15:54] <ubotu> Launchpad bug 188489 in darcs "darcs 1.0.9 FTBFS in Hardy" [High,Confirmed] https://launchpad.net/bugs/188489
[15:55] <LaserJock> mok2: that's a pretty general questions "explain it to me" :-)
[15:56] <mok2> LaserJock: I ran into a package (WxWidgets using) where upstream wants to put the locale stuff in $pkgdatadir and not in /usr/share/locale
[15:56] <ScottK> mok2: Did you see sistpoty|work's comment?
[15:56] <LaserJock> mok2: hmm, interesting
[15:56] <mok2> ScottK: ah ok
[15:56] <LaserJock> mok2: do you know if the system finds it?
[15:56] <mok2> LaserJock: I don't know how to test that
[15:57] <LaserJock> use a different locale? :-)
[15:57] <mok2> LaserJock: I don't want to screw up the locale on my system .-)
[15:57] <mok2> LaserJock: But if I can do it for just that one process...
[15:57] <LaserJock> sure
[15:57] <slicer> bug 193808 (in a program) is due to bug 178084 (in a library the program uses). Does this make the bug a duplicate?
[15:57] <ubotu> Launchpad bug 193808 in mumble "mumble refuses to start" [Undecided,In progress] https://launchpad.net/bugs/193808
[15:57] <ubotu> Launchpad bug 178084 in qt4-x11 "Missing SQL drivers in libQtSql.so" [Undecided,New] https://launchpad.net/bugs/178084
[15:58] <mok2> LaserJock: how? Set LC_something?
[15:59] <LaserJock> I think something like export LANG=fr_FR.UTF-8 && <program to run>
[15:59]  * mok2 realizes he has a whole bunch of pidgin instances running...
[15:59] <mok2> LaserJock: OK, noted, thx
[16:01] <LaserJock> mok2: did wxwidgets actual change where it puts the locales?
[16:01] <mok2> LaserJock: not sure
[16:02] <mok2> LaserJock: I only know that upstream wants to put it there, and they must know (I figure)
[16:02] <LaserJock> well, my thought would be that if it's done that in the past and we didn't get any complaints it probably works alright
[16:03] <sistpoty|work> Laney: maybe geser would like to look at it? Otherwise, I'll take a look at it once I'm home (and have finished the developer week session)
[16:03] <mok2> LaserJock: ... and my guess is that no one uses that locale stuff ;-)
[16:03] <LaserJock> mok2: no?
[16:03] <mok2> j/k
[16:03] <LaserJock> ah
[16:04] <LaserJock> should have caught the ;-)
[16:04] <mok2> LaserJock: Anyway, I can't get the language to change
[16:05] <LaserJock> hmm
[16:06] <LaserJock> you could ask -devel
[16:06] <LaserJock> I've just don't it for stuff with lang packs or install to /locale/
[16:07] <mok2> LaserJock: You've just don't it??
[16:08] <LaserJock> sorry, *done it
[16:08] <mok2> :-)
[16:08] <LaserJock> too early in the morning over here
[16:08] <mok2> I am trying to get an ordinary KDE app to start up in french
[16:08] <mok2> which I can't do
[16:09] <LaserJock> so you have the french locale installed?
[16:10] <mok2> LaserJock: I don't know... I assume
[16:10] <mok2> LaserJock: Aren
[16:10] <mok2> 't they all there?
[16:10] <LaserJock> hehe, no
[16:10] <LaserJock> that would be huge
[16:10] <mok2> I see
[16:10] <proppy> dpkg-reconfigure locales ?
[16:10] <mok2> Anyway, man complains
[16:11] <LaserJock> you need to install the french language packs to get french
[16:11] <mok2> can't set the locale; make sure $LC_* and $LANG are correct
[16:11] <mok2> proppy: I don't want to screw up my box
[16:12] <LaserJock> pfft, what's a little french gonna hurt ;-)
[16:12] <LaserJock> "oh crap, how do I type sudo reboot in french?" ;-)
[16:12]  * mok2 shudders
[16:12] <mok2> rebouter
[16:13] <LaserJock> well, see that man message is right
[16:13] <kirkland> mathiaz: sorry, but I not finding instructions for the php5 tests.  i've clicked all over that launchpad link you sent.
[16:13] <LaserJock> if you set $LANG to a language you don't have the locale for it'll complain
[16:13] <proppy> mok2: try it in a chroot then :)
[16:14] <proppy> locale-gen fr_FR.UTF-8 ?
[16:14] <mok2> funny, I install the french language pack, and it says libsoup is no longer required
[16:15] <LaserJock> yeah, proppy's got a good point. Doing it in a  chroot would be easy
[16:15] <mathiaz> kirkland: let me check
[16:15] <mok2> LaserJock: I guess. But getting it to work isn
[16:15] <mok2> 't :(
[16:16] <proppy> mok2: after a debootstrap you usually have to locale-gen or dpkg-configure locales to get rid of that warning
[16:17] <mok2> proppy: I thought I could do it by just changing the locale of one process
[16:17] <mok2> (konsole, for example)
[16:17] <LaserJock> you should be able to do that
[16:18] <LaserJock> but you need the locale available before you can do that
[16:18] <mok2> Well apt-get started speaking french on me
[16:18] <mok2> Souhaitez-vous continuer [O/n] ? O
[16:18] <mok2> :-)
[16:19] <mathiaz> kirkland: if you look into build_testing/php5/, you'll have a README file
[16:19] <mathiaz> kirkland: that explains how to run the php unit tests.
[16:20] <RainCT> ScottK, ScottK2: Is the new python- package in ubuntu-dev-tools okay for entering Hardy or does it need a Freeze Exception (it's not a new feature, but just moving some stuff out from an executable and putting it into a Python module by itself)?
[16:20] <LaserJock> mok2: awesome
[16:21] <mok2> LaserJock: I will do this in a chroot env.
[16:21] <LaserJock> RainCT: it creates a new binary package?
[16:22] <RainCT> LaserJock: yes, python-ubuntutools (which contains the module ubuntutools.ppaput)
[16:23] <LaserJock> sounds like that might need a FFe since Ubuntu Archive will need to process it
[16:23] <LaserJock> although maybe they don't care
[16:24] <sistpoty|work> RainCT: what does ubuntutools.ppaput contain code for?
[16:24] <sistpoty|work> (out of interest)
[16:25] <ScottK> RainCT: It's a New package, so it does (impacts archive admin workload).
[16:25]  * ScottK really wonders why we need a script for dput name-of-ppa
[16:26] <RainCT> sistpoty|work: stuff from ppaput (the executable one) which could also be useful in other scripts
[16:26] <RainCT> ScottK: I don't use it myself, but I think it also handles bug reports and such
[16:26] <RainCT> LaserJock: okay, I'll file a bug then. Thanks
[16:26] <ScottK> How can you have a bug report for a PPA upload?
[16:28] <RainCT> ScottK: "man ppaput" knows better :)
[16:28] <RainCT> or ping dholbach
[16:29] <RainCT> (well, once he is back)
[16:30] <ScottK> RainCT: I think it should be removed from the package.
[16:31] <dholbach> ScottK: why?
[16:31] <ScottK> dholbach: Is PPA part of our agreed sponsoring process?
[16:31] <ScottK> We've talked about this before.
[16:31] <ScottK> We have a process and PPA isn't in it.
[16:32] <dholbach> we did and I've changed the documentation
[16:32] <ScottK> This tool puports to support our sponsoring proces, but is an entirely different one
[16:32] <dholbach> I'm not sure I understand
[16:33] <ScottK> From the man page: "This tool aims to help with the sponsoring process ... and is written by the MOTU team"
[16:33] <ScottK> This is not true
[16:33] <dholbach> that's no reason to remove it from the tools package
[16:34] <dholbach> I can certainly change the text (or anybody can)
[16:34] <ScottK> dholbach: Why should it be in the package taking up space on my hard drive?
[16:34] <\sh> damn
[16:34] <\sh> 0.9.56 is released...
[16:34] <LaserJock> ScottK: well, that's not a particularly convincing argument
[16:34] <LaserJock> there is a *great* many files that are taking up space on your hard drive
[16:35] <ScottK> LaserJock: The tool claims to support our sponsoring process, but is actually irrelevant to it.
[16:35] <LaserJock> so more of a description/usage problem
[16:35] <LaserJock> I'm not really sure what ppaput is useful for
[16:36] <ScottK> It seems like it's off topic for Ubuntu Development Tools
[16:36] <LaserJock> well, it's useful at least as an example
[16:36] <LaserJock> though I'm not sure I like the idea of creating a new binary just for it
[16:36] <ScottK> From the package overview it doesn't seem to have any other purpose.
[16:37] <ScottK> We've got clear working processes for New packages, upgrades, and new revisions now.  This isn't any of those.
[16:37] <LaserJock> dholbach: do we have a clear use case for ppaput?
[16:38] <ScottK> dholbach: If I touch the package I'll just remove ppaput.  Someone with a different interest might want to clarify it then.
[16:38] <LaserJock> I must confess I'm a little sketchy on what it does
[16:39] <RainCT> LaserJock: the new package is intended to get more stuff later (see http://paste.ubuntu.com/4899/)
[16:40] <LaserJock> tbh, that seems a little weird
[16:40] <ScottK> RainCT: Then it should go in a package called launchpad-dev-tools.  It's nothing to do with MOTU processes.
[16:40] <LaserJock> or it should provide a "general" abstraction
[16:41] <LaserJock> it seems odd to me to create a whole new package and "abstraction" specifically for PPA
[16:42] <sistpoty|work> actually, I've just looked at the gutsy ppaput thingy, and imho it doesn't make sense to have it in ubuntu-dev-tools as long as we don't adjust the sponsorship process. if we don't do the latter, the only thing that is not buggy imo in ppaput is the dput call
[16:42] <dholbach> sorry, in a call right now - be back in a bit
[16:42] <sistpoty|work> and for testing purposes, having ppaput lying on a ppa seems the best option for me :)
[16:43] <sistpoty|work> (or in bzr)
[16:43] <sistpoty|work> damn... I *must* stop procrastrinating *g*
[16:43] <RainCT> ScottK: neither the package's name nor description (talking about python-ubuntutools) say that it's for MOTU (and when I said that it's intended to get more stuff I ment other non-LP related stuff..)
[16:44] <LaserJock> hmm, I'm just getting a bit confused by all the "helper packages" with seemingly overlapping and/or trivial content
[16:44]  * RainCT agrees that the ppa module should be more general, btw
[16:45]  * RainCT will stop now discussing about this as he isn't neither interested in ppaput nor has he ever tried it
[16:46] <LaserJock> so we'd have at least python-ubuntutools, ubuntu-dev-tools, bughelper, python-bughelper, python-launchpad-bugs, and five-a-day packages for "work in Ubuntu"
[16:47] <RainCT> LaserJock: isn't the 5 a day stuff in a PPA?
[16:47] <LaserJock> yep
[16:47] <LaserJock> but there is a "needs packaging" bug files
[16:47] <LaserJock> *filed
[16:47] <sistpoty|work> LaserJock: that's FOSS at it's best :P
[16:48] <RainCT> oh, I don't know what it contains but wouldn't it be suitable for ubuntu-dev-tools?
[16:48] <LaserJock> sistpoty|work: hmmm, I think I could debate you on that one
[16:48] <LaserJock> I would argue that having lots of nice little tools is great, but scattering them all over everywhere isn't so nice
[16:48] <RainCT> (ubuntu-dev-tools and python-ubuntutools don't overlap, the first one has executables and the second one modules -well, until now only one but there will be more- used by some of those executables; and their are the same source package)
[16:48] <ScottK> Well this kind of stuff is the kind of thing that was really concerining me when I pulled back at the start of the Hardy cycle.  I thought it'd stopped.
[16:48] <LaserJock> especially when the keep changing names, don't seem to have stability
[16:49] <ScottK> I'm going to go calm down now.
[16:49] <sistpoty|work> LaserJock: heh... I guess I'd even go as far to say it's software engineering at its best... :)
[16:49] <kirkland> mathiaz: http://pastebin.com/pastebin.php?diff=m1e055dfe
[16:49] <kirkland> mathiaz: there seem to be regressions, i'm chasing those down
[16:49] <LaserJock> sistpoty|work: I don't mind the software engineering part nearly as much as the packaging part
[16:49] <sistpoty|work> heh
[16:50] <RainCT> ScottK2: hey, no need to overhead just because you don't like a script ;)
[16:50] <LaserJock> if they are in different packages from different sources
[16:50] <LaserJock> it's easy to break stuff
[16:51]  * sistpoty|work just wonders, why it's so trivial to write code doing roughly the same things twice and cleaning it up is much harder (while cleaining up my own project)
[16:51] <RainCT> *overheat
[16:52] <jpatrick> RainCT: he's not here :p
[16:52] <RainCT> oh right
[16:52] <RainCT> :P
[16:53] <kirkland> zul: see http://pastebin.com/pastebin.php?diff=m1e055dfe for test differences, -before +after
[16:54] <zul> eh?
[16:54] <zul> why is there more tests failed?
[16:55] <LaserJock> RainCT: whether they are executables or modules is basically irrelevant
[16:55] <kirkland> zul: I'm looking....
[16:55] <kirkland> zul: and I'm running on i386 too
[16:55] <RainCT> LaserJock: Python policy :)
[16:55] <LaserJock> RainCT: no, hang on a sec there
[16:55] <LaserJock> Python policy does *not* state you have to have a new package if you have modules
[16:55] <zul> *grumble*
[16:57] <LaserJock> it would be perfectly fine to ship it all in a single package for now
[16:57] <RainCT> LaserJock: neither if those are public modules?
[16:57] <LaserJock> they shouldn't *be* public modules
[16:57] <LaserJock> that's my point
[16:57] <LaserJock> why would you make them public modules and do a new binary package at this point
[16:58] <RainCT> LaserJock: well, the idea of even having those modules is for them to be public. and afaik there's at least 1 person interested in them (right, 1 person is really not a good argument :))
[16:58] <LaserJock> if there is need for them to go public then great, but it should most likely be in a different package
[16:59] <LaserJock> unless we have a number of things we want to make public
[16:59] <LaserJock> it just seems odd to add the maintainence overhead and complexity for such a narrow and small library
[16:59]  * \sh <- EoB
[16:59] <LaserJock> which in fact, at this point, has really not much of any bearing on MOTU
[17:00] <RainCT> LaserJock: well, I'll leave the module in the same binary then until there are more modules, if dholbach is OK with that
[17:00] <sistpoty|work> well making such modules public would imho only be a good idea, if the api has become stable... otherwise it's no fun depending on it ;)
[17:00] <LaserJock> sistpoty|work: exactly
[17:00] <LaserJock> this is a fairly common thing I'm seeing
[17:01] <LaserJock> people putting out public libraries with before they reach any stability, then everything breaks on the next upload
[17:01] <LaserJock> s/with//
[17:03] <LaserJock> ideally I'd like to see only 2 packages
[17:03] <LaserJock> python-launchpad and ubuntu-dev-tools
[17:03] <LaserJock> and let python-launchpad handle all the abstraction of LP we need
[17:04] <LaserJock> and then ubuntu-dev-tools being the actual tools and scripts people would use
[17:14] <kirkland> zul: before and after on i386 look good: http://pastebin.com/pastebin.php?diff=dc66f64a
[17:15] <zul> kirkland: so what changed? :)
[17:15] <kirkland> zul: nothing on i386, which is good
[17:15] <kirkland> zul: but tests are failing on amd64
[17:15] <kirkland> zul: I'm retracing my steps
[17:16] <zul> ok sounds good
[17:16] <kirkland> to make sure my test runs are identical (save the diff)
[17:16] <kirkland> zul: what's scary is that the failing tests are all strtotime related :-/
[17:16] <kirkland> zul: potentially test cases need to be updated
[17:16] <kirkland> now that 64bit time is properly supported
[17:16] <zul> I was about to say that :0
[17:17] <kirkland> any idea of this php developer is on irc<EMAIL_ADDRESS>[17:17] <zul> #php maybe?
[17:18]  * sistpoty|work heads home
[17:18] <sistpoty|work> later folks
[17:25] <tbf> why doesn't lintian consider this entry:
[17:25] <tbf> # Override this warning, as we do not have message catalogs yet.
[17:25] <tbf> gnome-lirc-properties: package-contains-empty-directory usr/share/locale/
[17:25] <tbf> when i add it to debian/gnome-lirc-properties.lintian-override?
[17:26] <kirkland> zul: okay, i'm going to work against the upstream PHP tar balls, in case the tests have been updated themselves
[17:27] <zul> ok with me..
[17:27] <kirkland> zul: this rabbit hole is far deeper than I might have expected ;-)
[17:28] <zul> it usually is :)
[17:35] <kirkland> zul: bingo, those tests have been updated
[17:35] <zul> nifty so they work?
[17:36] <kirkland> zul: i'm rerunning
[17:36] <kirkland> zul: if they do, i'll roll in the patch
[17:44] <pochu> persia: midi support! \o/
[17:44] <pochu> persia: good work with wildmidi ;)
[17:47] <LaserJock> oh man, I guess I need to stock up on polaroid film, they are ceasing production
[17:49] <dholbach> RainCT: do you need the ppaput source in ubuntu-dev-tools for it?
[17:50]  * RainCT doesn't understand dholbach's question
[17:50] <dholbach> RainCT: do you need the ppaput source in ubuntu-dev-tools for your module?
[17:51]  * RainCT still doesn't understand :P
[17:51] <dholbach> RainCT: you have a module in ubuntu-dev-tools right now, right?
[17:52] <dholbach> is it necessary for the module to have the ppaput script in ubuntu-dev-tool too? I guess not, right?
[17:52] <LaserJock> he didn't write it I don't think
[17:54] <RainCT> dholbach: the ppaput module that is currently going into python-ubuntutools (which isn't mine; rexbron worked on it)? it doesn't require the ppaput command, but the command needs the module
[17:54] <RainCT> dholbach: is this what you were asking?
[17:54] <dholbach> yes, thanks a bunch
[17:55]  * mok1 wonders why all config tools require X to be running :-(
[17:55] <LaserJock> dholbach: would it be feasible to merge the bughelper and 5-a-day stuff into ubuntu-dev-tools?
[17:56] <mok1> There *really* should be tui's for all config tools
[17:56] <dholbach> LaserJock: I have a session coming on right now, for bughelper best to ask bdmurray and thekorn - I'm not that much involved with it anymore
[17:56] <dholbach> LaserJock: for five-a-day I'm not sure
[17:57] <dholbach> MOTU Q&A Session in #ubuntu-classroom in a bit
[17:58] <dholbach> LaserJock, RainCT: ppaput removed for now
[17:59] <RainCT> dholbach: what's with the ppaput module?
[18:00] <dholbach> RainCT: I left it as it is
[18:00] <LaserJock> well, a general library for dealing with packages may indeed be helpful
[18:00] <LaserJock> but it should certainly be more than just for PPAs
[18:01] <LaserJock> gotta run, bbl
[18:01] <RainCT> ok, I'll remove python-ubuntutools from debian/control and comment the module stuff in setup.py and such for now until the module gets improved and properly documented
[18:02] <RainCT> btw, stdin got a new dgetlp version ready (with support for native packages and a bug fix), if someone wants to try it before I commit, http://stdin.me.uk/dgetlp
[18:28] <tbf> .oO(the ppa build services rock)
[18:39] <jdong> siretart: poke, bug 194226, I believe a while back you said you had a ffmpeg staging from experimental... Would you like to comment on that bug?
[18:39] <ubotu> Launchpad bug 194226 in ffmpeg "Outdated FFMPEG version impeding HD video playback" [Undecided,New] https://launchpad.net/bugs/194226
[18:47] <tbf> i keep getting rejects like this: "MD5 sum of uploaded file does not match existing file in archive"
[18:48] <tbf> is that because deleted packages just are hidden, but not really deleted?
[18:48] <tbf> i wanted to keep the release number, since package building failed
[18:51] <norsetto> tbf: you talking about PPAs I guess? In that case please ask in #launchpad
[18:51] <tbf> norsetto: ok. thank you.
[18:53] <pochu> tbf: (deleting them seems to take a while, maybe an hour or a few hours...)
[18:54] <pochu> tbf: hello, btw :)
[18:54] <tbf> hello pochu. ah, ok.
[18:54] <stdin> it happens on an daily cron job iirc
[18:57] <tbf> stdin: uch, how inconvenient
[18:59] <tbf> bbl - hopefully i've got all build-deps right this time
[19:00] <emgent> heya people
[19:14] <dholbach> Library Packagin Session in #ubuntu-classroom
[19:17] <siretart> jdong: well, I got a response from slomo that the package from experimental had an ABI break
[19:17] <siretart> jdong: I didn't find the time to investigate it properly. most likely we should do an sobump
[19:18] <siretart> jdong: if you are willing to convince the relase teams that we can just go with recompiling depending packages, I'd vote for it
[19:22] <nareshov> I have a package-request: Please package this http://rubygame.sourceforge.net/ Thanks!
[19:23] <hellboy195> nareshov: please file a bug on LP
[19:23] <nareshov> okay
[19:26] <nareshov> hellboy195: https://bugs.launchpad.net/ubuntu/+bug/194463
[19:26] <ubotu> Launchpad bug 194463 in ubuntu "[Package Request] Rubygame" [Undecided,New]
[19:26] <dholbach> nareshov: http://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[19:26] <dholbach> best to tag it as 'needs-packaging'
[19:26] <nareshov> ok
[19:27] <nareshov> Done re-tagging
[19:27] <dholbach> great
[19:27]  * dholbach calls it a day now - have a great weekend everybody
[19:31] <james_w> bye dholbach, have a good one yourself.
[19:31] <dholbach> james_w: "ROCK" ON! :-)
[19:33] <Iulian> Have fun, dholbach.
[19:33] <dholbach> bye Iulian
[19:33] <RainCT> dholbach: good weekend :)
[19:33] <dholbach> bye RainCT :-)
[19:33] <dholbach> see you monday :)
[19:33] <emgent> :)
[19:33] <dholbach> bye emgent
[19:33] <emgent> bye dholbach ^^
[19:37] <gouchi> Hi there
[19:37] <gouchi> I'm gonna try to package a software with wxwidget lib
[19:37] <gouchi> I compile it with codeblocks
[19:38] <gouchi> I was wondering if I can compile it with codeblocks when doing the deb package process ?
[19:38] <gouchi> or I must make it work with autotools , cmake .... ?
[19:48] <Laney> I need some advice. If I have a patch which modifies aclocal.m4, I need to run autoconf somehow, right? So I've put this in the patch stanza in debian/rules. But then I have to build-dep on autoconf, which isn't really ideal. Can someone advise me on the best way to proceed?
[19:49] <slangasek> Laney: one option is to capture the changes resulting from running autoconf in a separate patch
[19:49] <slangasek> but build-depending on autoconf is common enough, and not really frowned upon
[19:49] <slangasek> btw, you say you're editing aclocal.m4, not acinclude.m4?
[19:50] <Laney> slangasek: It's an upstream patch which modifies aclocal
[19:50] <slangasek> well, ok
[19:50] <slangasek> bad upstream, they should be making their changes to acinclude.m4 :)
[19:51] <slangasek> (aclocal.m4 is also supposed to be auto-generated)
[19:51] <Laney> Actually there isn't even an acinclude file...
[19:51] <Laney> Maybe they've just hand written an aclocal
[19:53] <Laney> slangasek: Anyway, you don't think that build-depending on autoconf is a problem? I'll go ahead and do that if so.
[19:57] <slangasek> yes, build-depending on autoconf is a common practice.  Please be sure to remove the modified configure script in the clean target, though
[20:01] <Laney> As in `rm configure'?
[20:04] <slangasek> Laney: yes
[20:04] <slangasek> that way you don't end up with a lot of interdiff churn for each new version of autoconf that's used
[20:05] <Laney> Ah, ok :)
[20:10]  * LaserJock hands sistpoty a cold drink
[20:10] <sistpoty> thanks LaserJock
[20:17] <LaserJock> is anybody still using dgetlp?
[20:21]  * ScottK2 understood it's not needed anymore, but I'm not sure.
[20:22] <LaserJock> well, it's been modified recently according to debian/changelog
[20:23] <LaserJock> but I think all it does beyond what we can do without it is dpkg-source -x the downloaded source package
[20:28] <geser> LaserJock: dget -x unpacks also the downloaded source package
[20:29] <LaserJock> ah
[20:29] <LaserJock> so there we go
[20:29] <LaserJock> perhaps we should have a "ubuntu-dev-tools hackup/cleanup" session?
[20:44]  * ScottK2 is seriously wondering if the launchpad cookie alternative to a GPG signature for PPA uploads is really a good idea.
[20:44] <LaserJock> the what??
[20:44]  * ScottK2 wonders if it's really a security hole and ppaput is a working model of the exploit
[20:45] <ScottK2> According to the ppaput man page I was annoyed about earlier it appears to me if you're logged into LP and have an appropriate cookie from LP, you're PPA uploads don't need to be signed.  I'm not certain of this yet, however
[20:45]  * ScottK2 has it on his list to investigate later.
[20:45] <LaserJock> woah, I would be very surprised about that
[20:46] <polopolo> hello all
[20:46] <polopolo> can someone help me?
[20:46] <ScottK2> Dunno.  Maybe the cookie this is just for bug filing.  I'm really not sure.
[20:46] <norsetto> !ask polopolo
[20:46] <ubotu> Sorry, I don't know anything about ask polopolo - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[20:46] <norsetto> oh well....
[20:46] <norsetto> polopolo yes?
[20:47] <LaserJock> norsetto: you need to pipe it, | or > ;-)
[20:47] <polopolo> how do I add my ssh code in launchpad?
[20:47] <polopolo> how do I add my ssh code in launchpad?
[20:47] <norsetto> laserjock: :-)
[20:47] <thekorn> ScottK, the cookie is just for bug filing
[20:47] <ScottK2> thekorn: OK.
[20:47] <ScottK2> theq
[20:48] <norsetto> polopolo: you mean key I guess?
[20:48] <polopolo> no, ssh code
[20:48] <polopolo> ssh key yes
[20:48] <polopolo> sorry
[20:49] <norsetto> polopolo: ah ... in your launchpad page, the menu on the left?
[20:49] <polopolo> yes, but how can I know my ssh code?
[20:49] <hellboy195> norsetto: does a motu has to have a ssh key?
[20:49] <norsetto> hellboy195: no
[20:49] <hellboy195> norsetto: k, thx
[20:49] <norsetto> hellboy195: but you need it if you want to use things like bzr
[20:50] <hellboy195> ah,k
[20:50] <polopolo> hmmmmmm, wait a sec
[20:51] <norsetto> polopolo: are you arsenepaul?
[20:59] <Laney> blueyed: Can you take a look at my new patch on the darcs FTBFS bug?
[21:18] <pochu> nxvl: hi, did you read my previous message regarding terminator?
[21:18] <nxvl> pochu: Ng is writing the Freeze exeption
[21:18] <pochu> oh, cool
[21:18] <blueyed> Laney: builds fine. I wonder though: if you now have changes in "configure", do you need the autoconf dependency/rebuild in rules?
[21:18] <pochu> thanks
[21:18] <pochu> Ng: good luck ;)
[21:18] <nxvl> (or al least that's what i think) i'm kind of busy right now on the work
[21:19] <Ng> pochu: thanks ;)
[21:20] <pochu> Ng: I'll open a bug regarding how the links are highlighted if you put the mouse over the domain, to see what people thinks, if that's fine with you
[21:20] <nxvl> pochu: 0.8.1 is already in debian
[21:20] <nxvl> pochu: and 0.9 will come with some surprises, so stay tuned :P
[21:21] <pochu> nxvl: yeah, I saw it in debian-devel-changes, that's how I realized 0.8 was out ;)
[21:21] <nxvl> heh
[21:21] <nxvl> :D
[21:21] <pochu> as I can't subscribe to<EMAIL_ADDRESS>unless I'm a member of ~terminator...
[21:21] <pochu> have to run, bbl
[21:22] <Laney> blueyed: I think I do - the new configure file referse to the state after autoconf has been run. Unless you're suggesting that I include the changes in the patch, which is a bit messy in my opinion. To me it's pretty clean currently - has a nice small debdiff ;)
[21:23] <Ng> pochu: sure
[21:23] <Laney> I'm trying to build darcs on sid now, to see if it works or not
[21:24] <Legendario> hello everybody! I would like to know: how am I supposed to pack something that doesn't need to be compiled, like a script? I couldn't find such an answer on the guide...
[21:25] <blueyed> Laney: I've seen the changes to configure in "debdiff ../darcs*dsc", but missed the "reverted".. there's currently no configure in the source, correct?
[21:26] <blueyed> Laney: you are trying to build it without your patch?
[21:26] <Laney> blueyed: Yeah, just to check if it's necessary
[21:26] <Laney> But man do the deps take *ages* to download and install
[21:27] <Laney> blueyed: There is a configure in the source
[21:27] <Legendario> does anyone know the answer?
[21:28] <Laney> Legendario: I think I saw something about packaging python scripts on there, let me look
[21:30] <Laney> Legendario: Sorry, I can't see it :(
[21:30] <geser> Legendario: just use cp where you would use make install and cp them to the right location
[21:30] <blueyed> Laney: I'm only seeing configure.ac.. Maybe because you delete it in clean?
[21:31] <Legendario> Laney, what about other scripts like perl and bash???
[21:31] <Laney> blueyed: Yes, that was per slangasek
[21:31] <Legendario> geser, i want to pack them.
[21:32] <geser> Legendario: yes, and make install usually uses /usr/bin/install to get the files into the correct dir below debian/ from where the deb is build later
[21:32] <geser> so you just need to make sure you do it too
[21:33] <Legendario> geser, sorry. but i couldn't understand what i am supposed to do exactly
[21:34] <geser> Legendario: are you familiar how the deb building works for a package which needs compilation?
[21:35] <Legendario> geser, i am giving my first steps. Have created 3 packages so far...
[21:36] <blueyed> ...which is quite good already :)
[21:36] <blueyed> Laney: uploaded.
[21:36] <geser> have you looked at the dirs below debian/ which appear during package building?
[21:36] <geser> Legendario: ^^
[21:36] <Laney> blueyed: Thanks!
[21:36] <Legendario> geser, sure thing
[21:37] <Laney> Urgh, I should be more generous in allocating space to my VMs
[21:37] <geser> Legendario: from those dir the deb is packed in the end
[21:38] <geser> Legendario: so if you don't need compilation, you just need to make sure that the files are in the correct dirs below debian/ so a deb can be build from it
[21:39] <geser> Legendario: btw: doesn't it have any install script or a Makefile?
[21:41] <Legendario> geser, one of the sources i am trying to pack have, the other doesn't
[21:45] <geser> Legendario: there is no big magic between package a software with a makefile and a software without the makefile, the makefile helps you with "installing" the software so you don't need to have to do it manually
[21:45] <geser> so if you don't have a makefile you need to the things the makefile would usually do
[21:47] <Legendario> geser, what are those? I only know how to pack ones with makefile. Install scripts don't work with me too...
[21:47] <geser> have you tried to look what a Makefile does?
[21:49] <geser> you need to cp the script(s) into debian/<packagename/... where ... is the path it should have later in the package
[21:49] <Laney> Legendario: I find that looking at how existing similar packages work helps my understanding
[21:49] <geser> oO( someone should add a chapter about packaging script to the packaging guide who can explain it better than me )
[21:50] <Legendario> geser, i agree with this guide adition...
[21:50] <Legendario> geser, would it be, for example: debian/usr/bin ?
[21:51] <Legendario> or debian/usr/bin/packagename?
[21:52] <geser> debian/packagename/usr/bin
[21:52] <geser> dpkg-deb takes at the end the contents of debian/packagename/ and makes a packagename.deb out of it
[21:54] <Legendario> geser, so. the script goes on the end of the path debian/packagename/usr/bin ?
[21:54] <geser> yes
[21:54] <geser> and the deb will contain it later as usr/bin/scriptname
[21:55] <Legendario> geser, and I build the package as always: debuild -S -sa
[21:56] <geser> yes, everything is nearly the same like in other packages
[21:57] <Legendario> geser, thanks a lot man... I am going to try it right away. But i think someone should add it on the wiki
[21:57] <geser> the only difference is that you don't need to call make in debian/rules (as there is nothing to compile) and need to replace the make install call with the correct cp call(s) to get the script where it belongs (if you don't have a Makefile which does it for you)
[21:59] <geser> e.g. some python modules don't have a makefile but a setup.py script which does the building (if needed) and can also copy the files to the correct location when called with install
[22:02] <Legendario> geser, so, if i am using cdbs, i take the line: include /usr/share/cdbs/1/class/makefile.mk
[22:02] <Legendario> out, and what should i place?
[22:03] <geser> sorry, I don't how to best to do it with cdbs
[22:03] <Seveas> Legendario, there's a distutils class
[22:04] <Legendario> Seveas, /usr/share/cdbs/1/class/distutils.mk?
[22:04] <Seveas> Legendario, here's a simple debian/rules for cdbs+distutils:
[22:04] <Seveas> #!/usr/bin/make -f
[22:04] <Seveas> DEB_PYTHON_SYSTEM=pycentral
[22:04] <Seveas> include /usr/share/cdbs/1/rules/debhelper.mk
[22:04] <Seveas> include /usr/share/cdbs/1/class/python-distutils.mk
[22:05] <Seveas> not sure if it's still necessary to define DEB_PYTHON_SYSTEM
[22:06] <Legendario> Seveas, i my case, it is a perl script... so, can it be perl-distutils.mk?
[22:07] <Seveas> ah sorry, didn't read it all, from gesers comment I though tou were dealing with python
[22:09] <Seveas> Legendario, if what you want to package is just simple files, have a debian/install and use dh_install
[22:10] <hellboy195> Seveas: cdbs seems to be very easy. why hasn't replaced it the other things?
[22:10] <Seveas> hellboy195, imho it's too much black magic
[22:11] <Seveas> hellboy195, but I use it for all simple packages I do :)
[22:11] <hellboy195> Seveas: ^^
[22:12] <sistpoty> hellboy195: easy != you know what's going on or have control of it ;)
[22:12] <Legendario> Seveas, how is the sintaxe of dh_install?
[22:12] <hellboy195> sistpoty: for me is the easiest way the best way ^^
[22:13] <Seveas> Legendario, man dh_install
[22:13] <geser> hellboy195: cdbs works well with packages using autotools or python-distutils, but you have to fight it in the other cases
[22:13] <mario_limonciell> hellboy195, i'm personally a huge fan of cdbs, but still feel that you should learn to package with and without it (so you learn what the underlying things its doing are)
[22:13] <Legendario> geser, i agree.
[22:14] <geser> Legendario: iirc there should be chapter describing packaging with debhelper in the packaging guide
[22:14] <sistpoty> hellboy195: when reviewing packages I often found out that people had no clue how to do a simple thing I requested, because they didn't know what's going on or how to change it
[22:14] <hellboy195> sistpoty: yeah I understand :)
[22:14] <hellboy195> mario_limonciell: because of that I'm doing merges without grab-merge ^^
[22:15] <sistpoty> granted, cdbs is very powerful though, if you do know what's going on
[22:15] <Legendario> geser, i've read it all. I am trying to pack with all the options
[22:15] <hellboy195> geser: unfortunately there is no *one way* :(
[22:15] <geser> sistpoty: even if you know what cdbs does in the background it's not easy to get cdbs to do what you want
[22:16] <sistpoty> geser: it's not straightforward or easy, but I guess it can be done... however /me prefers to not use cdbs because debian/rules say what is going on (even if they are longer)
[22:21] <geser> sistpoty: do you know how to get cdbs to specify a build-indep target for arch:all package?
[22:22] <sistpoty> geser: no... as I wrote, I prefer to not use it (and used it actually only once for a python package)
[22:22]  * geser looks a the bad work-around done to the clipper FTBFS on !i386 by moving B-D-I to B-D
[22:22] <Seveas> ouch
[22:23] <sistpoty> imho it was a bad move as well, to diverge from debian's cdbs (with the symlink thingies)... oh, I must report a bug for this still
[22:23] <ScottK> sistpoty: It was by design though, so good idea or bad, it's not a bug.
[22:23] <ScottK> geser: You might use that as an education opportunity for mok0 then (clipper).
[22:24] <sistpoty> ScottK: imho the current implementation is a bug, because it allows bad symlinks (but I looked more closely at the implementation 2 weeks ago, maybe it's already fixed)
[22:24] <geser> ScottK: I know the taken approach is wrong, but have no idea how the correct fix looks like
[22:25] <ScottK> sistpoty: OK.  Fair enough.
[22:25] <sistpoty> ScottK: luckily, it omits debian/copyright from symlinking... if that was done, it could lead to serious license violations :)
[22:25] <ScottK> geser: He's pretty sharp about a lot of stuff, just still learning Debian packaging.   With a little pointing, I bet he could solve it.
[22:34]  * tbf wonders if there i some guide to muve stuff from ppa to universe....
[22:35] <tbf> ...now that lintian accepts this gnome-lirc-properties package....
[22:36] <tbf> https://bugs.launchpad.net/ubuntu/+bug/192368
[22:36] <ubotu> Launchpad bug 192368 in ubuntu "Please add gnome-lirc-properties" [Wishlist,Confirmed]
[22:36] <tbf> https://launchpad.net/~openismus-team/+archive
[22:37] <ScottK> PPA is pretty much irrelevant to getting a package in Universe.
[22:37] <ScottK> It's the same as any package.
[22:39] <tbf> ScottK: well the build service helps alot to fix issues without bugging motus
[22:44] <ScottK> tbf: Yes.  It's likely a better package to start with, but the process is the same.
[22:55] <Legendario> geser, what about java software without makefiles or install scripts... is it the same process?
[22:55] <Legendario> i don't think so...
[22:57] <sistpoty> oh, anyone with gnome and an nvidia card who could test a debdiff to sensors-applet for me?
[22:58] <hellboy195> sistpoty: here :)
[22:58] <sistpoty> hellboy195: excellent... http://launchpadlibrarian.net/12022921/proposed.debdiff is against the latest version (imo)
[22:58] <geser> Legendario: doesn't java use ant?
[22:59] <hellboy195> sistpoty: ähm. I *make* debdiffs but I don't know how to *use* them :(
[22:59] <Legendario> geser, i don't know what it is...
[22:59] <sistpoty> hellboy195: öhm... apt-get source sensors-applet
[23:00] <sistpoty> hellboy195: then cd into the top source dir and do
[23:00] <sistpoty> hellboy195: patch -p0 < thedebdiff
[23:00] <hellboy195> sistpoty: k :)
[23:00] <geser> Legendario: some java apps use ant (Java based build tool like make) and there is already a cdbs class for ant
[23:01] <sistpoty> and funny, to see an ähm btw. :)
[23:02] <hellboy195> sistpoty: germanism ^^
[23:02] <sistpoty> hellboy195: Ich weiß :P
[23:03] <hellboy195> sistpoty: ich bin ein Berliner ^^
[23:04] <paultag> hey guys, I am interested in becoming a MOTU, any tips?
[23:04] <sistpoty> hellboy195: /me is from Franken (near Erlangen/Nürnberg)
[23:04] <hellboy195> sistpoty: ah sry. I thought you are from Berlin ^^ /me is from southern Austria
[23:04] <sistpoty> hellboy195: ah
[23:05] <paultag> hellboy195: My family is from Hallein, and I have an exchange student in Munchen
[23:05] <hellboy195> paultag: nice :)
[23:05] <Legendario> geser, i found a page that says i need ant and java SDK, to build it... does the ant class able to handle it?
[23:05] <sistpoty> paultag: maybe there some bitesize bugs left, you could look at wiki.ubuntu.com/MOTU/TODO
[23:06] <tbf> guess i'll have to change the package's version number from 0.2.0-0ubuntu1~ppa3 to something different, before uploading to REVU?
[23:06] <hellboy195> sistpoty: what do you want to know about sensors-applet?
[23:06] <norsetto> night all
[23:06] <hellboy195> norsetto: night :)
[23:06] <geser> Legendario: I don't know, I try to avoid cdbs when possible
[23:06] <sistpoty> hellboy195: does the updated one show the temparatures of the GPU?
[23:06] <tbf> probably "0.2.0-0ubuntu2"?
[23:06] <hellboy195> sistpoty: k, still building
[23:06] <sistpoty> hellboy195: that's what I hope, since it's built with nvidia support now
[23:07] <sistpoty> jdong: do you happen to know if there is a debootstrap in gutsy-updates (I know, I'm lazy :P)
[23:07] <jdong> grep 'jdong:.*bluekuja.*' ~/irclogs -R
[23:07] <jdong> crap
[23:07] <jdong> sistpoty: gutsy-backports always has the latest
[23:08] <ScottK> sistpoty: There is
[23:08] <sistpoty> jdong: excellent, thanks!
[23:08] <jdong> and while I'm here, anyone heard from bluekuja recently?
[23:08] <sistpoty> nope
[23:08] <Legendario> got this: You must specify a valid JAVA_HOME or JAVACMD!
[23:09] <sistpoty> Legendario: iirc, this should be provided by the right java package... but that was *very* long ago, when I last had seen this
[23:09] <hellboy195> jdong: it seems that he is fine
[23:10] <hellboy195> sistpoty: only cpu :(
[23:10] <sistpoty> :(
[23:10] <sistpoty> hellboy195: do you have l-r-m installed? and are using the restricted driver?
[23:10] <jdong> hellboy195: that's what I wanted to know, I hope he's alright, just too busy to contribute to Ubuntu
[23:10] <hellboy195> jdong: luca phoned him last week
[23:10] <jdong> hellboy195: that's good to hear
[23:10] <hellboy195> jdong: well he is my mentor. So *I* miss him ^^
[23:11] <jdong> I was just worried that he hasn't shown up in IRC for more than a month
[23:11] <hellboy195> sistpoty: sry. l-r-m?
[23:11] <jdong> mplayer http://www.computersoc.com/video/radar/22108_ka.wmv
[23:11] <sistpoty> hellboy195: linux-restricted-modules
[23:11] <jdong> wow I really suck at focus today
[23:11] <sistpoty> -something
[23:11] <hellboy195> siretart: +1 , +1
[23:12] <sistpoty> damn!
[23:12]  * sistpoty must install gnome *g*
[23:12] <hellboy195> jdong: whats the video about?
[23:12] <hellboy195> sistpoty: gnome should be installed ;)
[23:12] <jdong> hellboy195: oh it's just a radar encounter with the Valentine One radar detector
[23:12] <jdong> hellboy195: the guy just wanted to know if his detection distances were normal
[23:12] <sistpoty> hellboy195: *g*
[23:13] <hellboy195> jdong: xD, keep contribution to ubuntu! ^^
[23:13] <hellboy195> sistpoty: I leave soon, if you need me to test it again tomorrow - just ping me
[23:13] <jdong> :)
[23:14] <sistpoty> hellboy195: oh, do you have nvidia-settings installed... if so, could you start that and see if that one shows you the GPU temperature?
[23:14] <Legendario> sistpoty, any hints on how to deal with it?
[23:14] <sistpoty> others than that, I have no real clue where to fix it w.o. trying myself
[23:15] <hellboy195> sistpoty: the restricted driver doesn't install the -settings so no, but I can install it ...
[23:15] <sistpoty> Legendario: what do your build-depends look like?
[23:15] <Legendario> sistpoty, cdbs, debhelper (>= 5)
[23:16] <sistpoty> Legendario: you'll need s.th. that provides a java compiler in there... I wouldn't know what actually though (maybe gcj?)
[23:16] <sistpoty> Legendario: and "ant"
[23:17] <hellboy195> sistpoty: 47° :)
[23:18] <sistpoty> hm... damn again *g*
[23:18]  * sistpoty installs gnome
[23:18] <hellboy195> sistpoty: gnome should already be installed ^^ xD
[23:18] <Legendario> sistpoty, gcj and ant?
[23:18] <sistpoty> heh, not for a kubuntu user (who purged gnome partly once)
[23:19] <Legendario> only this?
[23:19] <hellboy195> sistpoty: I don't understand what's so cool about kde/kubuntu
[23:19] <sistpoty> Legendario: it might be worth a try... but I can't really say that it is sufficient to build a java package with these
[23:20] <Legendario> sistpoty, what about this package: libjaxp1.3-java-gcj - Java XML parser and transformer APIs (DOM, SAX, JAXP, TrAX)
[23:20] <tbf> that linda message seems bogous to me: http://revu.tauware.de/revu1-incoming/gnome-lirc-properties-0802230010/linda
[23:20] <sistpoty> hellboy195: I found out how to assign a shortcut to launch a shell (back in kde1.something, where it was really hard work)... since then I never switched, so this very shortcut is broken right now :/
[23:20] <hellboy195> sistpoty: xD ^^
[23:21] <sistpoty> tbf: yes, it is... linda is quite outdated on revu
[23:21] <sistpoty> (or rather outdated in general... but she still spots some errors lintian won't find)
[23:21] <hellboy195> sistpoty: wouldn't it be the best to merge these 2 ?
[23:21] <slangasek> sistpoty: which errors are those?  I'm sure the lintian maintainers would like to know about them
[23:22] <tbf> sistpoty: ok - pew
[23:22] <tbf> :-)
[23:22] <sistpoty> hellboy195: ask StevenK ;)
[23:22] <hellboy195> sistpoty: away atm :( ^^
[23:22] <sistpoty> slangasek: I don't recall right now... and actually my knowledge of these dates back to when linda wasn't outdated yet :P
[23:23] <slangasek> right, ok :)
[23:24] <sistpoty> grml... either I'm stupid, or gnome2 is still not installable (note, that I'm one day behind, mirror)
[23:25] <hellboy195> sistpoty: sudo apt-get install ubuntu-desktop ;)
[23:27] <tbf> pochu: fresh meat: http://revu.tauware.de/details.py?package=gnome-lirc-properties :-D
[23:28] <sistpoty> hm... why is there a gnome-desktop-environment in universe?
[23:28] <sistpoty> (which fooled me)
[23:28] <LaserJock> probably from Debian
[23:28] <sistpoty> it is from debian, but is it needed (meta-package)?
[23:31] <LaserJock> we sync many metapackages from Debian
[23:31] <LaserJock> that it is in Universe is the first indicator that it's probably not what you want ;-)
[23:37] <hellboy195> gn8 :)
[23:50] <emgent> heya *
[23:54] <tbf> nite


[17:02] <Sarvatt> ok, how about a nonouveau (can anyone think of a better word?) boot option to blacklist the nouveau module so people can actually use vesa or nv without manually blacklisting it? noticing this is a pretty sore spot right now
[17:19] <Sarvatt> oh, blacklist=nouveau directly from the kernel command line looks like a valid option now that I'm digging through initramfs-tools, didn't know that
[17:36] <Sarvatt> http://bazaar.launchpad.net/~sarvatt/initramfs-tools/working/revision/163 is kind of pointless then if they can just do blacklist=nouveau, need to try that out
[17:40] <Sarvatt> i'm thinking it might be handy to have say, failsafex or the old xforcevesa as boot arguements. we could blacklist all KMS drivers in initramfs-tools and have the gdm upstart job pick failsafeX if it matches because its already checking the kernel command line for inhibitors
[17:44] <Sarvatt> then we could just extend the kernel command line check in /etc/init/gdm.conf to check for the command and set env XORGCONFIG=/etc/X11/xorg.conf.vesa and ship a new stock vesa xorg.conf?
[17:46] <Sarvatt> actually we could just make gdm exit1 if it matches, that'd automatically start a failsafe session
[17:53] <verbalshadow> what did i miss? booting with Mobility Radeon HD 4200 with KMS now freeze my system and won't boot with out disabling.
[18:14] <Sarvatt> verbalshadow: mind filing a bug so we can look at your logs?
[18:15] <Sarvatt> just ubuntu-bug xserver-xorg-video-ati and subscribe Sarvatt if you dont mind
[18:16] <Sarvatt> and whoa booting straight into failsafe is insanely fast compared to normal booting, menu was up in 11 seconds on this slow hdd netbook
[18:22] <verbalshadow> Sarvatt: filing now
[18:31] <verbalshadow> ok  now i need to file a bug on ubuntu-bug it thinks i don't have an internet connection and can't connect to the crash DB :(
[19:20] <Sarvatt> hmm, not having any luck adding the xforcevesa option to initramfs-tools. i added the option to Init and had it set blacklist=drm,i915,nouveau,radeon and quiet=n, and also tried adding a check for xforcevesa to scripts/init-top/blacklist and blacklist those modules explicitly in there
[19:21] <Sarvatt> but plymouth seems to be loading drm/i915 and such on its own
[19:22] <Sarvatt> changed the gdm upstart job to exit 1 if it sees xforcevesa in /proc/cmdline to load failsafe and that part works but its using fbdev on top of KMS of course because drm and such is loaded for plymouth
[19:31] <Sarvatt> looks like i need to either extend plymouth to recognize xforcevesa as well or remove splash from the cmdline if xforcevesa is used
[20:02] <Sarvatt> no luck, removing splash doesn't stop i915 from loading. hmm
[20:06] <bjsnider> is superm1 ever in here on weekends?
[20:08] <Sarvatt> verbalshadow: https://bugs.edge.launchpad.net/ubuntu/+source/apport/+bug/538097
[20:09] <Sarvatt> maybe if you ping him and ask a question he might pop up :)
[20:21] <bjsnider> are there any useful dkms logs anywhere? there's one in /var/log but it's no help
[20:26] <albert23> bjsnider: there is a full build log like  /var/lib/dkms/nvidia/kernel-2.6.31-20-generic-x86_64/log/make.log
[20:47] <bjsnider> if the build didn't happen on that kernel that directory and log do not end up existing
[20:50] <bjsnider> all i get here is exit code 6
[22:36] <Sarvatt> anyone really familiar with compiz? i'm almost positive its one of our patches breaking resoluions where one side is the same as the max texture size, 010-disable-child-window-clipping.patch maybe? it's just 1 pixel thats the problem, 2047x1152 works for instance if the max texture size is 2048
[22:37] <RAOF> I used to be a bit familiar with compiz.
[22:41] <BUGabundo> RAOF: used to ?
[22:41] <RAOF> Compiz *has* been around a while :).
[22:41] <BUGabundo> ahh
[22:41] <BUGabundo> well, before compiz we had
[22:42] <Sarvatt> we should probably adjust our max texture size checks in 060_move_checks_to_compiz.patch to max -1 though because people with 2048x1152 monitors are having all kinds of problems
[22:42] <BUGabundo> ... what was it called? ....
[22:42]  * BUGabundo blanks
[22:43] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/428769
[22:43] <Sarvatt> i want to ask those people to try a fedora livecd and see if its different because they dont have most of our compiz patches :D
[22:43] <RAOF> Which lucky bugger has a 2048x1152 monitor? :)
[22:44] <Sarvatt> lots of mac people
[22:44] <RAOF> Aaah.
[22:49] <BUGabundo> ehe
[23:39] <MarcoPau> Hello, I just put xserver-no-backfill ppa in my sources.list but I don't get anything upgraded out of it. Any hint? Using karmic
[23:40] <libv> jcristau: ?
[23:40] <MarcoPau> the xorg-server package itself is not available
[23:40] <libv> jcristau: how does this affect compatibility over the different kernel versions?
[23:41] <libv> (from a separation pov, i like the move though, this drm/libdrm stuff is a right mess)
[23:49] <libv> nah, nm my question, the compat issue is just as bad from either side of the change
[23:50] <libv> there are only two solutions to this compatibility issue anyway
[23:50] <jcristau> meh.  whoever tries to make it work with different versions can fix things up
[23:51] <libv> yes :)
[23:51] <libv> it's an issue between developer and user, and the packager is between a rock and a hard place there
[23:53] <libv> unable to satisfy both in the current constellation


[07:55] <G> hmmm interesting observation from upgrading to saucy, the lock screen is no more, only indication that the machine is locked seems to be a little triangle next to the password box
[20:10] <olly_> morning
[20:19] <ibeardslee> morning
[20:29] <mwhudson> morning
[23:19] <mwhudson> clearly instead of paying my provisional tax, i should have bought xero stock
[23:19] <G> yep, wishing I wasn't convinced out of it when they IPOed :(
[23:20] <ibeardslee> well think that now that you haven't done that you could buy more power company shares
[23:21] <ibeardslee> surely they'll go up being a valuable asset worth investing in


[00:12] <soreau> can you have your package conflict with all packages in another ppa?
[00:16] <penguin42> is it ever legal for a client to add a resource of type 0?
[00:17] <penguin42> (which I realise might be a question of an x-spec lawyer)
[00:30] <bjsnider> penguin42, yes, there are several hundred people behind bars in turkey for such offenses
[00:30] <bjsnider> soreau, i don't see how
[00:30] <soreau> bjsnider: ok thanks
[00:31]  * penguin42 looks at bjsnider curiously
[00:33] <penguin42> bjsnider: I'm looking at bug 1060059, I've got a 'fix' for it, but I was trying to understand whether the fix was the correct one
[00:33] <bjsnider> musta been the way you axed the question
[00:34] <penguin42> bjsnider: The bug is being triggered because there is a resource of type 0, and the XRes code doesn't handle the case; trivial to stop the xres code falling over, but it's not clear to me if that should ever happen
[00:34] <penguin42> bjsnider: I've added debug and I can see that AddResource is being called with a type of 0, and I just wanted to know whether that should ever happen
[00:38] <penguin42> it certainly seems odd
[10:31] <stigarn> hi sorry for the newbie question but how do I install the latest amd drivers after adding the ppa?
[22:42] <Dandel> tormod: i saw your comments on the piglit packing update... along with a few other updates.
[22:43] <tormod> hi Dandel
[22:43] <Dandel> it appears the rapid development of piglit is what caused the issue ( since the build failure is directly linked to a commit made on the 20th )
[22:44] <tormod> yeah, so does it require latest of everything to build now?
[22:45] <Dandel> yes
[22:45] <Dandel> the last 3 commits depend on this change.
[22:45] <Dandel> http://cgit.freedesktop.org/piglit/log/tests/egl/spec/egl_khr_create_context
[22:45] <Dandel> so any revision before that would have worked just fine
[22:46] <tormod> btw are you Ken?
[22:48] <tormod> do you think it would be possible to fix piglit upstream so that it builds against whatever is available?
[22:48] <tormod> i.e. #ifdef EGL_OPENGL_ES3_BIT_KHR sprinkled around?
[22:49] <Dandel> look at latest message on the bug report.
[22:49] <Dandel> it actually points to a simple fix
[22:49] <Dandel> http://bazaar.launchpad.net/~kphillisjr/piglit/trunk/revision/3391
[22:51] <tormod> aha, that's possibly where I had that idea from :) Is the first hunk meant to be there?
[22:52] <Dandel> dunno.
[22:52] <Dandel> bzr is alien to me... i prefer git.