=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== Ursinha-afk is now known as Ursinha
ausxxhin ubuntu is tgt or iscsitarget default for openstack/cinder?02:32
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== freeflyi1g is now known as freeflying
=== Ursinha is now known as Ursinha-afk
=== security is now known as megha
=== Ursinha-afk is now known as Ursinha
=== hloeung_ is now known as hloeung
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== Ursinha is now known as Ursinha-afk
pittiGood morning05:47
=== Ursinha-afk is now known as Ursinha
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== geser_ is now known as geser
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
dholbachgood morning06:48
=== Ursinha is now known as Ursinha-afk
stgraberchiluk: 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 anyway07:02
ubottubug 1057358 in isc-dhcp (Ubuntu Precise) "dhcpd in isc-dhcp-server-ldap cannot read /etc/ldap/ldap.conf due to missing entry in apparmor profile" [Medium,Fix committed] https://launchpad.net/bugs/105735807:02
stgraberchiluk: 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 policy07:03
ubottubug 1069570 in MAAS "1 MAC Address, two IPs - DNS is "out of sync" with DHCP leases databases, I think..." [Critical,Triaged] https://launchpad.net/bugs/106957007:03
=== smb` is now known as smb
=== Ursinha-afk is now known as Ursinha
=== Ursinha is now known as Ursinha-afk
tkamppeter_OdyX, I have released cups-filters 1.0.34, uploaded it to Ubuntu and committed it to the Debian BZR.07:48
=== Ursinha-afk is now known as Ursinha
OdyXtkamppeter_: aye. Won't have time today unfortunately.07:58
pittitkamppeter_: need some Debian sponsoring?07:58
OdyXpitti: ah yeah, if you could upload it to experimental, it would be great.08:00
pittiOdyX: I'll update the changelog for Debian then08:00
OdyXpitti: 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:01
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== ckpringle_ is now known as ckpringle
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== Ursinha is now known as Ursinha-afk
=== security is now known as megha
=== Ursinha-afk is now known as Ursinha
apacheloggerLaney: yes (about kdiff3 and im-config)09:41
Laneyah, because I checked the Debian BTS list for im-config and didn't see it09:41
apacheloggerI wasn't particularly in the mood to file tickets in all the broken software I saw yesterday, so I sent mails to the authors09:43
Laneyif you add patch headers then people can find this information out without having to check with you09:44
apacheloggergood point09:48
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== tkamppeter_ is now known as tkamppeter
=== Ursinha is now known as Ursinha-afk
tkamppeterOdyX, 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:15
=== Ursinha-afk is now known as Ursinha
OdyXtkamppeter: yeah, np, as long as the general rule stays first-to-experimental-when-reasonable, I'm happy.10:27
pitticjwatson, 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:33
=== Ursinha is now known as Ursinha-afk
pitti(for crash reports)10:34
xnoxev: see pitti above ^10:35
Davieypitti: It makes little difference to server TBH. So i don't object.10:36
cjwatsonpitti: I'm OK with that if ev is10:36
evpitti: to be clear, leave it running for reporting to errors.ubuntu.com? Just turning it off for reporting to Launchpad, right?10:36
pittiev has lobbied for turning off apport LP reports all the time :)10:36
pittiev: correct10:36
evpitti: fine by me then10:36
evand 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
Davieyev: Do you have some recent documentation how server users can add more value to errors.ubuntu.com?10:37
evDaviey: I still need to implement an automatic non-interactive reporting toggle :-/10:38
pittiev, seb128: oh, and we've traditionally kept "Type: Package" reports on LP10: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
pittii. e. upgrade errors10:38
seb128pitti, is e.u.c listing those?10:38
pittiseb128: yes10:39
dpmpitti, 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
cjwatsonfeel free10:39
evpitti: 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
pittiseb128, ev: I have no strong opinion about package problems on LP10:39
evI'm not convinced the current wall of text is particularly useful for grouping them together.10:40
pittithey are incredibly hard to process even manually10:40
* ev nods10:41
pittiit often takes nontrivial smarts to figure out what the actual problem is10:41
xnoxev: 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
pittixnox: bug reports have never been disabled10:41
pittispecifically, errors.u.c. isn't well suited for manual bug reports10:41
pittiso they always go to LP, even for stables10:41
xnoxpitti: ah, ok. than it's all good. So it's just apport popups for "something crashed" will stop taking people to +filebug ?!10:42
Davieyev: Are you likely going to have capacity to add server lovin' to whoopie in raring+1?10:42
xnoxpitti: awesome. +1 from me ;-)10:42
evDaviey: I really hope so.10:42
=== doko_ is now known as doko
evBut extra hands are always welcome10:42
Davieyev: If we can help.. just let me know.10:42
dokopitti, jibel: python3.3 now ready for autopkgtest's10:43
evDaviey: find me someone to write a bit of code to automatically process and upload an apport report.10:43
pittidoko: \o/10:43
evIt's really not that much work - I'm just buried under the day-to-day operations.10:43
pittidoko: can we disable the one test that relies on stdin existing? or was that fixed/dropped in 3.3?10:43
evs/upload/mark for upload/g10:43
pittiseb128, ev: apport uploaded10:43
evDaviey: basically apport-cli without the interaction and an upstart job10:43
dokopitti, please first run the test10:43
pittidoko: is it in some branch?10:44
=== Ursinha-afk is now known as Ursinha
dokopitti, it might be different, because subprocess handles file desriptors different in 3.x10:44
pittiah, I just got a closed bug mail, apparently you uploaded already10:44
cjwatsonpitti: I thought I contributed debian/script.py some time back to fix that test10:46
pittiok, will still take a bit until jenkins hits it10:46
cjwatsondoes the autopkgtest not use it?10:46
pittiI'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 afternoon10:47
dokocjwatson, it doesn't help (I think), if apt-run enables the redirection10:47
pitticjwatson: 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
cjwatsonnot sure I agree; debian/script.py should work regardless of the prior state of stdin10:47
pittiis debian/script.py a wrapper which the tests should be run under?10:48
dokothey do in the build10:48
cjwatsonright, grep debian/rules for it10:48
seb128pitti, danke10:49
pittipython debian/script.py foo 'python2.7 -E -Wd -3 -E -tt /usr/lib/python2.7/test/regrtest.py -w test_file2k' < /dev/null10:50
pitti^ works10:50
pittifoo → /dev/null works as well (we aren't actually interested in the output)10:50
pittiso that should be added to debian/tests/testsuite ?10:51
pittijibel: ^ FYI (as you were looking at that, too)10:51
cjwatsonpitti: just to check, you're testing this within adt-run and not just from a terminal?10:52
pittiI tested that particular bit in a terminal10:52
pittiI 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 command10:53
dpmcjwatson, 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
cjwatsontests in a terminal are misleading here because in a terminal you have a useful stdin10:53
pittiadt-run redirects stdin, causing the failure of that particular test10:53
cjwatsonanyway, yeah, debian/script.py is very likely the right answer10:53
pitticjwatson: the "</dev/null" should disable that, though?10:54
cjwatsonI wasn't sure exactly what you meant by "foo → /dev/null", that's all10:54
cjwatson→ not being a redirection operator in my shell :-)10:54
pittidpm: langpack PPA to NewReleaseCycleProcess> yes from my side; you can add me as a contact point10:54
pittidpm: 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 crontabs10:55
pittidpm: but we should set up the cronjobs for the stable releases when opening a new dev release10:55
dpmpitti, yeah, I'm documenting that too10:55
cjwatsondamnit, haskell-hakyll hangs on the buildds - I could've sworn I'd fixed that10:56
pitticjwatson: 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/null10:56
pittii.e. just replacing the "foo" in my orignal call with /dev/null10:56
cjwatsonah, gotcha10:56
cjwatsonI'd recommend just running the entire suite under debian/script.py and catting the logfile at the end, or similar?10:57
pittiyes, sounds good10:57
pitticjwatson: actually, we don't need to cat the log file; output still goes to stdout AFAICS?10:58
dokopitti, 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:58
cjwatsonpitti: oh, yes, true10:59
cjwatsonforgot my own code10:59
pittidoko: one step at a time :) but it's great to have coverage for the pythons now!10:59
=== MacSlow is now known as MacSlow|lunch
=== Ursinha is now known as Ursinha-afk
cjwatsonLaney: 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-, and /usr/share/man/man1/ghci.1.gz11:26
* Laney blinks11:26
cjwatsonLaney: 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:26
LaneyThat wouldn't surprise me11:27
cjwatsonand libghc-ghc-dev changing hash isn't a problem if it's going to change on armhf anyway; it just surprised me11:27
Laneycjwatson: I just turned up http://thread.gmane.org/gmane.comp.lang.haskell.debian/328711:35
cjwatsonAh, yes, the tail-end of that thread matches11:37
cjwatsonIf the armhf build also only changes the ghc hash then I think we're good enough11:38
Laney"In fact, I'm pretty impressed that we manage to get the same hashes even11:38
cjwatsonheh, yeah, I liked that11:38
Laneyat least he's honest!11:38
cjwatsonI believe the reverse chain is (1) doctest, ghc-mtl, ghc-syb-utils, gitit, haddock (2) hint11:42
cjwatsonWhich seems tolerable11:42
jibeldoko, pitti sorry lunch break. I'll run the testsuite in our environment with script.py11:47
=== greyback is now known as greyback|lunch
=== MacSlow|lunch is now known as MacSlow
jibeldoko, python2.7 testsuite pass when run under script.py12:24
dokojibel, the other tests too?12:24
tim`is there a reason raring is sticking with boost 1.49 instead of moving up to 1.53?12:26
tim`errr 1.50 maybe - looks like both are packaged12:27
cjwatsontim`: regardless of reasons it's far too late now - boost transitions take time12:29
cjwatsonwe do them at or near the start of release cycles12:30
jibeldoko, 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 up12:30
tim`or if there was just not much interest12:31
dokojibel, 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
dokotim`, time ... and there is no 1.50 anymore12:31
pittidoko: https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-python3.3/, FYI12:32
tim`when do versions for 13.10 get laid out ?12:32
pittiInvalid -u/--use option: all,-network,-urlfetch,-gui,-xpickle12:32
pittiUse --help for usage12:32
=== Ursinha-afk is now known as Ursinha
pittiit didn't get very far12:33
dokopitti, my browser tries to download these files. is there a way to show these in the browser?12:33
pittidoko: not that I know of; but you can use the "console output", that will be displayed inline12:33
pittiI just look at them in gedit12:33
pittidoko: "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/console12:34
dokoapw, 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 arm6412:35
cjwatsontim`: only a handful of toolchain packages need to be decided early12:35
cjwatsontim`: so nowish or before, and AFAIK it'll be boost 1.5312:35
dokowe switch to 1.53 together with GCC 4.812:36
dokoat least, that's my plan12:36
dokoxnox had already set up the transition tracker12:36
apacheloggercjwatson: I forgot to remove the colors yesterday, https://code.launchpad.net/~kubuntu-members/debian-cd/kubuntu-raring-artwork/+merge/158350 should fix this12:38
=== _salem is now known as salem_
cjwatsonapachelogger: merged/deployed, thanks12:40
tim`oh man - gcc 4.7 breaks enough things already :)12:40
apacheloggercjwatson: thank you12:41
xnoxtim`: well and gcc 4.8 fixes a lot of C++11 things that were missing in 4.7 ;-)12:42
=== Ursinha is now known as Ursinha-afk
tim`will there likely be an alt gcc-4.6 package still ?12:43
xnoxtim`: 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
xnoxtim`: why do you want gcc-4.6?12:44
xnoxboost-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 cuda12:45
xnoxstill a few things to fix, but nothing out of the ordinary.12:45
cjwatsonwe only remove older gcc packages once nothing in our archive requires them any more12:45
=== greyback|lunch is now known as greyback
cjwatsonwe do generally have to keep moving forward though, otherwise the hill to climb is just that much higher later on12:46
tim`yeah - understandable12:46
mitya57we still have gcc-4.6 in raring (and even 4.4), but I wouldn't recommend anyone to use that12:46
doko4.4 will die in the s-series, killing all the games packages implemented in Dv112:50
dokoworking on getting D to 4.8, so 4.6 can die too12:50
dokonot C12:51
tim`ah yes12:52
NCommanderBeside D, is there any other unusual GCC frontends hanging around? (I know GNAT is kinda special though thats fortunately mainstream ...)12:53
xnoxsiretart: we have go even in precise ;-)12:54
xnoxsiretart: 4.8 has some support for 1.1.12:54
sconklin@pilot out12:55
=== udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Frozen for Final Release | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
=== Ursinha-afk is now known as Ursinha
dokoNCommander, do you want to package the PL/1 and Cobol frontends?13:09
NCommanderdoko, don't we already have opencobol in archive? (and no, I don't :-P)13:11
=== Ursinha is now known as Ursinha-afk
=== wedgwood_away is now known as wedgwood
=== Ursinha-afk is now known as Ursinha
* 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_DIRS13:49
xnoxthat looks wrong... and still doesn't solve my ftbfs... looking more.13:49
=== Reanimator is now known as Herbertwest
=== NCommander is now known as Guest94000
jamespagepitti, 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 archive13:57
jamespageI'd like to backport the same into 12.04 as well13:57
=== ckpringle_ is now known as ckpringle
pittijamespage: do you figure that users will have a need to change that configuration?13:59
jamespagepitti, not quite sure I understand your question13:59
pittijamespage: I'd start with putting the actual configuration into the hook, instead of adding it to the config file14:00
jamespagepitti, ah - so add the crashdb configuration to the ubuntu_cloud.py hook itself - right - lemme give that a go14:00
=== Ursinha is now known as Ursinha-afk
pittijamespage: right, like report['CrashDB'] = '{"impl": "launchpad", ....}'14:01
jamespagepitti, working on that now14:03
pittijamespage: and as a style nitpick, let's drop the line break and the parens in the if14:03
jamespagepitti, ack14:04
=== Ursinha-afk is now known as Ursinha
jamespagepitti, 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:19
pittijamespage: oh, inline config doesn't work in 12.04 yet, there we'll need a file in /etc/apport/crashdb.conf.d/14:20
jamespagepitti, yeah - I just noticed that :-)14:20
jamespageOK - so for 12.04 I need a crashdb config in crashdb.conf.d14:20
pittijamespage: you should get the origin text in raring as well, but only if it's actually from a PPA14:20
pittijamespage: if not, then it's the ubuntu package14:20
jamespagepitti: these packages come from ubuntu-cloud.archive.canonical.com14:21
pittijamespage: you can check explicitly with if apport.packaging.is_distro_package(report['Package'].split()[0]):14:21
pittijamespage: you don't get an [origin: ...] field in raring?14:21
=== t1mp_ is now known as t1mp
jamespagepitti, lemme check again14:25
dokoSweetshark, bug subscriptions for liblangtag missing ...14:29
xnoxdoko: http://paste.ubuntu.com/5698613/        isn't         /usr/include/x86_64-linux-gnu/ missing from that list?14:30
dokodamn, he did smell that14:30
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 -dM14:32
doko /usr/lib/gcc/x86_64-linux-gnu/4.7/include14:32
doko /usr/local/include14:32
doko /usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed14:32
doko /usr/include/x86_64-linux-gnu14:32
doko /usr/include14:32
dokoxnox, works for me. why do you call cc1 directly?14:32
jamespagepitti, it would appear not14:35
dokoSweetshark, bug subscriptions for liblangtag missing ...14:35
xnoxdoko: hmm.... thanks that your command also works for me.14:36
xnoxdoko: trying to understand https://launchpadlibrarian.net/136352236/buildlog_ubuntu-raring-armhf.sword_1.6.2%2Bdfsg-5ubuntu1_FAILEDTOBUILD.txt.gz14:38
xnoxzlib.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
jamespagepitti, packaging.get_package_origin give me 'Canonical' - I think thats good enought for my filter14:40
dokoxnox, the -I/usr/lib/arm-linux-gnueabihf looks suspcicious, but shouldn't hurt14:42
=== francisco is now known as Guest35830
doko-- ZLib: system /usr/lib/arm-linux-gnueabihf/libz.so14:43
doko-- cURL: system /usr/lib/arm-linux-gnueabihf/libcurl.so and /usr/include14:43
apwdoko, thanks14:46
Sweetsharkdoko: thx for adding14:51
dokoxnox, ^^^ so for curl it does detect the include, but not for zlib ?14:52
dokocmake madness?14:52
stokachuxnox: am i reading nmu wrong? i thought since im not the maintainer it should be filed as such (re sosreport)14:54
xnoxstokachu: 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/copyright14:56
xnoxstokachu: NMU is when another person makes an upload of the debian package on-behalf of the regular package maintainer.14:57
xnoxstokachu: for example if you upload xiphos into debian, instead of me, that would be NMU. As I'm debian maintainer for xiphos.14:57
xnoxstokachu: 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
cjwatsonfiling a bug report with "NMU" in the title is kind of a declaration of intent14:58
cjwatsonassuming that's what you mean14:58
xnoxcjwatson: stokachu meant to do an ITP ;-)14:58
jamespagepitti, how does that look - https://code.launchpad.net/~james-page/ubuntu/raring/apport/cloud-archive/+merge/15837814:58
stokachuok so do i close this sponsor request14:59
jamespageseems to work OK for me (although the test on raring is a little artificial as the cloud archive is really just for 12.0414:59
xnoxstokachu: one files an ITP if you intend to upload and hence become package maintainer in debian for that new piece of software.14:59
pittijamespage: splendid!15:00
stokachuxnox: yea thats what i need to do15:00
cjwatsonstokachu: don't close the bug and open a new one - that's pointless15:00
cjwatsonstokachu: mutate it into what it's supposed to be instead with control commands15:00
pittijamespage: 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 reason15:00
jamespagepitti, yes indeed - that's kinda what I thought15:00
xnoxstokachu: well open an ITP with cc to debian-devel, and mutate the sponsorship request =)15:01
jamespagepitti, are you OK for me to upload that and push the branch?15:01
stokachuso i should have an ITP ane a sponsorship request bug15:01
pittijamespage: I just hope that ~cloud is a sufficiently tight test15:01
xnoxstokachu: as one should file ITP to "announce" that you are about to take-up a package.15:01
jamespagepitti: I think ~cloud with origin 'Canonical' is15:02
stokachuxnox: 69832915:02
pittijamespage: sure, please do (and use  "dch -r" and "debcommit -r" after that)15:02
jamespagepitti, ack15:02
xnoxstokachu: 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
xnoxstokachu: new maintainer guide should tell you all about these things.15:02
stokachuyea ive been reading through the guides but i guess i got confused on nmu versus itp15:03
BenCinfinity: any reason that linux-ppc-3.8.0-8 isn't in raring proper yet?15:05
xnoxstokachu: in ubuntu we do not have "strong maintainership" instead anyone can upload anything, thus the concept of NMU is non-existent in ubuntu.15:05
cjwatsonBenC: it's waiting for me to upload debian-installer15:06
BenCcjwatson: Ah, ok, thanks15:06
cjwatsonwhich in turn is waiting for somebody to approve libdebian-installer in the upload queue15:06
BenCJust making sure it doesn't fall through the cracks :)15:06
stokachuxnox: ahh15:06
stokachuxnox: its all making sense now :)15:06
cyphermoxslangasek: 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 around15:23
ubottuLaunchpad bug 1124803 in network-manager (Gentoo Linux) "duplicate for #1073433 NetworkManager doesn't respond to SIGTERM in daemon mode" [Undecided,New]15:23
slangasekcyphermox: ok, so what is keeping the root fs busy?15:42
cyphermoxslangasek: I don't know ;)15:45
cyphermoxslangasek: 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 anywhere15:46
cyphermoxcertainly running lsof like so adds one more thing to write to /, but the same issue appears even if I comment out that part15:47
cyphermox(I had lsof run as part of sendsigs)15:47
=== rickspencer3_ is now known as rickspencer3
=== Sabbathlives_ is now known as Sabbathlives
=== Sabbathlives_ is now known as Sabbathlives
pittistgraber, Laney: could you please accept ~ubuntu-core-dev invitation into ~network-manager?16:40
pittiwith that, core devs can finally push to the NM packaging branch16:40
stgraberpitti: yep, will do16:40
pittistgraber: merci!16:41
pittijamespage: http://launchpadlibrarian.net/136986347/apport_2.0.1-0ubuntu17.1_2.0.1-0ubuntu17.2.diff.gz LGTM16:41
jamespagepitti, great!17:22
=== security is now known as megha
tkamppeterOdyX, 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:01
bryceslangasek, does udev automatically reload all rules at boot, or do you have to deliberately run udevadm trigger?18:23
bryce(or udevadm control --reload-rules; google gives me some conflicting recommendations)18:24
smosercjwatson, do you know how i can make debian installer not go into vga mode from the netboot iso?18:46
smosertrying to boot with 'kvm -curses'18:46
smoserkirkland, for some reason i think maybe you have known that?18:47
slangasekbryce: so, if by "reload" you mean "load from disk when started from the root filesystem"... sure?18:49
slangasekbryce: what's the root problem here?18:49
bryceslangasek, 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:51
slangasekbryce: udev has an in-memory cache of the rules (naturally), but otherwise reads them from disk on every boot.18:52
bryceslangasek, 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:54
ubottubug 1168066 in xserver-xorg-video-intel (Ubuntu) "[arrandale] GPU lockup IPEHR: 0x54300004" [High,New] https://launchpad.net/bugs/116806618:54
slangasekbryce: we're talking about /lib/udev/rules.d/40-xserver-xorg-video-intel.rules, right?18:56
bryceslangasek, yes18:57
slangasekbryce: I have the version of the package from that bug installed, and I see a present and active udev rule18:57
slangasekso it doesn't seem to actually be disabled in the package?18:57
bryceslangasek, not commented out?19:00
slangasekbryce: nope19:00
slangasek# Disable freeze hook.19:00
slangasekSUBSYSTEM=="drm", ACTION=="change", ENV{ERROR}=="1", RUN+="/usr/share/apport/apport-gpu-error-intel.py"19:00
slangasekthere's a nice comment /above/ it ;)19:00
brycehum, that could be the problem.  It *is* commented out in the package19:00
slangasekdefine "in the package"19:00
slangasekthat's the unmodified version of the file, from the binary package in the archive19:01
bryceapt-get source xdiagnose; cat xdiagnose-3.4.4/debian/xdiagnose.udev19:01
slangasekbryce: oh, but it's not shipped by xdiagnose19:02
slangasekit's shipped by xserver-xorg-video-intel!19:02
bryceahem.  yay leftovers.19:05
=== G4MBY is now known as PaulW2U
=== chilicuil is now known as chilicuil_away
barryslangasek: 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:46
slangasekbarry: definitely yes19:47
barryslangasek: cool.  we'll see if that makes the package buildable :)19:47
barryslangasek: hmm, likely will have to bump down some dep version numbers as well19:49
=== highvolt1ge is now known as highvoltage
slangasekbryce: so I guess that also explains why I was getting two apport popups for every gpu hang ;D20:03
bryceslangasek, and also why we were still getting false gpu reports after we thought we fixed it...20:06
roadmrhello! 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:19
sarnoldroadmr: can't go wrong with a bug report :)20:22
roadmrsarnold: ok, makes sense, let me research this a bit more and then I'll file20:23
=== seb128_ is now known as seb128
bryceslangasek, sru's are in for that.  thanks for noticing the redundant rule.20:50
=== chilicuil_away is now known as chilicuil
=== rickspencer3_ is now known as rickspencer3
=== salem_ is now known as _salem
dobeybarry: is bug #1071897 still relevant at all or should i just close it as invalid?21:11
ubottubug 1071897 in ubuntuone-client (Ubuntu) "4.0.0-0ubuntu1 fails to build (test failures) on Raring" [Undecided,New] https://launchpad.net/bugs/107189721:11
barrydobey: i haven't tried recently.  let me grab it and try.21:12
dobeybarry: 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 changing21:13
barrydobey: yeah, probably doesn't21:14
barrydobey: 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:23
dobeybarry: 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 you21:27
barrydobey: me neither, but if you don't care i don't either :)21:27
dobeybarry: 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 fix21:30
cjwatsonsmoser: https://help.ubuntu.com/12.04/installation-guide/i386/boot-parms.html - DEBIAN_FRONTEND=text21:34
cjwatsonbarry: 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:35
slangasekcjwatson: yep, sorry, I may have suggested to barry that a full apt backport from precise-updates /might/ possibly be easier21:57
barrycjwatson: 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 instead21:57
slangasekbut apparently this was me forgetting just when lucid was :-)21:57
barryslangasek: ;)21:57
slangasek(i.e.: before multiarch... and apparently also before dpkg-symbols supported c++ names!)21:58
barryslangasek, cjwatson maybe we should convince is to just upgrade to precise already :)21:58
slangasekbarry: depends on how soon we want this bug fixed21:58
barryslangasek: yeah.  the bug report made it sound like a big deal for some folks21:58
barryanyway, let's see if mvo can help us out here before we worry too much22:00
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:17
sarnoldcelso_: there's a log of package operations in /var/log/dpkg.log -- perhaps that can help you22:19
geofftcelso_: ask xnox if he's deployed our LP-Librarian-using snapshot code yet :)22:20
geofftI can probably cobble something together if you give me a timestamp22:20
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:23
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:24
celso_but unfortunatly, i am no developer or programer.22:25
celso_so, i am kind of "stuck"22:25
sarnoldcelso_: 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 names22:25
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:27
celso_i think a feature to install/block updates by time would be a good feature to debug some bugs22:28
celso_the problem for dpkg.log is it will not show the time each update become available if i install all now22:30
celso_i think22:30
sarnoldcelso_: true enough, it only shows what happened on that one machine..22:31
celso_i will install 100 updates each time and will see what happens, and then cut another half, and again....22:32
celso_it will cost alot of bandwitch but its the only way i can see.22:33
celso_brb and by the way, thanks for the help!22:34
stokachuif 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
sarnoldcelso_: apt-cacher-ng or apt-cacher can easily cache packages that you download, it can drastically save time here22:36
celso_ok. i will try.22:37
ionAlso see squid-deb-proxy22:45
celso_have to restart. brb22:46
=== wedgwood is now known as wedgwood_away
=== rickspencer3_ is now known as rickspencer3
stokachuso 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 error23:18
stokachui have updated debian/copyright accordingly23:18
=== G4MBY is now known as PaulW2U
slangasekstokachu: 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, yes23:48
stokachuslangasek: any urls you can point me to? googling is failing for me :(23:49
slangasekstokachu: might be better to use a worked example23:49
slangasekstokachu: can you point me at your package?23:49
stokachuso right now im working off https://github.com/sosreport/sosreport/tree/master/debian23:50
stokachuusing debhelper and the Makefile is what is forcing a install of LICENSE into /usr/share/sos/.23:50
stokachuso 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 makefile23:50
slangasekstokachu: (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
slangasekstokachu: python-support is deprecated, please use dh_python instead (wiki link in one second)23:52
stokachuyea ive got a few changes i haven't committed yet23:53
stokachulemme show you my branch one sec23:53
stokachuslangasek: https://github.com/battlemidget/sosreport/tree/debian-packaging/debian23:54
stokachuthats my latest work from after fixing all lintian errors23:54
slangasekstokachu: so I'd say the simplest approach here is:23:55
slangasek\trm -f debian/tmp/usr/share/sos/LICENSE23:55
stokachuah ok23:55
stokachui tried override before but didnt call dh_auto_install first23:55
* slangasek nods23:56
stokachugonna try that now and test23:56
stokachuslangasek: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705192 trying to get this thing sponsored23:57
ubottuDebian bug 705192 in sponsorship-requests "RFS: sosreport/2.3-2 ITP" [Wishlist,Open]23:57
stokachuso far i think ive fixed all the warnings from message 2923:58
slangasekstokachu: you seem to still have a dep on python-support in your branch23:58
stokachuah in my control file23:59
stokachulemme remove that23:59
stokachui also see this warning23:59
stokachuW: dh_python2:90: Python 2.7 should install files in /usr/lib/python2.7/dist-packages/. Did you forget "--install-layout=deb"?23:59
stokachubut when i look at the layout after it builds it is in dist-packages already23:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!