[02:32] <ausxxh> in ubuntu is tgt or iscsitarget default for openstack/cinder?
[05:47] <pitti> Good morning
[06:48] <dholbach> good morning
[07:02] <stgraber> chiluk: so, for bug 1057358, I didn't upload the fix, but it sounds like someone re-uploaded the exact same broken fix as last time... I said I'd take care of this when I had time but it looks like that wasn't good enough for somebody who went ahead anyway
[07:03] <stgraber> chiluk: for bug 1069570, the "fix" is a feature addition in isc-dhcp, so I have no plan to SRU it as it's against SRU policy
[07:48] <tkamppeter_> OdyX, I have released cups-filters 1.0.34, uploaded it to Ubuntu and committed it to the Debian BZR.
[07:58] <OdyX> tkamppeter_: aye. Won't have time today unfortunately.
[07:58] <pitti> tkamppeter_: need some Debian sponsoring?
[08:00] <OdyX> pitti: ah yeah, if you could upload it to experimental, it would be great.
[08:00] <pitti> OdyX: I'll update the changelog for Debian then
[08:01] <OdyX> pitti: of course. :-) .oO(And in these cases, uploading there first, and syncing looks like a good plan to me, but I'm not enough into Ubuntu to know…)
[08:04] <pitti> sbuilding..
[09:41] <apachelogger> Laney: yes (about kdiff3 and im-config)
[09:41] <Laney> ah, because I checked the Debian BTS list for im-config and didn't see it
[09:43] <apachelogger> I wasn't particularly in the mood to file tickets in all the broken software I saw yesterday, so I sent mails to the authors
[09:44] <Laney> if you add patch headers then people can find this information out without having to check with you
[09:48] <apachelogger> good point
[10:15] <tkamppeter> OdyX, pitti, I know that getting usually synced packages to Debian first is the better way, I only quickly upload into Ubuntu as we ara in a stage close to release and so the packages should get in quickly to get more testing.
[10:27] <OdyX> tkamppeter: yeah, np, as long as the general rule stays first-to-experimental-when-reasonable, I'm happy.
[10:33] <pitti> cjwatson, Daviey: from the desktop side, seb128 proposed to turn off apport now as for raring we won't change a lot any more and we have errors.u.c.; any opinion from you from the foundations/server side?
[10:34] <pitti> (for crash reports)
[10:35] <xnox> ev: see pitti above ^
[10:36] <Daviey> pitti: It makes little difference to server TBH. So i don't object.
[10:36] <cjwatson> pitti: I'm OK with that if ev is
[10:36] <ev> pitti: to be clear, leave it running for reporting to errors.ubuntu.com? Just turning it off for reporting to Launchpad, right?
[10:36] <pitti> ev has lobbied for turning off apport LP reports all the time :)
[10:36] <pitti> ev: correct
[10:36] <ev> pitti: fine by me then
[10:37] <ev> and yeah, the sooner we can make errors.u.c a suitable replacement for using LP bugs as a crash database for seb128 and others, the better :)
[10:37] <Daviey> ev: Do you have some recent documentation how server users can add more value to errors.ubuntu.com?
[10:38] <ev> Daviey: I still need to implement an automatic non-interactive reporting toggle :-/
[10:38] <pitti> ev, seb128: oh, and we've traditionally kept "Type: Package" reports on LP
[10:38] <Daviey> (In Raring+1, I'd really like us to considering running the dev cycle with it submit-by-default, easy opt-out - and turn off at B1.
[10:38] <pitti> i. e. upgrade errors
[10:38] <seb128> pitti, is e.u.c listing those?
[10:39] <pitti> seb128: yes
[10:39] <dpm> pitti, cjwatson, if we get the language pack exports from Launchpad to be part of the new release opening process, do you think it might make sense to add the step to set up the language packs PPA for the new release on https://wiki.ubuntu.com/NewReleaseCycleProcess ?
[10:39] <cjwatson> feel free
[10:39] <ev> pitti: those things are the bane of my existence. Can we sit down at not-UDS with some dpkg/apt/aptd/software-center/ohmygodtoomanypieces people and come up with a better signature algorithm?
[10:39] <pitti> seb128, ev: I have no strong opinion about package problems on LP
[10:40] <ev> I'm not convinced the current wall of text is particularly useful for grouping them together.
[10:40] <pitti> +1
[10:40] <pitti> they are incredibly hard to process even manually
[10:40] <ev> yay
[10:41]  * ev nods
[10:41] <pitti> it often takes nontrivial smarts to figure out what the actual problem is
[10:41] <xnox> ev: pitti: so we often tell people to run `ubuntu-bug ubiquity` to collect and submit all the installation logs. Would they simply arrive to errors.u.c or whould that command just do nothing?
[10:41] <pitti> xnox: bug reports have never been disabled
[10:41] <pitti> specifically, errors.u.c. isn't well suited for manual bug reports
[10:41] <pitti> so they always go to LP, even for stables
[10:42] <xnox> pitti: ah, ok. than it's all good. So it's just apport popups for "something crashed" will stop taking people to +filebug ?!
[10:42] <pitti> right
[10:42] <Daviey> ev: Are you likely going to have capacity to add server lovin' to whoopie in raring+1?
[10:42] <xnox> pitti: awesome. +1 from me ;-)
[10:42] <ev> Daviey: I really hope so.
[10:42] <ev> But extra hands are always welcome
[10:42] <Daviey> ev: If we can help.. just let me know.
[10:43] <doko> pitti, jibel: python3.3 now ready for autopkgtest's
[10:43] <ev> Daviey: find me someone to write a bit of code to automatically process and upload an apport report.
[10:43] <pitti> doko: \o/
[10:43] <ev> It's really not that much work - I'm just buried under the day-to-day operations.
[10:43] <pitti> doko: can we disable the one test that relies on stdin existing? or was that fixed/dropped in 3.3?
[10:43] <ev> s/upload/mark for upload/g
[10:43] <pitti> seb128, ev: apport uploaded
[10:43] <ev> Daviey: basically apport-cli without the interaction and an upstart job
[10:43] <doko> pitti, please first run the test
[10:44] <ev> yay
[10:44] <pitti> doko: is it in some branch?
[10:44] <doko> pitti, it might be different, because subprocess handles file desriptors different in 3.x
[10:44] <pitti> ah, I just got a closed bug mail, apparently you uploaded already
[10:46] <cjwatson> pitti: I thought I contributed debian/script.py some time back to fix that test
[10:46] <pitti> ok, will still take a bit until jenkins hits it
[10:46] <cjwatson> does the autopkgtest not use it?
[10:47] <pitti> I'm already running a VM on my workstation right now, I have too little RAM to run a second one with py3.3; but can do in teh afternoon
[10:47] <doko> cjwatson, it doesn't help (I think), if apt-run enables the redirection
[10:47] <pitti> cjwatson: apparently not; but the failure is easy to reproduce with "python2.7 -E -Wd -3 -E -tt /usr/lib/python2.7/test/regrtest.py -w test_file2k </dev/null"
[10:47] <cjwatson> not sure I agree; debian/script.py should work regardless of the prior state of stdin
[10:48] <pitti> is debian/script.py a wrapper which the tests should be run under?
[10:48] <cjwatson> yes
[10:48] <doko> they do in the build
[10:48] <cjwatson> right, grep debian/rules for it
[10:49] <seb128> pitti, danke
[10:50] <pitti> python debian/script.py foo 'python2.7 -E -Wd -3 -E -tt /usr/lib/python2.7/test/regrtest.py -w test_file2k' < /dev/null
[10:50] <pitti> ^ works
[10:50] <pitti> foo → /dev/null works as well (we aren't actually interested in the output)
[10:51] <pitti> so that should be added to debian/tests/testsuite ?
[10:51] <pitti> jibel: ^ FYI (as you were looking at that, too)
[10:52] <cjwatson> pitti: just to check, you're testing this within adt-run and not just from a terminal?
[10:52] <pitti> I tested that particular bit in a terminal
[10:53] <pitti> I ran the full thing under run-adt-test (i. e. adt-run in a VM) and adt-run (i. e. on my workstation), and reduced the failure to above command
[10:53] <dpm> cjwatson, ok, thanks, will do (re: new release openings and translations). pitti, do you have the steps documented somewhere to set up the langpacks PPA for dev releases, or can you give me a couple of bullet points and I'll add them to the wiki page?
[10:53] <cjwatson> tests in a terminal are misleading here because in a terminal you have a useful stdin
[10:53] <pitti> adt-run redirects stdin, causing the failure of that particular test
[10:53] <cjwatson> anyway, yeah, debian/script.py is very likely the right answer
[10:54] <pitti> cjwatson: the "</dev/null" should disable that, though?
[10:54] <cjwatson> right
[10:54] <cjwatson> I wasn't sure exactly what you meant by "foo → /dev/null", that's all
[10:54] <cjwatson> → not being a redirection operator in my shell :-)
[10:54] <pitti> dpm: langpack PPA to NewReleaseCycleProcess> yes from my side; you can add me as a contact point
[10:55] <pitti> dpm: we don't actualy use the PPA for dev releases, we upload straight to raring; we just need to do a first manual build (once we have an export), and then set up the crontabs
[10:55] <pitti> dpm: but we should set up the cronjobs for the stable releases when opening a new dev release
[10:55] <dpm> pitti, yeah, I'm documenting that too
[10:56] <cjwatson> damnit, haskell-hakyll hangs on the buildds - I could've sworn I'd fixed that
[10:56] <dpm> thanks
[10:56] <pitti> cjwatson: right, sorry; I meant: python debian/script.py /dev/null 'python2.7 -E -Wd -3 -E -tt /usr/lib/python2.7/test/regrtest.py -w test_file2k' < /dev/null
[10:56] <pitti> i.e. just replacing the "foo" in my orignal call with /dev/null
[10:56] <cjwatson> ah, gotcha
[10:57] <cjwatson> I'd recommend just running the entire suite under debian/script.py and catting the logfile at the end, or similar?
[10:57] <pitti> yes, sounds good
[10:58] <pitti> cjwatson: actually, we don't need to cat the log file; output still goes to stdout AFAICS?
[10:58] <doko> pitti, and enable xvfb too, and fix the disabled tests for running in the installed location ;)
[10:58] <pitti> (hence my "/dev/null" log file proposal)
[10:59] <cjwatson> pitti: oh, yes, true
[10:59] <cjwatson> forgot my own code
[10:59] <pitti> doko: one step at a time :) but it's great to have coverage for the pythons now!
[11:26] <cjwatson> Laney: so, slightly perplexingly, this ghc change changes the libghc-ghc-dev ABI hash on i386 (although none of the others), and the debdiff shows the addition of /usr/share/man/man1/runghc.1.gz, /usr/share/man/man1/ghci-7.6.2.1.gz, and /usr/share/man/man1/ghci.1.gz
[11:26]  * Laney blinks
[11:26] <cjwatson> Laney: ghci still works fine; I wonder if some of this depends on which ghc was used to build (IOW the effective change here might simply be that I'm building ghc with ghc 7.6 rather than ghc 7.4)
[11:27] <Laney> That wouldn't surprise me
[11:27] <cjwatson> and libghc-ghc-dev changing hash isn't a problem if it's going to change on armhf anyway; it just surprised me
[11:35] <Laney> cjwatson: I just turned up http://thread.gmane.org/gmane.comp.lang.haskell.debian/3287
[11:37] <cjwatson> Ah, yes, the tail-end of that thread matches
[11:38] <cjwatson> If the armhf build also only changes the ghc hash then I think we're good enough
[11:38] <Laney> "In fact, I'm pretty impressed that we manage to get the same hashes even
[11:38] <Laney> sometimes."
[11:38] <cjwatson> heh, yeah, I liked that
[11:38] <Laney> at least he's honest!
[11:42] <cjwatson> I believe the reverse chain is (1) doctest, ghc-mtl, ghc-syb-utils, gitit, haddock (2) hint
[11:42] <cjwatson> Which seems tolerable
[11:47] <jibel> doko, pitti sorry lunch break. I'll run the testsuite in our environment with script.py
[12:24] <jibel> doko, python2.7 testsuite pass when run under script.py
[12:24] <doko> jibel, the other tests too?
[12:26] <tim`> is there a reason raring is sticking with boost 1.49 instead of moving up to 1.53?
[12:27] <tim`> errr 1.50 maybe - looks like both are packaged
[12:29] <cjwatson> tim`: regardless of reasons it's far too late now - boost transitions take time
[12:30] <cjwatson> we do them at or near the start of release cycles
[12:30] <jibel> doko, yes, the 3 tests that failed yesterday: stdin, fsync and fdatasync. For fsync I removed eatmydata. IO performance is good enough with unsafe-io enabled in dpkg.
[12:30] <tim`> just curious if there was something specific holding it up
[12:31] <tim`> or if there was just not much interest
[12:31] <doko> jibel, ok, thanks! for bonus points you may want to re-enable the tests in the test scripts, and then send patches to fix these =)
[12:31] <doko> tim`, time ... and there is no 1.50 anymore
[12:32] <pitti> doko: https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-python3.3/, FYI
[12:32] <tim`> when do versions for 13.10 get laid out ?
[12:32] <pitti> Invalid -u/--use option: all,-network,-urlfetch,-gui,-xpickle
[12:32] <pitti> Use --help for usage
[12:33] <pitti> it didn't get very far
[12:33] <doko> pitti, my browser tries to download these files. is there a way to show these in the browser?
[12:33] <pitti> doko: not that I know of; but you can use the "console output", that will be displayed inline
[12:33] <pitti> I just look at them in gedit
[12:34] <pitti> doko: "Konsolenausgabe" is at the left menu, leading to https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-python3.3/1/ARCH=i386,label=adt/console
[12:35] <doko> apw, ogasawara: I'm preparing an upload of the final GCC 4.7.3. the current version in r already has 4.7.3 as the "upstream" version. There are no changes on x86, compared to the current version. still looking at armhf and arm64
[12:35] <cjwatson> tim`: only a handful of toolchain packages need to be decided early
[12:35] <cjwatson> tim`: so nowish or before, and AFAIK it'll be boost 1.53
[12:36] <doko> we switch to 1.53 together with GCC 4.8
[12:36] <doko> at least, that's my plan
[12:36] <doko> xnox had already set up the transition tracker
[12:38] <apachelogger> cjwatson: I forgot to remove the colors yesterday, https://code.launchpad.net/~kubuntu-members/debian-cd/kubuntu-raring-artwork/+merge/158350 should fix this
[12:40] <cjwatson> apachelogger: merged/deployed, thanks
[12:40] <tim`> oh man - gcc 4.7 breaks enough things already :)
[12:41] <apachelogger> cjwatson: thank you
[12:42] <xnox> tim`: well and gcc 4.8 fixes a lot of C++11 things that were missing in 4.7 ;-)
[12:43] <tim`> will there likely be an alt gcc-4.6 package still ?
[12:44] <xnox> tim`: raring has 1.49 as default and 1.53 available in universe. The plan for next cycle (S-something) is to have 1.53 the one and only atm. We might be switching to 1.54 or have it available in universe, all depends on upstream release timing.
[12:44] <tim`> cool
[12:44] <xnox> tim`: why do you want gcc-4.6?
[12:45] <xnox> boost-1.53 is looking very good so far: http://people.canonical.com/~xnox/boost1.53/
[12:45] <tim`> i guess the issues i've run into are with cuda and zeroc-ice - ice has sorted out thier issues by now - not sure about cuda
[12:45] <xnox> still a few things to fix, but nothing out of the ordinary.
[12:45] <cjwatson> we only remove older gcc packages once nothing in our archive requires them any more
[12:46] <cjwatson> we do generally have to keep moving forward though, otherwise the hill to climb is just that much higher later on
[12:46] <tim`> yeah - understandable
[12:46] <mitya57> we still have gcc-4.6 in raring (and even 4.4), but I wouldn't recommend anyone to use that
[12:50] <doko> 4.4 will die in the s-series, killing all the games packages implemented in Dv1
[12:50] <doko> working on getting D to 4.8, so 4.6 can die too
[12:51] <tim`> D?
[12:51] <doko> not C
[12:52] <mitya57> https://en.wikipedia.org/wiki/D_(programming_language)
[12:52] <tim`> ah yes
[12:53] <NCommander> Beside D, is there any other unusual GCC frontends hanging around? (I know GNAT is kinda special though thats fortunately mainstream ...)
[12:53] <siretart> go?
[12:54] <xnox> siretart: we have go even in precise ;-)
[12:54] <xnox> siretart: 4.8 has some support for 1.1.
[12:55] <sconklin> @pilot out
[13:09] <doko> NCommander, do you want to package the PL/1 and Cobol frontends?
[13:11] <NCommander> doko, don't we already have opencobol in archive? (and no, I don't :-P)
[13:49]  * xnox really thinks old-style cmake find modules are brain dead..... goes to file a patch to FindZlib.cmake to include /usr/include/$(MULTIARCH) in the $ZLIB_INCLUDE_DIRS
[13:49] <xnox> that looks wrong... and still doesn't solve my ftbfs... looking more.
[13:57] <jamespage> pitti, could you take a look at https://code.launchpad.net/~james-page/ubuntu/raring/apport/cloud-archive/+merge/158378 - it adds a crashdb config and handler to pickup packages from the ubuntu cloud archive
[13:57] <jamespage> I'd like to backport the same into 12.04 as well
[13:59] <pitti> jamespage: do you figure that users will have a need to change that configuration?
[13:59] <jamespage> pitti, not quite sure I understand your question
[14:00] <pitti> jamespage: I'd start with putting the actual configuration into the hook, instead of adding it to the config file
[14:00] <jamespage> pitti, ah - so add the crashdb configuration to the ubuntu_cloud.py hook itself - right - lemme give that a go
[14:01] <pitti> jamespage: right, like report['CrashDB'] = '{"impl": "launchpad", ....}'
[14:03] <jamespage> pitti, working on that now
[14:03] <pitti> jamespage: and as a style nitpick, let's drop the line break and the parens in the if
[14:04] <jamespage> pitti, ack
[14:19] <jamespage> pitti, hmm - so on 12.04 I got a origin text in the package field - how do I detect the source of the package in raring?
[14:20] <pitti> jamespage: oh, inline config doesn't work in 12.04 yet, there we'll need a file in /etc/apport/crashdb.conf.d/
[14:20] <jamespage> pitti, yeah - I just noticed that :-)
[14:20] <jamespage> OK - so for 12.04 I need a crashdb config in crashdb.conf.d
[14:20] <pitti> jamespage: you should get the origin text in raring as well, but only if it's actually from a PPA
[14:20] <pitti> jamespage: if not, then it's the ubuntu package
[14:21] <jamespage> pitti: these packages come from ubuntu-cloud.archive.canonical.com
[14:21] <pitti> jamespage: you can check explicitly with if apport.packaging.is_distro_package(report['Package'].split()[0]):
[14:21] <pitti> jamespage: you don't get an [origin: ...] field in raring?
[14:25] <jamespage> pitti, lemme check again
[14:29] <doko> Sweetshark, bug subscriptions for liblangtag missing ...
[14:30] <xnox> doko: http://paste.ubuntu.com/5698613/        isn't         /usr/include/x86_64-linux-gnu/ missing from that list?
[14:30] <doko> damn, he did smell that
[14:32] <doko> $ gcc -v -E -dM - < /dev/null 2>&1| grep '^ '
[14:32] <doko>  /usr/lib/gcc/x86_64-linux-gnu/4.7/cc1 -E -quiet -v -imultilib . -imultiarch x86_64-linux-gnu - -mtune=generic -march=x86-64 -fstack-protector -dM
[14:32] <doko>  /usr/lib/gcc/x86_64-linux-gnu/4.7/include
[14:32] <doko>  /usr/local/include
[14:32] <doko>  /usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed
[14:32] <doko>  /usr/include/x86_64-linux-gnu
[14:32] <doko>  /usr/include
[14:32] <doko> xnox, works for me. why do you call cc1 directly?
[14:35] <jamespage> pitti, it would appear not
[14:35] <doko> Sweetshark, bug subscriptions for liblangtag missing ...
[14:36] <xnox> doko: hmm.... thanks that your command also works for me.
[14:38] <xnox> doko: trying to understand https://launchpadlibrarian.net/136352236/buildlog_ubuntu-raring-armhf.sword_1.6.2%2Bdfsg-5ubuntu1_FAILEDTOBUILD.txt.gz
[14:39] <xnox> zlib.h is in non-arch qualified, zconf.h is in arch-qualified location. Yet somehow zconf.h doesn't get included from zlib.h..... probably cmake/that package silliness.
[14:39] <xnox> then.
[14:40] <jamespage> pitti, packaging.get_package_origin give me 'Canonical' - I think thats good enought for my filter
[14:42] <doko> xnox, the -I/usr/lib/arm-linux-gnueabihf looks suspcicious, but shouldn't hurt
[14:43] <doko> -- CONFIGURING SOURCE LIST
[14:43] <doko> -- ZLib: system /usr/lib/arm-linux-gnueabihf/libz.so
[14:43] <doko> -- cURL: system /usr/lib/arm-linux-gnueabihf/libcurl.so and /usr/include
[14:46] <apw> doko, thanks
[14:51] <Sweetshark> doko: thx for adding
[14:52] <doko> xnox, ^^^ so for curl it does detect the include, but not for zlib ?
[14:52] <doko> cmake madness?
[14:54] <stokachu> xnox: am i reading nmu wrong? i thought since im not the maintainer it should be filed as such (re sosreport)
[14:56] <xnox> stokachu: from the point of view of the Debian Project - the package maintainer is the person who uploads and maintains the package in debian. the upstream contact is who wrote the software and is the main committer, the upstream contact can be mentioned in ./debian/copyright
[14:57] <xnox> stokachu: NMU is when another person makes an upload of the debian package on-behalf of the regular package maintainer.
[14:57] <xnox> stokachu: for example if you upload xiphos into debian, instead of me, that would be NMU. As I'm debian maintainer for xiphos.
[14:57] <stokachu> ahh
[14:58] <xnox> stokachu: if I upload sosreport into debian instead of you, that would be NMU. As i will not be the regular maintainer of that package.
[14:58] <cjwatson> filing a bug report with "NMU" in the title is kind of a declaration of intent
[14:58] <cjwatson> assuming that's what you mean
[14:58] <xnox> cjwatson: stokachu meant to do an ITP ;-)
[14:58] <jamespage> pitti, how does that look - https://code.launchpad.net/~james-page/ubuntu/raring/apport/cloud-archive/+merge/158378
[14:59] <stokachu> ok so do i close this sponsor request
[14:59] <jamespage> seems to work OK for me (although the test on raring is a little artificial as the cloud archive is really just for 12.04
[14:59] <jamespage> )
[14:59] <xnox> stokachu: one files an ITP if you intend to upload and hence become package maintainer in debian for that new piece of software.
[15:00] <pitti> jamespage: splendid!
[15:00] <stokachu> xnox: yea thats what i need to do
[15:00] <cjwatson> stokachu: don't close the bug and open a new one - that's pointless
[15:00] <cjwatson> stokachu: mutate it into what it's supposed to be instead with control commands
[15:00] <pitti> jamespage: yeah, but it doesn't hurt to have it there, so that it will be there for the next LTS, or if we actually get a cloud archive for raring for some reason
[15:00] <stokachu> ok
[15:00] <cjwatson> http://www.debian.org/Bugs/server-control
[15:00] <jamespage> pitti, yes indeed - that's kinda what I thought
[15:01] <xnox> stokachu: well open an ITP with cc to debian-devel, and mutate the sponsorship request =)
[15:01] <jamespage> pitti, are you OK for me to upload that and push the branch?
[15:01] <stokachu> so i should have an ITP ane a sponsorship request bug
[15:01] <pitti> jamespage: I just hope that ~cloud is a sufficiently tight test
[15:01] <stokachu> and*
[15:01] <xnox> stokachu: as one should file ITP to "announce" that you are about to take-up a package.
[15:02] <jamespage> pitti: I think ~cloud with origin 'Canonical' is
[15:02] <stokachu> xnox: 698329
[15:02] <pitti> jamespage: sure, please do (and use  "dch -r" and "debcommit -r" after that)
[15:02] <jamespage> pitti, ack
[15:02] <xnox> stokachu: yeah. As ITPs are usually forwarded to debian-devel and some people can point out typpos in the descriptions, or reason for a package to be not included in debian and such like. Just google for "ITP" on debian-devel to get the sense of those bugs/descriptions.
[15:02] <xnox> stokachu: new maintainer guide should tell you all about these things.
[15:03] <stokachu> yea ive been reading through the guides but i guess i got confused on nmu versus itp
[15:05] <BenC> infinity: any reason that linux-ppc-3.8.0-8 isn't in raring proper yet?
[15:05] <xnox> stokachu: in ubuntu we do not have "strong maintainership" instead anyone can upload anything, thus the concept of NMU is non-existent in ubuntu.
[15:06] <cjwatson> BenC: it's waiting for me to upload debian-installer
[15:06] <BenC> cjwatson: Ah, ok, thanks
[15:06] <cjwatson> which in turn is waiting for somebody to approve libdebian-installer in the upload queue
[15:06] <BenC> Just making sure it doesn't fall through the cracks :)
[15:06] <stokachu> xnox: ahh
[15:06] <stokachu> xnox: its all making sense now :)
[15:23] <cyphermox> slangasek: I'd remove the duplication for https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1073433 if you don't mind, I can definitely reproduce the / is busy even after manually stopping and killing just about everything before doing a reboot; I got lsof after the stops and all, and there's very little left around
[15:42] <slangasek> cyphermox: ok, so what is keeping the root fs busy?
[15:45] <cyphermox> slangasek: I don't know ;)
[15:46] <cyphermox> slangasek: http://paste.ubuntu.com/5698847/  <-- I think "sh", is related to sendsigs too, there are no sessions open at the time in VTs or in lightdm or anywhere
[15:47] <cyphermox> certainly running lsof like so adds one more thing to write to /, but the same issue appears even if I comment out that part
[15:47] <cyphermox> (I had lsof run as part of sendsigs)
[16:40] <pitti> stgraber, Laney: could you please accept ~ubuntu-core-dev invitation into ~network-manager?
[16:40] <pitti> with that, core devs can finally push to the NM packaging branch
[16:40] <stgraber> pitti: yep, will do
[16:41] <stgraber> done
[16:41] <pitti> stgraber: merci!
[16:41] <pitti> jamespage: http://launchpadlibrarian.net/136986347/apport_2.0.1-0ubuntu17.1_2.0.1-0ubuntu17.2.diff.gz LGTM
[17:22] <jamespage> pitti, great!
[18:01] <tkamppeter> OdyX, I have added a new USB quirk rule patch (5 printers) to CUPS and also submitted it upstream, it also contains your correction for the Stylus Photo 750. See Debian GIT, new Ubuntu CUPS package, and https://www.cups.org/str.php?L4311.
[18:23] <bryce> slangasek, does udev automatically reload all rules at boot, or do you have to deliberately run udevadm trigger?
[18:24] <bryce> (or udevadm control --reload-rules; google gives me some conflicting recommendations)
[18:46] <smoser> cjwatson, do you know how i can make debian installer not go into vga mode from the netboot iso?
[18:46] <smoser> trying to boot with 'kvm -curses'
[18:47] <smoser> kirkland, for some reason i think maybe you have known that?
[18:49] <slangasek> bryce: so, if by "reload" you mean "load from disk when started from the root filesystem"... sure?
[18:49] <slangasek> bryce: what's the root problem here?
[18:51] <bryce> slangasek, for the gpu hang apport hook, which is started by a udev rule, I wanted to disable that for the release, so commented out the line in the udev rule.  However I'm noticing we're still getting a few reports, so am wondering if something more needs done to get the rule disabled for folks.
[18:52] <slangasek> bryce: udev has an in-memory cache of the rules (naturally), but otherwise reads them from disk on every boot.
[18:54] <bryce> slangasek, ok, that's what I thought.  But I can't explain how bug #1168066 got autofiled.  I mean it's good that it got filed, it's a legit bug.  But AFAIK the rule should not be filing these bugs anymore so I'm a bit perplexed.
[18:56] <slangasek> bryce: we're talking about /lib/udev/rules.d/40-xserver-xorg-video-intel.rules, right?
[18:57] <bryce> slangasek, yes
[18:57] <slangasek> bryce: I have the version of the package from that bug installed, and I see a present and active udev rule
[18:57] <slangasek> so it doesn't seem to actually be disabled in the package?
[19:00] <bryce> slangasek, not commented out?
[19:00] <slangasek> bryce: nope
[19:00] <slangasek> # Disable freeze hook.
[19:00] <slangasek> SUBSYSTEM=="drm", ACTION=="change", ENV{ERROR}=="1", RUN+="/usr/share/apport/apport-gpu-error-intel.py"
[19:00] <slangasek> there's a nice comment /above/ it ;)
[19:00] <bryce> hum, that could be the problem.  It *is* commented out in the package
[19:00] <slangasek> define "in the package"
[19:01] <slangasek> that's the unmodified version of the file, from the binary package in the archive
[19:01] <bryce> apt-get source xdiagnose; cat xdiagnose-3.4.4/debian/xdiagnose.udev
[19:02] <slangasek> bryce: oh, but it's not shipped by xdiagnose
[19:02] <slangasek> it's shipped by xserver-xorg-video-intel!
[19:02] <bryce> o_O
[19:03] <ogra_> heh
[19:05] <bryce> ahem.  yay leftovers.
[19:46] <barry> slangasek: so, apt-ftparchive.  between mvo and i, we've uploaded for raring and sru for precise.  i *think* i've got a chroot to build for lucid-cat.  now the fun bit: lucid dpkg-source can't parse multiarch deps like gettext:any.  it's probably okay to just remove :any from the build-dep (it's the only bd with that that i can see).  agreed?
[19:47] <slangasek> barry: definitely yes
[19:47] <barry> slangasek: cool.  we'll see if that makes the package buildable :)
[19:49] <barry> slangasek: hmm, likely will have to bump down some dep version numbers as well
[20:03] <slangasek> bryce: so I guess that also explains why I was getting two apport popups for every gpu hang ;D
[20:06] <bryce> slangasek, and also why we were still getting false gpu reports after we thought we fixed it...
[20:19] <roadmr> hello! when doing a pxe installation with raring, entries in /etc/network/interfaces appear borked ;/ there's no space between the lo and eth0 stanzas. Is this known or should I file a bug?
[20:22] <sarnold> roadmr: can't go wrong with a bug report :)
[20:23] <roadmr> sarnold: ok, makes sense, let me research this a bit more and then I'll file
[20:50] <bryce> slangasek, sru's are in for that.  thanks for noticing the redundant rule.
[21:11] <dobey> barry: is bug #1071897 still relevant at all or should i just close it as invalid?
[21:12] <barry> dobey: i haven't tried recently.  let me grab it and try.
[21:13] <dobey> barry: does it even matter now? 4.2.0 is in rarning now, and this bug is from ~5 months ago when lots of deps were changing
[21:14] <barry> dobey: yeah, probably doesn't
[21:23] <barry> dobey: well, the test suite is still giving me errors on a local sbuild.  if it's not breaking on the buildd's, i'll close my eyes and pretend they aren't happening.
[21:27] <dobey> barry: it works building in 3 PPAs and the official archive, so not sure what the difference would be exactly to cause it to fail locally for you
[21:27] <barry> dobey: me neither, but if you don't care i don't either :)
[21:30] <dobey> barry: i do know i had problems with ubuntu-sso-client when trying to switch from pbuilder to sbuild for testing locally, and i think there is a config difference with the lp builders vs. local sbuild, where the issue doesn't occur on the lp builders, so maybe it's related to that. but i haven't had time to deal with fixing it, and it's a fairly complicated thing to fix
[21:34] <cjwatson> smoser: https://help.ubuntu.com/12.04/installation-guide/i386/boot-parms.html - DEBIAN_FRONTEND=text
[21:35] <cjwatson> barry: the fact that you're asking that question (gettext:any) makes me a bit concerned that you're trying to drop the whole of raring's apt into lucid-cat, rather than cherry-picking the relevant patches - is that the case or am I missing something?
[21:35] <cjwatson> (or precise-updates' apt into lucid-cat, either way)
[21:57] <slangasek> cjwatson: yep, sorry, I may have suggested to barry that a full apt backport from precise-updates /might/ possibly be easier
[21:57] <barry> cjwatson: well, i was being optimistic, but i think it's not the right way to go.  unfortunately, the apt code in question has changed significantly since lucid, so the precise/raring patch has little hope of applying to the lucid version.  i've been talking with mvo over email about it, and he'll probably take a crack at producing a lucid version of the patch instead
[21:57] <slangasek> but apparently this was me forgetting just when lucid was :-)
[21:57] <barry> slangasek: ;)
[21:58] <slangasek> (i.e.: before multiarch... and apparently also before dpkg-symbols supported c++ names!)
[21:58] <barry> slangasek, cjwatson maybe we should convince is to just upgrade to precise already :)
[21:58] <slangasek> barry: depends on how soon we want this bug fixed
[21:58] <barry> slangasek: yeah.  the bug report made it sound like a big deal for some folks
[22:00] <barry> anyway, let's see if mvo can help us out here before we worry too much
[22:17] <celso_> People,  i need something that install the updates available until last week. but i dont want to install the ones after that. how do i do that? i need this to detect a regression.
[22:19] <sarnold> celso_: there's a log of package operations in /var/log/dpkg.log -- perhaps that can help you
[22:20] <geofft> celso_: ask xnox if he's deployed our LP-Librarian-using snapshot code yet :)
[22:20] <geofft> I can probably cobble something together if you give me a timestamp
[22:23] <celso_> i will explain what is happening. until near last week, my laptop was doing fine, using vgaswitcheroo to turn off my atihd5000 series to use my intell hd3000. after the last week updates (near that time) my laptop almost 90% of the time, when booting, it stays with the black screen.
[22:24] <celso_> but it won't happen if i don't install the updates, so, something has gone wrong in some file updated.
[22:24] <celso_> and i would like to find what is.
[22:25] <celso_> but unfortunatly, i am no developer or programer.
[22:25] <celso_> so, i am kind of "stuck"
[22:25] <sarnold> celso_: If I understand what I've seen others report, plymouth fights lightdm for console during boot.. you may wish to search for bugreports with both those names
[22:27] <celso_> but it don't even show a console. it stays with completely black screen with brightness and with some disk activity each half second.
[22:28] <celso_> i think a feature to install/block updates by time would be a good feature to debug some bugs
[22:30] <celso_> the problem for dpkg.log is it will not show the time each update become available if i install all now
[22:30] <celso_> i think
[22:31] <sarnold> celso_: true enough, it only shows what happened on that one machine..
[22:32] <celso_> i will install 100 updates each time and will see what happens, and then cut another half, and again....
[22:33] <celso_> it will cost alot of bandwitch but its the only way i can see.
[22:34] <celso_> brb and by the way, thanks for the help!
[22:36] <stokachu> if there is a LICENSE file and a debian/copyright but the package is for both Debian and Fedora do I renamed the LICENSE file to like LICENSE.Fedora?
[22:36] <sarnold> celso_: apt-cacher-ng or apt-cacher can easily cache packages that you download, it can drastically save time here
[22:37] <celso_> ok. i will try.
[22:39] <celso_> thanks!
[22:45] <ion> Also see squid-deb-proxy
[22:46] <celso_> have to restart. brb
[23:18] <stokachu> so if an upstream source has a LICENSE file is it acceptable to remove it during a debian build? lintian keeps reporting an extra-license-file error
[23:18] <stokachu> i have updated debian/copyright accordingly
[23:48] <slangasek> stokachu: it doesn't make sense to remove it from the source tree during the build, but you can use any of a number of techniques to make sure it doesn't ship in the binary package, yes
[23:49] <stokachu> slangasek: any urls you can point me to? googling is failing for me :(
[23:49] <slangasek> stokachu: might be better to use a worked example
[23:49] <slangasek> stokachu: can you point me at your package?
[23:50] <stokachu> so right now im working off https://github.com/sosreport/sosreport/tree/master/debian
[23:50] <stokachu> using debhelper and the Makefile is what is forcing a install of LICENSE into /usr/share/sos/.
[23:50] <stokachu> so one thing i thought of was to let debian and rpm spec handle the actual copying of the license file and removing it out of the makefile
[23:52] <slangasek> stokachu: (the reason I suggest this is that "how do I exclude this file" is dependent on the style of packaging in use... it might be a matter of fixing debian/sos.install, or calling 'rm debian/sos/usr/share/sos/LICENSE' in debian/rules)
[23:52] <slangasek> stokachu: python-support is deprecated, please use dh_python instead (wiki link in one second)
[23:53] <stokachu> yea ive got a few changes i haven't committed yet
[23:53] <stokachu> lemme show you my branch one sec
[23:53] <slangasek> ok
[23:54] <stokachu> slangasek: https://github.com/battlemidget/sosreport/tree/debian-packaging/debian
[23:54] <stokachu> thats my latest work from after fixing all lintian errors
[23:55] <slangasek> stokachu: so I'd say the simplest approach here is:
[23:55] <slangasek> override_dh_auto_install:
[23:55] <slangasek> \tdh_auto_install
[23:55] <slangasek> \trm -f debian/tmp/usr/share/sos/LICENSE
[23:55] <stokachu> ah ok
[23:55] <stokachu> i tried override before but didnt call dh_auto_install first
[23:56]  * slangasek nods
[23:56] <stokachu> gonna try that now and test
[23:57] <stokachu> slangasek: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705192 trying to get this thing sponsored
[23:58] <stokachu> so far i think ive fixed all the warnings from message 29
[23:58] <slangasek> stokachu: you seem to still have a dep on python-support in your branch
[23:59] <stokachu> ah in my control file
[23:59] <stokachu> lemme remove that
[23:59] <stokachu> i also see this warning
[23:59] <stokachu> W: dh_python2:90: Python 2.7 should install files in /usr/lib/python2.7/dist-packages/. Did you forget "--install-layout=deb"?
[23:59] <stokachu> but when i look at the layout after it builds it is in dist-packages already