[06:48] <pitti> Good morning
[08:00] <pitti> didrocks: did you see the vte FTBFS due to the wrong python path? can you work on this?
[08:23] <didrocks> pitti: yes, I will do it tonight
[08:24] <didrocks> Hi everybody o/
[08:25] <seb128> hello didrocks
[08:25] <seb128> didrocks: do what?
[08:28] <didrocks> seb128: vte is ftbfs du to python path changes in karmic apparently (it was building successfully in jaunty)
[08:28] <seb128> ok
[08:28] <didrocks> seb128: I did gnome-python and ready for review
[08:28] <seb128> yeah I noticed thanks
[08:29] <didrocks> seb128: for gnome-python-extras, I was wondering about one thing
[08:29] <seb128> I'm catching up with weekend emails first then will do reviews
[08:29] <didrocks> seb128: ok, we will discuss that later so :)
[08:29] <didrocks> just ping me
[08:29] <seb128> we can discuss that now
[08:29] <didrocks> ok, it was about the patch 04_use_PYTHON-config_check.patch
[08:29] <seb128> I'm just no doing review now ;-)
[08:29] <didrocks> is it still usefull?
[08:30] <didrocks> it just add checking for more than one revision of Python, right?
[08:30] <seb128> not sure what is was doing
[08:30] <seb128> that was to not hard depend on a specific python version?
[08:30] <didrocks> maybe. Without it, it's building against python 2.5 and 2.6
[08:31] <didrocks> seb128: that's why I put the merge in ~didrocks/python-gnome-extras/ubuntu
[08:31] <seb128> ok, I will have a look later
[08:31] <seb128> ideally the issue should be reported to debian if the bug is still there
[08:31] <didrocks> I just left a comment in the changelog, but didn't integrate it, waiting for some thoughts :)
[08:31] <didrocks> yes, I checked and found nothing
[08:33] <seb128> what was the rational to add the patch? it should be explained in the changelog entry?
[08:36] <seb128> lut huats
[08:36] <huats> morning everyone
[08:36] <huats> seb128hello !
[08:39] <didrocks> hello huats
[08:40] <huats> hey didrocks
[08:41] <didrocks> seb128: no, it's not, regarding the changelog, there is just: "- debian/patches/01_use_PYTHON-config_check.dpatch
[08:41] <didrocks> it's listed on a merge against debian, and nothing more :/
[08:41] <seb128> let me look
[08:41] <didrocks> ok
[08:43] <seb128> didrocks: I guess it has been added in this version https://edge.launchpad.net/ubuntu/+source/gnome-python-extras/2.14.2-1ubuntu2
[08:44] <didrocks> "acinclude.m4: Fix PYTHON_INCLUDES; run autoreconf -i
[08:44] <didrocks> ok
[08:44] <didrocks> so, I will ask doko
[08:46] <seb128> didrocks: I think it's needed to get the correct interpreter for the dbg build
[08:47] <didrocks> seb128: I don't really get it. We use python-config because the other one can't get the correct interpreter for debug packages?
[08:48] <seb128> PYTHON_INCLUDES="-I${py_prefix}/include/python${PYTHON_VERSION}"
[08:48] <seb128> is what upstream use
[08:49] <seb128> didrocks: see http://bugzilla.gnome.org/show_bug.cgi?id=448173
[08:50] <didrocks> seb128: ok, so. python-config is best to used than usual inclusion. Especially for dbg packages :)
[08:51] <didrocks> thanks ;)
[08:51] <seb128> didrocks: well, the hardcoded upstream variant doesn't have a case for dbg
[08:51] <didrocks> seb128: so, I will report a debian on GNOME bt
[08:51] <didrocks> s/debian/bug
[08:51] <seb128> don't bother with debian
[08:52] <seb128> open an upstream one, debian will get it in the next version
[08:52] <seb128> or do it if you send the change for dbg packages there
[08:52] <didrocks> yes, that's what I meant :)
[08:52] <seb128> but you might have to send some other gnome-python dbg changes before that
[08:53] <didrocks> I might have to send other dbg changes?
[08:54] <seb128> python-gnome2-extras-dbg depends on python-gnome2-desktop-dbg and there is no python-gnome2-desktop-dbg in debian
[08:55] <seb128> so gnome-python-desktop needs to get a dbg variant first
[08:55] <seb128> and gnome-python too
[08:55] <seb128> chain of depends ...
[08:55] <seb128> to get a -dbg working you need all the depends to have a -dbg variant
[08:56] <didrocks> seb128: of course. So, I have some work to do on python-gnome2-desktop :)
[08:56] <robert_ancell> seb128: pitti: can you guys tell me what I'm supposed to do about bug 372592?  I thought it was ok to SRU these changes or should I just abort it.  The SRU request is to update to the latest stable version - is this appropriate?
[08:56] <seb128> yeah, that one will not be trivial
[08:56] <seb128> they splitted everything
[08:57] <seb128> don't bother splitted the -dbg I would say
[08:57] <seb128> debian want to use one -dbg by source
[08:57] <seb128> hello robert_ancell
[08:57] <robert_ancell> seb128: morning seb
[08:57] <seb128> robert_ancell: what pitti wrote there is "use the bugs for issues fixed in this version"
[08:57] <seb128> ie bug #368252
[08:58] <seb128> or bug #366647 or bug #362820
[08:58] <robert_ancell> so I should SRU each of those?
[08:58] <seb128> use one of those for the sru
[08:58] <seb128> no, just use one of those to add the debdiff etc
[08:59] <seb128> I'm not sure why pitti has this policy now but that doesn't make much of a difference
[08:59] <seb128> rather than using the new version bug for the paper work use on the other bugs
[08:59] <seb128> open jaunty tasks for each issue the sru fix, add the debdiff to one of the bugs, subscribe ubuntu-sru to each bug
[09:00] <didrocks> seb128: ok. So, we wait for debian to do it in its own way, or do we go ahead and do it in the "ubuntu way"?
[09:00] <robert_ancell> ok. I'm a bit confused by the process though considering you can only accept the whole update or none of it.
[09:00] <seb128> didrocks: gni?
[09:01] <seb128> robert_ancell: well, each bug concerned by the upgrade need to be confirmed as fixed and not creating new issues
[09:01] <seb128> robert_ancell: what is confusing?
[09:02] <didrocks> seb128: I'm a bit confused too by the "debian want to use one -dbg by source". But that's not what we do regarding those packages. So, I just add some -dbg for gnome-python-desktop binary packages?
[09:02] <seb128> didrocks: gnome-python-desktop has been splitted in different binaries, rather than adding a -dbg for each one just do it directly the debian way, use one -dbg for the source
[09:02] <robert_ancell> seb128: if there is no core bug for the update then it seems harder to link together.  It just feels backwards
[09:03] <seb128> didrocks: that will mean less work for you and easier to get it accepted by debian
[09:03] <seb128> robert_ancell: just make any of the fixed bugs the core one
[09:03] <seb128> robert_ancell: usually one sru fixes one bug so we use this bug as the core one
[09:03] <robert_ancell> seb128: And because it is a stable update it will include fixes that we don't have tracked
[09:04] <seb128> robert_ancell: you happened to have a case where several bugs are fixed so you still do that but in extra open jaunty task for the other bugs so they can be tracked too
[09:04] <didrocks> seb128: oh ok. understood :)
[09:05] <seb128> robert_ancell: the sru procedure tries to ensure that each bug closed is properly fixed ... if you want to reduce paper work don't list all the bug numbers in the changelog but only the one you consider worth checking to make sure they work and don't break anything
[09:06] <seb128> I'm not sure where pitti he could probably give you extra details on the current procedure and why the "new version" bug is incorrect
[09:07] <didrocks> seb128: when you will have some time: I just have an issue with gnome-python-extras: running autoreconf output some cycling dependencies that I can't get fixed :/
[09:08] <seb128> what do you mean?
[09:08] <didrocks> seb128: to take into account the previous patch, I have to run autoreconf in 70_..
[09:08] <didrocks> and there, I saw some "cycling dependencies" and it failed
[09:09] <seb128> didrocks:  can you pastebin the error?
[09:10] <didrocks> seb128: let me rebuild it on my server to get it (I just didn't copy it as I was unsure if we have to autoreconf it)
[09:10] <seb128> didrocks: why do you autoreconf? autoconf should be enough for this python path thing?
[09:11] <pitti> robert_ancell: no need to add the debdiff three times, but you need to justify each bug for SRU, describe impact, testing, and regression potential, and we will ask for verification on each bug
[09:11] <pitti> robert_ancell: since the best people to tell us whether it's fixed are teh reporters/subscribers of those bugs
[09:11] <pitti> seb128: we have always had this policy
[09:11] <pitti> seb128: for hardy you just filed new bugs for new upstream microreleases when we didn't have "real" bugs in LP already
[09:12] <seb128> pitti: I've been used "new version" bugs for srus before
[09:12] <seb128> right
[09:12] <pitti> seb128: and it makes a huge difference in terms of who will read the request for testing
[09:12] <pitti> robert_ancell: if one of the bugs is not eligible for SRU, we'll reject teh entire upload
[09:12] <seb128> they will read all the request for testing anyway
[09:12] <pitti> robert_ancell: and be warned, priority: low bugs have a very small chance of being accepted
[09:12] <seb128> and I think it makes sense to do some "new version testing" too in case of new versions
[09:13] <pitti> robert_ancell: if it's not dealbreaker and causes totem to crash for every second movie, please don't SRU it
[09:13] <didrocks> seb128: autoreconf is needed for aclocal.m4 patch (and autoconf does the same, btw)
[09:13] <seb128> pitti: I think the upload is SRU worth, it makes apple trailers work again and fix some browser crasher
[09:14] <robert_ancell> pitti: I don't think I can justify each bug by the SRU guidelines (at the time one or two seemed useful).  Now it is in Karmic it seems obvious that it should be requested as a backport.
[09:14] <pitti> seb128: regressions are valid SRUs (shoudl be regression-release then)
[09:14] <seb128> don't bother with backports
[09:14] <pitti> +1 ^
[09:15] <robert_ancell> seb128: interesting thing in this case - the regression was actually caused by Apple (they changed to a tag that totem didn't understand)
[09:18] <robert_ancell> What is the position on using BZR packages now?  I was updating Glade which is not in BZR, can I create one?
[09:18] <seb128> yes, feel free to add to bzr anything desktopish
[09:18] <seb128> http://wiki.ubuntu.com/DesktopTeam/Bzr
[09:19] <robert_ancell> seb128: (I remember you saying it was still a bit experimental when we were in London so not to push all the packages into it)
[09:21] <robert_ancell> last question on my list: regarding gnome-games and clutter+libcanberra - I packaged 2.27.1 built using gstreamer and gnometris disabled.  I think we should go with that configuration for now and then decide at UDS what we do about clutter/sound.  Agree/disagree?
[09:22] <seb128> agreed
[09:22] <seb128> clutter will probably be an issue for CD space
[09:23] <robert_ancell> sure
[09:23] <didrocks> so, splitting gnome-games package?
[09:24] <robert_ancell> didrocks: I guess we have to make a special case for gnometris for Karmic - it's going to get a whole lot more interesting Karmic+1 as there will be a lot more Clutter dependent games
[09:24] <robert_ancell> what else on the desktop uses clutter?
[09:25] <didrocks> robert_ancell: yes, and with gnome-shell, at the end, it seems that we will have no choice
[09:26] <robert_ancell> those annoying gnome-games developers. Making life difficult for integrators.  Hang on... :)
[09:26] <didrocks> hehe :)
[09:26] <robert_ancell> gtg, see you guys tomorrow
[09:35] <didrocks> seb128: here it is http://paste.ubuntu.com/169387/
[09:36] <seb128> didrocks: ask to Keybuk maybe he has an idea about that
[09:40] <didrocks> seb128: ok. I'm pinging him :)
[09:47] <didrocks> pitti: I got it for vte. It's in the debian autoreconf patch that I haven't to generate. But I'm still wondering why it wasn't FTBFS in my jaunty pbuilder :/
[09:47] <pitti> didrocks: you didn't have pkgbinarymangler installed
[09:47] <pitti> it's a check in pkgsanitychecks
[09:48] <didrocks> pitti: oh, I have maybe to install it as a pbuilder hook, don't you think?
[09:49] <didrocks> pitti: is it possible to simulate it, even if I don't have rosetta? (It seems to be used for stripping translation)
[09:50] <seb128> didrocks: rosetta has nothing to do with builds
[09:50] <pitti> didrocks: no, it does more than that
[09:50] <pitti> didrocks: just install it in the pbuilder, or your local system
[09:51] <didrocks> ok, I give some test without fixing the issue to check it works at home :)
[09:58] <pitti> didrocks: just dpkg -c the .debs to check for site-packages vs. dist-packages
[10:20] <didrocks> pitti: I installed it with a hook in my pbuilder and yes, it wraps dh_builddeb (or a command that is called by it) and effectivelly, it FTBFS. I will keep this hook, thanks
[10:24] <chrisccoulson> hi seb128 - you got any updates for me to work on later? ;)
[10:24] <seb128> hello chrisccoulson
[10:25] <seb128> chrisccoulson: want to resync gnome-panel or gnome-appets on debian?
[10:25] <pitti> hey chrisccoulson, good morning
[10:25] <chrisccoulson> yeah, i can do those
[10:26] <chrisccoulson> hi pitti
[10:26] <seb128> excellent, they are for you then
[10:26] <seb128> thanks
[10:26] <chrisccoulson> you're welcome
[10:28]  * seb128 still fighting bug emails from the weekend
[10:28] <seb128> IRC and bug backlog will have taken the morning
[10:28] <seb128> and I did read and reply to email twice this weekend
[10:32] <seb128> chrisccoulson: btw I don't know if you read the backlog on friday but you should run for MOTU now ;-)
[10:33] <lool> seb128: heya!
[10:33] <lool> seb128: how is it going?
[10:33] <seb128> hello lool
[10:34] <seb128> good, lot to do as usual, and a bit too many bugs open for details to my taste but other good ;-)
[10:34] <lool> Eh
[10:34] <seb128> and you? did you have good holidays?
[10:34] <lool> Yeah, it was nice to take some break
[10:34] <lool> I'd like to discuss https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/283447 with you
[10:35] <lool> I just added the Ubuntu package task and the jaunty task
[10:35] <lool> This bug is an important issue in UNR and is fixedin metacity 2.26.0
[10:35] <lool> Do you mind if we move to 2.26.0 in karmic and jaunty?
[10:35] <lool> Is anything preventing this update?
[10:35] <seb128> no, just somebody having interest for the software
[10:36] <seb128> I'm using compiz so didn't really bother and nobody else picked up on the task, talk to pitti perhaps about jaunty
[10:36] <seb128> it's probably better to backport the change there than to update to a new version
[10:36] <lool> seb128: So new version in karmic and backported fix in jaunty; will talk to pitti then, thanks!
[10:37] <seb128> new version in karmic without any doubt
[10:37] <pitti> lool: you need this to be an ubuntu sru for UNR?
[10:37] <lool> pitti: Correct
[10:37] <pitti> hmkay
[10:37] <lool> pitti: UNR being Ubuntu jaunty's UNR
[10:37] <lool> pitti: UNR is really in Ubuntu now
[10:37] <pitti> yeah, understood
[10:44] <chrisccoulson> hi seb128 - i did see your conversation with dholbach on friday
[10:44] <chrisccoulson> i'll hopefully get around to applying this week if you think i should:)
[10:46] <seb128> you should!
[10:46]  * pitti puts on the "Chris Coulson for Pres^WMOTU!" badge
[10:47] <seb128> ;-)
[10:54] <seb128> ok, time for some sponsoring now
[11:08] <lool> Ah mvo is in holidays
[11:09] <seb128> is he?
[11:09] <lool> Yeah, whole week it seems
[11:09] <seb128> we really need a VAC calendar we can add to e-d-s ;-)
[11:09] <lool> "update-manager -c -d" works on my desktop but doesn't on a jaunty UNR install
[11:14] <lool> ah was just flaky network
[12:39] <crevette> hello, I've a small question how daniel did check there were missing files in https://bugs.edge.launchpad.net/ubuntu/+source/bluez/+bug/372428 ?
[12:40] <crevette> and furthermore, what the the test I should conduct to validate I don't break things
[12:42] <Hobbsee> crevette: it's --list-missing as a switch, but i don't remember which tool it is.  it's dpkg-something
[12:42]  * crevette tries dpkg-something :)
[12:43] <crevette> dpkg-something should be a wrapper for all dpkg* tools :)
[13:14] <pitti> Hobbsee, crevette: you mean dh_install --list-missing ?
[13:14] <Hobbsee> pitti: yeah, that sounds right!
[13:15] <crevette> pitti, is it possible to have it run in pbuilder in order to have a report at the end of the build ?
[13:15] <pitti> crevette: you can certainly run it in debian/rules
[13:16] <pitti> crevette: cdbs has an utils.mk for list-missing, too
[13:16] <crevette> okay, I'll try tht, thanks
[13:22] <chrisccoulson> is there any way of making dh_install --list-missing useful for packages that build multiple binaries? the last time I tried, it listed the missing files for each binary package in turn, and considered all files installed in one of the other binaries as missing for that particular package
[13:23] <pitti> chrisccoulson: that works fine for me
[13:24] <pitti> chrisccoulson: you just can't invoke it with -p, obviously
[13:25] <chrisccoulson> pitti - thanks. i'll try again next time i need to do that and see if it works
[13:26] <seb128> it doesn't work for multi-build packages, ie when you don't  install to debian/tmp for example
[13:27] <seb128> ie that doesn't work for python packages which build for multiple version or for gtk+ which has a static, etc build
[13:33] <chrisccoulson> thanks seb128. i think the last package i tried it on was tracker, and it didn't seem to work too well for that. i'll try it again as i'm looking at the 0.7.x packaging at the moment anyway and it would be useful for that
[13:52]  * kenvandine_wk hopes this morning isn't a bad time to update :)
[14:01] <pitti> kenvandine: not worse than any other morning :)
[14:01] <kenvandine> hehe
[14:01] <kenvandine> it worked
[14:01] <kenvandine> pitti: did you get a share request from me today?
[14:01] <pitti> kenvandine: by mail? no
[14:01] <kenvandine> ok
[14:02] <kenvandine> any idea why there is kde stuff in my updates?
[14:02] <pitti> oh?
[14:02]  * kenvandine doesn't think he installed anything kde related :)
[14:02] <pitti> what in particular?
[14:02] <kenvandine> kdebase stuff
[14:02] <pitti> might be a wrong new dependency
[14:02] <kenvandine> that is what i am wondering
[14:02] <pitti> kenvandine: if you just do apt-get upgrade, what does it hold back?
[14:02] <kenvandine> let me try to remove it :)
[14:03] <pitti> kenvandine: oh, it wanted to _upgrade_ kdebase, not newly install it?
[14:03] <kenvandine> not sure, i was using update manager
[14:03] <kenvandine> not apt-get
[14:03] <kenvandine> not sure if it is easy to tell there
[14:04] <pitti> don't think so
[14:04] <seb128> pitti: do you have an opinion on code logic copy and copyright assignment?
[14:04] <seb128> pitti: ie gnotes being a tomboy copy in c++ ... should the copyright list the tomboy authors?
[14:04] <pitti> seb128: context?
[14:04] <pitti> seb128: it's a total code rewrite?
[14:04] <kenvandine> The following packages have been kept back:
[14:04] <kenvandine>   f-spot gksu kdebase-runtime kdebase-runtime-bin-kde4 kdebase-workspace-dev kdebase-workspace-libs4+5 kdelibs-bin kdelibs5 kdelibs5-data kdelibs5-dev khelpcenter4
[14:04] <kenvandine>   libkdecorations4 libkrb5-dev libkwineffects1 libltdl7 libphonon-dev libphonon4 libplasma3 libqt4-assistant libqt4-core libqt4-dbus libqt4-designer libqt4-dev libqt4-gui
[14:04] <kenvandine>   libqt4-help libqt4-network libqt4-opengl libqt4-opengl-dev libqt4-qt3support libqt4-script libqt4-scripttools libqt4-sql libqt4-sql-mysql libqt4-svg libqt4-test
[14:04] <kenvandine>   libqt4-webkit libqt4-xml libqt4-xmlpatterns libqtcore4 libqtgui4 libstartup-notification0 libstartup-notification0-dev linux-generic linux-headers-generic
[14:05] <seb128> they basically take tomboy and copy line by line translating to c++
[14:05] <kenvandine>   linux-image-generic linux-restricted-modules-generic openoffice.org-base-core openoffice.org-calc openoffice.org-common openoffice.org-core openoffice.org-draw
[14:05] <kenvandine>   openoffice.org-gnome openoffice.org-gtk openoffice.org-impress openoffice.org-math openoffice.org-style-human openoffice.org-writer phonon phonon-backend-gstreamer
[14:05] <seb128> kenvandine: grrrrr
[14:05] <kenvandine>   python-uno qt4-qmake qt4-qtconfig
[14:05] <kenvandine> whoops
[14:05] <seb128> kenvandine: use pastebin please
[14:05] <kenvandine> it was 2 lines :)
[14:05] <kenvandine> sort of ... sorry
[14:05] <pitti> seb128: hm, no idea I'm afraid; would certainly at least be nice to credit them
[14:05] <seb128> update-manager doesn't install new packages or remove other binaries
[14:06] <pitti> seb128: "system upgrade" does, though
[14:06] <seb128> it does new installs but no removals
[14:06] <kenvandine> i must have something installed that brought it in as a dep
[14:06] <james_w> pitti: it's basically a line-by-line port for a lot of it. The tomboy authors didn't add headers to many of their files. Where they did they are preserved, but the other files only state (C) new author, which seems a bit wrong
[14:08] <seb128> kenvandine: what is the question?
[14:08] <pitti> james_w: I agree; even if it's legal, it's at least nasty
[14:08] <kenvandine> seb128: i was just wondering if there as a bad dep bringing in new packages... or if it was something i had installed
[14:08] <james_w> pitti: I don't see it as a reason to keep it out the archive though?
[14:08] <kenvandine> just did an update today in karmic
[14:08] <kenvandine> seb128: just verifying there wasn't a bug
[14:09] <kenvandine> morning rickspencer3
[14:09] <seb128> kenvandine: your log lists kept back packages
[14:09] <seb128> hello rickspencer3
[14:09] <pitti> james_w: that'd require a lawyer, I'm afraid
[14:09] <kenvandine> seb128: that was just answering pitti's question
[14:09] <rickspencer3> good morning kenvandine, seb128, pitti
[14:09] <pitti> hey rickspencer3
[14:10] <seb128> kenvandine: oh ok, I read the backlog, try to apt-get remove those and see what else get uninstalled, could be a recommends which triggered those
[14:10] <kenvandine> yeah
[14:11] <seb128> but it's easier to track that before clicking yes
[14:11] <james_w> pitti: ok, how should I proceed?
[14:11] <pitti> james_w: perhaps ask elmo? he's got much more license/copyright experience than me
[14:12] <james_w> pitti: ok, I'll mail him and CC ubuntu-archive?
[14:12] <pitti> james_w: sounds good
[14:12] <james_w> thanks
[14:13] <james_w> pitti: also, there is a linux-ports-meta in the queue. Would you have a few minutes sometime today to walk me through that, or to process it yourself?
[14:13] <james_w> seb128 is scared of the kernel ;-)
[14:13] <seb128> indeed!
[14:13]  * kenvandine needs more coffee... bbiaf
[14:14] <Ampelbein> seb128: hi. thanks for the little correction on the gnome-utils patch. however, i get failed builds on sparc, hppa and armel. on sparc and armel it's because of the "warnings treated as errors" and some sloppy program code. but on hppa it reruns autoreconf for some reason and configure fails with a syntax error. See http://launchpadlibrarian.net/26573002/buildlog_ubuntu-karmic-hppa.gnome-utils_2.27.1-0ubuntu1_FAILEDTOBUILD.txt.gz for
[14:14] <Ampelbein> this.
[14:22] <seb128> Ampelbein: I would not bother about the hppa case for now but working on an update not using -Werror would be useful
[14:22] <seb128> Ampelbein: the hppa case is probably a timestamp issue and autotools installed on the buildd machine, a retry on a clean install will probably work
[14:33] <Ampelbein> seb128: how do i disable -Werror ? should i just pass '-Wno-error=*' to CFLAGS in debian/rules? i can't find where -Werror is defined in the first place.
[14:41] <seb128> Ampelbein: configure.ac:        MAINTAINER_CFLAGS="-Werror -Wall -Wshadow -Wcast-align -Wno-uninitialized -Wformat-security -Winit-self"
[14:42] <Ampelbein> seb128: ah, there it is. thanks. should i do a ubuntu2 for this?
[14:42] <seb128> Ampelbein: I guess editing that line in the configure and updating autoconf should work
[14:42] <seb128> Ampelbein: yes
[14:42] <Ampelbein> ok will do
[14:42] <seb128> thanks
[14:56] <jbailey> pitti, What's mvo's excuse this time? ;)
[14:56] <jbailey> Hi all ;)
[14:57] <pitti> jbailey: he's on holiday
[14:57] <seb128> he's on holidays for the week apparently
[14:57] <jbailey> Bah! =)
[14:57] <seb128> you can try dropping him an email though ;-)
[14:57] <jbailey> Ah well.  /me sits on his hands and waits.
[14:57] <jbailey> Nah, if he's on holidays I don't want to bug him.
[14:58] <seb128> I'm not sure how good he's at not readin email during holidays ;-)
[14:58] <jbailey> Most Canonical people are terrible at the best of times.
[14:58] <jbailey> Having an email from a friend show up is almost a guarantee that it would get read.
[15:05] <Ampelbein> seb128: bug 374889, branch linked.
[15:06] <seb128_> ok
[15:35] <Ampelbein> seb128: i think gnome-utils just got worse... now it even fails on i386 with the "syntax error" after rerunning autoconf on the build-daemon. See http://launchpadlibrarian.net/26586210/buildlog_ubuntu-karmic-i386.gnome-utils_2.27.1-0ubuntu2_FAILEDTOBUILD.txt.gz
[15:36] <seb128> Ampelbein: right
[15:36] <seb128> I hate autotools
[15:36] <Ampelbein> seb128: is this my fault?
[15:37] <seb128> define "your" there ;-)
[15:37] <seb128> it's a bug in the package yes
[15:37] <Ampelbein> it worked on pbuilder so this must be a race condition.
[15:37] <seb128> it is
[15:37] <seb128> the autotools try to be clever
[15:38] <seb128> if some timestamps are never than others they run autoconf or automake for you
[15:38] <seb128> never -> newer
[15:40] <jbailey> seb128, autotools are cuddly.
[15:40] <jbailey> But AM_MAINTAINER_MODE was wired backwards, and is useless.
[15:40] <seb128> how do you ensure that autotools are not ran in such cases?
[15:40] <jbailey> It should always be in there, disabled by default, and be an option that you pass to configure.
[15:41] <jbailey> If I weren't totally apathetic, I would write a patch for that.
[15:41] <seb128> $ grep am-maintainer configure.ac
[15:41] <seb128> $
[15:42] <Ampelbein> debian/rules passes --disable-maintainer-mode to configure already. but that option is not recognized.
[15:42] <jbailey> Hah, apparently I wrote an LJ article once ranting about this.
[15:42] <seb128> right
[15:42] <seb128> the modern autotools version don't seem to understand the option
[15:44] <seb128> in fact no
[15:44] <jbailey> seb128, It's still in Hardy.
[15:44] <seb128> configure.ac should have a AM_MAINTAINER_MODE and autoconf should be run
[15:44] <jbailey> AC_PREREQ(2.61)
[15:44] <jbailey> AC_INIT(FULL-PACKAGE-NAME, VERSION, BUG-REPORT-ADDRESS)
[15:44] <jbailey> AC_CONFIG_SRCDIR([main.cc])
[15:44] <jbailey> AC_CONFIG_HEADER([config.h])
[15:44] <jbailey> AM_MAINTAINER_MODE
[15:44] <jbailey> Bah, never run autoconf on it's own.
[15:44] <seb128> aclocal; autoconf
[15:44] <jbailey> "autoreconf -f -i -s" is your friend. =)
[15:44] <seb128> I hate autoreconf
[15:45] <jbailey> Why?
[15:45] <seb128> it makes a some hundred kbs patch where autoconf does a 25 liners
[15:45] <seb128> I don't need all the Makefile.in to be updated for a configure change
[15:45] <jbailey> Well, those other changes are probably bug fixes and the like, though.
[15:46] <jbailey> And the size of the patch isn't a big deal once you have AM_MAINTAINER_MODE in there, because then you don't have to worry about spurious rebuilds on top of that.
[15:46] <seb128> right, it just makes updates hard to review
[15:48] <seb128> AM_MAINTAINER_MODE should be the default mode in any tarball
[15:48] <seb128> I just don't see the point of that clever timestamp magic
[15:48] <seb128> usually you either want to build using ./configure && make or you want to run autogen.sh and you do that
[15:49] <pitti> it's useful for an upstream if you change Makefile.am
[15:49] <pitti> then you do make and it DTRT
[15:49] <seb128> well, make dist should switch maintainer mode on
[15:50] <pitti> +1
[15:51] <jbailey> seb128, the problem is that then a user has to remember one more thing when trying to figure out what's happening.
[15:52] <jbailey> So they either then edit the Makefile directly and lose their changes, or they edit the Makefile.{am,in} and nothing happens.
[15:52] <jbailey> If the use wants to touch that *and* has autotools installed, it does the right thing.
[15:52] <seb128> it's just annoying to have to patch the configure.ac and have to run autoreconf to be able to use the configure option
[15:53] <jbailey> You're arguing against yourself there.
[15:53] <jbailey> That's what maintainer mode kills.
[15:53] <jbailey> Right now you don't have to.  Just edit configure.ac, it will notice that it's newer, regenerate the configure script, rerun it, and go.
[15:54] <seb128> I'm not arguing against myself
[15:54] <seb128> I want to tell autotools that I know what I'm doing and that they should try to be clever because that's just buggy
[15:54] <jbailey> What I think would be useful is leaving that by default, but having an option to say --disable-maintainer-mode which says don't detect the timestamps, I know what I'm doing.
[15:54] <seb128> but for that I need to patch configure.ac and run autoreconf which is annoying
[15:55] <seb128> right
[15:55] <jbailey> Just edit configure.ac, and it will do the right thing when you're hacking on the code.
[15:55] <jbailey> The only time you have a problem is when you're patching configure directly.
[15:55] <seb128> I'm not hacking on the code, I'm uploading to a buildd which should not have autoconf installed
[15:55] <jbailey> Something that the system isn't built for.
[15:55] <jbailey> Right.  The buildds don't.
[15:55] <jbailey> It's on your dev machine that's a problem.
[15:55] <jbailey> You have it installed, and you're editting a file you're never supposed to touch.
[15:56] <seb128> I'm not
[15:56] <jbailey> It's like binary patching make on the build system.  You're not supposed to do it.
[15:56] <jbailey> You're not patching configure?
[15:56] <seb128> I'm having a autoreconf patch in my series
[15:56] <jbailey> or Makefile{.in}
[15:56] <seb128> I'm not touching it manually, I run autoreconf and put the diff in a patch
[15:56] <seb128> the issue is the timestamp after patch apply
[15:56] <jbailey> Doesn't matter.  Something other than autoconf on the current system is touching it.
[15:56] <jbailey> It's not designed for that.
[15:56] <seb128> you have to list the changes in the right order in the patch
[15:57] <seb128> right
[15:57] <seb128> I'm not arguing that
[15:57] <seb128> I just say it's annoying it's not decided to do what I want ;-)
[15:57] <jbailey> Eheh
[15:57] <seb128> decided -> designed
[15:58] <seb128> sometimes I wonder if we should just run autoreconf on the buildds
[15:58] <jbailey> No!
[15:58] <seb128> rather than having autoreconf patches
[15:58] <jbailey> CDBS has an option for that and it's *horrible*
[15:58] <jbailey> I tried to convince duck not to put it in.
[15:58] <jbailey> Then you have no clue what the buildd built.
[15:58] <seb128> cdbs is buggy according to Keybul
[15:58] <seb128> Keybuk
[15:58] <jbailey> Sure, it's software.  Of course it's buggy. =)
[15:58] <seb128> it tries to run autotools in a smart way rather than using autoreconf simply
[15:58] <jbailey> Keybuk, You're wrong. =)
[15:59] <jbailey> autoreconf means that you lose reproducability of builds.
[15:59] <jbailey> Unless you keep all the build-deps around as long as the binary is still around, you can't reproduce the build reliably.
[15:59] <jbailey> Debian/Ubuntu builds aren't hermetic, you have to draw a matrix of all the pieces in order to get a build.
[16:00] <jbailey> That's a hassle as it is without the actual code for something changing underneath you.
[16:00] <seb128> we need build system for human beings ;-)
[16:00] <jbailey> I really really believe that AM_MAINTAINER_MODE([false]) should be the default, and then always done.
[16:00] <seb128> right, I would like this one
[16:00] <jbailey> This is for humans - we're the ones who have to debug the damned things after.
[16:01] <seb128> if would mean you just have to add the configure option to the rules
[16:01] <seb128> if -> it
[16:01] <jbailey> No, I would then make that *always* the default in all autoconf builds.
[16:01] <jbailey> BEcause it has no side effects if not chosen.
[16:01] <jbailey> But then people who need to stop moving parts always have the option.
[16:01] <jbailey> Lagging, phone.
[16:01] <seb128> right, which is what I was saying no?
[16:02] <Keybuk> jbailey: you're wrong.
[16:02] <seb128> you could just add the configure option to the rules if required
[16:02] <jbailey> Keybuk, Bah!
[16:02] <jbailey> seb128, Then packagers all need to patch the source.  Make it the default.
[16:02] <seb128> right
[16:02] <Keybuk> jbailey: autoreconf is a tool to run autoconf, autoheader, automake, aclocal, libtoolize and autopoint in THE RIGHT ORDER
[16:03] <Keybuk> and re-run them where it is sometimes necessary
[16:03] <Keybuk> cdbs does not use it
[16:03] <Keybuk> instead cdbs has a hardcoded order that isn't even correct for the common case
[16:03] <jbailey> Keybuk, Right.  And that should never be required at build time where the goal is a reproducable build.
[16:03] <Keybuk> this has nothing to do with build reproducability
[16:03] <jbailey> Keybuk, Oh, we're arguing different things.
[16:03] <jbailey> Right, cdbs shouldn't call those individually; it shouldn't call them at all.
[16:04] <Keybuk> no, you're arguing the wrong thing
[16:04] <Keybuk> cdbs does call those things today
[16:04] <Keybuk> and that is the bug
[16:04] <jbailey> But if it's going to autoreconf is the right thing.
[16:04] <Keybuk> correct
[16:04] <jbailey> s/to/to,/
[16:05] <Keybuk> though the differing opinions on AM_MAINTAINER_MODE shall stay different ;)
[16:06] <Keybuk> personally I like to just let "make" invoke autoconf/automake as necessary, and have them as build-deps
[16:06] <Keybuk> since then I only need to patch Makefile.am in debian/patches
[16:06] <seb128> but you don't have predictable builds
[16:06] <Keybuk> really?
[16:06] <seb128> ie things which used to work break because new autotools version have been uploaded
[16:06] <seb128> ie libtool 1.5 to libtool 2
[16:06] <Keybuk> you ship the exact versions of "make", "gcc", "ld", etc. that you tested with in the package?
[16:07] <jbailey> Keybuk, for that it's a matter of track record. =)
[16:07] <seb128> no, but I had a lot higher of issue with autoreconf runs than with normal make
[16:07] <Keybuk> I'd argue that auto-*'s track record over the past decade has been excellent
[16:07] <pitti> seb128 +1
[16:07] <Keybuk> the problem has been that Debian stalled updating things like automake because of it's previously terrible track record
[16:07] <Keybuk> which meant that packages got stuck using the broken versions
[16:07] <seb128> maintainers have not being excellent at writting correct configure.ac though
[16:08] <Keybuk> not so much
[16:08] <seb128> and old version of autotools have sometime but better at handling those
[16:08] <Keybuk> the real problem was that there had to be a flag day where all new versions would be forwardly compatible
[16:08] <seb128> but -> be
[16:08] <Keybuk> but where the version you were currently on wasn't
[16:08] <Keybuk> and the trouble is people stuck at the "wasn't" version for a long time
[16:08] <Keybuk> autoconf 2.50, automake 1.6 and libtool 2.0 are intended to always be forwardly compatible
[16:08] <Keybuk> sure, there have been bugs, but they have fixed tghose
[16:09] <didrocks> seb128: +1 too with the number of issues :)
[16:09] <jbailey> Keybuk, I'd give the success rate in the 4-5 year range more than the last decade.
[16:09] <seb128> the issue is that most maintainer don't understand autotools and just copy bits from other softwares
[16:09] <jbailey> So we're getting into the realm where people are getting off of the crappy versions.
[16:09] <Keybuk> jbailey: I think you'd be surprised if you actually checked when versions were actually released ;)
[16:09] <seb128> so you have broken code copied all over the place and nobody knowing how to fix it
[16:09] <jbailey> seb128, The same could be argued for their C code.
[16:09] <jbailey> Keybuk, I'm thinking Gnome in particular when I left Canonical still had a number of packages using Automake 1.4
[16:10] <Keybuk> seb128: nobody affiliated with GNOME can use *that* argument ;)
[16:10] <seb128> jbailey: the maintainer are usually keen at fixing their code bugs, not so much at fixing autotools ;-)
[16:10] <Keybuk> since GNOME programming entirely consists of copying other people's code
[16:10] <seb128> lol
[16:11] <didrocks> troll detected :)
[16:11] <jbailey> didrocks, Yeah, but we like Séb.
[16:11] <jbailey> ;)
[16:11] <seb128> I'm troll proof no worry
[16:12] <didrocks> well.. hopefully we have Keybuk for fixing all the autotool errors we don't understand (did you have any success with mine? ;)) :p
[16:12] <Amaranth> my autofoo is copied from other places
[16:12] <jbailey> didrocks, #autotools as well. =)
[16:12] <Amaranth> almost 100% of it
[16:13] <Amaranth> I kind of know what it means
[16:13] <didrocks> jbailey: hum, next time, I will bother people there too ^^
[16:13] <jbailey> didrocks, Sure.  We have a surprising number of people come in there.
[16:13] <jbailey> For a channel we created a month or so ago and didn't tell anyone about. =)
[16:13] <seb128> lol
[16:13] <Amaranth> I suspect they were going there before and finding it didn't exist before
[16:16] <didrocks> jbailey: :)
[16:16] <didrocks> I think I will idling there ^^
[16:17] <Keybuk> though it'd be nice to get things like intltool and gtk-doc-tool into autoreconf
[16:17] <Keybuk> or at least make it locally extensible
[16:17] <Keybuk> so people don't continue to ship autogen.sh
[16:17] <seb128> right
[16:28] <seb128> Ampelbein: did you follow the discussion, ie do you know what to change to avoid the build issue?
[16:32] <Ampelbein> seb128: although i have to reread the discussion again to understand it completely, I take it that I have to add AM_MAINTAINER_MODE to configure.ac, rerun autoreconf and I'm done?
[16:32] <jbailey> Keybuk, Do an extensibility mechanism in autoconf and have autoreconf pull that out with a trace.
[16:32] <seb128> Ampelbein: right, autoconf should be enough, just update the autotools patch you have
[16:34] <Ampelbein> seb128: ok, will do
[16:35] <Ampelbein> seb128: is it enough to just request a merge of the branch or should i open a new sponsoring bug?
[16:35] <seb128> Ampelbein: just update your bzr and ping me about it when it's done
[16:35] <Ampelbein> ok
[16:53] <chrisccoulson> hey pitti, i see you've done some hal updates today. would you mind having a look at a patch i wrote to fix a hald crash? (it's in a branch proposed for merging in to ubuntu-core-dev)
[16:56] <pitti> chrisccoulson: sure; I'd commit it upstream, though
[16:56] <pitti> chrisccoulson: I wonder why I didn't get a merge request mail
[16:57] <pitti> chrisccoulson: perhaps you can mail me the URL to the MP, and I'll get to it ASAP?
[16:57] <chrisccoulson> i sent the patch upstream but the bug report it's attached to is fairly quiet
[16:58] <chrisccoulson> i don't think i added you as a reviewer for the merge request. i'll mail you the URL to that shortly anyway. i have to dash now to go home
[16:59] <pitti> chrisccoulson: yeah, hal patches are better on the upstream ML, nobody looks at bz, I'm afraid
[17:02] <asac> pitti: so i attached a patch for the almost dead modem fdi ;) ... bug 374970
[17:02] <asac> hope i didnt sumit that before (had it in my inbox for a week or so)
[17:02] <asac> submit
[17:04] <pitti> asac: heh, thanks
[17:05] <Ampelbein> seb128: branch https://code.edge.launchpad.net/~amoog/gnome-utils/devel updated
[17:06] <seb128> ok
[17:27] <seb128> Ampelbein: you forgot to bzr add the new change?
[17:30] <Ampelbein> seb128: arghs. yes.
[17:30] <Ampelbein> seb128: change pushed.
[17:35] <seb128> Ampelbein: did you check that's it's working?
[17:35] <seb128> Ampelbein: I mean the change, the bzr is updated now
[17:41] <Ampelbein> seb128: how do i check this? i tried touching Makefile.am in clean virtualboxenvironment which should provoke invocation of the autotools, right? and it did not autoreconf on building.
[17:41] <seb128> you need to touch it after the autotools change
[17:41] <seb128> try adding a patch after that one which edit the Makefile.am or touch it in the rules
[18:01] <Ampelbein> could it be that the latest cdbs in ubuntu broke it? i get http://paste.ubuntu.com/169803/ using 0.4.56ubuntu2, with ubuntu1 it works as expected
[18:02] <seb128> weird
[18:02] <pitti> latest cdbs just fixed a corner case in cdbs-edit-patch
[18:04] <Ampelbein> pitti: give me a minute, i will provide terminal-logs of new version and ubuntu1.
[18:10] <Ampelbein> pitti: 0.4.56ubuntu1: http://paste.ubuntu.com/169805/ , 0.4.56ubuntu2: http://paste.ubuntu.com/169808/
[18:12] <Ampelbein> pitti: do you need more info? if so, just tell me and i happily provide it.
[18:14] <pitti> Ampelbein: ah, that would be my change, indeed
[18:16] <Ampelbein> pitti: is it anything wrong with my pathnames or anything else where I did something unusual?
[18:17] <pitti> Ampelbein: no, I just screwed up; I'm at it
[18:22] <pitti> Ampelbein: uploaded; sorry!
[18:23] <Ampelbein> pitti: i guess there is no need to be sorry. thanks for fixing it so fast.
[18:23] <didrocks> I'm screwing vte. I can't find why it is choosing site-packages and doko isn't here!
[18:23] <didrocks> I will still fight a little :)
[18:28] <pitti> didrocks: you call setup.py install with --install-layout=deb ?
[18:29] <pitti> that shuold fix it
[18:29] <didrocks> pitti: there is no setup.py call
[18:29] <pitti> didrocks: that would be it then
[18:30] <pitti> didrocks: use dh_install to install debian/tmp/.... site-packages to dist-packages
[18:30] <didrocks> pitti: yes, that's what I read in doko's post
[18:30] <pitti> anyway, /me waves goodbye, Taekwondo time
[18:30] <pitti> see you tomorrow!
[18:30] <didrocks> pitti: see you tomorrow ;)
[18:41] <chrisccoulson> nice spam from ubuntu-devel list today :/
[18:57] <asac> lool: http://launchpadlibrarian.net/26594087/buildlog_ubuntu-karmic-amd64.gtk%2B2.0_2.16.1-0ubuntu4~asac~k_FAILEDTOBUILD.txt.gz ...
[18:57] <asac> cp: cannot stat `./debian/install/directfb/usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so': No such file or directory
[18:57] <asac> dh_install: cp returned exit code 1
[18:58] <asac> lool: do you see anything in the build log that would prevent that lib from ending up there?
[18:58] <asac> (that worked on all bug amd64)
[18:59] <asac> but
[19:05] <rickspencer3-afk> awe: hi
[19:06] <rickspencer3> oops, I've had the wrong nick for over two hours!
[19:11] <awe> rickspencer3: hey
[19:11] <awe> ;)
[19:11] <rickspencer3> awe: I saw your mail
[19:11] <awe> cool, i just read your reply
[19:11] <rickspencer3> you should keep in mind that I am a complete hard ass
[19:11] <rickspencer3> ;)
[19:12] <rickspencer3> ask any one here
[19:12] <awe> that's nice to hear!
[19:12] <rickspencer3> :)
[19:12] <awe> I'm having fun with merges today.
[19:12] <rickspencer3> awe: seriously, it sounds like things are going well, and you can't do better than to work with asac, he's made of awesome
[19:13] <rickspencer3> hehe
[19:13] <awe> cool.  we know each other well, so I'm glad we finally get a chance to work together
[19:13] <rickspencer3> also, pitti is the tech lead for the desktop team, so you should feel free to ask him any questions as well
[19:14] <awe> sounds good.  as i mentioned before, we've played guitar together at a few of our UDS/AllHands jams, so I know pitti well too...
[19:14] <awe> looking forward to working with everyone!
[19:59] <lool> asac: checking pixbuf loaders to build...
[19:59] <lool> checking if gio can sniff png... no
[19:59] <lool> This might be the issue
[20:18] <asac> lool: hmm thanks ... but it builds the -png builder from what i saw.
[20:18] <asac> lool: odd. was temporarily. i made a new upload and now it worked ;)
[20:18] <asac> great
[20:20] <lool> asac: Not too reassuring   :-/
[21:12] <Ampelbein> seb128: welcome back. i updated the gnome-utils branch, lp:~amoog/gnome-utils/devel
[21:12] <seb128> Ampelbein: hey, did you manage to test the issue?
[21:13] <Ampelbein> seb128: yeah. but i had to run autoreconf after the AM_MAINTAINER_MODE change, it did not work with just running autoconf.
[21:13] <seb128> oh ok
[21:13] <Ampelbein> and cdbs has been updated, ubuntu3 works as expected now.
[21:14] <seb128> I've noticed the update
[21:24] <jbailey> Amaranth, AM_MAINTAINER_MODE requires the whole set to be run, yes.
[21:24] <jbailey> It's quite invasive.
[21:24] <jbailey> But after that, the right things should happen.
[21:27] <Nafallo> jbailey: wow. you're alive... :-)
[21:27] <Nafallo> jbailey: hi
[21:28] <jbailey> Nafallo, Still moving.  There were some iffy moments, but.. =)
[21:28] <jbailey> Meeting in 90 seconds, back in 30 minutes.
[21:28] <Nafallo> heha
[21:28] <Nafallo> ehrm
[21:28] <Nafallo> hehe
[21:36] <lool> asac: BTW I uploaded a gtk+2.0 fixing the missing --build and --host; do you plan an ia32libs uplaod for A1?
[21:36] <asac> lool: yes. bug 369498 fix will land soon
[21:37] <asac> did the patches today. just want to verify gio too
[21:37] <lool> Cool, thanks
[21:37] <lool> asac: You might have to revert the jaunty triplet changes
[22:19] <seb128_> Ampelbein: do you still have work on your list or are you looking for other updates?
[22:20] <Ampelbein> seb128_: i could do other updates now. otherwise i would just look on MoM to find me some work ;-)
[22:21] <seb128_> Ampelbein: eog is to merge on debian and update to 2.27.1 if you want
[22:22] <Ampelbein> seb128_: ok, doing that one