/srv/irclogs.ubuntu.com/2013/01/10/#ubuntu-devel.txt

xnoxbdrung: waf upstream was never hostile to packaging waf in distros. they did accept debian-specific patches into upstream which debian maintainer claimed to mean "hostile". And while ftp-masters didn't accept waf into debian, i disagree with their resolution.00:02
xnoxconfigure, which is generated using out-of-the-archive autoconf & possibly hand crafted aclocal with missing m4 files is a far bigger FTBFS / DFSG / build reproducibility problem them. Then a handful of python files compressed with bzip2 and uuencoded.00:04
xnoxSo I would not block packages on having waf in them.00:05
xnoxhttp://lintian.ubuntuwire.org/quantal/tags/source-contains-waf-binary.html00:09
* xnox goes to ping ubuntuwire about setting up raring lab00:10
geofftxnox: btw, you got my email about apt-mirror, right? Did you ever play with setting that up?00:13
xnoxgeofft: yes, I did. I did play around with it a little. Changing a few things around. But nothing published, nor running publically yet.00:15
xnoxtrying to find time for this project =))))00:15
xnoxgeofft: thank you though, a lot!00:16
geofftxnox: Sure (and thank broder, really). Just wanted to make sure I didn't fail to get you something you needed.00:17
Bluefoxicyhang on, there's been no power drop here00:24
Bluefoxicywhy did my computer reboot00:24
xnoxdid you kick it to hard & it wiggled a power cable?00:29
Bluefoxicydon't know, someone says I timed out.00:30
slangasekcjwatson: hmm :/ why is -fno-stack-protector still needed?  I didn't find much explanation in the changelog for it, and it wasn't needed for gnu-efi's /own/ build00:31
Bluefoxicymy bios isn't set to turn power back on if I experience power loss, but I came back to a log-in screen on a fresh reboot.00:31
Bluefoxicysince I timed out, I assume unclean means of system run termination rather than update-manager deciding I should reboot without my input.00:31
=== slank is now known as slank_away
xnoxslangasek: it came up in the context of causing efilinux FTBFS, if gnu-efi is build without -fno-stack-protector. And cjwatson added comments in the gnu-efi explaining this now.00:46
xnoxgnu-efi doesn't need it, but rdeps do =)00:46
bdrungxnox: a binary blob is not the preferred form of modification (in which the source code should be)01:40
micahgxnox: why shouldn't waf blobs be problematic in Ubuntu? aside from semantik, all of the packages are from Debian and should be fixed there, I think most are already, but since we don't have a raring lintian lab yet, we can't be sure04:58
* micahg goes and repacks symantik05:05
hyperairsymantik?05:07
hyperairhmm, mindmapping tool. interesting.05:08
pittixnox: err, how so? I'm getting mails to it all the time05:22
pittiGood morning05:22
pittixnox: ah, it's not pitti@debian.org, but mpitt@d.o.05:24
pittixnox: https://launchpad.net/~pitti has the correct address, too05:29
=== Amaranthus is now known as Amaranth
gdanehello06:15
gdanei am interest in some pxa270 ubuntu project06:16
gdaneis someone work on it?06:16
gdanewhere i can find any info about?06:17
sarnoldgdane: I haven't seen anything about that board specifically, but hopefully you'll find something useful here: https://wiki.ubuntu.com/ARM06:23
gdaneYes i use, thanks06:24
gdaneive read this06:24
gdanei mean may be someone worked with it before me06:24
gdaneand did working kernel and rootfs06:25
gdanei have several debian dootfses and kernels for my pxa270 intel xscale06:26
gdaneso i am wonder if someone did ubuntu project with it06:26
=== smb` is now known as smb
=== Tonio_aw is now known as Tonio_
=== Tonio_ is now known as Tonio_aw
pittidoko, infinity: :any build deps don't work in Debian yet; do you happen to know when/whether that's planned?09:11
=== Tonio_aw is now known as Tonio_
=== Tonio_ is now known as Tonio_aw
=== henrix_ is now known as henrix
xnoxbdrung: in that case snapshot upstream VCS, as packed waf binary only has some of the plugins & is processed to remove whitespace & uses tabs instead of space and has comments stripped.09:46
xnoxmicahg: the point I am trying to say that waf is not a blob but bz2 compressed source code, where as configure is obfuscated pre-generated code, which many packages do not regenerate.09:47
xnoxconfigure is "plain-text" and is a bigger blob, imho.09:48
xnoxpitti: ha =) my error.09:48
=== yofel_ is now known as yofel
cjwatsonslangasek: right, as xnox said - the problem is that gnu-efi builds a library which is linked into freestanding code in other packages, so ssp blows up at that later stage10:51
infinitypitti: Not sure, though in most cases, they really shouldn't be needed anyway.10:52
cjwatsonpitti,doko,infinity: I was working just yesterday on sorting out Debian buildds to support :any, as it happens10:52
cjwatsonI'm not quite there yet, since I haven't figured out enough of the relevant bits of wanna-build10:52
=== Quintasan_ is now known as Quintasan
cjwatsonI have sbuild working AFAICT10:52
bdrungxnox: we can regenerate the autotools files and we can manually modify them. i can't modify bz2 compressed stuff without extracting it. a problem arise if i want to patch that bz2 compressed code!10:53
infinitycjwatson: Until such a time as people think they actually want to allow multiarch buildds (which I'm still wary of as an "official" solution to anything), wouldn't it just be easier to strip :* and let 'er rip?10:54
cjwatsonThat's more or less what I plan to do in wanna-build, yes10:54
cjwatsonFor sbuild, well, I've already done the work - it was easier to backport the relevant dpkg patches to forked code10:54
xnoxbdrung: autoreconf does not work on many packages. I have been bitten by that many times. /me dislikes how one build system is favoured over the other when exactly the same argument can be applied.10:55
infinitycjwatson: Oh, for sbuild, it may as well DTRT, sure.10:55
infinityxnox: Do we have ways to regen the waffy stuff with in-archive source?10:55
infinityxnox: What form it takes is vaguely irrelevant if we're shipping stuff we can't even pretend to be able to regenerate (and thus modify).10:56
bdrungxnox: autoreconf is not favoured over waf in point of getting it packaged. we just require to ship the  waf script in extracted form (so we could create patches against it)10:56
xnoxinfinity: there is no need to regen anything. but you can set WAFLIB= variable and point it to a dir where you can override any bit, as it will be prepented pythonpath.10:56
infinityxnox: Err, "no need to" is a meaningless statement when we're talking about software freedom.10:57
diwicpitti, hi, do you know why there is a "jockey" (and "meta-kde-telepathy") in https://code.launchpad.net/~ubuntu-audio-dev/+archive/alsa-daily/+packages ?10:57
infinityxnox: You have no need to modify your kernel either, we'll stop shipping the source.10:57
bdrungwhy isn't there one build system that suites all needs?10:57
* cjwatson contemplates a Debian release goal of having every autotoolsy package use dh-autoreconf10:57
pittidiwic: presumably a wrong manual build10:58
xnoxinfinity: waf script is bzip2 compressed python files, if you want to unpack & modify. It's a binary that produces it's own source code. If that's not DFSG-free, I'm not sure what is.10:58
diwicpitti, ok, I'll remove it then10:58
pittidiwic: for some reason, the "request build" page on +recipe pages always default to the alphabetically first PPA I can upload to, instead of the one I configured for autobuilds10:58
infinityHrm, if this glibc 2.17 builds and passes the testsuite first try after I rebased about 100 patches, I'm going to be very shocked.10:58
pittidiwic: in most cases I change it, but I guess a manual build slipped through, sorry10:58
diwicpitti, so we should rename "alsa" to "qalsa" or so :-)10:58
cjwatsonThat said I wonder if it's bootstrappily sane for base-passwd to use dh-autoreconf.10:59
infinityxnox: Is there a reason it needs to be compressed, other than someone thinks that's cool?10:59
diwicpitti, although that would just put another ppa in the same spot10:59
cjwatsonMaybe I can rationalise heavier build-deps for base packages now that we can cross-build packages sanely10:59
bdrungxnox: it not a DFSG problem, it's a "preferred form of modification" problem10:59
infinitycjwatson: I think packages lower down the stack get a pass.  There are still a couple that don't use debhelper at all, and I'm fine with that.10:59
bdrungs/it/it's/10:59
cjwatsonYeah, base-passwd doesn't use debhelper at the moment (in fact that was sort of a condition of me taking it over :-) ).  But I wonder if worrying about that for port bootstraps still makes sense given that all this stuff is Architecture: all.11:00
cjwatsonOr at least Multi-Arch: foreign.11:00
xnoxinfinity: it's not necessory nor mandatory, is there a reason to decompress & repackage orig tarball, other that someone thinks they may need to modify it sometime in the future?11:01
xnoxinfinity: i can see how one thinks waf is similar to tarball-inside-tarball, but it's not.11:01
OdyXxnox: for Debian it's clear: http://wiki.debian.org/UnpackWaf FTP-masters ruled, sooo11:01
infinitycjwatson: Well, it still takes us one step further away from being able to do a scorched-earth make world.  Not that Debian has been able to do that for over a decade, but I still think it might be shiny if it was sort of possible.  Some day.11:01
cjwatsonSeeing as dpkg uses debhelper it seems a bit pointless to worry about it11:02
infinityxnox: Well, there you go.  If Debian ftpmasters ruled, I'm happy to just follow suit.11:02
xnoxOdyX: I respect ftp-masters decision for Debian. That does not mean I agree with it.11:02
infinitycjwatson: That could be fixed. :P11:02
OdyXxnox: the core of the issue is that you have to execute an untrusted blob to get the source.11:02
pitticjwatson, infinity: :any> I committed doko's glib change to Debian's svn, but reverted the :any bit as current dpkg doesn't seem to like them11:02
infinitycjwatson: But yeah, I'm not sure it's worth worrying about either.11:02
OdyXyou don't know what this blob could do.11:02
cjwatsonpitti: Current dpkg is fine.  It's sbuild/etc. that breaks.11:02
pittihm, /me upgrades his sid chroot then, it's already two days old11:03
cjwatsonpitti: Build-depending on python:any, *specifically*, won't be possible in Debian until python is multiarched there11:03
infinitypitti: Our dpkg and Debian's don't have any divergence in this area (and haven't for months).11:03
pittiaah, so I guess that's the reason why dpkg failed11:03
cjwatsonpitti: Build-depending on X:any is only permitted if X is Multi-Arch: allowed.11:03
pittinot because of :any, but because "python:any" is indeed not installed11:03
pittithanks11:04
infinitypitti: python should be multiarched in experimental, if you want to upload there.11:04
cjwatsonThat's defined in MultiarchSpec, and there's a clearer table in MultiarchCross.11:04
infinity(At least, I think doko landed all of that)11:04
xnoxOdyX: not really, the header of was script is plain text and uses python stdlib bz2 to decompress a stream, which is a folder with python files. I can write a C implementation that does it, if you wish and then further inspect the code.11:04
cjwatsonYou could upload but wanna-build will kick it out.11:04
xnoxs/was/waf/11:04
cjwatsonSo I still wouldn't recommend it.11:04
infinitycjwatson: Oh, right. :P11:04
pittiinfinity: indeed I do (experimental), thanks11:04
infinityxnox: I'm not sure what the point in arguing the point is.11:05
pitticjwatson: *nod*, thanks; so I keep it reverted for now11:05
cjwatsonpitti: You can test it locally against experimental with a reasonably current version of sbuild, but not yet upload it.11:05
xnoxinfinity: ack. i'll shut up.11:05
pittiLaney: ^ FYI11:05
infinityxnox: Our general goal is to always upstream as much of our stuff to Debian as we can, so doing things that Debian ftpmaster specifically doesn't allow is silly.11:05
pittiLaney: so it seems we won't have to carry that delta for very long at least11:05
Laneyright; we will just need to remember to bump the BD version to get the experimental python11:06
Laneydepending on when the buildd side gets deployed, of course11:06
* cjwatson sends off the first half of the buildd side now11:07
cjwatsoninfinity: Hmm.  Having just tried to dh-autoreconf binfmt-support, it feels pretty weird on native packages.  Maybe I should turn that into non-native ...11:13
infinitycjwatson: It doesn't even make sense on native packages...11:14
cjwatsonWell, it sort of does; you still want to keep current on the generated code11:14
cjwatsonAs it stands I reautotool before every upload, but it's a bit manual11:14
infinitySure, but that should be in your clean target then, or some other pre-upload task.11:14
cjwatsonI dunno.  I do like the consistency of having all my packages work kind of the same way as far as the autotools are concerned.11:15
cjwatsonAnd all my non-native packages are now dh-autoreconfed, including the one that was 2.13 only until I beat on it11:15
infinityJust build-dep on dh-autoreconf and call it in clean with a hard failure if it's not there?11:15
infinitySo it forces it to be called on source package generation? :P11:16
cjwatsonThere are some good reasons to call it at build time; it means that you get upstream autotools improvements even if you haven't uploaded for a while11:16
cjwatsonParticularly relevant for config.guess/sub, but it's occasionally useful elsewhere11:16
infinityYeah, true.11:16
=== _salem is now known as salem_
bdrungcjwatson: for native package, you could just remove all the auto-generated files.11:29
cjwatsonbdrung: I could.  The reason I decided I was uncomfortable with that for binfmt-support is that it means that anyone using that on other distributions will have to sort out the autotools stuff manually; and the fact that that is a concern for me is a good indication that it shouldn't actually be native in the first place.11:33
infinitycjwatson: Oh, see, yeah, that argument makes perfect sense.11:35
infinity(I do wonder if apt and dpkg should go non-native for similar reasons)11:35
bdrungcjwatson: yes (too many packages are native despite the fact that i could be used elsewhere)11:41
=== Tonio_aw is now known as Tonio_
=== sraue_ is now known as sraue
infinityricotz: I have a few packaging changes to make to glibc 2.17 as well before I upload, but you should expect it in experimental tomorrow (or later today, I guess, but after I've slept), and raring in a few days, after the test rebuilt dust settles.11:59
ricotzinfinity, alright, i am hoping to see it soon :)12:05
ogra_jodh`, hmm, just thinking about that serial stuff, what if someone has a serial tty that isnt used for console= at all ?12:22
ogra_i.e. i dont need kernel and boot messages but want a login via serial12:24
=== MacSlow is now known as MacSlow|lunch
=== cpg is now known as cpg|away
dokoLaney, pitti, only python2.7 is multiarched, not 2.613:30
pittidoko: that's fine, python is 2.7 in sid/exp anyway13:30
ebischoff Hello people and happy New Year. Is it normal that libselinux1 libsemanage and libsemanage-common got installed on Raring? I thought Ubuntu was using AppArmor. I don't have these packages on Quantal.13:34
cjwatsonebischoff: Yes, because shadow is compiled with support for them in any case (from Debian).13:35
cjwatsonThe libraries in themselves don't hurt.13:35
ebischoffSure they don't hurt. They are just losing space on the system and not needed. Couldn't "shadow" be compiled without that dependancy?13:37
cjwatsonIt could, but it doesn't seem worth the divergence.13:37
pittithere's two handfuls of other packages which also depend on libselinux1 anyway13:38
ebischoffOK. I disagree, but OK. Thanks for the answer and thanks also for all the great work.13:38
cjwatson(And it would mean that people wouldn't be able to take Ubuntu and drop in a kernel that uses the SE Linux security module instead.)13:39
ebischoffGood point. Although one could wonder why a kernel would depends on libraries :-).13:39
cjwatsonIt doesn't.13:40
cjwatsonIndeed, as pitti says, libselinux1 was already in minimal Ubuntu chroots in Quantal.13:40
jdstrandactually, selinux is available via kernel boot parameter13:40
cjwatsonYou've made a mistake somewhere if you believe that it wasn't there before.13:40
cjwatsonlibsemanage1 and libsemanage-common are new.13:40
ebischoffah, correct, I compared only libsemanage ones13:40
ebischoff# dpkg -l | grep libsel13:41
ebischoffii  libselinux1:amd64                     2.1.9-5ubuntu1                           amd64        SELinux runtime shared libraries13:41
pittiSize: 6202 (-common) -> hardly worth the effort again, I guess13:41
ebischoffI learned something, thanks.13:41
tjaalton~150kB all three combined13:41
cjwatsonGiven upstream changes in shadow, IIRC, disabling libsemanage in shadow was going to effectively require ripping out selinux support entirely when it was previously present13:41
cjwatsonAnd I wasn't wild about possible regressions for people in doing that13:41
=== Ursinha is now known as Ursinha-afk
cjwatsonjdstrand: thanks13:41
jdstrandfwiw, that is my resollection13:42
jdstrandrecollection13:42
tjaaltonit should be, yes13:42
jdstrandthat had one way of doing selinux in shadow, then ripped it out and did it with libsemanage13:42
ebischoffOK, thanks for the detailed answer everyone. And thanks again for the great work.13:42
jdstrandit wouldn't be trivial to revert to the old way13:43
* cjwatson completes the stuff he meant to do yesterday evening and ran out of time for, and now wonders what he was actually going to do today ... sigh13:44
ebischoffbest && goodbye13:45
tjaaltoncjwatson: the change to precise livecd-rootfs to pull xorg backport? :)13:45
cjwatsontjaalton: mm, yeah, I seem to have been putting that off ...13:49
tjaaltoncjwatson: should I push this to bzr? http://pastebin.com/b3gzhpnf13:50
jdstrandcjwatson: that is an interesting problem you have :)13:50
tjaaltondon't mind if you do it the way you prefr13:50
tjaalton+e13:50
cjwatsontjaalton: that doesn't look right13:50
cjwatsonit'll end up with both stacks13:51
cjwatsonI don't see a reason to put this in the "live" phase13:51
cjwatson"install" should work better, but needs testing13:51
tjaaltoncjwatson: no, the package will replace the old stack13:52
tjaaltoncan't have both installed13:52
cjwatsontjaalton: But it will go horribly wrong if you do it in the live phase, trust me13:52
tjaaltonok :)13:52
cjwatsonUbiquity will get very confused13:52
cjwatsonThis is intended to be part of the installed system; it does not belong in the live phase, which is for things that will generally be removed after copying the livefs to the target13:53
tjaaltonbut this is for hw enablement..13:53
cjwatsonWhy does that mean you'd want it to be removed after copying to the target system? :)13:53
cjwatsonThe live phase just makes no sense heree13:54
cjwatson*here13:54
tjaaltonok ok13:54
tjaaltonmaybe I got it backwards13:54
cjwatsonlive contains stuff like the installer, language packs most of which are going to be removed, casper which we don't want on the target system, etc.13:56
mdeslaurseb128: mind if I merge gnupg2?13:56
=== MacSlow|lunch is now known as MacSlow
seb128mdeslaur, hey, did I touch that last? please go for it, I hate the TIL concept (more often that not you touch something for a random reason and gets sticky) ;-)13:58
mdeslaurseb128: yep, you did :) thanks.13:58
cjwatsontjaalton: you might have been misled by the signed kernel being in live - it's there because there are many systems for which we don't want it installed.  Things that we conditionally install are often easiest to have in live.  But it's there because it's the signed kernel, not because it's an enablement kernel13:58
seb128mdeslaur, thank *you* ;-)13:59
mdeslaurseb128: yeah, now I've caught the TIL disease :)13:59
tjaaltoncjwatson: yeah, it's the mention of the backport kernel.. so wrong package to touch?13:59
cjwatsontjaalton: Wrong package to use as a model for this14:00
cjwatsontjaalton: I'm testing a build with http://paste.ubuntu.com/1516802/ now - will probably take an hour or two14:01
tjaaltoncjwatson: ah, now I get it :)14:02
tjaaltonsheesh14:02
tjaaltonthings you forget in a week14:02
Laneyd14:11
cjwatsontjaalton: Hmm, nope, this installs xserver-xorg-lts-quantal and then installs xserver-xorg and removes the former ... I thought xorg had been fixed not to do that14:21
cjwatsonOh, blah, it's probably got something to do with the task14:21
cjwatsonThis will be painful14:21
tjaalton:/14:21
tjaaltonbut renames are great! :)14:22
cjwatsonhate you all14:22
tjaaltonhehe14:22
Myrtti14:22
mlankhorst:/14:25
cjwatsonI think I will have to expand the task by hand and hope that that doesn't cause anything else to blow up14:25
mlankhorstwasn't me who decided on the rename route!14:25
mlankhorstanyhow installing xserver-xorg will remove -lts-quantal, which is correct :-) xserver-xorg-lts-precise is just a convenience alias since otherwise input-all and video-all don't get pulled in14:26
cjwatsonSure, but it's not what you actually want for this image14:26
=== Tonio_ is now known as Tonio_aw
cjwatsonI'm not arguing about the correctness of the package metadata heree14:27
cjwatsonAlthough I still hate you all14:27
=== Tonio_aw is now known as Tonio_
mlankhorstwell that's your job, I know you don't mean it :-)14:31
=== chiluk is now known as chiluk_away
=== slank_away is now known as slank
=== rickspencer3_ is now known as rickspencer3
caribouwhat is the process to get a package (kdump-tools) in main when its source package (makedumpfile) is already in main ?15:26
caribouthe MIR wiki page says that a MIR is not required for those15:26
seb128caribou, get something in main to (build-)depends on or recommends it15:28
pitticaribou: by and large, upload something to main which depends on it15:28
cjwatsonor get a core-dev to seed it somewhere if it should be a top-level item15:28
caribouseb128: pitti cjwatson thanks for the tips15:29
micahgcaribou: you also want to make sure that it wasn't left out of main for a reason, the original MIR usually mentions these things if that's the case15:33
cariboumicahg: I think it's not in main because it's not systematically being used15:33
cariboumicahg: but thanks for the detail15:33
=== Ursinha-afk is now known as Ursinha
=== mbarnett` is now known as mbarnett
=== chiluk_away is now known as chiluk
=== Tonio_ is now known as Tonio_aw
ogra_pitti, ev, is anything in whoopsie or apport using gksudo ? bug 1098235 is the third one i see around this issue and i thought everything uses pkexec16:21
ubottubug 1098235 in ubuntu-nexus7 "Keybord non responsive for "Report problem"" [Undecided,New] https://launchpad.net/bugs/109823516:21
=== slank is now known as slank_away
=== slank_away is now known as slank
pittiogra_: I ported apport from gksudo to polkit (pkexec) in quantal16:45
ogra_pitti, right, i also see the changelog, pkexec doesnt have any issues with onboard (and definitely doesnt blacken the screen), so i'm a bit confused16:50
pittiogra_: I don't see a package hook with gksu either (at least not on my amd64 system)16:51
ogra_we dont have anything like bug buddy anymore, right ? it must be apport they are seeing there16:52
ogra_i guess i'll just sit down tomorrow and try to reproduce it16:52
pittino, no bug buddy; KDE has its own crash handler, and Firefox does16:55
pittibut neither grab the keyboard16:55
pittiand even for apport, you rarely will see hooks needing root privs16:55
ogra_no, the keyboard (well, focus) grabbing is clearly gksu16:57
ogra_it is known to be broken with onscreen kbd16:57
ogra_but something seems to trigger it nontheless when "report this problem" is selected16:57
pittiogra_: the three things which are still knowingly using it are xdiagnose, update-notifier, and ubuntu-nexus7-installer16:59
ogra_yeah, i wonder if any hook calls xdiagnose or some such16:59
ogra_ubuntu-nexus7-installer isnt in the archive17:00
pitti*mumble* gksu must die *mumble*17:00
ogra_++17:00
ogra_quickly ...17:00
ogra_well, not die but be shot into the universe17:00
ogra_i was actually hoping we could do that this release17:01
bdmurraypitti, ev: bug 109825017:01
ubottubug 1098250 in Apport "unable to send suspend resume crash from raring" [Undecided,New] https://launchpad.net/bugs/109825017:01
ogra_anyeway, thaks pitti, i'll go on researching that part17:01
pittiand with that, bonne nuit tout le monde!17:02
evnice spot17:02
bdmurrayogra_: is there anything in /var/crash?17:02
bdmurrayev: I sometimes wish whoopsie had a log file...17:03
pittihm, what should we use as a dupe signature?17:03
ogra_bdmurray, no idea, i'll ask the reporter ...17:03
pittimachine vendor/product or so? but even that isn't guaranteed to be the same problem17:03
evhmm17:04
evmaybe the kernel guys would have a better idea?17:05
evmy naive thought would be concatenation of the various SMBIOS and PCI IDs that are relevant here17:05
evthat it would be more useful if it underrepresented the number of systems affected equally than if it lumped every Dell together17:06
pittiI subscribed apw to the bug with a question17:06
rbasakbarry: re bug 1097783, thanks. That was quick!17:07
ubottubug 1097783 in genshi (Ubuntu) "re module apis return longs now" [High,Triaged] https://launchpad.net/bugs/109778317:07
evbdmurray: doesn't it log to /var/log/upstart/whoopsie.log?17:07
evpitti: cheers17:07
=== slank is now known as slank_away
apwpitti, bug # ?17:09
bdmurrayev: not with communication details17:12
bdmurrayapw: bug 109825017:12
ubottubug 1098250 in Apport "unable to send suspend resume crash from raring" [High,Incomplete] https://launchpad.net/bugs/109825017:12
=== slank_away is now known as slank
evbdmurray: oh, consider that a bug :)17:13
evit's probably sending to stdout instead of stderr, or whichever upstart cares about17:14
apwev, what symptoms does the error here actually detect?17:16
smbapw, Good question. One might guess dmesg....17:18
bdmurrayapw: its /usr/share/apport/apportcheckresume17:18
=== mspencer is now known as iBelieve
apwok so this is one of those where we suspended and then had to reboot17:20
apwso there is no stack ... tricky17:20
apwev, so we are looking for something to identify the machine, so perhaps the list of devices and machinetype17:22
Laneyogra_: Pretty sure that bug refers to update-notifier.17:22
Laney      invoke_with_gksu(CRASHREPORT_REPORT_APP,17:22
Laney                              _("<span weight=\"bold\" size=\"larger\">Please enter your password to access problem reports of system programs</span>"),17:22
evapw: will that not be too wide a match?17:23
evthat is, can you do anything with "Dell XPS whatever machines failed to suspend 343028 times in Quantal"17:23
apwev, right thats why i am saying 'dell XXX with these 10 devices'17:24
evah right17:24
apwas most likely it has to be related to wahts in the machine17:24
=== chiluk is now known as chiluk_away
=== chiluk_away is now known as chiluk
=== slank is now known as slank_away
cjwatsontjaalton: well, this at least builds now, and includes the enablement stack and not the precise one; I still want to do a bit more comparison with a stock image though, as switching to metapackages is a fairly considerable change18:14
dkesselhello guys. when would you think would be a good time to submit an apport crash report for signon-ui ? i have tried two times now, but apport always refuses/fails to retrace the stacktraces and closes the bugs automatically...18:19
dkesseli don't want to submit a bug the third time only to see apport retracing fail a third time...18:19
tjaaltoncjwatson: nice :)18:21
=== deryck is now known as deryck[lunch]
=== slank_away is now known as slank
=== nrosvall_ is now known as nrosvall
=== henrix is now known as henrix_
bdmurraymterry: there are 2 uploads of duplicity in the quantal -proposed queue, yours is the newer of the two.  the other upload fixes bug 101344619:16
ubottubug 1013446 in duplicity (Ubuntu Quantal) "Uncached grp and pwd calls make duplicity slow with large group and passwd maps" [Medium,In progress] https://launchpad.net/bugs/101344619:16
mterrybdmurray, oh, that was SRU'd?  I didn't notice.19:17
mterrybdmurray, you know what, hold up on mine, and let that one through.  I want to triple-confirm the fix I put in for corruption19:18
bdmurraymterry: well it hasn't been approved for quantal yet and there seems to be an issue with the precise upload so it could use reuploading19:18
mterrybdmurray, which one could use re-uploading?19:19
bdmurraythe fix for bug 1013446 to precise19:19
ubottubug 1013446 in duplicity (Ubuntu Quantal) "Uncached grp and pwd calls make duplicity slow with large group and passwd maps" [Medium,In progress] https://launchpad.net/bugs/101344619:19
=== henrix_ is now known as henrix
smoserslangasek, https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/643289 is 'triaged' for precise. my test just now seems to agree with that (it seems not fixed in precise).19:23
ubottuUbuntu bug 643289 in nfs-utils (Ubuntu Precise) "idmapd does not starts to work after system reboot" [High,Triaged]19:23
smoserwere you planning on fixing that in precise?19:23
bdmurraymterry: so I'll reject your upload of duplicity to quantal and review / approve the one fixing bug 1013446 and if you upload the new precise debdiff to the queue I'd be happy to look at it too19:30
ubottubug 1013446 in duplicity (Ubuntu Quantal) "Uncached grp and pwd calls make duplicity slow with large group and passwd maps" [Medium,In progress] https://launchpad.net/bugs/101344619:30
mterrybdmurray, OK19:32
=== deryck[lunch] is now known as deryck
slangasekcjwatson, xnox: ok, thanks for the clarification.  FWIW the gnu-efi in raring is still broken in some manner I haven't yet identified, as it makes shim unusable (but not unbuildable).19:40
=== slank is now known as slank_away
=== Tonio_aw is now known as Tonio_
=== Tonio_ is now known as Tonio_aw
=== Tonio_aw is now known as Tonio_
cjwatsonslangasek: was that something I broke?20:04
slangasekcjwatson: no, it's my doing20:04
slangasekI was vaguely hoping that the -fno-stack-protector issue would fix shim (even though I had already tested reintroducing -fno-stack-protector)20:04
slangasekI'll get it sorted this week20:05
psusismoser: had a chance to try out kpartx -u yet?20:12
smoserpsusi, no. sorry.20:12
smoseri've not played or thought any more about that.20:12
truexfan81is this the right place to make a suggestion for a program to be included in ubuntu?20:20
truexfan81in this case the program is inxi, this would greatly help the guys in the forums and #ubuntu to get the info they need to help people20:21
=== Tonio_ is now known as Tonio_aw
cjwatsonslangasek: might be worth trying -ffreestanding if that isn't there already ...20:25
=== salem_ is now known as _salem
=== slank_away is now known as slank
=== henrix is now known as henrix_
=== chiluk is now known as chiluk_away
=== chiluk_away is now known as chiluk
Laneywhyever does screen -ls return 1 in all cases?21:34
=== slank is now known as slank_away
=== chiluk is now known as chiluk_away
=== chiluk_away is now known as chiluk
=== slank_away is now known as slank
=== chiluk is now known as chiluk_away
cody-somervilleUbuntu package dependency graph is pretty: http://tinyurl.com/a23nzp222:14
=== Tonio_ is now known as Tonio_aw
cielakcody-somerville: any details on that picture? how was it generated, is there a hi-res version available anywhere, can I generate one myself?22:16
sarnoldcielak: http://tech-foo.blogspot.com22:18
=== _salem is now known as salem_
cielaksarnold: thanks!22:19
cody-somervillesarnold: thanks!22:21
RAOFcody-somerville: That's pretty awesome!22:24
slangaseksmoser: yes, planning to fix bug #643289 in precise, but the mountall part of it needed to settle first22:44
ubottubug 643289 in nfs-utils (Ubuntu Precise) "idmapd does not starts to work after system reboot" [High,Triaged] https://launchpad.net/bugs/64328922:44
micahgcjwatson: maybe one of the causes of the TIL breakdown is the lack of mention of it on the UDD packaging guide22:59
=== slank is now known as slank_away
=== salem_ is now known as _salem
=== cpg|away is now known as cpg

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