[00:45] <carstenh> paissad: imagine I installed your package, how do I stop or start the daemon?
[00:47] <paissad> carstenh, /etc/init.d/pms-linux stop
[00:48] <carstenh> paissad: good. how do I tell dpkg not to kill things during package installations or upgrades?
[00:48] <paissad> hmm
[00:48] <carstenh> paissad: the answer is: I use /usr/sbin/policy-rc.d
[00:48] <paissad> i did not know
[00:48] <carstenh> paissad: this does not work with your postinst
[00:49] <paissad> how should i proceed then ?
[00:49] <carstenh> paissad: policy says "The package maintainer scripts must use invoke-rc.d to invoke the /etc/init.d/* initscripts, ...", this avoids problems like ignoring policy-rc.d
[00:50] <carstenh> paissad: your silent-kill-foo needs to be replaced with calling the init-script
[00:52] <carstenh> paissad: and your do_perms looks weird, but this is an other possible problem you could check later
[00:52] <paissad> carstenh, ok, i make some changes and tell you
[01:14] <carstenh> paissad: an other thing I noticed is that you use pgrep.  you need to depend on pgrep to be able to use it.  if you would use start-stop-daemon in a sane way you would not need to use pgrep.
[01:14] <carstenh> paissad: depend on procps, not pgrep
[01:17] <carstenh> paissad: good resources for information about packaging after you know the very basic things are http://www.debian.org/doc/developers-reference/ http://www.debian.org/doc/debian-policy/ and some sites on the ubuntu wiki
[01:17] <carstenh> good night
[01:19] <paissad> carstenh, i tried to use use start-stop-daemon, but the program itself is run like this 'java -jar options"
[01:19] <carstenh> paissad: oh, I forget to mention one thing: this invoke-rc.d and start-stop-daemon thinks do not directly address your initial question but they need to be done in a correct way before you upload to ubuntu or debian and if you are lucky your initial problem is gone
[01:20] <carstenh> paissad: write a wrapper?
[01:20] <paissad> wrapper ?
[01:21] <carstenh> paissad: echo '#!/bin/sh'; echo 'wget -O- "$@"') > wcat
[01:21] <carstenh> paissad: chmod a+x wcat
[01:22] <carstenh> paissad: wcat google.com
[01:22] <carstenh> paissad: if you do this you wrote and used a wrapper
[01:22] <paissad> carstenh, ok thanks, but last thing please (if you still have a little time)
[01:22] <carstenh> the first line must be (echo '#!/bin/sh'; echo 'wget -O- "$@"') > wcat
[01:22] <carstenh> just ask
[01:22] <paissad> carstenh, yes indeed, the 1st line ins #!/bin/sh
[01:23] <carstenh> I forgot the initial "(" on 02:21:46
[01:23] <carstenh> (plus/minus your time zone)
[01:23] <paissad> about, the postinst, where should i invoke invoke.rc
[01:23] <paissad> carstenh, same time ^^
[01:24] <paissad> i changed silent_stop* to /etc/init.d/pms-linux stop
[01:24] <carstenh> paissad: if you need to stop or restart it use invoke-rc.d instead of your pgrep/kill-solution
[01:25] <paissad> i'm confused, i try to read some package builds to get an idea
[01:25] <paissad> thanks anyway
[01:25] <carstenh> paissad: why do you stop it and do not start it again?
[01:27] <carstenh> invoke-rc.d is just a "wrapper" ;) ... around /etc/init.d/script with some additional magic
[01:28] <carstenh> now I'm away. good luck with your package
[03:17] <family> Hi im new to ubuntu, can anyone answer a question for me?
[03:18] <family> hello?
[03:21] <family> hello
[03:21] <family> is anyone available to answer a question?
[04:13] <paissad> guys, i have this the start section of my init.d script
[04:13] <paissad> start-stop-daemon --start --quiet --background --oknodo --exec $DAEMON "$DAEMON_OPTS"
[04:13] <paissad> here is what set -x shows
[04:13] <paissad> start-stop-daemon --start --quiet --background --oknodo --exec /usr/bin/pms-linux 'console -c /etc/PMS.conf'
[04:14] <paissad> but in that case, 'console -c /etc/PMS.conf' is considered as a single option (because of the double quotes in $DAEMON_OPTS"
[04:14] <paissad> )
[04:15] <paissad> but when i remove the double quotes, i have have this
[04:15] <paissad> start-stop-daemon --start --quiet --background --oknodo --exec /usr/bin/pms-linux console -c /etc/PMS.conf
[04:15] <paissad> that creates an error because of '-c' which is an option of start-stop-daemon
[04:15] <paissad> how should i proceed then ?
[04:16] <paissad> without double quotes -> start-stop-daemon "thinks" that /etc/PMS.conf is a user  (which is not the case of course)
[04:17] <paissad> thanks in advance for helping
[04:17] <ebroder> paissad: You can use -- to separate arguments to start-stop-daemon from arguments to your program
[04:18] <paissad> hmmm where i put -- ?
[04:18] <ebroder> paissad: After /usr/bin/pms-linux, which is the last part of the arguments to start-stop-daemon
[04:18] <paissad> ok thanks
[04:18] <hyperair> paissad: you can often use -- like this for most *nix command-line applications as well
[04:18] <hyperair> e.g. grep
[04:18] <hyperair> grep blah blah -- -file-that-begins-with-dash
[04:18] <paissad> oh ok i will remember that !
[04:19] <hyperair> er minsu one blah
[04:19] <paissad> thanks for all
[12:00] <Leon_Wallch_Deve> hi.. i am making a program.. from the mainwindow i open a new dialog... from this dialog i push a button and the program is restartign.. but the problem is that the programm will pass the close event of the mainwindow... i do not know if you understand me... I am using Qt Creator with c++, ubuntu 10.10,.. ( For further information please go here --> http://www.qtcentre.org/threads/37281-Create-a-thread-to-the-one-UI-to-be-conn
[12:00] <Leon_Wallch_Deve> restarting*
[12:00] <Leon_Wallch_Deve> will not pass*
[12:02] <Leon_Wallch_Deve> I really need a solution to this because the only thing that left to my programm is that
[12:02] <Leon_Wallch_Deve> Thank you anyway
[15:11] <ari-tczew> what is the point of fixing ftbfs which binaries actually exist? I mean ftbfs from http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi
[15:33] <bdrung> tumbleweed: preferred-mirror merged. one thing left: you b-d on python-simplejson, but you don't recommend it
[15:45] <tumbleweed> bdrung: err yes I should recommend python (>= 2.7) | python-simplejson
[15:48] <tumbleweed> now I need to attack syncpackage and pbuilder-dist...
[15:49] <bdrung> tumbleweed: can you fix the recommends and get the tests succeeding first?
[15:49] <tumbleweed> oh tests failing? whoops. Yeah I'll sort those out first
[15:50] <bdrung> tumbleweed: FAIL: test_pull-debian-source (ubuntutools.test.test_help.HelpTestCase)
[16:02] <carstenh> ari-tczew: providing updated packages with security fixes is impossible if the package does not build. additionally, sometimes packages need to be rebuilt if they use libraries whose abi (application binary interface) changed.
[16:04] <ari-tczew> carstenh: so ftbfs can be fixed if new revision is necessary
[16:04] <ari-tczew> if there is not security update or other bugfix, I see no point of fix ftbfs
[16:05] <udienz> seems like many packages failed build because LDSO Link
[16:06] <udienz> I have successfully fixing libmatchbox
[16:07] <udienz> bug 694300
[16:07] <carstenh> ari-tczew: imagine a billionaire is looking for a new hobby and chooses to start a new distribution and to rebuild the whole debian archive twice a year ;)
[16:08] <ari-tczew> carstenh: why billionaire?
[16:08] <carstenh> ari-tczew: your way of fixing ftbfs bug would also mean that the security team is responsible to fix those bugs
[16:08] <carstenh> ari-tczew: because this already happened
[16:08] <ari-tczew> carstenh: I didn't get it
[16:09] <carstenh> ari-tczew: ubuntu is sponsored by someone who made a lot of money with ssl certificates and the dot com bubble
[16:09] <ari-tczew> carstenh: I know. Mark S
[16:10] <ari-tczew> carstenh: FYI ubuntu is sponsored by volunteers, as well.
[16:10] <carstenh> and he choose to rebuilt debian twice a year a whilw ago. with a lot of unfixed ftbfs bugs this would have been much harder
[16:11] <carstenh> yes, this "mark s sponsored ..." was a bit simplified
[16:12] <ari-tczew> carstenh: heh, I can fix a lot of these FTBFS if Mark S will pay me
[16:13] <Laney> because the archive must be buildable within itself
[16:13] <Laney> modulo bootstrapping
[16:13] <carstenh> it's not only him, other people also rebuild packages, e.g., because they think they could harden them or improve performance
[16:15] <carstenh> ... or want to port to different architectures and/or kernels
[16:17] <ari-tczew> 1400 ftbfs... decisively we need more contributors
[16:20] <hakermania> What is 'ftbfs' ?
[16:20] <carstenh> ari-tczew: trying to build ubuntu source package in debian can help to find and prevent future ftbfs in debian, since ubuntu currently has newer versions of many packages
[16:20] <carstenh> hakermania: fails to build from source
[16:20] <ari-tczew> !ftbfs | hakermania
[16:20] <bdrung> tumbleweed: your error message could be improved. -> "Please install foo."
[16:20] <ari-tczew> hmm, ubottu doesn't know what's ftbfs! you're n00b ubottu
[16:21] <bdrung> ari-tczew: ububot is on vacation :P
[16:21] <ari-tczew> bdrung: ah, right
[16:21] <bdrung> s/ububot/ubottu/
[16:21] <ari-tczew> merry x-mas ubottu
[16:22] <hakermania> !noob | ubottu
[16:22] <hakermania> haha
[16:24] <bdrung> :D
[16:25] <bdrung> !motu | ubottu
[16:26] <hakermania>  ari-tczew: You said "1400 ftbfs... decisively we need more contributors", when you say contributors you mean persons that can make new projects for ubuntu or persons who are willing to fix bugs etc?
[16:26] <bdrung> tumbleweed: you could drop the devscripts check. u-d-t should depend on devscripts!
[16:27] <tumbleweed> bdrung: err that's true, I should be removing those, not adding them
[16:27] <ari-tczew> hakermania: this second
[16:27] <ari-tczew> udienz: do you know what is merge?
[16:28] <udienz> ari-tczew, Yes, merge is copying from debian with changes
[16:28] <bdrung> s/is merge/a merge is/
[16:29] <udienz> And Sync,  copying from debian without any changes
[16:29] <ari-tczew> udienz: I'm reviewing your FTBFS fix. why did you call it as merge?
[16:29] <ari-tczew> it's just ftbfs fix. you didn't grab changes from Debian
[16:30] <Bachstelze> hmm, if a package uses dpatch but debian/rules does not implement the patch/unpatch rules, is it okay to add them, or should I just Deal With It™?
[16:30] <bdrung> Bachstelze: yes, add them
[16:31] <udienz> ari-tczew, no no.. i;m not call this bug 694300 with merge,
[16:31] <ari-tczew> Bachstelze: and inform Debian maintainer about that
[16:32] <carstenh> hakermania: people doing development are of course also needed
[16:32] <ari-tczew> udienz: from your debdiff: * Merge from Debian Unstable (LP: #694300), Remaining change:
[16:32] <ari-tczew> am i blind?
[16:33] <udienz> ari-tczew, ah... you right.. :D sorry i will fixing it
[16:33] <hakermania> carstenh: I don't think so that ubuntu really wants them. If it did, more reviewers would be available and the process for reviewing your package would take less, and no weeks
[16:33] <hakermania> :P
[16:33] <ari-tczew> udienz: please also add DEP3 tags
[16:33] <ari-tczew> udienz: https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines
[16:35] <ari-tczew> udienz: no, stop. there is no patch system
[16:35] <ari-tczew> you should apply changes indirect to files directly
[16:35] <carstenh> hakermania: people doing reviewss are also needed ;)
[16:35] <ari-tczew> your debdiff is ftbfs
[16:35] <udienz> ari-tczew, btw, libmatchbox maybe merge. because there is nothing ubuntu version at least
[16:36] <hakermania> carstenh: A lot of dependencies haha
[16:36] <ari-tczew> udienz: please understand that merging means getting changes from Debian
[16:37] <ari-tczew> you just adding changes to clean debian package
[16:38] <udienz> ari-tczew, so this a file under patches/ must be removed? ok i will do it
[16:38] <ari-tczew> udienz: that's right. before preparing a fix please check in the source package directory command 'what-patch'
[16:42] <carstenh> hakermania: if you want to work on something and you show the required skills and engagement, you normally get the chance to do so. packaging random new software is often less useful than improving existing packages or doing things that are not related to packaging.
[16:43] <udienz> ari-tczew, done
[16:43] <hakermania> carstenh: Agree :)
[16:43] <udienz> ari-tczew, ah.. dorry please forget it. a merge still appear at changelog
[16:45] <udienz> s/dorry/sorry
[16:47] <udienz> ari-tczew, ok done
[16:49] <hakermania> udienz: What kinf of packages are you fixing?
[16:49] <hakermania> kind*
[16:50] <ari-tczew> udienz: hmm, seems to you want fix bug 692860 so you can just set LP: #692860 and attach your debdiff there. you didn't need to open a new bug
[16:50] <udienz> hakermania, libmatchbox
[16:50] <udienz> ari-tczew, but this is different packages
[16:50] <hakermania> udienz: Are you finding bugs from Harvest?
[16:50] <ari-tczew> udienz: summarizing: remove second LP: because there is no affected libmatchbox
[16:51] <udienz> hakermania, no, from udd.d.o
[16:51] <hakermania> udienz: link?
[16:52] <udienz> hakermania http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi
[16:54] <udienz> ari-tczew, done
[16:54] <hakermania> udienz: What of the three options do I select in order to download the ftbfs package? (PTS   BTS   LP)
[16:54] <udienz> a new debdiff has been uploaded
[16:55] <udienz> hakermania, hm.. PTS to got source from debian, and then look at error messages
[16:55] <udienz> try to fix it
[16:55] <hakermania> udienz: Ok thx
[16:56] <ari-tczew> udienz: again d/changelog is wrong because you removed patch file ;)
[16:57] <bdrung> hakermania: pull-lp-source
[16:57] <ari-tczew> udienz: now you can use just: * Fix FTBFS linking with binutils-gold and gcc 4.5. (LP: #694300)
[16:57] <bdrung> hakermania: or pull-debian-source if you want the corresponding package from debian
[16:57] <hakermania> bdrung: So, this command will provide me e.g. with the package 'wally' ftbfs package?
[16:58] <hakermania> 'pull-lp-source wally'
[16:58] <bdrung> hakermania: it will download the latest source of wally
[16:59] <bdrung> from launchpad
[16:59] <hakermania> bdrung: http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi is referring to the latest sources of the list packages, isn't it?
[16:59] <bdrung> hakermania: or use "bzr branch lp:ubuntu/wally" if you prefer bzr
[17:00] <bdrung> hakermania: yes, it should
[17:00] <udienz> ari-tczew, Ok Done... again ;)
[17:00]  * udienz too nervous
[17:01] <ari-tczew> udienz: are you too nervous? why?
[17:01] <ari-tczew> beginning in MOTU areas always are failing
[17:02] <bdrung> not failings, growth by making mistakes ;)
[17:02] <hakermania> bdrung: Two questions: a)Who informs udd.debian.org for the failed to build packages? Or udd.debian.org tries to build the packages for natty and if it cannot it sends them to ftbfs section? b) Aren't the real maintainers currently working on their ftbfs packages ?
[17:02] <udienz> ari-tczew, hehehe
[17:02] <ari-tczew> bdrung: I'm calling things by their names, colloquially :)
[17:04] <bdrung> hakermania: lucas nussbaum rebuild all packages from natty and provided this list: http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi
[17:05] <bdrung> hakermania: he send a mail to the debian devel mailing list pointing to this list and asking the debian maintainer to have a look at it and see if they are affected by these ftbfs too.
[17:05] <hakermania> bdrung: Oh, so if a package fails building it goes there :) nice! And all these packages must be ready till 4/11 ?
[17:07] <udienz> hakermania, before submitting a patch try to build it with pbuilder or put to your ppa
[17:07] <bdrung> hakermania: this page is only a snapshot in time.
[17:08] <ari-tczew> udienz, hakermania: not necessary ppa. pbuilder or sbuild - locally
[17:08] <bdrung> hakermania: these ftbfs packages should be fixed till 4/11, but we can't promise to fix all.
[17:08] <hakermania> bdrung: After fixing a package, where can you submit your patch?
[17:09] <udienz> ari-tczew, right.. but i can do with pbuilder if lucid/maverick release.. internet connections is my problem :D
[17:09] <ari-tczew> hakermania: launchpad?
[17:09] <bdrung> hakermania: attach the patch (debdiff) to the ftbfs bug (open one if there isn't one) and subscribe ubuntu-sponsors
[17:10] <hakermania> ari-tczew, bdrung: The bug will be reported to lp or to  http://udd.debian.org ?
[17:11] <bdrung> hakermania: launchpad
[17:11] <udienz> hakermania: as bdrung and ari-tczew says, you may fail many times in MOTU :) but don't worry to gained new knowledge
[17:11] <bdrung> hakermania: more specific: to the ubuntu package in launchpad
[17:12] <hakermania> udienz, bdrung: Udienz, what do you mean by telling 'fail'? Who failed? Anyway, thx, I now have to learn how to build with pbuilder, go straight to #ubuntu-packaging :P
[17:12] <udienz> bdrung: i have questions. if Fedora/Opensuse providing patch can i apllied at here?
[17:13] <ari-tczew> udienz: sure!
[17:14] <ari-tczew> hakermania: fail = mistake
[17:14] <bdrung> hakermania: getting your changes into ubuntu often taken more iterations until it suits our requirements. that's why we have sponsorship.
[17:14] <hakermania> Ok
[17:15] <bdrung> udienz: yes, but we prefer to have fixes applied upstream. then upstream maintains the patch.
[17:17] <bdrung> udienz: at least there should be an open upstream bug for the patch.
[17:25] <ari-tczew> udienz: done, thanks
[17:55] <udienz> :)
[17:55] <udienz> anyway i look at another FTBFS bug, and some of packages is fixed but not uploaded at archive
[17:57] <udienz> like bug 687988
[17:57] <udienz> bug 687991
[17:57] <udienz> why those packages has not pushed yet?
[17:58] <bdrung> udienz: because ubuntu-sponsor weren't subscribed to the bugs.
[17:59] <bdrung> ubuntu-sponsors (with s)
[18:00] <udienz> bdrung, can i try to fix those bugs? and subscribed bugs? i'm not confident because those packages actually fixed by someone else
[18:01] <bdrung> udienz: subscribe ubuntu-sponsors to these bugs and find other ftbfs packages where no fix is available.
[18:02] <bdrung> udienz: doing work twice gives us no benefit.
[18:02] <udienz> ok
[18:03] <ari-tczew> udienz: ah, I'd forgot: please forward your patch to Debian
[18:06] <ari-tczew> udienz: there are 1400 other ftbfs to fix :P
[18:09] <udienz> ari-tczew, Hehehe, ok. Done sending to debian http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555284
[18:11] <bdrung> udienz: it's better to attach the patch (without debian/changelog modifications) to the debian bug instead of only linking to launchpad.
[18:13] <ari-tczew> udienz: +1 for bdrung ^^ also please don't send all debdiff, just create a patch as in your 1st debdiff, attach and send next mail to this bug
[18:16] <udienz> bdrung, ari-tczew: Done, i send patch again
[18:45]  * Bachstelze hates autoconf
[18:46] <Bachstelze> looking at FTbFS in autofs5, it fails to detect hesiod because it puts the linker flags at the wrong place
[18:46] <Bachstelze> instead of cc test.c -lhesiod, it does cc -lhestiod test.c
[18:48] <azeem> Bachstelze: that looks like a broken Makefile to me, rather
[18:48] <azeem> why does it compile and link in the same step?
[18:48] <Bachstelze> azeem: that's in the configure script
[18:49] <azeem> pastebin it somewhere
[18:49] <ebroder> Bachstelze: Is it just using AC_SEARCH_LIBS or something like that?
[18:51] <Bachstelze> ebroder: no idea, I know very little about autoconf, but it's kinda frustrating
[18:51] <Bachstelze> http://paste.ubuntu.com/547567/
[18:51] <Bachstelze> line 2
[18:52] <ebroder> Bachstelze: I'm looking at the source now. This isn't an inherent problem with autogoo - it's a problem with autofs's configure.in
[18:52] <Bachstelze> if I could just make it do  gcc ... conftest.c -lhesiod -lresolv
[18:52] <Bachstelze> it would work
[18:54] <ebroder> Bachstelze: I think you want to edit AF_CHECK_LIBHESIOD in aclocal.m4, then re-run autoconf
[18:55] <ebroder> Bachstelze: Probably set LIBS instead of LDFLAGS or something?
[18:57] <Bachstelze> it's also weird why the order matters in Natty when the same source package built fine in Maverick
[18:58] <bdrung> Bachstelze: the order was wrong since the beginning, but now it fails.
[18:59] <bdrung> Bachstelze: it's common that something is used in a wrong way and one day it fails to build because the toolchain changed.
[18:59] <Bachstelze> this package seems to have a lot of things wrong then :p it's the same one where d/rules doesn't have patch/unpatch
[18:59] <Bachstelze> anyway, putting LIBS seems to fix it
[19:01] <Bachstelze> bdrung: now what would be a good way to dpatch that? the build normally doesn't run autoconf, right?
[19:03] <bdrung> Bachstelze: patch autoconf.ac/makefile.am and a) run autoreconf and store the diff in a second patch or b) modify debian/rules to run autoreconf
[19:03] <ebroder> Bachstelze: Look into dh_autoreconf. But make sure you only run autoconf, not aclocal
[19:04] <ebroder> (I don't know if dh_autoreconf can do that, or if it will only run autoreconf)
[19:07] <ebroder> Ok, yeah - autoreconf only runs aclocal if you're using automake, so dh_autoreconf should do what you want
[19:50] <Bachstelze> okay, all good
[19:51] <Bachstelze> bdrung: is there a standard procedure to create a LP bug for a FTBFS?
[19:52] <bdrung> Bachstelze: IIRC, no
[20:07] <Bachstelze> bdrung: bug 694342 if you have the time to look at it, otherwise I subscribed ubuntu-sponsors
[20:08] <ebroder> Bachstelze: You should be able to use /usr/share/dpatch/dpatch.make instead of calling dpatch yourself
[20:09] <ebroder> Also, you should call dh_clean_autoreconf in the clean step to undo what dh_autoreconf did - I think there's an example in the dh_autoreconf manpage
[20:10] <ebroder> In 18fix_hesiod_detect, I think you probably should restore LIBS back to the state it was in before, like it used to do for LDFLAGS
[20:45] <Bachstelze> ebroder: posted a new one
[20:58] <Bachstelze> hmm, there are also new upstream patches, maybe we should include them for Natty
[21:59] <mka> hi
[22:03] <mka> i want to become part of MOTU
[22:06] <mka> but i think i need mentor
[22:06] <mka> :)
[22:14] <Bachstelze> mka: read the wiki, try to work on some packages, ask any questions you have :)
[22:22] <Bachstelze> ebroder: uploaded a new debdiff with the upstream patches released since ubuntu2
[22:40] <ari-tczew> dpatch sux
[22:40] <ari-tczew> now my motto is - no quilt, no sponsor ;D
[22:54] <Bachstelze> ffff, btrfs-utils FTBFS because upstream apparently failed Programming 101 and doesn't initialise a variable properly
[22:54] <Bachstelze> and I'm afraid to change it since I don't know what a sane default would be
[22:57] <ari-tczew> Bachstelze: get in touch with upstream if you really want to spend time on this case
[22:58] <Bachstelze> I don't :p
[22:59] <Bachstelze> next
[23:00] <ari-tczew> Bachstelze: hehe, like me
[23:14] <bdrung> tumbleweed: around?
[23:15] <tumbleweed> bdrung: vaguely
[23:16] <bdrung> tumbleweed: what do you think about having a testcase that checks for pylint errors?
[23:17] <bdrung> tumbleweed: currently the "pylint -E" on all python files gives me this result: http://pastebin.com/sMmdpRPA
[23:17] <bdrung> most errors come from the launchpad wrapper, but there are some bugs detected too.
[23:17] <tumbleweed> personally I use pyflakes, as pylint is very noisy
[23:18] <tumbleweed> but it also picks up less issues
[23:18] <tumbleweed> then there's pychecker (which is responsible for one of the python2.7 FTBFSs, IIRC)
[23:19] <tumbleweed> hmm, there are some real bugs in that paste
[23:21] <bdrung> tumbleweed: "pylint -E" gives only errors (and does not show all those noise)
[23:21] <tumbleweed> yeah I see that
[23:22] <tumbleweed> I do like the idea of static analysis in the tests, and I've considered it too
[23:22] <bdrung> tumbleweed: pyflakes seams to be not flexible enough.
[23:23] <tumbleweed> no, it's very simple - pretty much just a syntax checker with some extras
[23:23] <bdrung> tumbleweed: the test should only check for grave things, which "pylint -E" does, but pyflakes doesn't
[23:23] <tumbleweed> yeah, except we'd need to whitelist all the launchpadlib related issues
[23:23] <bdrung> tumbleweed: can't we fix them?
[23:24] <tumbleweed> I think they are inherent in the design of launchpadlib
[23:24] <bdrung> tumbleweed: they come from the launchpadlib wrapper, not from launchpadlib IIRC
[23:25] <bdrung> oh, no. you are right
[23:25] <tumbleweed> but yes there are ones related to the wrapper too
[23:25] <tumbleweed> my guess from reading that is that it doesn't understand metaclasses
[23:26] <bdrung> tumbleweed: uses launchpadlib metaclasses?
[23:27] <tumbleweed> don't know, haven't read it, but lpapicache does
[23:36] <Bachstelze> wow
[23:36] <Bachstelze> the sendmail package is a huge mess
[23:53] <bdrung> tumbleweed: we can do that pylint -E check. we can easily disable invalid errors. see r913 as example
[23:53] <bdrung> tumbleweed: my command: pylint -E ubuntutools 404main ack-sync backportpackage dgetlp get-branches grab-attachments grep-merges hugdaylist import-bug-from-debian lp-list-bugs lp-project-upload lp-set-dup lp-shell manage-credentials massfile merge-changelog pbuilder-dist pull-debian-debdiff pull-lp-source requestsync sponsor-patch submittodebian suspicious-source syncpackage ubuntu-build ubuntu-iso update-maintainer wrap-and-sort
[23:54] <ari-tczew> bdrung: use pastebin ;D
[23:54] <bdrung> ari-tczew: for one short line? :P
[23:54] <ari-tczew> bdrung: I'm kidding
[23:55] <bdrung> me too
[23:55] <tumbleweed> bdrung: doing that whenever you use launchpadlib is horrible. I'd rather just run a regex on the pylint output
[23:55] <bdrung> tumbleweed: if you prefer reqex, you can do that too
[23:55] <Bachstelze> sendmail has the same linker problem as autofs, just the wrong flags order
[23:56] <Bachstelze> I would bet a lot of money that a lot of the FTBFSs are the same
[23:59] <ari-tczew> Bachstelze: looking on lucas__' ftbfs script you can see the reason :P