=== jono is now known as Guest36495 === dendro-afk is now known as dendrobates [04:39] stgraber: no worries [04:39] good morning === tkamppeter_ is now known as tkamppeter [06:53] good morning === smb` is now known as smb === henrix_ is now known as henrix === henrix is now known as henrix_ === henrix_ is now known as henrix [08:55] hm, the e.u.c graph hasn't updated in 5 days [08:58] Laney: it has ... *drumroll* ... an error [08:58] quis custodiet ipsos custodes? [08:59] Host errors.errors.ubuntu.com not found: 3(NXDOMAIN) :( [09:02] 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] ev: are cron jobs fixed?! =) [09:08] does anyone know difference between 'NO_PROXY' and 'no_proxy'? [09:10] The latter is an environment variable I've heard of; the former isn't [09:11] 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] did i really need to specify 'and no smart answers' :) [09:11] brendand: Um, I thought that was a perfectly straightforward answer. [09:12] 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] 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] cjwatson, ok, but I need to pass some env variables to it. [09:13] (I don't know the history behind that.) [09:13] I'm going to go paste something. [09:13] marga: Why not use 'env'? [09:14] The Upstart stanza, I mean, not the command [09:14] cjwatson, just let me paste this and you tell me how to make it better. [09:14] Sure [09:15] http://paste.ubuntu.com/1282738/ [09:15] The thing is, if I add my stanza like that, upstart gets very angry and refuses to start or stop anything. [09:15] Ah, you need to compute the environment variables; that's trickier [09:15] OK, I'll work something out for you, few minutes [09:15] Your basic problem is that you've confused fork tracking [09:16] Ok... [09:16] marga: I don't think that's the whole file; can you show me the whole file, please? [09:16] 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] KDE bug 54898 in kcmproxy "implement NO_PROXY in preset environment variables proxy configuration" [Normal,Resolved: fixed] [09:16] brendand: I have never heard of that. [09:16] I was reading the cookbook, which I found very interesting, but I still can't figure out why upstart stops working [09:16] Perhaps it's something KDE made up. [09:17] Note that the w3.org reference quoted there has no mention of upper-case forms. [09:17] cjwatson, i'm not on kubuntu, fyi [09:17] But of course environment variables are all just conventions of varying strengths. [09:17] brendand: Use the lower-case forms and ignore these alleged upper-case forms. [09:17] cjwatson, i wonder where the upper-case form is getting set though? [09:18] brendand: Nowhere, quite possibly :-) [09:18] cjwatson, ok, 1 min. I think the rest is just the original /etc/init/gssd.conf, although I'm not totally sure [09:18] cjwatson, something has set it, without my knowledge [09:19] http://paste.ubuntu.com/1282741/ [09:19] brendand: Could be anywhere [09:19] cjwatson, exactly [09:19] But I doubt it's terribly interesting [09:20] Anything can set whatever environment variables it likes, with or without any meaning [09:20] marga: Yeah, so 'expect fork' means that Upstart tracks the first process in the main script [09:20] Running dpkg-query and dpkg --compare-versions throws that off [09:20] ok. [09:21] Is there a way to fix it? [09:21] Can you not do this with a dependency instead, and lose the dpkg* calls? [09:22] No, this file is distributed to the clients via puppet. [09:22] 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] Although the temporary file would have to be in a fixed location [09:22] But wouldn't sourcing have the same effect? [09:23] No [09:23] Sourcing doesn't fork a subprocess [09:26] ugh, this is ugly [09:29] marga: Regard it as the cost for getting rid of the ugliness of pid files :-) [09:36] 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] logpriority in debug, I meant === hrww is now known as hrw [09:49] marga: set -x at the start, and look at the logs? [09:49] (the start of the pre-start script) [09:50] ok, that would have been better. I used logger on each line. [09:57] So, now it works when the flags are empty, but it hangs when there are flags. [09:57] This makes me miserable... [09:57] I'll paste how it looks now. [09:59] http://paste.ubuntu.com/1282778/ [09:59] What did I do wrong this time? [09:59] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach [09:59] marga: Use '.' not 'source' [09:59] 'source' is a bashism [10:00] marga: 'export EXTRA_FLAGS' is useless [10:00] Oh, actually you initialise that, never mind. You could drop the export and make it just env though [10:00] ok. That was in the cookbook. [10:01] I think just 'env EXTRA_FLAGS=' [10:01] What's the difference between env and export? [10:01] 'man 5 init' documents it [10:01] ok, thanks. [10:02] So, I don't totally understand why it hangs, so I'm not sure that'll fix it [10:03] Maybe jodh can take over if that isn't enough; I have two bugs I need to be fixing urgently [10:03] Ok, thanks a lot for the help! [10:03] Good luck with your bugs [10:04] marga: do you see anything in /var/log/upstart/.log? when you say it hangs, is a rpc.gssd process actually running and if so with which flags? [10:05] jodh, I just rebooted (once it hangs, nothing I do will make it right again, except a reboot). Just a moment [10:05] marga: does it hang on boot or when you attempt to start the job manually? [10:07] It hangs when I do something that upstart doesn't like... [10:07] I mean, if I modify the file in some ways, it hangs on start/stop [10:07] But not on boot. [10:08] marga: when you attempt to start it manually, are you sure there isn't already a rpc.gssd process already running? [10:08] Yes [10:08] I found the bug [10:08] It was a shell escaping bug [10:09] marga: that should have been logged in /var/log/upstart/.log [10:09] It was in the upstart log that you mentioned. I didn't know about it till now [10:09] I was looking at the syslog which wasn't helpful at all. [10:09] Now I know better. [10:09] Thanks. [10:09] marga: also, if you'd run 'init-checkconf job.conf', that would have given you an error. [10:10] No, it was a more convoluted syntax error [10:11] Oh? I didn't spot that ... [10:11] I am echoing into a file and then sourcing it, and I'm missing some escaping quotes [10:11] 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] I didn't see anything that clearly required quotation [10:11] Ah [10:11] And I didn't escape the space [10:12] Yeah, so echo "EXTRA_FLAGS=\"${EXTRA_FLAGS}\"" then [10:12] Right. [10:12] (or echo "EXTRA_FLAGS='${EXTRA_FLAGS}'") [10:13] Thanks a lot cjwatson and jodh ! [10:28] Riddell, are you planning to do another kubuntu-docs upload before release? [10:28] 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] Riddell, ^ I'll ping Darkwing about it too [10:33] dpm, pitti: any opinions about https://bugs.launchpad.net/ubuntu/+source/langpack-locales/+bug/997248? [10:33] Launchpad bug 997248 in langpack-locales (Ubuntu) "Inconsistency in decimal point for es_MX and es_NI locale" [Undecided,In progress] [10:35] 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] I've seen too many wars about other people then chiming in and saying "but that's all wrong!!!" [10:35] ok [10:35] will do [10:35] thanks pitti [10:35] thanks! [10:37] -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] for bugs, not sure about MPs [10:38] yes, sounds good [10:38] it'd be nice if we could do the same for MPs easily [10:39] 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] what would the hack do? mark the MP as 'WIP' (or something) and then repropose it? [10:41] does WIP hide? [10:41] yes [10:42] not sure though if you need special permissions for that [10:42] 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] at least I can do it [10:42] cool [10:42] 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] assuming this is possible via API [10:43] I guess it should [10:44] * Laney can probably implement this [10:45] 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] it's WIP+review from role account [10:45] xnox, WIP is something everyone can do, but not 'reject' :-/ [10:45] Laney: that would be nice =) [10:46] call it ~defer-sponsorship [10:46] "needs reivew" -> "WIP+review" with a comment on the merge proposal would be nice indeed =)))) [10:47] haha [10:47] dholbach: was "HOLY PATATAS BRAVAS" you? [10:47] yes :) [10:48] dholbach, I will have a look to the seahorse merge request, I looked a bit at it before [10:49] seb128, merci beaucoup mon ami [10:49] dholbach, de rien ;-) === MacSlow is now known as MacSlow|lunch [11:22] 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] ecise). That surely must be wrong. Any ideas? === amb__ is now known as alexbligh1 [11:30] $ dpkg-buildflags | fgrep LDFLAGS [11:30] LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro [11:30] manpage suggests the -Wl etc. should not be there. [11:31] Man page doesn't document the Ubuntu vendor defaults [11:31] "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] Sure, man page bug [11:31] The actual program behaviour is correct for Ubuntu [11:32] Although note that further down there's a bit about relro which says it's enabled by default [11:32] Ah, does it mean '-Wl' has to be stripped by the setter? or by the consumer? [11:32] You should be linking with gcc, not with ld [11:33] AFAICT it's running a bog standard autoconf [11:33] As the man page says, if you want to link with ld, you need to strip off -Wl, [11:33] Ah, I read that as 'the setter needs to strip it'. [11:33] No, that's wrong [11:33] autoconf doesn't control how programs are linked [11:33] automake does, but bog-standard automake will link with gcc [11:34] oh sorry, auto* [11:34] Can't be bog-standard [11:34] I expect there are some custom rules somewhere [11:35] seems to be using $(LD) ... [11:35] The Ubuntu package in precise had a patch to adjust LDFLAGS for use by ld [11:35] The Xen package? How do you remember all this stuff? :-) [11:36] I looked up the changelog [11:36] 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] ha ha [11:36] However this means that the quantal package has the (far from uncommon) bug of not using the default build flags [11:36] 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] Failing that, restore the patch to hack LDFLAGS [11:37] 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] Hence stealing the Debian one. [11:37] Sure, but there's no reason you couldn't borrow most of the packaging, or at least that patch from it [11:37] No indeed, that is exactly what I shall do. [11:38] xen ought to be modified to use dpkg-buildflags, at which point it'll start noticing this problem again, even in Debian [11:38] I may not steal the ubuntu packaging, as the xen 4.1 ubuntu packaging was 'interesting' (like the dev libraries were incomplete) [11:38] (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] dpkg-buildpackage -rfakeroot -D -us -uc -b [11:39] dpkg-buildpackage: export CFLAGS from dpkg-buildflags (origin: vendor): -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security [11:39] dpkg-buildpackage: export CPPFLAGS from dpkg-buildflags (origin: vendor): -D_FORTIFY_SOURCE=2 [11:39] dpkg-buildpackage: export CXXFLAGS from dpkg-buildflags (origin: vendor): -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security [11:39] dpkg-buildpackage: export FFLAGS from dpkg-buildflags (origin: vendor): -g -O2 [11:39] dpkg-buildpackage: export LDFLAGS from dpkg-buildflags (origin: vendor): -Wl,-Bsymbolic-functions -Wl,-z,relro [11:39] doesn't that suggest it is? [11:39] That's precise's behaviour, yes [11:39] Notice that I said quantal [11:40] ah it's an implict call to buildflags. === Quintasan_ is now known as Quintasan [11:40] cjwatson, thx [11:41] no problem [12:00] 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] 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] dholbach: not an issue for xubuntu/lubuntu because we use our own config file. === _salem is now known as salem_ [12:11] * smartboyhw thinks so too with Ubuntu Studio [12:11] mr_pouit, do you by chance know how other flavours deal with this? [12:11] aha [12:12] maybe you could reply on the merge proposal? [12:12] just so it's easier to track down for us [12:12] and maybe we should ask some of the other flavours to review this too [12:13] in the bug report, Gunnar already stated this (https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/803858/comments/27) too [12:13] Launchpad bug 803858 in lightdm-gtk-greeter (Ubuntu) "No language chooser on login screen in LightDM" [Undecided,In progress] [12:14] ok cool [12:14] dholbach: ping [12:15] ochosi, pong [12:15] 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] mr_pouit, smartboyhw and I were just talking about it [12:16] dholbach, some comments in our dev channel says it is ok [12:16] sorry, i was informed about that just now :p [12:16] ochosi, so it seems like xubuntu/lubuntu because use their own config file [12:16] so it might well be that the change is not necessary [12:17] (and it might be similar for Ubuntu Studio) [12:17] dholbach, I wonder: Actually what will the lightdm-gtk-greeter look like after the merge? [12:17] dholbach: just out of interest, is this the language-selector here: http://www.zimagez.com/zimage/screenshot-10162012-020905pm.php [12:17] dholbach, should I go and ask the Kubuntu guys? [12:17] dholbach: it's useful for people who use lightdm-gtk-greeter with ubuntu [12:18] smartboyhw, they use lightdm-kde-greeter [12:18] dholbach, er....Wait [12:18] mr_pouit, right, yes [12:19] ok, I guess I will just ping mterry about it once he turns up later on [12:19] 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] 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] There are various options and exactly which to use depends on the build system === MacSlow|lunch is now known as MacSlow [12:25] 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] 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] So it's moderately important to fix that for R. === cpg is now known as cpg|away [12:27] 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. === salem_ is now known as _salem === _salem is now known as salem_ === doko__ is now known as doko [13:03] cjwatson, which hardening flags do we loose exactly? these are still defaults in gcc [13:04] Oh, maybe [13:04] I looked into this a while back but I forget the results [13:05] Not hardening then, but -Wl,-Bsymbolic-functions [13:05] right, that would be the one [13:22] jamespage, are you ok with building gwt, mondrian using openjdk-6 to work-around the build failures? [13:22] doko, +1 [13:23] doko: Would that help with eigenbase-resgen too? [13:23] I'll check [13:24] But yeah, we can't remove that stack, too many build-deps === yofel_ is now known as yofel [13:59] 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] 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] 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] stokachu, yes [14:29] dholbach: ok cool just checking so I dont incorrectly subscribe sponsors again [14:29] it's all good :) [14:29] thanks for your work on this [14:30] sure thing :D [14:31] stokachu: most of SRU folks are busy doing the release =) [14:32] xnox: ah [14:33] xnox: http://people.canonical.com/~ubuntu-archive/pending-sru.html, does the package show up once the upload has been approved? [14:35] 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] Laney, your handbrake upload ftbfs on amd64 [14:36] yes I know [14:36] =) [14:36] I pinged jbicha, it's his backport really [14:36] the way we upload those makes it appear to be the backporter on the hook [14:38] doko: is there a way to do that scanning locally with sbuild? [14:39] Laney, don't know. maybe ask lamont, I think he did add the code to the buildds in ia64 times ... [14:40] implicit pointer conversion build failures are so annoying [14:42] It's in lp:launchpad-buildd [14:43] 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). === dendrobates is now known as dendro-afk [14:43] lpbuildd/check_implicit_pointer_functions.py 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] xnox: is there anyone in particular i could bug about this package being in the unapproved queue? [14:47] without losing some fingers [14:48] stokachu: I'll take a look. [14:49] stokachu: looking at https://launchpad.net/~ubuntu-sru/+members the usual suspects are steve, colin, adam, clint... =) for that sort of package. [14:50] stokachu: accepted [14:51] cjwatson: awesome thanks man [15:01] safe to assume we have no sparcs in build farm? [15:01] We have two sparc builders. [15:01] artigas and sejong. https://launchpad.net/builders [15:02] cjwatson: so openbios-sparc, which must be built on sparc, *could* be pulled into ubuntu? [15:02] No, that's a different problem [15:02] i'm looking into how closely we can mirror debian's qemu packaging layout for r [15:02] We have no way to do architecture: all builds on anything other than i386 [15:03] ok so i should drop sparc [15:04] cjwatson: thanks [15:05] bug 183495 [15:05] Launchpad bug 183495 in openbios-sparc (Ubuntu Hardy) "[FTBFS] openbios-sparc (1.0~alpha2+20070816-1) fails to build in hardy" [High,Confirmed] https://launchpad.net/bugs/183495 [15:05] Although I'm sure there's a bug on Launchpad somewhere, where it more properly belongs [15:06] cjwatson: but as it's been around since 2008, low prio i assume [15:08] hallyn: Bug 217427 [15:08] Launchpad bug 217427 in Launchpad itself "Please support arbitrary arch/buildd affinity for arch:all builds" [High,Triaged] https://launchpad.net/bugs/217427 [15:09] cjwatson: but there is no way to currently express that in .dsc e.g. build-arch field [15:10] cjwatson: i'm a little surprised a powerpc - on - x86 crosscompiler isn't packaged... [15:10] cjwatson: hallyn: (ugly-hack) arch: ppc, Multi-Arch: [15:10] cjwatson: hallyn: (ugly-hack) Arch: ppc, Multi-Arch: allowed [15:10] xnox: See that bug report. [15:10] xnox: I'd rather you didn't work around it that way. [15:10] If nothing else, that's no use for cases that involve build-deps. [15:11] hallyn: *shrug* [15:11] cjwatson: i'm wondering whether, if it did, that sufficed [15:12] hallyn: Don't know. Possibly [15:12] hallyn: well all rdeps would need to be changed to: package [sparc] [15:12] hallyn: well all rdeps would need to be changed to: package [ppc] [15:12] xnox: No, they wouldn't. [15:13] Cross-compile binary, put it in an architecture: all binary just as it is now. [15:13] Also, you can't specify a particular architecture in Depends. [15:18] cjwatson: any sense having a uds session on this? [15:19] 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] ok :) [15:20] there used to be a simple howto for locally creating cross-compiler, but might be a bear to package [15:21] hrw might know [15:21] hi [15:22] hrw: wondering about feasability of creating a set of cross-compiler packages [15:22] (specifically gcc for powerpc and sparc) [15:23] hallyn: doable with arm cross compiler packages as base [15:24] hallyn: but openbios-sparc on debian is arch:all - can't be same in ubuntu? [15:25] I see - 'This package must be built on a SPARC machine' [15:26] hrw: right (same with openbios-ppc, and presumably openhackware) [15:27] so gcc-arm-linux-gnueabi as an example? [15:27] hallyn: going for cross compilation with them means maintaining 3 packages per arch (6 for biarchs). [15:27] hallyn: binutils-armel-cross, armel-cross-toolchain-base, gcc-4.7-armel-cross [15:28] hallyn: first gives binutils, second glibc and libgcc, last one gives compiler [15:28] Might be less effort to fix the LP bug ... [15:29] cjwatson: and then we will pray that no one wants openbios-hppa :D [15:29] 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] So a cross-compiler would be needed for that either way [15:30] or package removal but that will hurt all users of qemu-sparc [15:33] The package was actually removed ages ago [15:33] But it'd be nice to be able to reintroduce it [15:34] question is: who wants to maintain those cross compilers? [15:35] hallyn's the one pushing for this currently :) [15:37] 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] @pilot out === udevbot_ changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [15:37] hallyn: if you are lucky then small amount of work needed. [15:40] hrw: thanks, will give it a shot [15:42] hallyn: wookey did aarch64 cross compiler recently from those packages so it is doable ;) [15:42] hallyn: in case of problems - ask me [15:43] will do thx [15:46] jbicha: like cjwatson said - it's just a logfile scan that looks for implicits that were conversion truncation, or so === adam_g_ is now known as adam_g === Ursinha-afk is now known as Ursinha === deryck is now known as deryck[lunch] === glebihan_ is now known as glebihan === deryck[lunch] is now known as deryck === rsalveti_ is now known as rsalveti === Ursinha_ is now known as Ursinha === cpg|away is now known as cpg [19:53] jtaylor: abiword/armel failed to build [19:53] Oo [19:53] can't be the abiword change === henrix is now known as henrix_ [19:54] jtaylor: No, but now we're in a bit of a bind for release [19:54] We *were* at the point where there were zero out-of-date binaries in the archive [19:54] abiword has broken that [19:55] The last build was only 2012-10-08 ... === cpg is now known as cpg|away [19:55] yes not long ago [19:55] Looks like somebody has retried it already? [19:55] I didn't expect toolchain breaking [19:55] He says as the build log goes away [19:55] jtaylor: I should have noticed it was in images and required your sync to go through -proposed [19:58] but isn't this a larger issue jut discovered by abiword [19:59] Maybe, but such fine principles are for earlier in the cycle [19:59] Now we need to not break stuff or expose breakage [20:00] cjwatson: if it's just armel, it shouldn't impact any images at least [20:00] No, but if fixing it requires a source upload, that'll hit Xubuntu and Lubuntu [20:00] I am *not* going to leave out-of-dates just after we spent weeks getting them clean [20:01] I mean *literally* just after, as in the next publisher cycle [20:04] true === Ursinha is now known as Ursinha-afk === cpg|away is now known as cpg [20:36] probably not the place to ask this question, but: [20:37] why would apt-get remove $package (unattended-upgrades in this case) want to install over 100 new packages? [20:38] 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] ah right [20:39] i think i don't want to remove it in fact [20:39] just disable it [21:23] cjwatson: Is you comment on Bug #674627 at all indicative that it's still an issue or you just doing cleanup? [21:23] Launchpad bug 674627 in sip4-qt3 (Ubuntu) "python: /build/buildd/sip4-qt3-4.11.2/siplib/siplib.c:10613: sipEnumType_alloc: Assert-makro "(((currentType)->td_flags & 0x0007) == 0x0003)" ei pidä paikkaansa." [Undecided,Confirmed] https://launchpad.net/bugs/674627 [21:25] ScottK: Just cleanup. [21:25] OK. Thanks. [21:25] ScottK: I was hunting for bugs filed on the upstream ubiquity project, which we don't use. [21:26] 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. === salem_ is now known as _salem [21:55] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cyphermox [22:01] barry: so did you also hit bug #1054712? [22:01] Launchpad bug 1054712 in usb-creator (Ubuntu) "usb-creator-gtk crashed with SIGSEGV" [Medium,Triaged] https://launchpad.net/bugs/1054712 [22:07] 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] 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:08] Launchpad bug 915626 in usb-creator (Ubuntu Quantal) "usb-creator-gtk crashed with SIGSEGV" [High,Confirmed] https://launchpad.net/bugs/915626 [22:08] Launchpad bug 1054712 in usb-creator (Ubuntu) "duplicate for #1064072 usb-creator-gtk crashed with SIGSEGV" [Medium,Triaged] https://launchpad.net/bugs/1054712 [22:08] Launchpad bug 1054712 in usb-creator (Ubuntu) "usb-creator-gtk crashed with SIGSEGV" [Medium,Triaged] https://launchpad.net/bugs/1054712 === charlieS` is now known as charlieS [22:09] 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] stgraber: it sure smells like a reference counting bug [22:11] 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] jtaylor: Yeah, you're off the hook - a retry succeeded [22:17] (phew) [22:17] uff [22:17] strange [22:18] 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] sorry for the screwup [22:19] Ah well, no real harm done in the end [22:20] at least i saw another potential issue scroll by in the log [22:20] Wsequence-point [22:20] and reported to debian [22:50] barry, stgraber: so for me the problem is consistently reproducible when trying to write to a USB stick without persistence [22:51] haven't tried with yet [22:51] slangasek: yep, when i was looking at it, it crashed every time for me. debugging it will be fun though [22:52] yeah, segfaulting python is my favoite [22:56] slangasek: especially memory ownership bugs :) [22:56] slangasek: is that the usb-creator bug? [22:57] bdmurray: yep [22:57] well, apparently a different one than the one we currently have targeted [23:19]