[04:39] <pitti> stgraber: no worries
[04:39] <pitti> good morning
[06:53] <dholbach> good morning
[08:55] <Laney> hm, the e.u.c graph hasn't updated in 5 days
[08:58] <cjwatson> Laney: it has ... *drumroll* ... an error
[08:58] <cjwatson> quis custodiet ipsos custodes?
[08:59] <Laney> Host errors.errors.ubuntu.com not found: 3(NXDOMAIN) :(
[09:02] <xnox> Laney: I heard that ev was calculating / updating the graph in a "semi" automatic way, e.g. by computing it somewhere and pushing the result.
[09:02] <xnox> ev: are cron jobs fixed?! =)
[09:08] <brendand> does anyone know difference between 'NO_PROXY' and 'no_proxy'?
[09:10] <cjwatson> The latter is an environment variable I've heard of; the former isn't
[09:11] <marga> Is this an appropriate channel to ask upstart questions?  I need to know the difference of having an "exec" line alone in the file and having it inside a "script" block (no pre-start or post-stop, just script)
[09:11] <brendand> did i really need to specify 'and no smart answers' :)
[09:11] <cjwatson> brendand: Um, I thought that was a perfectly straightforward answer.
[09:12] <cjwatson> marga: The latter will involve an unnecessary /bin/sh process that then execve-s (or similar) the thing you actually wanted to run, rather than having upstart exec it directly
[09:13] <cjwatson> brendand: IOW, without further context, I would have assumed that NO_PROXY was an error, perhaps influenced by the way the *_proxy environment variables are curious anomalies in being lower-case.
[09:13] <marga> cjwatson, ok, but I need to pass some env variables to it.
[09:13] <cjwatson> (I don't know the history behind that.)
[09:13] <marga> I'm going to go paste something.
[09:13] <cjwatson> marga: Why not use 'env'?
[09:14] <cjwatson> The Upstart stanza, I mean, not the command
[09:14] <marga> cjwatson, just let me paste this and you tell me how to make it better.
[09:14] <cjwatson> Sure
[09:15] <marga> http://paste.ubuntu.com/1282738/
[09:15] <marga> The thing is, if I add my stanza like that, upstart gets very angry and refuses to start or stop anything.
[09:15] <cjwatson> Ah, you need to compute the environment variables; that's trickier
[09:15] <cjwatson> OK, I'll work something out for you, few minutes
[09:15] <cjwatson> Your basic problem is that you've confused fork tracking
[09:16] <marga> Ok...
[09:16] <cjwatson> marga: I don't think that's the whole file; can you show me the whole file, please?
[09:16] <brendand> cjwatson, it seems that all proxy env variables have both an upper and lower-case form (https://bugs.kde.org/show_bug.cgi?id=54898) ?? how confusing
[09:16] <cjwatson> brendand: I have never heard of that.
[09:16] <marga> I was reading the cookbook, which I found very interesting, but I still can't figure out why upstart stops working
[09:16] <cjwatson> Perhaps it's something KDE made up.
[09:17] <cjwatson> Note that the w3.org reference quoted there has no mention of upper-case forms.
[09:17] <brendand> cjwatson, i'm not on kubuntu, fyi
[09:17] <cjwatson> But of course environment variables are all just conventions of varying strengths.
[09:17] <cjwatson> brendand: Use the lower-case forms and ignore these alleged upper-case forms.
[09:17] <brendand> cjwatson, i wonder where the upper-case form is getting set though?
[09:18] <cjwatson> brendand: Nowhere, quite possibly :-)
[09:18] <marga> cjwatson, ok, 1 min.  I think the rest is just the original /etc/init/gssd.conf, although I'm not totally sure
[09:18] <brendand> cjwatson, something has set it, without my knowledge
[09:19] <marga> http://paste.ubuntu.com/1282741/
[09:19] <cjwatson> brendand: Could be anywhere
[09:19] <brendand> cjwatson, exactly
[09:19] <cjwatson> But I doubt it's terribly interesting
[09:20] <cjwatson> Anything can set whatever environment variables it likes, with or without any meaning
[09:20] <cjwatson> marga: Yeah, so 'expect fork' means that Upstart tracks the first process in the main script
[09:20] <cjwatson> Running dpkg-query and dpkg --compare-versions throws that off
[09:20] <marga> ok.
[09:21] <marga> Is there a way to fix it?
[09:21] <cjwatson> Can you not do this with a dependency instead, and lose the dpkg* calls?
[09:22] <marga> No, this file is distributed to the clients via puppet.
[09:22] <cjwatson> Otherwise, the only way I can think of to do this is to move the dpkg* calls to the pre-start script and have it write out a temporary file which is then sourced by the main script
[09:22] <cjwatson> Although the temporary file would have to be in a fixed location
[09:22] <marga> But wouldn't sourcing have the same effect?
[09:23] <cjwatson> No
[09:23] <cjwatson> Sourcing doesn't fork a subprocess
[09:26] <marga> ugh, this is ugly
[09:29] <cjwatson> marga: Regard it as the cost for getting rid of the ugliness of pid files :-)
[09:36] <marga> Uhm, it's saying that the pre-start process terminated with status 1.  I already have initctl logpriority in 1.  Is there anyway I could find out WHY it's finishing with status 1?
[09:37] <marga> logpriority in debug, I meant
[09:49] <cjwatson> marga: set -x at the start, and look at the logs?
[09:49] <cjwatson> (the start of the pre-start script)
[09:50] <marga> ok, that would have been better.  I used logger on each line.
[09:57] <marga> So, now it works when the flags are empty, but it hangs when there are flags.
[09:57] <marga> This makes me miserable...
[09:57] <marga> I'll paste how it looks now.
[09:59] <marga> http://paste.ubuntu.com/1282778/
[09:59] <marga> What did I do wrong this time?
[09:59] <dholbach> @pilot in
[09:59] <cjwatson> marga: Use '.' not 'source'
[09:59] <cjwatson> 'source' is a bashism
[10:00] <cjwatson> marga: 'export EXTRA_FLAGS' is useless
[10:00] <cjwatson> Oh, actually you initialise that, never mind.  You could drop the export and make it just env though
[10:00] <marga> ok.  That was in the cookbook.
[10:01] <cjwatson> I think just 'env EXTRA_FLAGS='
[10:01] <marga> What's the difference between env and export?
[10:01] <cjwatson> 'man 5 init' documents it
[10:01] <marga> ok, thanks.
[10:02] <cjwatson> So, I don't totally understand why it hangs, so I'm not sure that'll fix it
[10:03] <cjwatson> Maybe jodh can take over if that isn't enough; I have two bugs I need to be fixing urgently
[10:03] <marga> Ok, thanks a lot for the help!
[10:03] <marga> Good luck with your bugs
[10:04] <jodh> marga: do you see anything in /var/log/upstart/<job>.log? when you say it hangs, is a rpc.gssd process actually running and if so with which flags?
[10:05] <marga> jodh, I just rebooted (once it hangs, nothing I do will make it right again, except a reboot).  Just a moment
[10:05] <jodh> marga: does it hang on boot or when you attempt to start the job manually?
[10:07] <marga> It hangs when I do something that upstart doesn't like...
[10:07] <marga> I mean, if I modify the file in some ways, it hangs on start/stop
[10:07] <marga> But not on boot.
[10:08] <jodh> marga: when you attempt to start it manually, are you sure there isn't already a rpc.gssd process already running?
[10:08] <marga> Yes
[10:08] <marga> I found the bug
[10:08] <marga> It was a shell escaping bug
[10:09] <jodh> marga: that should have been logged in /var/log/upstart/<job>.log
[10:09] <marga> It was in the upstart log that you mentioned.  I didn't know about it till now
[10:09] <marga> I was looking at the syslog which wasn't helpful at all.
[10:09] <marga> Now I know better.
[10:09] <marga> Thanks.
[10:09] <jodh> marga: also, if you'd run 'init-checkconf job.conf', that would have given you an error.
[10:10] <marga> No, it was a more convoluted syntax error
[10:11] <cjwatson> Oh?  I didn't spot that ...
[10:11] <marga> I am echoing into a file and then sourcing it, and I'm missing some escaping quotes
[10:11] <marga> cjwatson, no, because it was not in the original paste. My bad.  I don't have a -e capable rpc.gssd, so to test it, I was using -t 600
[10:11] <cjwatson> I didn't see anything that clearly required quotation
[10:11] <cjwatson> Ah
[10:11] <marga> And I didn't escape the space
[10:12] <cjwatson> Yeah, so echo "EXTRA_FLAGS=\"${EXTRA_FLAGS}\"" then
[10:12] <marga> Right.
[10:12] <cjwatson> (or echo "EXTRA_FLAGS='${EXTRA_FLAGS}'")
[10:13] <marga> Thanks a lot cjwatson and jodh !
[10:28] <dholbach> Riddell, are you planning to do another kubuntu-docs upload before release?
[10:28] <dholbach> I saw there's https://code.launchpad.net/~bkerensa/ubuntu/quantal/kubuntu-docs/fix-for-1049278/+merge/125965 and https://code.launchpad.net/~m-alaa8/ubuntu/quantal/kubuntu-docs/fix-for-1066132/+merge/129598 in the queue
[10:30] <dholbach> Riddell, ^ I'll ping Darkwing about it too
[10:33] <dholbach> dpm, pitti: any opinions about https://bugs.launchpad.net/ubuntu/+source/langpack-locales/+bug/997248?
[10:35] <pitti> dholbach: I always demand forwarding them upstream (http://sourceware.org/bugzilla/enter_bug.cgi?product=glibc, "localedata" component), with a reference to an official documents which proves that the proposed change is correct
[10:35] <pitti> I've seen too many wars about other people then chiming in and saying "but that's all wrong!!!"
[10:35] <dholbach> ok
[10:35] <dholbach> will do
[10:35] <dholbach> thanks pitti
[10:35] <pitti> thanks!
[10:37] <Laney> -devel discussion> seems like a tag defer-next-release which hides from the overview, together with a script that untags all such bugs would work?
[10:37] <Laney> for bugs, not sure about MPs
[10:38] <dholbach> yes, sounds good
[10:38] <dholbach> it'd be nice if we could do the same for MPs easily
[10:39] <Laney> a hack would be to make an account whose purpose is to cause a MP to be hidden, then request a review from it
[10:41] <dholbach> what would the hack do? mark the MP as 'WIP' (or something) and then repropose it?
[10:41] <Laney> does WIP hide?
[10:41] <dholbach> yes
[10:42] <dholbach> not sure though if you need special permissions for that
[10:42] <dholbach> seb128, does https://code.launchpad.net/~carifio/seahorse/seahorse-remove-broken-help-buttons/+merge/129303 look OK to you? or is it something that should be forwarded upstream?
[10:42] <Laney> at least I can do it
[10:42] <dholbach> cool
[10:42] <Laney> so the unhide script has credentials for this account, sees which 'reviews' it has to do, flips the status back to Needs review and abstains
[10:43] <Laney> assuming this is possible via API
[10:43] <dholbach> I guess it should
[10:44]  * Laney can probably implement this
[10:45] <xnox> Laney: dholbach: I don't like "work in progress" because many "work in progress" are actually sponsor asking sponsoree to do something, which has not been done yet. Maybe we should reject those, but I have been setting to "work in progress".
[10:45] <Laney> it's WIP+review from role account
[10:45] <dholbach> xnox, WIP is something everyone can do, but not 'reject' :-/
[10:45] <xnox> Laney: that would be nice =)
[10:46] <Laney> call it ~defer-sponsorship
[10:46] <xnox> "needs reivew" -> "WIP+review" with a comment on the merge proposal would be nice indeed =))))
[10:47] <Laney> haha
[10:47] <Laney> dholbach: was "HOLY PATATAS BRAVAS" you?
[10:47] <dholbach> yes :)
[10:48] <seb128> dholbach, I will have a look to the seahorse merge request, I looked a bit at it before
[10:49] <dholbach> seb128, merci beaucoup mon ami
[10:49] <seb128> dholbach, de rien ;-)
[11:22] <amb__> I am trying to port a debian experimental package (xen 4.2.0) to Precise. When I debuild I get /usr/bin/ld.bfd.real: unrecognized option '-Wl,-Bsymbolic-functions'. AIUI if -B is passed to ld, it should be without the -Wl. The text 'symbolic-functions' does not appears anywhere within the source. But config.log & config.status (built) have 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro' - it's coming from inside the ship (um, inside Pr
[11:22] <amb__> ecise). That surely must be wrong. Any ideas?
[11:30] <alexbligh1> $ dpkg-buildflags | fgrep LDFLAGS
[11:30] <alexbligh1> LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro
[11:30] <alexbligh1> manpage suggests the -Wl etc. should not be there.
[11:31] <cjwatson> Man page doesn't document the Ubuntu vendor defaults
[11:31] <alexbligh1> "Options passed to the compiler when linking executables or shared objects (if the linker is called directly, then -Wl and , have to be stripped from these options). Default value: empty."
[11:31] <cjwatson> Sure, man page bug
[11:31] <cjwatson> The actual program behaviour is correct for Ubuntu
[11:32] <cjwatson> Although note that further down there's a bit about relro which says it's enabled by default
[11:32] <alexbligh1> Ah, does it mean '-Wl' has to be stripped by the setter? or by the consumer?
[11:32] <cjwatson> You should be linking with gcc, not with ld
[11:33] <alexbligh1> AFAICT it's running a bog standard autoconf
[11:33] <cjwatson> As the man page says, if you want to link with ld, you need to strip off -Wl,
[11:33] <alexbligh1> Ah, I read that as 'the setter needs to strip it'.
[11:33] <cjwatson> No, that's wrong
[11:33] <cjwatson> autoconf doesn't control how programs are linked
[11:33] <cjwatson> automake does, but bog-standard automake will link with gcc
[11:34] <alexbligh1> oh sorry, auto*
[11:34] <cjwatson> Can't be bog-standard
[11:34] <cjwatson> I expect there are some custom rules somewhere
[11:35] <alexbligh1> seems to be using $(LD) ...
[11:35] <cjwatson> The Ubuntu package in precise had a patch to adjust LDFLAGS for use by ld
[11:35] <alexbligh1> The Xen package? How do you remember all this stuff? :-)
[11:36] <cjwatson> I looked up the changelog
[11:36] <cjwatson> It was dropped in quantal because the quantal packaging toolchain no longer exports LDFLAGS to the environment by default; you have to ask for it using dpkg-buildflags
[11:36] <alexbligh1> ha ha
[11:36] <cjwatson> However this means that the quantal package has the (far from uncommon) bug of not using the default build flags
[11:36] <cjwatson> If upstream can be persuaded to use $(CC) rather than $(LD) to link, that would be best, but they may have reasons not to
[11:37] <cjwatson> Failing that, restore the patch to hack LDFLAGS
[11:37] <alexbligh1> I'm trying to build on Precise anyway, and there is no Xen4.2.0 anywhere in Ubuntuland as far as I can tell (even in PPA)
[11:37] <alexbligh1> Hence stealing the Debian one.
[11:37] <cjwatson> Sure, but there's no reason you couldn't borrow most of the packaging, or at least that patch from it
[11:37] <alexbligh1> No indeed, that is exactly what I shall do.
[11:38] <cjwatson> xen ought to be modified to use dpkg-buildflags, at which point it'll start noticing this problem again, even in Debian
[11:38] <alexbligh1> I may not steal the ubuntu packaging, as the xen 4.1 ubuntu packaging was 'interesting' (like the dev libraries were incomplete)
[11:38] <cjwatson> (Debian's packaging toolchain never exported LDFLAGS to the environment by default; that was an Ubuntuism which we dropped in quantal in the cause of getting closer to Debian)
[11:39] <alexbligh1>  dpkg-buildpackage -rfakeroot -D -us -uc -b
[11:39] <alexbligh1> dpkg-buildpackage: export CFLAGS from dpkg-buildflags (origin: vendor): -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security
[11:39] <alexbligh1> dpkg-buildpackage: export CPPFLAGS from dpkg-buildflags (origin: vendor): -D_FORTIFY_SOURCE=2
[11:39] <alexbligh1> dpkg-buildpackage: export CXXFLAGS from dpkg-buildflags (origin: vendor): -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security
[11:39] <alexbligh1> dpkg-buildpackage: export FFLAGS from dpkg-buildflags (origin: vendor): -g -O2
[11:39] <alexbligh1> dpkg-buildpackage: export LDFLAGS from dpkg-buildflags (origin: vendor): -Wl,-Bsymbolic-functions -Wl,-z,relro
[11:39] <alexbligh1> doesn't that suggest it is?
[11:39] <cjwatson> That's precise's behaviour, yes
[11:39] <cjwatson> Notice that I said quantal
[11:40] <alexbligh1> ah it's an implict call to buildflags.
[11:40] <alexbligh1> cjwatson, thx
[11:41] <cjwatson> no problem
[12:00] <dholbach> can the people from lubuntu,mythbuntu,xubuntu,ubuntustudio please have a look at https://code.launchpad.net/~gunnarhj/ubuntu/quantal/lightdm-gtk-greeter/lang-chooser-on-by-default/+merge/129758 and see if that's what they want?
[12:10] <smb> cjwatson, I am somewhat torn between trying to ask you one evening in Copenhagen what should be done exactly with the buildflags and the Xen package or after it when there is a bit time (and not release week). Though both has somewhat illusional chances. I try to keep it in mind/on a list for the next time I touch it...
[12:11] <mr_pouit> dholbach: not an issue for xubuntu/lubuntu because we use our own config file.
[12:11]  * smartboyhw thinks so too with Ubuntu Studio
[12:11] <dholbach> mr_pouit, do you by chance know how other flavours deal with this?
[12:11] <dholbach> aha
[12:12] <dholbach> maybe you could reply on the merge proposal?
[12:12] <dholbach> just so it's easier to track down for us
[12:12] <dholbach> and maybe we should ask some of the other flavours to review this too
[12:13] <mr_pouit> in the bug report, Gunnar already stated this (https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/803858/comments/27) too
[12:14] <dholbach> ok cool
[12:14] <ochosi> dholbach: ping
[12:15] <dholbach> ochosi, pong
[12:15] <ochosi> dholbach: astraljava passed a question about this merge-request along: https://code.launchpad.net/~gunnarhj/ubuntu/quantal/lightdm-gtk-greeter/lang-chooser-on-by-default/+merge/129758
[12:16] <dholbach> mr_pouit, smartboyhw and I were just talking about it
[12:16] <smartboyhw> dholbach, some comments in our dev channel says it is ok
[12:16] <ochosi> sorry, i was informed about that just now :p
[12:16] <dholbach> ochosi, so it seems like xubuntu/lubuntu because use their own config file
[12:16] <dholbach> so it might well be that the change is not necessary
[12:17] <dholbach> (and it might be similar for Ubuntu Studio)
[12:17] <smartboyhw> dholbach, I wonder: Actually what will the lightdm-gtk-greeter look like after the merge?
[12:17] <ochosi> dholbach: just out of interest, is this the language-selector here: http://www.zimagez.com/zimage/screenshot-10162012-020905pm.php
[12:17] <smartboyhw> dholbach, should I go and ask the Kubuntu guys?
[12:17] <mr_pouit> dholbach: it's useful for people who use lightdm-gtk-greeter with ubuntu
[12:18] <dholbach> smartboyhw, they use lightdm-kde-greeter
[12:18] <smartboyhw> dholbach, er....Wait
[12:18] <dholbach> mr_pouit, right, yes
[12:19] <dholbach> ok, I guess I will just ping mterry about it once he turns up later on
[12:19] <smartboyhw> dholbach, hmm....Since I do saw the select language menus in 12.10 Ubuntu Studio builds.....maybe that wasn't needed for Ubuntu Studio..It is just derived from Ubuntu Studio
[12:20] <cjwatson> smb: In general, if not using sufficiently smart helper tools (dh(1) from debhelper compat level >= 9), packages should fetch at least the default values of CPPFLAGS, CFLAGS, and LDFLAGS from dpkg-buildflags in debian/rules and pass those to the upstream build system in whatever way is appropriate
[12:20] <cjwatson> There are various options and exactly which to use depends on the build system
[12:25] <smb> cjwatson, Yes, I guess I would have the do the latter as the Debian Xen package was (iirc) not using the shorter dh variant but a more complex rules file. I was wondering when it did not need the hack anymore but I think back then when I asked around it was not persistent/widely enough.
[12:25] <cjwatson> The LDFLAGS hack ceased to be required when we changed dpkg-buildpackage in early quantal to no longer export flags by default, but the flip side is that you've probably lost hardening flags.
[12:26] <cjwatson> So it's moderately important to fix that for R.
[12:27] <smb> cjwatson, Sure I saw that in the scrollback. It is now on my my list at least (and hopefully I do not forget to look at it when I touch it next). Probably also to go backwards into Q if opportunity permits.
[13:03] <doko> cjwatson, which hardening flags do we loose exactly? these are still defaults in gcc
[13:04] <cjwatson> Oh, maybe
[13:04] <cjwatson> I looked into this a while back but I forget the results
[13:05] <cjwatson> Not hardening then, but -Wl,-Bsymbolic-functions
[13:05] <doko> right, that would be the one
[13:22] <doko> jamespage, are you ok with building gwt, mondrian using openjdk-6 to work-around the build failures?
[13:22] <jamespage> doko, +1
[13:23] <cjwatson> doko: Would that help with eigenbase-resgen too?
[13:23] <doko> I'll check
[13:24] <cjwatson> But yeah, we can't remove that stack, too many build-deps
[13:59] <gogo_> Hello, in Ubuntu 12.10, I cannot change window animation duration from CCSM. Any altered value have no effect on duration and default values are still used. Is this a bug or intended behavior?
[14:16] <stokachu> Would someone be able take a look at https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=open-iscsi? its been in the unapproved queue since 10/3
[14:29] <stokachu> dholbach: so once the package is in the upload queue ubuntu-sponsors is not needed and it relies on ubuntu-sru at that point?
[14:29] <dholbach> stokachu, yes
[14:29] <stokachu> dholbach: ok cool just checking so I dont incorrectly subscribe sponsors again
[14:29] <dholbach> it's all good :)
[14:29] <dholbach> thanks for your work on this
[14:30] <stokachu> sure thing :D
[14:31] <xnox> stokachu: most of SRU folks are busy doing the release =)
[14:32] <stokachu> xnox: ah
[14:33] <stokachu> xnox: http://people.canonical.com/~ubuntu-archive/pending-sru.html, does the package show up once the upload has been approved?
[14:35] <xnox> stokachu: yes. these are packages that were accepted into $release-proposed and now are tracked how long they are in the -proposed and if they are "aged", "verified" and did not regress.
[14:36] <doko> Laney, your handbrake upload ftbfs on amd64
[14:36] <Laney> yes I know
[14:36] <doko> =)
[14:36] <Laney> I pinged jbicha, it's his backport really
[14:36] <Laney> the way we upload those makes it appear to be the backporter on the hook
[14:38] <Laney> doko: is there a way to do that scanning locally with sbuild?
[14:39] <doko> Laney, don't know. maybe ask lamont, I think he did add the code to the buildds in ia64 times ...
[14:40] <jbicha> implicit pointer conversion build failures are so annoying
[14:42] <cjwatson> It's in lp:launchpad-buildd
[14:43] <xnox> doko: yeah I totally want to know how to run that check locally, as it's not integrated into something useful which get's installed by mk-sbuild (same as pkgstripper, binary manglers & dbgsym generators).
[14:43] <cjwatson> lpbuildd/check_implicit_pointer_functions.py <foo.build
[14:43] <cjwatson> or sbuild | lpbuildd/check_implicit_pointer_functions.py --inline
[14:44]  * xnox takes a note to add a further wrapper to my sbuild....
[14:47] <stokachu> xnox: is there anyone in particular i could bug about this package being in the unapproved queue?
[14:47] <stokachu> without losing some fingers
[14:48] <cjwatson> stokachu: I'll take a look.
[14:49] <xnox> stokachu: looking at https://launchpad.net/~ubuntu-sru/+members the usual suspects are steve, colin, adam, clint... =) for that sort of package.
[14:50] <cjwatson> stokachu: accepted
[14:51] <stokachu> cjwatson: awesome thanks man
[15:01] <hallyn> safe to assume we have no sparcs in build farm?
[15:01] <cjwatson> We have two sparc builders.
[15:01] <cjwatson> artigas and sejong.  https://launchpad.net/builders
[15:02] <hallyn> cjwatson: so openbios-sparc, which must be built on sparc, *could* be pulled into ubuntu?
[15:02] <cjwatson> No, that's a different problem
[15:02] <hallyn> i'm looking into how closely we can mirror debian's qemu packaging layout for r
[15:02] <cjwatson> We have no way to do architecture: all builds on anything other than i386
[15:03] <hallyn> ok so i should drop sparc
[15:04] <hallyn> cjwatson: thanks
[15:05] <cjwatson> bug 183495
[15:05] <cjwatson> Although I'm sure there's a bug on Launchpad somewhere, where it more properly belongs
[15:06] <hallyn> cjwatson: but as it's been around since 2008, low prio i assume
[15:08] <cjwatson> hallyn: Bug 217427
[15:09] <xnox> cjwatson: but there is no way to currently express that in .dsc e.g. build-arch field
[15:10] <hallyn> cjwatson: i'm a little surprised a powerpc - on - x86 crosscompiler isn't packaged...
[15:10] <xnox> cjwatson: hallyn: (ugly-hack) arch: ppc, Multi-Arch:
[15:10] <xnox> cjwatson: hallyn: (ugly-hack) Arch: ppc, Multi-Arch: allowed
[15:10] <cjwatson> xnox: See that bug report.
[15:10] <cjwatson> xnox: I'd rather you didn't work around it that way.
[15:10] <cjwatson> If nothing else, that's no use for cases that involve build-deps.
[15:11] <cjwatson> hallyn: *shrug*
[15:11] <hallyn> cjwatson: i'm wondering whether, if it did, that sufficed
[15:12] <cjwatson> hallyn: Don't know.  Possibly
[15:12] <xnox> hallyn: well all rdeps would need to be changed to: package [sparc]
[15:12] <xnox> hallyn: well all rdeps would need to be changed to: package [ppc]
[15:12] <cjwatson> xnox: No, they wouldn't.
[15:13] <cjwatson> Cross-compile binary, put it in an architecture: all binary just as it is now.
[15:13] <cjwatson> Also, you can't specify a particular architecture in Depends.
[15:18] <hallyn> cjwatson: any sense having a uds session on this?
[15:19] <cjwatson> hallyn: No, we'd just all sit around and agree that either the Launchpad bug needs to be fixed or we need a cross-compiler
[15:20] <hallyn> ok :)
[15:20] <hallyn> there used to be a simple howto for locally creating cross-compiler, but might be a bear to package
[15:21] <cjwatson> hrw might know
[15:21] <hrw> hi
[15:22] <hallyn> hrw: wondering about feasability of creating a set of cross-compiler packages
[15:22] <hallyn> (specifically gcc for powerpc and sparc)
[15:23] <hrw> hallyn: doable with arm cross compiler packages as base
[15:24] <hrw> hallyn: but openbios-sparc on debian is arch:all - can't be same in ubuntu?
[15:25] <hrw> I see - 'This package must be built on a SPARC machine'
[15:26] <hallyn> hrw: right (same with openbios-ppc, and presumably openhackware)
[15:27] <hallyn> so gcc-arm-linux-gnueabi as an example?
[15:27] <hrw> hallyn: going for cross compilation with them means maintaining 3 packages per arch (6 for biarchs).
[15:27] <hrw> hallyn: binutils-armel-cross, armel-cross-toolchain-base, gcc-4.7-armel-cross
[15:28] <hrw> hallyn: first gives binutils, second glibc and libgcc, last one gives compiler
[15:28] <cjwatson> Might be less effort to fix the LP bug ...
[15:29] <hrw> cjwatson: and then we will pray that no one wants openbios-hppa :D
[15:29] <cjwatson> OK, that's true, fixing the LP bug wouldn't help with openbios-sparc since it's no longer an architecture in modern series
[15:29] <cjwatson> So a cross-compiler would be needed for that either way
[15:30] <hrw> or package removal but that will hurt all users of qemu-sparc
[15:33] <cjwatson> The package was actually removed ages ago
[15:33] <cjwatson> But it'd be nice to be able to reintroduce it
[15:34] <hrw> question is: who wants to maintain those cross compilers?
[15:35] <cjwatson> hallyn's the one pushing for this currently :)
[15:37] <hrw> hallyn: grab binutils-armel-cross source, sed -i s/armel/sparc/ debian/changelog then debian/rules control and build. then same with armel-cross-toolchain-base and gcc-4.7-armel-cross. when all done, grab gcc-defaults-armel-cross and do changelog and rules trick then rebuild.
[15:37] <dholbach> @pilot out
[15:37] <hrw> hallyn: if you are lucky then small amount of work needed.
[15:40] <hallyn> hrw: thanks, will give it a shot
[15:42] <hrw> hallyn: wookey did aarch64 cross compiler recently from those packages so it is doable ;)
[15:42] <hrw> hallyn: in case of problems - ask me
[15:43] <hallyn> will do thx
[15:46] <lamont> jbicha: like cjwatson said - it's just a logfile scan that looks for implicits that were conversion truncation, or so
[19:53] <cjwatson> jtaylor: abiword/armel failed to build
[19:53] <jtaylor> Oo
[19:53] <jtaylor> can't be the abiword change
[19:54] <cjwatson> jtaylor: No, but now we're in a bit of a bind for release
[19:54] <cjwatson> We *were* at the point where there were zero out-of-date binaries in the archive
[19:54] <cjwatson> abiword has broken that
[19:55] <cjwatson> The last build was only 2012-10-08 ...
[19:55] <jtaylor> yes not long ago
[19:55] <cjwatson> Looks like somebody has retried it already?
[19:55] <jtaylor> I didn't expect toolchain breaking
[19:55] <cjwatson> He says as the build log goes away
[19:55] <cjwatson> jtaylor: I should have noticed it was in images and required your sync to go through -proposed
[19:58] <jtaylor> but isn't this a larger issue jut discovered by abiword
[19:59] <cjwatson> Maybe, but such fine principles are for earlier in the cycle
[19:59] <cjwatson> Now we need to not break stuff or expose breakage
[20:00] <micahg> cjwatson: if it's just armel, it shouldn't impact any images at least
[20:00] <cjwatson> No, but if fixing it requires a source upload, that'll hit Xubuntu and Lubuntu
[20:00] <cjwatson> I am *not* going to leave out-of-dates just after we spent weeks getting them clean
[20:01] <cjwatson> I mean *literally* just after, as in the next publisher cycle
[20:04] <micahg> true
[20:36] <mwhudson> probably not the place to ask this question, but:
[20:37] <mwhudson> why would apt-get remove $package (unattended-upgrades in this case) want to install over 100 new packages?
[20:38] <slangasek> possiblybecause something else on the system depends on $package and apt looks for a way to satisfy your request that results in the smallest number of additional packages having to be removed
[20:39] <mwhudson> ah right
[20:39] <mwhudson> i think i don't want to remove it in fact
[20:39] <mwhudson> just disable it
[21:23] <ScottK> cjwatson: Is you comment on Bug #674627 at all indicative that it's still an issue or you just doing cleanup?
[21:25] <cjwatson> ScottK: Just cleanup.
[21:25] <ScottK> OK.  Thanks.
[21:25] <cjwatson> ScottK: I was hunting for bugs filed on the upstream ubiquity project, which we don't use.
[21:26] <ScottK> The sip4 upstream has been very responsive about fixing stuff, but since he actually spends time on stuff I send him, I'm reluctant to forward old bugs that I can't confirm are an issue.
[21:55] <cyphermox> @pilot in
[22:01] <slangasek> barry: so did you also hit bug #1054712?
[22:07] <stgraber> slangasek: I had that happen to me a couple of times lately while testing persistence. Seemed to happen pretty often when dealing with fast storage (external USB3 SSD).
[22:08] <barry> slangasek: yep.  i was investigating bug #915626 but realized it was different.  my reported bug #1064072 was duped to bug #1054712 but i didn't investigate further
[22:09] <stgraber> segfault would typically happen after the file copy and before the boot sector would get written. Apparently killing the leftovers udisk and usb-creator processes was helping but it was still mostly random in my case (using the same source image and destination drive)
[22:10] <barry> stgraber: it sure smells like a reference counting bug
[22:11] <stgraber> at the time I was in the middle of sorting a bunch of casper bugs so didn't have much time to investigate. I just ended up manually setting up the MBR and the disk then worked fine.
[22:17] <cjwatson> jtaylor: Yeah, you're off the hook - a retry succeeded
[22:17] <cjwatson> (phew)
[22:17] <jtaylor> uff
[22:17] <jtaylor> strange
[22:18] <barry> stgraber, slangasek: i can take a closer look tomorrow.  the crash sure seems like dbus-string.c is trying to delete something it doesn't own but thinks it does
[22:18]  * jtaylor sticks big red marker onto scren "hands off seeded packages"
[22:18] <jtaylor> sorry for the screwup
[22:19] <cjwatson> Ah well, no real harm done in the end
[22:20] <jtaylor> at least i saw another potential issue scroll by in the log
[22:20] <jtaylor> Wsequence-point
[22:20] <jtaylor> and reported to debian
[22:50] <slangasek> barry, stgraber: so for me the problem is consistently reproducible when trying to write to a USB stick without persistence
[22:51] <slangasek> haven't tried with yet
[22:51] <barry> slangasek: yep, when i was looking at it, it crashed every time for me.  debugging it will be fun though
[22:52] <slangasek> yeah, segfaulting python is my favoite
[22:56] <barry> slangasek: especially memory ownership bugs :)
[22:56] <bdmurray> slangasek: is that the usb-creator bug?
[22:57] <barry> bdmurray: yep
[22:57] <slangasek> well, apparently a different one than the one we currently have targeted
[23:19] <slangasek> barry: python is very noisy under valgrind
[23:19] <barry> oh yes
[23:20] <barry> slangasek: Misc/vgrindefs from python's source helps (though it's been ages since i valground python ;)
[23:20] <barry> slangasek: oops
[23:20] <barry> slangasek: wrong file
[23:21] <barry> Misc/README.valgrind
[23:21] <slangasek> ta :)
[23:21] <barry> np!
[23:22] <slangasek> though it's possible I can just ignore everything up to the point right before it crashes, anyway; it's fairly quiet while it's running the disk copy
[23:24] <slangasek> ==12322==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
[23:24] <slangasek> well that's helpful
[23:35] <slangasek> hah, and when I run it under pdb it completes successfully :P
[23:45] <slangasek> barry: bah, what does pdb permute that causes this command to succeed? :/