=== freeflying_away is now known as freeflying
=== _salem is now known as salem_
[02:30] <Noskcaj> Is there an FTBFS list for arm64 yet?
=== salem_ is now known as _salem
[04:51] <slangasek> Noskcaj: no, and you shouldn't expect one any time soon
[04:52] <Noskcaj> ok
[04:52] <slangasek> because a /failed/ to build from source list implies sufficient resources to /try/ to build from source :)
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
[07:07] <DzAirmaX> hey ;à$
[07:07] <DzAirmaX> how are you guyz today ?
[07:34] <DzAirmaX> Can someone give me some infromation about the MOTD update system ? I noticed it was delayed on the 13.10 distrib ....
[07:47] <DzAirmaX> I noticed the displayed info was delayed from 1 login, so for example I will have the system info from the last login and not the actual one
[07:51] <rbasak> DzAirmaX: look into pam_motd
[07:56] <DzAirmaX> rbasak : how am I supposed to look there sir ?
[07:57] <rbasak> DzAirmaX: I don't know. I'm just giving you a keyword to help with your googling.
[07:57] <rbasak> I hope that helps.
=== sil2100_ is now known as sil2100
=== freeflying is now known as freeflying_away
=== freeflying_away is now known as freeflying
[08:57] <xnox> zyga: ha, nice. Did you see deb-squid-proxy-client? http://blog.surgut.co.uk/2013/03/avahi-apt-cacher-ng-sbuild.html essentially there is a way to advertise apt-proxies and automatically use them.
[08:58] <xnox> zyga: i use that on my laptop, chroots, sbuild, etc. Thus when I am at home it uses my main proxy, when on the go, it uses one if available.
=== iahmad is now known as iahmad|afk
[09:00] <zyga> xnox: nope, looking
[09:01] <xnox> zyga: it's been improved since apt-cacher-ng now ships the avahi config.
[09:01] <xnox> zyga: so that step is not needed.
[09:01] <zyga> xnox: ait is avahi based
[09:01] <zyga> xnox: it is avahi based
[09:02] <xnox> zyga: yes, avahi is required on the host. So I bypass that for sbuild, by checking & setting apt-proxy url at chroot setup.
[09:02] <xnox> zyga: avahi is pre-installed on desktops.
[09:02] <xnox> (chroot setup, meaning each time sbuild/schroot is invoked via it's hooks scripts)
[09:03] <zyga> xnox: while I really like the concept of avahi it is really not reliable enough IMHO, it's often filtered out in corporate networks and even at home, it easily fails to work on wifi due to silly packet loss
[09:03] <xnox> zyga: true, and due to e.g. routers by the UK ISPs often not allowing wifi clients to access LAN/ethernet clients and etc.
[09:04] <zyga> xnox: plus, my solution is really more robust, it updates each time the network changes
[09:05] <xnox> zyga: yeah, it is. In deb-squid-proxy-client, a python script is executed each time apt-get is invoked which is less than ideal performance wise.
[09:05] <zyga> xnox: one improvement I could see is for apt-proxy-setup to discover generic mDNS advertised proxies and pick one as an option
[09:05] <xnox> hm.... interesting.
[09:05] <zyga> xnox: and I'd like to have a way to maybe fallback to fully offline local apt-cacher-ng when offline
[09:05] <xnox> i've never used mDNS advertised proxies (well, to my knoweledge at least)
[09:05] <zyga> xnox: it's just 0.1 :)
[09:05] <zyga> well mDNS is avahi
[09:06] <xnox> zyga: fallback to local apt-cacher-ng when offline would be cool.
[09:06] <zyga> xnox: I'm doing this because we're sprinting next week
[09:06] <xnox> by pick the /actual/ fast desktop proxy when on "home" network. Yeah, that needs config files.
[09:06] <zyga> xnox: and I really want to have my stuff and not have to fiddle with it
[09:06] <zyga> xnox: well, if that proxy is advertised it would also be picked up
[09:06] <zyga> xnox: I meant mDNS apt-cacher-ng proxy
[09:07] <zyga> xnox: I think I'll do the offline proxy first to have something to do on the plane
[09:07] <zyga> (the proxy would only start when needed too, which is great about upstart)
[09:07] <zyga> xnox: but I'll look at setting up avahi discovery for apt-cacher-ng in a generic network
[09:07] <zyga> xnox: I was thinking about that earlier and I worried that there might be security issues, it it okay to use any random mirror?
[09:08] <zyga> xnox: I think it is but I wasn't 100% Sure
=== iahmad|afk is now known as iahmad
[09:26] <cjwatson> apachelogger: +  * Change all maintainer scripts to use sh -e rather than explicit set -e.
[09:27] <apachelogger> cjwatson: a voice in my head told me to do that :O
[09:27] <cjwatson> apachelogger: that's so backwards :)  explicit set -e is better because it means that it isn't a gotcha for people debugging your script with "sh -x <blah>" - I change everything I maintain to use explicit set -e whenever I notice sh -e
[09:27] <cjwatson> (not a reject or anything but I think this change is misguided)
[09:27] <infinity> That's not quite as backward as the part where we later ignore all errors anyway.
[09:28] <apachelogger> cjwatson: true, but sh -e is so elegant ^^
[09:28] <cjwatson> apachelogger: but wrong :)
[09:28] <apachelogger> pff :P
[09:28] <cjwatson> (well, less helpful)
[09:28] <apachelogger> I'll commit a revision to that if it makes you happy
[09:28] <infinity> Is kubuntu-default-settings intentionally being installed in ways where dependencies aren't set up yet, or is the whole thing just really misguidedly weird?
[09:29] <cjwatson> apachelogger: should the referenced bugs be reassigned to kubuntu-settings?
[09:29] <apachelogger> infinity: I have no idea, latter sounds reasonable
[09:29] <cjwatson> (they're on kubuntu-default-settings right now, so won't be closed by this upload)
[09:29] <apachelogger> cjwatson: yes
[09:30] <infinity> apachelogger: As a general rule, postinst should be able to expect that their deps aren't broken.  I find this whole "assume the world might be broken and just echo harmlessly to the terminal" thing a bit odd.
[09:30] <infinity> apachelogger: If there are known error conditions here, could we fix the buggy packages?
[09:30] <infinity> (And if there aren't known bugs here but rather just paranoia, you've effectively undone the whole point of "set -e")
[09:32] <cjwatson> I tend to agree, but it's also fairly harmless as-is.  Minded to accept unless infinity objects
[09:33] <infinity> cjwatson: Well, it looks like this was already done (or started) in the previous upload, so meh.
[09:33] <apachelogger> infinity: they aren't known, that is the problem....
[09:33] <infinity> cjwatson: But I'd still like to have the talk/argument.
[09:33] <cjwatson> at least one is
[09:33] <cjwatson> bug 1005555 is a configuration error probably caused by copy/pasting from some stupid website
[09:33] <ubottu> bug 1005555 in kubuntu-settings (Ubuntu) "package plymouth-theme-kubuntu-logo 1:12.04ubuntu4 failed to install/upgrade: el subproceso instalado el script post-installation devolvió el código de salida de error 2" [Undecided,New] https://launchpad.net/bugs/1005555
[09:33] <cjwatson> it'll break something else later anyway
[09:34] <cjwatson> oh, and ditto bug 1044690
[09:34] <ubottu> bug 1044690 in kubuntu-settings (Ubuntu) "package plymouth-theme-kubuntu-logo 1:12.04ubuntu4 failed to install/upgrade: installed post-installation script alt işlemi çıkış durumunda hata döndürdü:: 127" [Undecided,New] https://launchpad.net/bugs/1044690
[09:34] <cjwatson> they are not your problems
[09:34] <apachelogger> right, neither of the called things in postinst are actually fatal
[09:34] <cjwatson> and it really doesn't particularly help to ignore them - the whole upgrade will probably still fail when people have scribbled nonsense over config files
[09:34] <infinity> Uhm, yeah.  If things like update-grub or update-initramfs fail, people have a broken system, full stop.
[09:35] <cjwatson> but I agree that it doesn't make much difference either way in this case
[09:35] <infinity> The warm fuzzies produced from kubuntu-default-settings installing won't help.
[09:35] <cjwatson> Indeed.  They're logically triggers, though.
=== freeflying is now known as freeflying_away
[09:36] <cjwatson> (accepted)
[09:36] <infinity> Well, triggering those sort of solves the problem (or, rather, moves it to the package where it runs), which is fine.
[09:36] <infinity> But it seems to be an overreaction to "|| true" the world.
[09:37] <cjwatson> Yeah.
[09:37] <infinity> Like, if those update-alternatives calls explode, that legitimately means that kubuntu-whatever won't have installed correctly.  Which is exactly when a postinst is meant to fail.
[09:37]  * infinity shrugs.
[09:38] <cjwatson> Right.  I would say you should
[09:38] <infinity> I need sleep more than I need to lecture on the Internets, though. :)
[09:38] <cjwatson> er
[09:38] <cjwatson> apachelogger: Right.  I would say you can reasonably || true on the things that are logically triggering other packages, but that you should not || true the things that are actually entirely part of your own package (like the update-alternatives).
[09:41] <DzAirmaX> I noticed the motd update from motd.dynamic is not enforced as each login on the 13.10
[09:41] <DzAirmaX> someone has encoutered the same pb ?
[09:42] <apachelogger> cjwatson: ultimately I'd have it simply print a message but still exit in error as the entire point is to reduce bug triage work. alas, with release coming up I'll take ||true as immediate workaround.
[09:46] <cjwatson> apachelogger: For the triggers, I'd reluctantly agree, but for things that are actually functionality of your own package I do not agree that reducing bug triage work is sufficient reason to ignore errors
[09:47] <apachelogger> mhh, I guess you are right.
[09:51] <apachelogger> cjwatson: I put a todo down for 14.04 to look at it in detail
[09:53] <cjwatson> ta
[09:56] <cjwatson> right, better get back to verifying apt SRUs
[10:38] <seb128> xnox, hey, just as fyi, I assigned https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1200775 to you (apturl not working in saucy)
[10:38] <ubottu> Ubuntu bug 1200775 in update-manager (Ubuntu) "apturl-gtk crashed with AttributeError in __init__(): 'InstallBackendAptdaemon' object has no attribute 'connect'" [High,Confirmed]
[10:38] <seb128> xnox, it seems to be due to https://code.launchpad.net/~dylanmccall/update-manager/dialogs-refactor/+merge/164673 and you are the one that approved the merge it seems
[10:39] <xnox> seb128: ack. will look into this later today.
[10:39] <seb128> xnox, thanks
[10:39] <seb128> xnox, I commented on the mp as well, maybe Dylan is around/wanting to look at it
[11:24] <TJ-> Can we get some love for a critical ifupdown issue, bug #1235169
[11:24] <ubottu> bug 1235169 in ifupdown (Ubuntu) "Fails to read files in /etc/network/interfaces.d/" [Critical,New] https://launchpad.net/bugs/1235169
[11:29] <rbasak> How long as interfaces.d been around. OOI, has this ever worked?
=== MacSlow is now known as MacSlow|lunch
=== freeflying_away is now known as freeflying
[12:08] <TJ-> rbasak: Since April
=== freeflying is now known as freeflying_away
[12:15] <lool> cjwatson: getting a manpages upgrade error; would it be fs corruption?  dpkg: erreur de traitement de /var/cache/apt/archives/manpages_3.54-1ubuntu1_all.deb (--unpack) : impossible de créer un lien symbolique de secours pour « ./usr/share/man/man4/ptmx.4.gz »: Aucun fichier ou dossier de ce type
[12:15] <lool> cjwatson: file /usr/share/man/man4/ptmx.4.gz
[12:15] <lool> /usr/share/man/man4/ptmx.4.gz: unreadable symlink `/usr/share/man/man4/ptmx.4.gz' (No such file or directory)
[12:15] <lool> ls -l /usr/share/man/man4 is full of: lrwxrwxrwx 1 root root     0 août   1 15:36 zero.4.gz ->
[12:15] <lool> empty file, I guess it's not pointing at anything
[12:16] <lool> this is on btrfs
[12:17] <cjwatson> lool: looks like it
[12:17] <lool> ok
[12:18] <lool> I might have run out of battery a while ago
[12:18] <lool> but not particularly while upgrading
[12:18] <lool> so kind of sad
[12:23] <rbasak> TJ-: so is this a regression from Raring, or a new feature that doesn't work? What is the justification for it being Critical?
[12:24] <rbasak> TJ-: is there some essential thing that depends on this feature?
[12:24] <rbasak> TJ-: or is it the default now or something?
[12:27] <TJ-> It's a new feature since April, the default interfaces created by the postinst script writes the directive, but installing interface files in that directory fails to work
[12:27] <TJ-> I hit it earlier whilst configuring a 13.10 server with multiple interfaces
[12:28] <TJ-> So if you follow the guidance, it'd fail to bring up any network.
[12:28] <TJ-> I've just implemented a patch to fix it, I'm testing it now
[12:34] <smartboyhw> cjwatson, hmm, ardour3 sync build-failure on armhf and powerpc because of a header which only exists in amd64 and i386....
[12:34] <smartboyhw> Any ideas as to what I can do?
[12:38] <smartboyhw> (Note that the package failed to build in Debian's armhf and powerpc)
[12:38] <smartboyhw> s/Debian's/Debian archive archs/
[12:39] <cjwatson> Well, it's not fatal for using ardour3 in Ubuntu Studio
[12:40] <Laney> Find out why it's passing -DBUILD_SSE_OPTIMIZATIONS
[12:40] <cjwatson> I think it might actually be FPU_OPTIMIZATIONS
[12:40] <cjwatson> FPU_OPTIMIZATION, rather
[12:40] <cjwatson>         if bld.env['FPU_OPTIMIZATION']:
[12:40] <cjwatson>             testcommon.source += [ 'sse_functions_xmm.cc' ]
[12:40] <cjwatson> ifneq (,$(findstring amd64,$(DEB_BUILD_ARCH)))
[12:40] <cjwatson> DEB_MAKE_NOOPT_FLAGS := DEBUG=no FPU_OPTIMIZATION=yes
[12:40] <cjwatson> endif
[12:41]  * Laney got that from the debian bug
[12:41] <cjwatson> That should maybe be ifeq (,$(findstring i386,$(DEB_BUILD_ARCH))) instead since that code ain't gonna work on non-x86
[12:42] <cjwatson> Er, wait, I have my negatives backwards
[12:42] <cjwatson> Is DEB_MAKE_NOOPT_FLAGS actually being passed to anything?
[12:43] <cjwatson> It doesn't seem to be a recognised CDBS variable
[12:44] <cjwatson> Also check whether FPU_OPTIMIZATION=no works properly or if it needs to be unset
[12:44] <cjwatson> Anyway those are the general paths you probably want to look at
[12:46] <cjwatson> Looks like the build target is set wrongly
[12:46] <smartboyhw> cjwatson, :(
[12:46] <smartboyhw> Anyhow, at least it works for x86 and amd64
[12:46] <smartboyhw> (Good enough for us)
[12:46] <cjwatson> I'm afraid I've run out of interest for debugging waf nonsense, you'll have to sort the rest out yourself :)
[12:47] <smartboyhw> cjwatson, sure
=== MacSlow|lunch is now known as MacSlow
[12:47] <cjwatson> never been a fan of choose-your-own-adventure build systems :)
[12:47] <smartboyhw> cjwatson, agreed, I love dh:P
[12:49] <smartboyhw> cjwatson, so ardour3 won't auto-migrate to -release right?
[12:53] <cjwatson> smartboyhw: Nothing's stopping it that I know of
[12:53] <cjwatson> smartboyhw: Architecture support only has to not regress; if you don't build on an arch you've never built on before, that's fine
[12:54] <cjwatson> smartboyhw: https://wiki.ubuntu.com/ProposedMigration
=== _salem is now known as salem_
[12:58] <smartboyhw> cjwatson, nice wiki page, let me bookmark
[13:34] <seb128> cjwatson, you mentioned gnome-control-center-unity being newer in raring-updates than saucy ... do we have a tools to list such problems? it seems like that if that happened to that one we might as well have other sources in the same case
[13:34] <cjwatson> seb128: I've never wired it up to a proper report or anything but it's easy to generate with lp:~cjwatson/+junk/suite-diff
=== kentb is now known as kentb-afk
[13:42] <cjwatson> xnox: libboost1.53-dev should set its primary alternative to libstdc++-4.8-dev (which exists) rather than libstdc++6-4.8-dev (which doesn't).  Was going to just fix in Ubuntu but I noticed the changelog appears to include a matching change from you in Debian experimental (though apparently not actually uploaded there).  Would you mind fixing in both?
[13:42] <cjwatson> xnox: This is part of why libc++ is showing up in http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt
[13:51] <seb128> cjwatson, thanks for the script, there is a few listed out of g-c-c-unity
[13:51] <seb128> fwlogwatch: 1.2-2ubuntu0.13.04.1 > 1.2-2
[13:51] <seb128> kdeadmin: 4:4.10.5+repack-0ubuntu0.1 > 4:4.10.4-0ubuntu1
[13:51] <seb128> kdenetwork: 4:4.10.5+dfsg1-0ubuntu0.1 > 4:4.10.4-0ubuntu1
[13:51] <seb128> ubufox: 2.7-0ubuntu0.13.04.1 > 2.6-0ubuntu1
[13:51] <seb128> chrisccoulson, ^ ubufox is newed in raring-updates than saucy
[13:51] <seb128> Riddell, ScottK: ^ you might be interested by the KDE ones (newer in raring-updates than saucy, can create upgrade issues)
[13:54] <chrisccoulson> seb128, ah, i'll fix that
[13:54] <seb128> chrisccoulson, thanks ;-)
[13:55] <cjwatson> fwlogwatch looks like it should just be copied forward - security update
[13:55] <cjwatson> I'll do that
[13:56] <cjwatson> sarnold: ^- FYI.  I don't think you should rely on new versions coming from Debian in this kind of situation - better to copy the security update forward from raring if versions were previously identical between raring and saucy (no need for a separate upload)
[13:57]  * cjwatson runs "copy-package -s raring-updates --to-suite saucy-proposed -b fwlogwatch"
[13:57] <seb128> cjwatson, thanks
[14:11] <xnox> cjwatson: =/ sorry about that. yeah, let me fix that in debian & ubuntu then.
[14:13] <cjwatson> Thanks!
=== tkamppeter_ is now known as tkamppeter
[14:32] <psivaa> slangasek: re: bug #1234649 i see the tool is now fixed in saucy, but our test servers are still using precise with sbsigntool:0.6-0ubuntu1~12.04.1
[14:32] <ubottu> bug 1234649 in sbsigntool (Ubuntu) "UEFI shim verification against microsoft-uefica-public.pem fails with 20131003 saucy images" [Medium,Fix released] https://launchpad.net/bugs/1234649
[14:32] <psivaa> slangasek: any plans to backport it?
=== freeflying_away is now known as freeflying
[14:45] <xnox> psivaa: slangasek: yeap, i was planning to get it SRUed to precise, quantal & raring.
[14:46] <psivaa> xnox: ack, thank you
[14:51] <Riddell> seb128: those are newer in raring-updates than saucy because they have been removed in saucy so I don't think it's a problem
[14:52] <cjwatson> Riddell: No, they're in saucy
[14:52] <cjwatson> Riddell: They wouldn't have been reported if they'd been removed
[14:53] <cjwatson> Riddell: It looks like the binaries have (at least partially - didn't check them all) been supplanted by other sources, but the old source packages were never removed
=== DanChapman is now known as DanChapman|afk
[15:12] <marcoceppi> For packagining, I have a source tarbal and I want to update the the package contents with that tarbal and bump the package version. is there a command to do the unpacking of the tarbal in to the already fetched apt-source package?
[15:12] <Riddell> cjwatson: ah gotcha
[15:13] <Riddell> marcoceppi: #ubuntu-packaging I think if nobody answers here
[15:15] <mitya57> marcoceppi: in bzr trees you can do bzr merge-upstream, otherwise you can unpack the tarball and copy debian/ to new location
[15:16] <Laney> uupdate
[15:17] <smartboyhw> uupdate is the greatest thing;P (followed by bzr merge-upstream)
[15:17] <marcoceppi> the upstream is in a ppa, so I'm not sure if that will work
[15:18] <smartboyhw> Laney, if I update a flavour meta package (ubuntustudio-meta here) that includes a new package, that does require a FFe right? (Or do we need UIFe as well?)
[15:21] <smartboyhw> (A new package included in seeds, to clarify)
[15:29] <slangasek> xnox, psivaa: I don't think an SRU is justified for this issue; I think the test server should work around it by either pulling the saucy version, or using faketime.
[15:30] <slangasek> this is not a user-affecting issue, the only place we're using sbverify is for testing - and in any case, the you can't push an SRU right now because there's currently one in the queue, so chances are there'll be a fixed shim binary from MS by the time the SRU completes
[15:30] <xnox> ok.
[15:32] <xnox> slangasek: sbverify is part of our validation and security regression testing. and it's not like you can update the shim on the released 12.04.2, and .3
[15:33] <slangasek> xnox: yes, but why would we be retesting those released images?
[15:33] <xnox> slangasek: true. i see.
[15:33] <slangasek> anyway, faketime :)
[15:34] <xnox> psivaa: do you want me to write faketime patch for utah static validation such that it starts passing?
[15:35] <xnox> psivaa: or simply upload new sbverify to the same place as utah is.... which is also not in the ubuntu archive =) but in a ppa.
[15:35] <psivaa> xnox: i could try and pull the saucy version first to see if that works
[15:43] <TJ-> What's the procedure to revert one or more debian/patches/ prior to a "bzr bd -- -S" ?  I've tried simply commenting them out in "debian/patches/series" but of course quilt still has them applied to the source.
[15:48] <xnox> TJ-: quilt pop -a; edit debian/patches/series; quilt push -a; bzr add .pc; bzr bd -S
[15:48] <cjwatson> quilt pop -a, comment them out in debian/patches/series, and then "quilt push" and "quilt refresh" if necessary
[15:48] <cjwatson> snap, ish :)
[15:48] <xnox> TJ-: note, -S is a valid bzr bd option, to do source build.
[15:49] <TJ-> xnox: Thanks! I was missing the "bzr add .pc" step!
[15:58] <Laney> codesearch reindexing takes ages
[15:58]  * Laney wahs
[16:26] <TJ-> xnox: I must be missing something, "bzr bd -S" errors with "[Errno 2] No such file" for a ".pc/$PATCH_NAME/target.file". I can't much about reverting quilt 3.0 patches either, aside from Barry Warsaw's struggles with the same thing in 2010/2011 in the mailing list. All suggestions gratefully accepted
[16:26] <xnox> TJ-: commit, since you removed files.
[16:26] <TJ-> s/can't much/ can't find much/
[16:26] <xnox> TJ-: then build will succeed.
[16:27] <TJ-> xnox: OK, presumably also the updated changelog?
[16:27] <xnox> yeah, commit everything
[16:29] <TJ-> xnox: thanks, that sorted it. Doing this on a minimal server install without my dev tools and scripts so its painful
[16:53] <sarnold> cjwatson: thanks re: fwlogwatch advice :)
=== DanChapman|afk is now known as DanChapman
=== jdrab_ is now known as jdrab
=== psivaa is now known as psivaa-afk
[18:07] <smoser> slangasek, you are usually useful with my queries for things like this: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1235231
[18:07] <ubottu> Ubuntu bug 1235231 in cloud-init (Ubuntu) "ci-info: eth0 not reliable in latest saucy images" [Medium,Confirmed]
[18:09] <slangasek> smoser: can you distill the bug for me, please?  What is the race you're seeing?
=== kentb-afk is now known as kentb
[18:20] <smoser> slangasek, basically data written to /dev/console goes to /dev/null
[18:20] <smoser> or some other unrecoverable location
[18:20] <smoser> and we'd like it not to.
[18:21] <smoser> see the upstart job, it basically does 'for i in $(sed 1 1000); do echo i=$i && sleep .2 ; done'
[18:21] <smoser> and expects that I that data should get to /dev/console (well, the other side). but it does not.
[18:22] <slangasek> smoser: ok, so it's a question of the /output/ of this line
[18:22] <smoser> right.
[18:23] <smoser> it just gets swallowed up. i suspect by plymouth.
[18:23] <slangasek> ok; I'm not aware of any recent changes that could account for this
[18:23] <smoser> and to be fair, onthe raring test i just ran it swallowed up a buncch of it too, but just less, and the cloud-init info got there.
[18:24] <smoser> well https://launchpadlibrarian.net/152522624/manifest-changes-alpha3-to-beta1.diff
[18:24] <smoser> is the image contents diff
[18:24] <smoser> between "working enough" and "not working".
[18:26] <slangasek> smoser: yeah, and there have been no changes to packages that *should* impact console behavior this cycle, unless perhaps there's something that changed in the kernel itself
[18:27] <sarnold> do the retracers need a kick?
[18:27] <smoser> also on other boots we still do get the data. its clearly race conditiion related.
[18:27] <smoser> heres a canonistack instance log http://paste.ubuntu.com/6193370/
[18:28] <smoser> well, see line 741
[18:28] <slangasek> smoser: right, so I suspect that nothing has fundamentally changed, it's just that things have moved around to where the race is more likely to be hit now
[18:28] <smoser> err.. maybe line 1163 boot.
[18:28] <smoser> right.
[18:30] <slangasek> smoser: so the boot at line 1163 looks to be outputting fairly reliably from your test, but misses the first 13 iterations?
[18:30] <smoser> well, it'd be really nice if content written to /dev/console got to the device hooked up on the other side of /dev/console. (just like that is true for /dev/sda).
[18:30] <smoser> slangasek, yeah. once you start getting output, you sem to get it.
[18:31] <smoser> it just gets lost until some point.
[18:31] <slangasek> what's the value of /proc/cmdline here?
[18:31] <smoser> [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.11.0-11-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0
[18:31] <slangasek> ok
[18:31] <slangasek> so you know that kernel writes to /dev/console are not reliable?
[18:31] <slangasek> this is a kernel issue
[18:32] <slangasek> is it possible the write itself is failing?
[18:32] <smoser> i dont think its kernel.
[18:32] <smoser> i think its plymouth.
[18:32] <smoser> i can make sure the writes are returning success if you'd like.
[18:32] <slangasek> I think you should check that
[18:32] <smoser> and that is a good idea
[18:33] <slangasek> there's no dmesg output past the mount of the root filesystem; has that been diverted somewhere else, or is there just no more to see?
[18:34] <slangasek> it certainly could be plymouth, it's just hard to diagnose this without timestamps
[18:35] <slangasek> ok, I've convinced myself that plymouth is the most likely culprit
[18:40] <smoser> slangasek http://paste.ubuntu.com/6193435/
[18:40] <smoser> that is after doing:
[18:40] <smoser>  for x in /etc/init/plymouth*.conf; do sudo mv $x $x.dist; done
[18:40] <slangasek> ok
[18:49] <slangasek> smoser: so is there ever a case where cloud-init is installed where you would have an interactive console and care about actually interacting with plymouth?
[18:50] <slangasek> it may be that the right thing to do here is just to create /etc/init/plymouth*.override on all the cloud images and forcibly disable plymouth on the grounds that it serves no purpose
[18:50] <slangasek> (and cloud-init may be the package in which to do that)
=== slomo__ is now known as slomo
[18:50] <utlemming> slangasek, smoser: we do have the run a cloud-image locally under KVM, and then there are the Vagrant images that cloud image diratives.
[18:51] <utlemming> slangasek: mostly developer use cases
[18:52] <slangasek> utlemming: right, but such use cases do exist
[18:52] <utlemming> slangasek: yes, those use cases exist
[18:53] <slangasek> I'm trying to figure out how to solve this without causing regressions for other cases; we really need a hard specification on where we expect plymouth to spit what output (which we are currently lacking) and refactor things to work correctly across all the install types... that's not gonna happen for 13.10
[18:53] <slangasek> so that leaves "hack out plymouth" as the best option I can think of
[18:54] <slangasek> utlemming: oh, but if these are still cloud images, you still would never be interacting with plymouth
[18:54] <slangasek> because you might have a console, but it's only for staging, no?
[18:54] <utlemming> right...we just need a console
[18:55] <slangasek> so you e.g. wouldn't actually care about typing in the passphrase for unlocking a disk, or telling mountall to skip a missing disk :)
[18:55] <utlemming> yeah....exactly
[18:55] <utlemming> so in thinking about it, drop it
[18:55] <slangasek> utlemming: and cloud-init isn't something that users might install on their host system for testing?
[18:55] <utlemming> only if they want the most useless desktop ever
[18:55] <lifeless> I think we'd very much want to dissuade them from installing it
[18:55] <lifeless> but
[18:56] <lifeless> openstack will get two-way consoles at some point
[18:56] <utlemming> oh...
[18:56] <lifeless> I don't think it's true to say it's going to be just output indefinitely
[18:56] <utlemming> actually, no we can't drop it
[18:56] <slangasek> utlemming: cloud-init itself wouldn't break the desktop, would it?  if there are no options set it ought to be a no-op?
[18:56] <utlemming> cloud-init is an aggressive package...it wants a datasource and would delay the boot
[18:57] <slangasek> heh
[18:57] <utlemming> add ~2 minutes or more to the boot
[18:57] <slangasek> well, ok then
[18:57] <slangasek> so we can fairly safely say that having cloud-init override plymouth is probably not going to make things worse
[18:58] <utlemming> probably not
[19:08] <smoser> when cloud-init is instlaled, you're quite likely to end up with a 2 minute boot. with annoying timeouts.
[19:08] <smoser> lifeless, disabling plymouth doesn't mean non-interactive console
[19:08] <smoser> it means non-interactive console during boot
[19:09] <smoser> its still possible to put a getty on /dev/ttyS0
[19:09] <smoser> and openstack does have 2 way consoles in that respect now. (via vnc).
[19:12] <lifeless> smoser: cool
[19:12] <lifeless> smoser: so my point was that entering a password for luks in the cloud is viable in that setup
[19:13] <smoser> only moderately.
[19:13] <smoser> that is a use case, you're right.
[19:13] <smoser> but realisitcally... yoiu're uber paranoid at that point
[19:13] <smoser> and without a lot of benefit
[19:13] <lifeless> yeah
[19:13] <lifeless> agreed
[19:13] <smoser> as someone as direct access to your memory
[19:17] <smoser> hey... i'll beg again.
[19:17] <smoser> anyone able to take a review of https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1233486
[19:17] <ubottu> Ubuntu bug 1233486 in software-properties (Ubuntu) "add support for 'cloud-archive:' like 'ppa:' but for cloud archive" [Undecided,New]
[19:17] <smoser> mvo basically said "ok", but i'd like to upload to saucy, and would appreciate someone else's eyes on that.
[19:50] <goodwill> quick question, I am looking for the revision which the PPA build bots is building in the build log and I am failing to find it ... where is such information kept
[20:29] <cjwatson> goodwill: you mean of a recipe or something?  might be helpful to link to the build in question
[21:31] <goodwill> cjwatson: https://launchpadlibrarian.net/139863041/buildlog_ubuntu-precise-amd64.nginx_1.4.1-1ppa1~precise_UPLOADING.txt.gz
[21:48] <infinity> goodwill: A link to the build is more useful than a link to the log.
[21:57] <cjwatson> goodwill: I don't quite understand the question, then.  The builder is given a source package, whose version is right there in the URL.  If there's a version control system behind it, the builder doesn't know about it.
[21:58] <goodwill> hmmm
[21:58] <cjwatson> In the case of recipes, then there's a bzr revision, indeed, but that package wasn't built using a recipe.
[21:59] <goodwill> https://launchpad.net/~nginx/+archive/stable/+build/4577421
[21:59] <goodwill> I see
[21:59] <goodwill> yeah it was not clear what revision was pulled
[22:00] <cjwatson> So for instance in the build log linked from https://launchpad.net/~numix/+archive/ppa/+recipebuild/553593 you can pick apart the generated source package version to see that that was bzr revision 82.
[22:00] <infinity> goodwill: Well, what revision of *what*?  It wasn't autobuilt from a VCS, it was manually uploaded by a person.
[22:01] <cjwatson> Right, a source package like that nginx one may not even have a proper version control system behind it at all.
[22:01] <goodwill> I see
[22:01] <goodwill> this explains a few things
[22:01] <goodwill> I though that nginx is built from the sources in the launchpad code
[22:01] <cjwatson> But you can download the source package and look at it.
[22:02] <cjwatson> Poke around in https://launchpad.net/~nginx/+archive/stable
=== kentb is now known as kentb-out
=== salem_ is now known as _salem
=== freeflying is now known as freeflying_away
[22:16] <sarnold> I think the retracers are dead, this bug is five hours waiting for a retrace: https://bugs.launchpad.net/ubuntu/+source/unity-tweak-tool/+bug/1235353
[22:16] <ubottu> Error: ubuntu bug 1235353 not found
[23:03] <psusi> cjwatson, I notice that update-grub spews a *ton* of debug output into syslog in saucy... did you leave an extra debug flag on by accident?
[23:04] <cjwatson> No, that's probably os-prober which has done that forever.
[23:05] <psusi> really?  I know it has been fairly verbose, but now there are screen fulls of lines that say debug and end up echoing the entire contents of any and all other grub.cfg files found.. I didn't think it was quite that chatty before
[23:05] <cjwatson> That's os-prober and yes it has been.
[23:05] <psusi> oh... ok
[23:05] <cjwatson> It makes more sense within d-i.
[23:06] <psusi> yea... makes sense for the install logs... just a bit verbose going into syslog on a running system
[23:42] <ScottK> cjwatson: Your scripts for newer in raring-updates than saucy doesn't seem to take into account epochs or something because both kdeadmin and kdenetwork are false positives.
[23:42] <cjwatson> ScottK: No, they're really not.
[23:43] <cjwatson> ScottK: They're pointing out duplicate (old) binaries in saucy due to old sources that apparently haven't been removed.
[23:43] <ScottK> Right.
[23:43] <ScottK> I see it now.
[23:43] <ScottK> Thanks.
[23:43] <cjwatson> (What they don't take into account is the presence of binaries that are both older and newer in saucy ... but that's a fixable bug anyway :) )
[23:44] <cjwatson> I mean I consider that a thing to fix in the archive rather than in my script
[23:44] <ScottK> Yeah.  I'll remove the stale sources.
[23:44] <sarnold> older-and-newer? :)
[23:44] <cjwatson> Adam and I were just talking about going through the list of whines from the publisher's domination pass, which would fix this in bulk
[23:45] <cjwatson> sarnold: If there are multiple sources that claim to build the same binary, all versions will be kept around until the older sources stop claiming that
[23:46] <cjwatson> You could view this as a misfeature or you could view it as an early warning system: it's pointing out that if you were to do an upload of the one that builds older versions, it would (I think) fail to upload due to version conflicts
[23:47] <ScottK> Removed both the old ones.
[23:47] <cjwatson> Thanks
[23:47] <sarnold> cjwatson: aha, I think I get it, thanks :)
[23:48] <ScottK> The main problem with it was me misreading rmadison output.
[23:51] <ming> i use bzr branch got lp:chinese-calendar source,edit something and want to upload these source to my ppa.Every time the files can upload successfully ,but i alway got a reject email soon.Is there any people know what's the problem?
[23:52] <ming> the error is like this:Rejected:
[23:52] <ming> File <UPLOADED_FILE> already exists in <LOCATION>, but uploaded version has different contents.
[23:52] <ming> See more information about this error in https://help.launchpad.net/Packaging/UploadErrors.
[23:54] <ming> but i download the orig.tar.gz from the launchpad,how can it has difference with itself?
[23:55] <cjwatson> What exact URL did you download chinese-calendar_0.8.0.orig.tar.gz from?
[23:56] <ming> https://launchpad.net/chinese-calendar/+download
[23:56] <ming> this page
[23:56] <cjwatson> No, don't do that.  It must be from the Ubuntu archive
[23:56] <cjwatson> https://launchpad.net/ubuntu/+source/chinese-calendar/0.8.0-0ubuntu1
[23:57] <cjwatson> Also, you should not version your package 0.8.0-0ubuntu2 - that might conflict with a later version in the Ubuntu archive
[23:57] <cjwatson> You probably want to use something like 0.8.0-0ubuntu1ppa1 instead.  See https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage#versioning
[23:58] <ming> oh... thank you!!
[23:58] <ming> And can you tell me how do you get this page:https://launchpad.net/ubuntu/+source/chinese-calendar/0.8.0-0ubuntu1
[23:59] <cjwatson> I started at https://launchpad.net/ubuntu/+source/chinese-calendar which is a pattern I use all the time and have memorised
[23:59] <ming> search in any page?
[23:59] <cjwatson> You could also get to it by searching from https://launchpad.net/ubuntu