=== ember_ is now known as ember [06:48] Good morning [08:00] didrocks: did you see the vte FTBFS due to the wrong python path? can you work on this? [08:23] pitti: yes, I will do it tonight [08:24] Hi everybody o/ [08:25] hello didrocks [08:25] didrocks: do what? [08:28] seb128: vte is ftbfs du to python path changes in karmic apparently (it was building successfully in jaunty) [08:28] ok [08:28] seb128: I did gnome-python and ready for review [08:28] yeah I noticed thanks [08:29] seb128: for gnome-python-extras, I was wondering about one thing [08:29] I'm catching up with weekend emails first then will do reviews [08:29] seb128: ok, we will discuss that later so :) [08:29] just ping me [08:29] we can discuss that now [08:29] ok, it was about the patch 04_use_PYTHON-config_check.patch [08:29] I'm just no doing review now ;-) [08:29] is it still usefull? [08:30] it just add checking for more than one revision of Python, right? [08:30] not sure what is was doing [08:30] that was to not hard depend on a specific python version? [08:30] maybe. Without it, it's building against python 2.5 and 2.6 [08:31] seb128: that's why I put the merge in ~didrocks/python-gnome-extras/ubuntu [08:31] ok, I will have a look later [08:31] ideally the issue should be reported to debian if the bug is still there [08:31] I just left a comment in the changelog, but didn't integrate it, waiting for some thoughts :) [08:31] yes, I checked and found nothing [08:33] what was the rational to add the patch? it should be explained in the changelog entry? [08:36] lut huats [08:36] morning everyone [08:36] seb128hello ! [08:39] hello huats [08:40] hey didrocks [08:41] seb128: no, it's not, regarding the changelog, there is just: "- debian/patches/01_use_PYTHON-config_check.dpatch [08:41] it's listed on a merge against debian, and nothing more :/ [08:41] let me look [08:41] ok [08:43] 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] "acinclude.m4: Fix PYTHON_INCLUDES; run autoreconf -i [08:44] ok [08:44] so, I will ask doko [08:46] didrocks: I think it's needed to get the correct interpreter for the dbg build [08:47] 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] PYTHON_INCLUDES="-I${py_prefix}/include/python${PYTHON_VERSION}" [08:48] is what upstream use [08:49] didrocks: see http://bugzilla.gnome.org/show_bug.cgi?id=448173 [08:49] Gnome bug 448173 in general "use python-config to get python includes" [Normal,Resolved: fixed] [08:50] seb128: ok, so. python-config is best to used than usual inclusion. Especially for dbg packages :) [08:51] thanks ;) [08:51] didrocks: well, the hardcoded upstream variant doesn't have a case for dbg [08:51] seb128: so, I will report a debian on GNOME bt [08:51] s/debian/bug [08:51] don't bother with debian [08:52] open an upstream one, debian will get it in the next version [08:52] or do it if you send the change for dbg packages there [08:52] yes, that's what I meant :) [08:52] but you might have to send some other gnome-python dbg changes before that [08:53] I might have to send other dbg changes? [08:54] python-gnome2-extras-dbg depends on python-gnome2-desktop-dbg and there is no python-gnome2-desktop-dbg in debian [08:55] so gnome-python-desktop needs to get a dbg variant first [08:55] and gnome-python too [08:55] chain of depends ... [08:55] to get a -dbg working you need all the depends to have a -dbg variant [08:56] seb128: of course. So, I have some work to do on python-gnome2-desktop :) [08:56] 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] Launchpad bug 372592 in totem "Update to Totem 2.26.2" [Wishlist,Fix released] https://launchpad.net/bugs/372592 [08:56] yeah, that one will not be trivial [08:56] they splitted everything [08:57] don't bother splitted the -dbg I would say [08:57] debian want to use one -dbg by source [08:57] hello robert_ancell [08:57] seb128: morning seb [08:57] robert_ancell: what pitti wrote there is "use the bugs for issues fixed in this version" [08:57] ie bug #368252 [08:57] Launchpad bug 368252 in totem "Totem firefox plugin can't launch apple HD trailers" [Low,Fix released] https://launchpad.net/bugs/368252 [08:58] or bug #366647 or bug #362820 [08:58] Launchpad bug 366647 in totem "subtitle not re-loaded when totem restart" [Low,Fix released] https://launchpad.net/bugs/366647 [08:58] Launchpad bug 362820 in totem "totem-plugin-viewer crashed with SIGSEGV in strchr()" [Medium,Fix released] https://launchpad.net/bugs/362820 [08:58] so I should SRU each of those? [08:58] use one of those for the sru [08:58] no, just use one of those to add the debdiff etc [08:59] I'm not sure why pitti has this policy now but that doesn't make much of a difference [08:59] rather than using the new version bug for the paper work use on the other bugs [08:59] 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] 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] ok. I'm a bit confused by the process though considering you can only accept the whole update or none of it. [09:00] didrocks: gni? [09:01] robert_ancell: well, each bug concerned by the upgrade need to be confirmed as fixed and not creating new issues [09:01] robert_ancell: what is confusing? [09:02] 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] 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] seb128: if there is no core bug for the update then it seems harder to link together. It just feels backwards [09:03] didrocks: that will mean less work for you and easier to get it accepted by debian [09:03] robert_ancell: just make any of the fixed bugs the core one [09:03] robert_ancell: usually one sru fixes one bug so we use this bug as the core one [09:03] seb128: And because it is a stable update it will include fixes that we don't have tracked [09:04] 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] seb128: oh ok. understood :) [09:05] 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] 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] 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] what do you mean? [09:08] seb128: to take into account the previous patch, I have to run autoreconf in 70_.. [09:08] and there, I saw some "cycling dependencies" and it failed [09:09] didrocks: can you pastebin the error? [09:10] 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] didrocks: why do you autoreconf? autoconf should be enough for this python path thing? [09:11] 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] robert_ancell: since the best people to tell us whether it's fixed are teh reporters/subscribers of those bugs [09:11] seb128: we have always had this policy [09:11] seb128: for hardy you just filed new bugs for new upstream microreleases when we didn't have "real" bugs in LP already [09:12] pitti: I've been used "new version" bugs for srus before [09:12] right [09:12] seb128: and it makes a huge difference in terms of who will read the request for testing [09:12] robert_ancell: if one of the bugs is not eligible for SRU, we'll reject teh entire upload [09:12] they will read all the request for testing anyway [09:12] robert_ancell: and be warned, priority: low bugs have a very small chance of being accepted [09:12] and I think it makes sense to do some "new version testing" too in case of new versions [09:13] robert_ancell: if it's not dealbreaker and causes totem to crash for every second movie, please don't SRU it [09:13] seb128: autoreconf is needed for aclocal.m4 patch (and autoconf does the same, btw) [09:13] pitti: I think the upload is SRU worth, it makes apple trailers work again and fix some browser crasher [09:14] 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] seb128: regressions are valid SRUs (shoudl be regression-release then) [09:14] don't bother with backports [09:14] +1 ^ [09:15] 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] What is the position on using BZR packages now? I was updating Glade which is not in BZR, can I create one? [09:18] yes, feel free to add to bzr anything desktopish [09:18] http://wiki.ubuntu.com/DesktopTeam/Bzr [09:19] 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] 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] agreed [09:22] clutter will probably be an issue for CD space [09:23] sure [09:23] so, splitting gnome-games package? [09:24] 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] what else on the desktop uses clutter? [09:25] robert_ancell: yes, and with gnome-shell, at the end, it seems that we will have no choice [09:26] those annoying gnome-games developers. Making life difficult for integrators. Hang on... :) [09:26] hehe :) [09:26] gtg, see you guys tomorrow [09:35] seb128: here it is http://paste.ubuntu.com/169387/ [09:36] didrocks: ask to Keybuk maybe he has an idea about that [09:40] seb128: ok. I'm pinging him :) === dpm_ is now known as dpm [09:47] 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] didrocks: you didn't have pkgbinarymangler installed [09:47] it's a check in pkgsanitychecks [09:48] pitti: oh, I have maybe to install it as a pbuilder hook, don't you think? [09:49] pitti: is it possible to simulate it, even if I don't have rosetta? (It seems to be used for stripping translation) [09:50] didrocks: rosetta has nothing to do with builds [09:50] didrocks: no, it does more than that [09:50] didrocks: just install it in the pbuilder, or your local system [09:51] ok, I give some test without fixing the issue to check it works at home :) [09:58] didrocks: just dpkg -c the .debs to check for site-packages vs. dist-packages [10:20] 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] hi seb128 - you got any updates for me to work on later? ;) [10:24] hello chrisccoulson [10:25] chrisccoulson: want to resync gnome-panel or gnome-appets on debian? [10:25] hey chrisccoulson, good morning [10:25] yeah, i can do those [10:26] hi pitti [10:26] excellent, they are for you then [10:26] thanks [10:26] you're welcome [10:28] * seb128 still fighting bug emails from the weekend [10:28] IRC and bug backlog will have taken the morning [10:28] and I did read and reply to email twice this weekend [10:32] chrisccoulson: btw I don't know if you read the backlog on friday but you should run for MOTU now ;-) [10:33] seb128: heya! [10:33] seb128: how is it going? [10:33] hello lool [10:34] good, lot to do as usual, and a bit too many bugs open for details to my taste but other good ;-) [10:34] Eh [10:34] and you? did you have good holidays? [10:34] Yeah, it was nice to take some break [10:34] I'd like to discuss https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/283447 with you [10:34] Ubuntu bug 283447 in netbook-remix "Undecorating maximised windows sometimes leaves a blank space below the window (Intrepid & Jaunty)" [High,Fix committed] [10:35] I just added the Ubuntu package task and the jaunty task [10:35] This bug is an important issue in UNR and is fixedin metacity 2.26.0 [10:35] Do you mind if we move to 2.26.0 in karmic and jaunty? [10:35] Is anything preventing this update? [10:35] no, just somebody having interest for the software [10:36] 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] it's probably better to backport the change there than to update to a new version [10:36] seb128: So new version in karmic and backported fix in jaunty; will talk to pitti then, thanks! [10:37] new version in karmic without any doubt [10:37] lool: you need this to be an ubuntu sru for UNR? [10:37] pitti: Correct [10:37] hmkay [10:37] pitti: UNR being Ubuntu jaunty's UNR [10:37] pitti: UNR is really in Ubuntu now [10:37] yeah, understood [10:44] hi seb128 - i did see your conversation with dholbach on friday [10:44] i'll hopefully get around to applying this week if you think i should:) [10:46] you should! [10:46] * pitti puts on the "Chris Coulson for Pres^WMOTU!" badge [10:47] ;-) [10:54] ok, time for some sponsoring now [11:08] Ah mvo is in holidays [11:09] is he? [11:09] Yeah, whole week it seems [11:09] we really need a VAC calendar we can add to e-d-s ;-) [11:09] "update-manager -c -d" works on my desktop but doesn't on a jaunty UNR install [11:14] ah was just flaky network [12:39] 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:39] Ubuntu bug 372428 in bluez "[karmic] please sponsor bluez-4.38" [Undecided,New] [12:40] and furthermore, what the the test I should conduct to validate I don't break things [12:42] 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] dpkg-something should be a wrapper for all dpkg* tools :) [13:14] Hobbsee, crevette: you mean dh_install --list-missing ? [13:14] pitti: yeah, that sounds right! [13:15] pitti, is it possible to have it run in pbuilder in order to have a report at the end of the build ? [13:15] crevette: you can certainly run it in debian/rules [13:16] crevette: cdbs has an utils.mk for list-missing, too [13:16] okay, I'll try tht, thanks [13:22] 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] chrisccoulson: that works fine for me [13:24] chrisccoulson: you just can't invoke it with -p, obviously [13:25] pitti - thanks. i'll try again next time i need to do that and see if it works [13:26] it doesn't work for multi-build packages, ie when you don't install to debian/tmp for example [13:27] ie that doesn't work for python packages which build for multiple version or for gtk+ which has a static, etc build [13:33] 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] kenvandine: not worse than any other morning :) [14:01] hehe [14:01] it worked [14:01] pitti: did you get a share request from me today? [14:01] kenvandine: by mail? no [14:01] ok [14:02] any idea why there is kde stuff in my updates? [14:02] oh? [14:02] * kenvandine doesn't think he installed anything kde related :) [14:02] what in particular? [14:02] kdebase stuff [14:02] might be a wrong new dependency [14:02] that is what i am wondering [14:02] kenvandine: if you just do apt-get upgrade, what does it hold back? [14:02] let me try to remove it :) [14:03] kenvandine: oh, it wanted to _upgrade_ kdebase, not newly install it? [14:03] not sure, i was using update manager [14:03] not apt-get [14:03] not sure if it is easy to tell there [14:04] don't think so [14:04] pitti: do you have an opinion on code logic copy and copyright assignment? [14:04] pitti: ie gnotes being a tomboy copy in c++ ... should the copyright list the tomboy authors? [14:04] seb128: context? [14:04] seb128: it's a total code rewrite? [14:04] The following packages have been kept back: [14:04] 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] libkdecorations4 libkrb5-dev libkwineffects1 libltdl7 libphonon-dev libphonon4 libplasma3 libqt4-assistant libqt4-core libqt4-dbus libqt4-designer libqt4-dev libqt4-gui [14:04] 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] libqt4-webkit libqt4-xml libqt4-xmlpatterns libqtcore4 libqtgui4 libstartup-notification0 libstartup-notification0-dev linux-generic linux-headers-generic [14:05] they basically take tomboy and copy line by line translating to c++ [14:05] 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] 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] kenvandine: grrrrr [14:05] python-uno qt4-qmake qt4-qtconfig [14:05] whoops [14:05] kenvandine: use pastebin please [14:05] it was 2 lines :) [14:05] sort of ... sorry [14:05] seb128: hm, no idea I'm afraid; would certainly at least be nice to credit them [14:05] update-manager doesn't install new packages or remove other binaries [14:06] seb128: "system upgrade" does, though [14:06] it does new installs but no removals [14:06] i must have something installed that brought it in as a dep [14:06] 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] kenvandine: what is the question? [14:08] james_w: I agree; even if it's legal, it's at least nasty [14:08] 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] pitti: I don't see it as a reason to keep it out the archive though? [14:08] just did an update today in karmic [14:08] seb128: just verifying there wasn't a bug [14:09] morning rickspencer3 [14:09] kenvandine: your log lists kept back packages [14:09] hello rickspencer3 [14:09] james_w: that'd require a lawyer, I'm afraid [14:09] seb128: that was just answering pitti's question [14:09] good morning kenvandine, seb128, pitti [14:09] hey rickspencer3 [14:10] 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] yeah [14:11] but it's easier to track that before clicking yes [14:11] pitti: ok, how should I proceed? [14:11] james_w: perhaps ask elmo? he's got much more license/copyright experience than me [14:12] pitti: ok, I'll mail him and CC ubuntu-archive? [14:12] james_w: sounds good [14:12] thanks [14:13] 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] seb128 is scared of the kernel ;-) [14:13] indeed! [14:13] * kenvandine needs more coffee... bbiaf [14:14] 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] this. [14:22] Ampelbein: I would not bother about the hppa case for now but working on an update not using -Werror would be useful [14:22] 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 === asac_ is now known as asac [14:33] 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] Ampelbein: configure.ac: MAINTAINER_CFLAGS="-Werror -Wall -Wshadow -Wcast-align -Wno-uninitialized -Wformat-security -Winit-self" [14:42] seb128: ah, there it is. thanks. should i do a ubuntu2 for this? [14:42] Ampelbein: I guess editing that line in the configure and updating autoconf should work [14:42] Ampelbein: yes [14:42] ok will do [14:42] thanks === rickspencer3 is now known as rickspencer3-afk [14:56] pitti, What's mvo's excuse this time? ;) [14:56] Hi all ;) [14:57] jbailey: he's on holiday [14:57] he's on holidays for the week apparently [14:57] Bah! =) [14:57] you can try dropping him an email though ;-) [14:57] Ah well. /me sits on his hands and waits. [14:57] Nah, if he's on holidays I don't want to bug him. [14:58] I'm not sure how good he's at not readin email during holidays ;-) [14:58] Most Canonical people are terrible at the best of times. [14:58] Having an email from a friend show up is almost a guarantee that it would get read. [15:05] seb128: bug 374889, branch linked. [15:05] Launchpad bug 374889 in gnome-utils "FTBFS due to -Werror on sparc and armel architecture." [High,Confirmed] https://launchpad.net/bugs/374889 [15:06] ok === seb128_ is now known as seb128 === awe is now known as awe-afk === awe-afk is now known as awe [15:35] 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] Ampelbein: right [15:36] I hate autotools [15:36] seb128: is this my fault? [15:37] define "your" there ;-) [15:37] it's a bug in the package yes [15:37] it worked on pbuilder so this must be a race condition. [15:37] it is [15:37] the autotools try to be clever [15:38] if some timestamps are never than others they run autoconf or automake for you [15:38] never -> newer [15:40] seb128, autotools are cuddly. [15:40] But AM_MAINTAINER_MODE was wired backwards, and is useless. [15:40] how do you ensure that autotools are not ran in such cases? [15:40] It should always be in there, disabled by default, and be an option that you pass to configure. [15:41] If I weren't totally apathetic, I would write a patch for that. [15:41] $ grep am-maintainer configure.ac [15:41] $ [15:42] debian/rules passes --disable-maintainer-mode to configure already. but that option is not recognized. [15:42] Hah, apparently I wrote an LJ article once ranting about this. [15:42] right [15:42] the modern autotools version don't seem to understand the option [15:44] in fact no [15:44] seb128, It's still in Hardy. [15:44] configure.ac should have a AM_MAINTAINER_MODE and autoconf should be run [15:44] AC_PREREQ(2.61) [15:44] AC_INIT(FULL-PACKAGE-NAME, VERSION, BUG-REPORT-ADDRESS) [15:44] AC_CONFIG_SRCDIR([main.cc]) [15:44] AC_CONFIG_HEADER([config.h]) [15:44] AM_MAINTAINER_MODE [15:44] Bah, never run autoconf on it's own. [15:44] aclocal; autoconf [15:44] "autoreconf -f -i -s" is your friend. =) [15:44] I hate autoreconf [15:45] Why? [15:45] it makes a some hundred kbs patch where autoconf does a 25 liners [15:45] I don't need all the Makefile.in to be updated for a configure change [15:45] Well, those other changes are probably bug fixes and the like, though. [15:46] 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] right, it just makes updates hard to review [15:48] AM_MAINTAINER_MODE should be the default mode in any tarball [15:48] I just don't see the point of that clever timestamp magic [15:48] usually you either want to build using ./configure && make or you want to run autogen.sh and you do that [15:49] it's useful for an upstream if you change Makefile.am [15:49] then you do make and it DTRT [15:49] well, make dist should switch maintainer mode on [15:50] +1 === bluesmoke_ is now known as Amaranth [15:51] seb128, the problem is that then a user has to remember one more thing when trying to figure out what's happening. [15:52] So they either then edit the Makefile directly and lose their changes, or they edit the Makefile.{am,in} and nothing happens. [15:52] If the use wants to touch that *and* has autotools installed, it does the right thing. [15:52] 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] You're arguing against yourself there. [15:53] That's what maintainer mode kills. [15:53] 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] I'm not arguing against myself [15:54] 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] 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] but for that I need to patch configure.ac and run autoreconf which is annoying [15:55] right [15:55] Just edit configure.ac, and it will do the right thing when you're hacking on the code. [15:55] The only time you have a problem is when you're patching configure directly. [15:55] I'm not hacking on the code, I'm uploading to a buildd which should not have autoconf installed [15:55] Something that the system isn't built for. [15:55] Right. The buildds don't. === awe is now known as awe-afk [15:55] It's on your dev machine that's a problem. [15:55] You have it installed, and you're editting a file you're never supposed to touch. [15:56] I'm not [15:56] It's like binary patching make on the build system. You're not supposed to do it. [15:56] You're not patching configure? [15:56] I'm having a autoreconf patch in my series [15:56] or Makefile{.in} [15:56] I'm not touching it manually, I run autoreconf and put the diff in a patch [15:56] the issue is the timestamp after patch apply [15:56] Doesn't matter. Something other than autoconf on the current system is touching it. [15:56] It's not designed for that. [15:56] you have to list the changes in the right order in the patch [15:57] right [15:57] I'm not arguing that [15:57] I just say it's annoying it's not decided to do what I want ;-) [15:57] Eheh [15:57] decided -> designed [15:58] sometimes I wonder if we should just run autoreconf on the buildds [15:58] No! [15:58] rather than having autoreconf patches [15:58] CDBS has an option for that and it's *horrible* [15:58] I tried to convince duck not to put it in. [15:58] Then you have no clue what the buildd built. [15:58] cdbs is buggy according to Keybul [15:58]