[00:24] adam_g: hey there, that troveclient upload is supposed to contain some file permission fixes, but I'm not seeing that in the diff, did you miss something? [00:25] adam_g: ah, nevermind, I re-read the changelog entry and it's just the modes of the files within debian/ which can't be represented in a diff, will accept the upload now [00:25] stgraber, ah, cool. thanks [00:26] libsystemsettings1 (from ubuntu-system-settings) is seeded in: [00:26] lubuntu: supported [00:26] ubuntu-system-settings (from ubuntu-system-settings) is seeded in: [00:26] lubuntu: supported [00:26] in case someone wonders why ubuntu-system-settings isn't getting auto-accepted [00:33] the reason for that seems to be indicator-bluetooth on non-gnome based flavours [00:47] stgraber: erm, that sounds entirely bogus [00:48] slangasek: it's broken ordering of indicator-bluetooth dependencies [00:48] accepting [00:48] stgraber: well, if it's seeded in "supported" anyway, that shouldn't trump the fact that it's a touch package and covered by the policy for touch [00:49] slangasek: yeah, as I said in -ci I'm not against getting it approved but I'd like to make sure someone will take care of the wrong dependency ordering of indicator-bluetooth [00:52] I don't see why it's picked up by lubuntu supported at all; http://people.canonical.com/~ubuntu-archive/germinate-output/lubuntu.saucy/supported seems to show an infinite loop [00:54] yeah, there seems to be a unity related loop in there, I didn't look much closer than that, however the depends on indicator-bluetooth is wrong and should be fixed (which may be enough to convince germinate to drop ubuntu-system-settings from that seed so we don't have to force it in the future) [00:55] I don't see that the dependency is wrong; it's arbitrary which one is listed first, anything that actually cares which one is pulled in should make sure it's installed before pulling in indicator-bluetooth [00:56] pulling g-c-c + gnome-bluetooth in on the phone is no less wrong than pulling u-s-s in on the desktop [00:58] well, I don't see why someone would suddenly need to add a dependency for some gnome packages when a release ago they didn't have to, so adding any alternative that you don't want everyone to use should be done by prepending them, not appending [00:58] bah, the other way around :) [00:59] that's fair, but lubuntu isn't *actually* depending on unity anyway [01:00] so by this point anyone who is, and who doesn't want the phone implementation, has already dealt with this - forcing the dependencies to be flipped now is just causing churn for the phone images [01:01] well, we have no idea how many Lubuntu users out there actually installed indicator-bluetooth post-install and that germinate output says that if any did, they'll end up with ubuntu-system-settings on their system, so I agree it's not a critical bug to fix, but I still want it fixed by release [01:02] (especially as I believe we got all the other indicators fixed in the same way recently when something similar affected Edubuntu a few days back) [01:03] We can estimate the number of lubuntu users installing indicator-bluetooth at zero. It doesn't integrate with lubuntu, and people don't install lubuntu if they're looking for unity. The bug is in germinate, not in u-s-s. [01:05] if the phone seed + indicator-bluetooth both get fixed before release, then that's fine, but it's a minor issue [01:07] slangasek: what needs fixing in the phone seed? ubuntu-system-settings has been listed in there since it's been uploaded to the archive. [01:07] stgraber: is it listed in there in an order that ensures germinate won't pick up g-c-c + gnome-bluetooth *and* u-s-s? [01:09] slangasek: both the indicators and ubuntu-system-settings are listed in the same seed, so I believe so. Most if not all other indicators list those the other way around, so I don't see how fixing the odd one would change anything. [01:10] stgraber: in fact, indicator-bluetooth is listed first in the seed before any of the other indicators or u-s-s. So with the current seed, this dependency is the only thing that's keeping the touch image from pulling in the wrong deps. [01:11] which is exactly why we shouldn't be in a hurry to flip or'ed dependencies around that aren't actually hurting anything [01:19] ah, it's ubuntu-defaults-builder [01:19] lubuntu inherits from platform/supported-development-desktop, which lists u-d-b, which depends on unity-common [01:22] stgraber: so given that 'supported' is, by definition, "seeded stuff that's not on the images", shouldn't we ignore supported for this check? [01:24] not quite sure why this only shows up in the lubuntu seed, really, given that it's part of "supported-common" which is used everywhere - but anyway, I don't think "supported" is what we meant by "seeded". [01:26] I suspect there's a fair amount of server packages that are in supported (due to limited space) and which we don't want to just let through, so I don't think allowing packages only seeded in supported through is a good move [01:29] nagios3, exim4 and freeradius are some that come to mind at least and I know we've got a bunch more in our seeds [01:36] stgraber: right, but I think that's because supported has a special meaning for Ubuntu ... because it means "and that other stuff in main". But for !Ubuntu, I don't think it has any meaning [01:36] certainly, the presence of unity in the lubuntu seed shows that it doesn't mean anything in *that* case [01:36] so what about ignoring supported for !Ubuntu? [02:01] slangasek: I haven't really dealt with the adt tests, that's jibel and pitti... I could try retriggering it if you think it would help [02:08] plars: well, it's not the tests so much as the environment... that error clearly points to fs corruption [02:08] plars: is that anything you could fix? [02:10] plars: barring that, a retry is also fine :) [02:10] slangasek: I didn't see any obvious issues on the build slave, could be something in the jenkins environment not getting cleaned up properly. The run-adt-test script there does have a datestamp of today [02:10] the job itself isn't updating it though [02:11] so I'm not sure if there's another job somewhere that pulls the latest of that, or if someone updated it by hand today [02:12] plars: so whatever filesystem was corrupted is no longer an issue? [02:13] slangasek: those errors are after it's already in the VM, but the host system seems ok [02:13] plars: and the VM isn't reused across multiple jobs? [02:14] slangasek: It's probably cow, but I'm not familiar with the setup [02:15] hmm, alright [02:15] so if you could retry the job, that'd be keen [02:15] slangasek: yeah, looks like it does: qemu-img create -f qcow2 -o backing_file=$DISKPATH $BCKPATH [02:16] slangasek: these jobs are started in an unusual way it looks like, but I'll give it a shot [02:16] right... so there could be corruption on the underlying base image, or the VM itself might've somehow corrupted it [02:37] slangasek: still failing [02:37] blame: arg:systemd_204-0ubuntu13.dsc dsc:systemd [02:37] badpkg: dependency install failed, exit code 1 [02:37] quitting: erroneous package: dependency install failed, exit code 1 [02:37] slangasek: any chance it's a legitimate failure? [02:38] slangasek: there's also a .crash file getting picked up from the run for initramfs-tools [03:38] Evening all. Does the beta et al freezes apply to syncing a new debian package into Universe? [04:24] plars: I don't see any way it could be a legitimate failure in the systemd autopkgtests that the /tmp filesystem is corrupt. Was this on the same jenkins slave again? [04:25] mfisch: syncing a new Debian package into universe is covered by feature freeze [04:33] slangasek: talking to pitti about it now, apparently that machine caused some weird problems like this recently [04:33] ok [04:34] slangasek: he's worked around it for now, it came back green this time [04:35] alright, thanks :) === doko_ is now known as doko [08:20] sil2100: Mirv: any of you published friends? I wonder why it came without any landing requests ^ [08:22] didrocks: not me, maybe robru ? [08:22] robru: did you? ^ [08:22] Since I saw a task for unblocking libfriends assigned to him [08:22] sil2100: maybe, but it's not about publishing it without a landing slot [08:23] Maybe robru misinterpreted it... [08:23] can we have anyone unblocking libunity + scope-home? [08:24] didrocks: s/unblocking/reviewing/ and yeah, I'll look in a sec. Sorting some things. [08:24] thanks infinity [08:24] * cjwatson goes to accept the pile of langpacks [08:24] cjwatson: Think pitti was doing it [08:25] ok [08:25] * infinity hands some buildds to i386 for the incoming barrage. [08:26] care to change the default release in queuediff? [08:30] cjwatson: Oh, if you didn't catch up on backscroll, we now have a hack in place that auto-accepts non-set/unseeded packages, so unapproved should only be full of things that actually need review. [08:31] Yep, I heard [08:32] infinity: want me to look at didrocks' request? [08:33] cjwatson: I was grabbing it, but if you're keen on reviewing unity, I won't stop you. :P [08:33] Oh, I guess it's just libunity, how bad can it be? [08:34] didrocks: nope [08:34] If you're already on it I'll leave you to it [08:34] cjwatson: Alrighty. === tkamppeter_ is now known as tkamppeter === Ursinha is now known as Ursinha-afk === brainwash_ is now known as brainwash === seb128_ is now known as seb128 === psivaa is now known as psivaa-afk === psivaa-afk is now known as psivaa [13:29] ^ that's me marking the milestone as released [13:41] sigh, they should have gone to a ppa, I'll delete [13:42] Riddell, -.- [13:42] qeueu party ! [13:42] *queue [13:43] ogra_: will, now, it's killing party for Riddell :p [13:44] didrocks, doom3 queue party then ;) [13:44] someone got lucky [13:57] stgraber: hm cherrypy3 in ubuntu. I go to look. [14:01] hi, can i request an unblock of indicator-keyboard? this bug was fixed: https://bugs.launchpad.net/indicator-keyboard/+bug/1228489 [14:04] attente: I don't see it [14:04] Laney, the bug? [14:04] attente: Also, no need to request approvals now that beta is done; we'll be reviewing https://launchpad.net/ubuntu/saucy/+queue?queue_state=1&queue_text= often [14:04] the upload [14:04] I'm going to do a manual upload in a bit, so don't worry about the upload [14:04] (need the .pot to be added since that launchpad fix hasn't been deployed yet) [14:05] So, nothing to request for this one [14:05] oh ok [14:05] Laney, seb128, thanks [14:05] Feature freeze still stands for other stuff, of course [14:05] Laney, do i need a FFe for this bug? [14:05] not for bug fixes [14:06] was just making sure that me saying "no need to request approvals" wasn't too broadly stated [14:06] ah, understood [14:07] attente, Laney: it's already in saucy: https://launchpad.net/ubuntu/+source/indicator-keyboard/0.0.0+13.10.20130924.2-0ubuntu1 [14:07] oho [14:08] oh.. i didn't realize that [14:08] yay :) [14:11] zul: Did you discuss the above upload with anyone, or just feel that the appropriate response to a reject was to upload the exact same thing again and hope for a different review? [14:12] zul: Ahh, you filed an FFe bug this time. Would have been nice to reference that in the changelog... And also not mysteriously delete the last version from the changelog too. [14:13] sorry [14:14] $ md5sum ubuntu-13.10-beta2-server-amd64.iso [14:14] 4d869a82e8bc4e88de6379a0609fe598 ubuntu-13.10-beta2-server-amd64.iso [14:14] dammit ... not that channel ok [14:14] Laney, i have this FFe for unity-greeter, can you please take a look at it? [14:14] zul: Can you fix up the changelog to not drop the 1.0.3-0ubuntu2 revision from history, and include a ref to the FFe? [14:14] https://bugs.launchpad.net/unity-greeter/+bug/1228207 [14:14] infinity: sure [14:15] attente: ok [14:15] attente: Didn't see it before because it's not on the ubuntu package [14:16] https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=&field.status:list=NEW&field.status:list=CONFIRMED&field.status:list=TRIAGED&field.status:list=INPROGRESS&field.status:list=INCOMPLETE_WITH_RESPONSE&field.status:list=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=ubuntu-release&field.structural_subscriber=&field.component-empty-marker=1&field.tag=&f ... [14:16] Laney, sorry about that, i'm not really familiar with the FFe process [14:16] ... ield.tags_combinator=ANY&field.status_upstream-empty-marker=1&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_no_package.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search&orderby=st ... [14:16] ... atus&start=0 ← the URL I use to see outstanding requests [14:16] omg [14:16] http://is.gd/CgE4Hu [14:16] *cough*tinyurl*cough* [14:16] Or is.gd. :P [14:17] ah, so FFe requests need to be on ubuntu? should i re-write the request? [14:17] it's fine, I'll add the task [14:17] I'm just sayin' that's why I didn't see it so far [14:17] oh ok [14:18] thanks Laney [14:18] It should be against the package, yes, not the upstream project. [14:19] ok, i see, thanks infinity [14:20] In other news, I just superglued my fingers together [14:20] Did you type that with your nose? [14:20] I've ripped them apart [14:21] You can reduce that URL to https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-release&orderby=status if you don't mind it also showing Fix Committed [14:21] The oresum bar remembers it for me [14:31] Laney, thanks! [14:39] Rejected oslo-config, some changes in the upstream changelog looked like features and I don't see a FFe or a bug report justifying why this should get in after FeatureFreeze [14:45] Laney: wow, that's one confusing diff for glib-networking :) [14:45] though apparently it's pretty much exclusively automagic changes and addition of tests, so I guess that's fine [14:46] yeah I think it's ok if you filter out the guff [14:46] yeah, didn't see any obvious bad change in there, I'll let it in and accept the the new binary once it shows up [14:46] thanks [14:47] we should totally have a tool to filter noise from diffs [14:49] Laney: Like filterdiff? [14:49] I guess it'd wrap filterdiff [14:57] infinity, a nice fat saucy kernel to gum up the works for you. [14:57] rtg: Mmm, fat and saucy. [14:58] indeed [14:59] rtg: That's a remarkably conservative point release. Urgent bugfixes in there, or is Greg still hung over from New Orleans? [15:00] infinity, 117 stable patches I think. thats not totally conservative [15:00] rtg: It's pretty conservative, given the size of some of the recent ones. [15:00] true [15:01] rtg: Accepted. [15:01] infinity, thanks [15:04] stgraber: 1232062 for oslo.config [15:22] hi can i get oslo-config accepted please (#1232062) [15:22] bug #1232062 [15:35] zul: accepted [15:35] thanks [15:49] qt guys ship minified javascript and are suggesting to put a pointer to sources, is that acceptable? http://lists.qt-project.org/pipermail/development/2013-September/013226.html [15:51] Riddell: No. [15:51] didn't think so [15:52] Riddell: As stated in that post you link, pointing to somewhere else (that might change, not stay in sync, disappear) isn't an acceptable form of "providing the preferred form of modification". [15:53] Riddell: for packaging, I believe you should either use an already packaged version (libjs-*) or ship the upstream modifiable version of the library (if the minified version gives you a performance improvemented, then you could minify it at build time but the source package needs the full version) [15:53] *improvement === jhodapp|afk is now known as jhodapp|lunch [16:29] Riddell: what? http://launchpadlibrarian.net/151652586/mplayerthumbs_4%3A4.11.1-0ubuntu1_4%3A4.11.2-0ubuntu1.diff.gz [16:29] Riddell: that seems pretty minimal for a new upstream release ;) [16:31] stgraber/slangasek/xnox: FYI: just raised FFe bug 1232119 for upstart. [16:31] jodh: i didn't think there needs one. [16:32] jodh: bugfixes don't need FFe, is that more than a bugfix? [16:33] xnox/stgraber: ah right, thanks - yes it's just a bug fix so I'll close that sucker :) [16:33] stgraber: lots of kde sc packages don't get updates between releases, but they're all released nevertheless [16:34] Riddell: so what's the point in uploading that if it doesn't even change the version number in any of the source files? anyway, someone other than me rejected it :) [16:35] stgraber: they are all packaged by a script so it's more effort not to upload it than to upload it [16:36] I expect gnome does similar [16:36] cjwatson: infinity: if you can look at the unity7 stack, that would be awesome ^ (unity8 is depending on it as well to get some good fixes on touch) [16:36] (yeah, unity depends on unity ;)) [16:37] then, it will enable us to cut an image and get ogra_ some sleep :) [16:37] (mediascanner is coming in < 3 minutes) [16:37] heh [16:37] you all sound like i would lack sleep :) [16:37] i'm *not* infinity :) [16:37] ah no, the mediascanner we needed is already in ;) [16:38] yes, its on -changes [16:38] didrocks: firefighting something else right now [16:38] ogra_: I hope for you it's not that bad ;) [16:38] cjwatson: sure, no worry ;) [16:38] I'll look [16:38] Best not to ping individual RT members [16:39] thanks Laney! [16:39] (and good luck, it's quite a lot) [16:39] Well, can split it with someone [16:42] dont you let half packages through ! [16:42] Laney: was planning on doing some of them after lunch here, so if you give up I'll pick up the rest [16:43] half packages? [16:47] if you split them :) [16:48] why would I randomly split packages [16:49] * Laney is confused [16:49] to try to probe the inner truths of package particle physics [16:49] Well, can split it with someone [16:49] deb rpm duality [16:50] Oh I see, you mean accepting half of them [16:53] stgraber: nux compix unity-scope-guahuahfaiu unity-scope-audacious OK [16:53] -home changes a translated string; not sure about that and unity is left for your enjoyment [16:54] a visitor just turned up, better go see what's up for a bit [16:54] o/ === Ursinha-afk is now known as Ursinha === jhodapp|lunch is now known as jhodapp [17:42] ogra_: do you know why /etc/adjtime exists on the Touch images? [17:42] slangasek, it doesnt, but as i understood timedated falls over if it isnt writable ?!? [17:43] (i guess it would create it) [17:43] ogra_: I have /etc/adjtime here on my device; not sure how it got there if it's not part of the image [17:43] slangasek, pitt can give yu details i think [17:44] slangasek, it was explicitly added to the writable files which creates it if it doesnt exist ... [17:44] according to Laney, timedated falls over *if* /etc/adjtime exists *and* isn't writable [17:45] well, that stuff will go away again once pittis (and stgraber's) changes for timezone selection land on monday [17:45] no [17:45] /etc/adjtime is *not supposed to be there* [17:45] then there should be a writable dir and no adjtime [17:46] stgraber@castiana:~/mnt$ tar Jtvf ~/Desktop/phablet-flash/imageupdates/pool/ubuntu-5219cfe1d590fddbebe1228872ff1529156efdc996571da44cbbe2438b37cee9.tar.xz | grep adj [17:46] -rw-r--r-- root/root 10 2013-09-27 04:15 system/etc/adjtime [17:46] it's not supposed to be in /etc/writable either [17:46] so it sure is in the image generated on nusakan... [17:46] yes [17:46] as i said [17:47] there was an assumption that timedated needs it in the commit that adds it to writable-files ... pittis change will drop the code that creates it [17:48] and pittis change is scheduled for monday ... so image 71 should not ship adjtime anymore [17:51] ogra_: pitti's change moves the file to /etc/writable, which is *still wrong* [17:51] we should find what *created* the file, and fix that [17:51] slangasek, i'll talk to pitti then [17:52] it wont be fixed befoe monday anyway [17:58] slangasek, i'm pretty sure stgraber's touch initrd script touches /etc/adjtime if it doesnt exist but is in /etc/system-image/writable-paths [17:59] if [ ! -d "$dstpath" ]; then [17:59] # Deal with redirected files [17:59] if [ "$4" = "transition" ]; then [17:59] cp -a $dstpath $srcpath [17:59] else [17:59] touch $srcpath [17:59] fi [17:59] thats the code doing it [17:59] and the timestamp on the file in my install agrees [17:59] ogra_: nope [18:00] ogra_: the initrd never has write access to / so if the file is not there, it may create it under /userdata but it certainly won't be able to create it under /etc [18:00] ^ I rejected unity-scope-home because it's changing a translated string after UIF without an approved exception [18:01] stgraber, well, i'm pretty sure that file was never there before i merged cwaynes MP [18:01] which only added them to writable-paths [18:01] stgraber, omg, really ? [18:02] ogra_: what I pasted before was the output of a tar ztvf of the rootfs, and it clearly was in there :) [18:02] * ogra_ sighs that breaks the whole planning for touch :( [18:02] (the home scope thing) [18:02] stgraber, hmm, it definitely doesnt come from a package [18:02] ogra_: sure why not, the package is in pretty much all our images, the only change was a string after the string freeze, so yes, perfectly matches the criteria for rejection [18:03] and i surely havent added code to create it anywhere [18:03] stgraber, oh, it was supposed ot have a fix ... [18:03] *to [18:03] yeah, i agree, if its only the string change that wouldnt have helped anyway :) [18:04] yeah, it was the only change in there [18:04] cdimage@nusakan:/srv/system-image.ubuntu.com$ tar ztvf /srv/cdimage.ubuntu.com/www/full/ubuntu-touch/daily-preinstalled/20130927/saucy-preinstalled-touch-armhf.tar.gz | grep adj [18:04] -rw-r--r-- root/root 10 2013-09-27 08:15 etc/adjtime [18:04] no idea where that's coming from, but something in the image build process sure generates the file ;) [18:04] yeah [18:04] well, its not in livecd-rootfs [18:04] and that's before any of the system-image stuff ever runs :) [18:06] hmpf [18:07] root@ubuntu-phablet:/# grep /etc/adjtime /var/lib/dpkg/info/* [18:07] /var/lib/dpkg/info/util-linux.postrm: rm -f /etc/adjtime [18:07] not from a postinst either [18:09] so must be some command spawned from a postinst creating it then [18:10] accepted the result of the autolanding stack. Unity had a pretty confusing changelog but the code changes look fine. [18:10] stgraber, yay, thanks ... [18:11] * ogra_ waits for britney before spinning a new image [18:15] ogra_: live-build scripts/build/lb_chroot_hacks. [18:16] in live-build itself ? [18:16] yes [18:17] smells like a bug, why dont we have it in other builds ? [18:18] I suspect we do in all desktop images [18:18] yes [18:18] but it's a bug that went under the radar before [18:19] question is, why did dba think that was needed at all... [18:19] \o/ [18:19] well, Debian does use /etc/adjtime. [18:19] (it shouldn't, but the reasoning why is difficult to explain effectively so I haven't tried to get that change upstreamed) [18:20] ah, didn't know that, so I guess we missed that difference when we rebased on the newer live-build? [18:20] anyway, easy enough to fix for any new builds [18:21] yes, uploading live-build now [18:21] cool, I'll let it through when it's in the queue, maybe we'll have it in place before the next touch build then [18:24] stgraber, i can wait :) [18:24] touch is all manual ... from code commit to released image [18:24] accepted [18:42] stgraber: so did we come to any conclusion about packages seeded in "supported" for !Ubuntu? [18:45] slangasek: I think I'd have to look at the json file to convince myself it's safe (as I'm not sure all ubuntu supported packages show up under ubuntu), I'd also probably want to make sure none of the existing flavours use supported in a way to indicate that those packages are things they care about and have documentation on but are post-install or language/region specific packages to be installed post-install [18:45] so currently, status quo seems easier especially as we haven't seen a flood of those so far [18:46] you're checking both seeds and packagesets, right? [18:47] shouldn't "think we care about but is post-install" be in the packageset, even if it's not on the image? [18:47] s/think/thing/ [18:47] it should, but the packagesets are generated from the seeds... [18:47] hmm [18:48] well, some/most flavours ones are, kylin is manual [19:05] stgraber, oh, will writable-paths cope with the removal of adjtime ? [19:05] yep, it should simply fail to bind mount and move on [19:05] great [19:06] go britney ... i know you can make it [19:10] stgraber: and then we should follow through to remove adjtime handling from the writable-paths stuff as well, and make sure the file is correctly removed on upgrades [19:11] slangasek: yeah, my debdiff for lxc-android-config already removes it from writable-paths so once that one land, we'll be good [19:11] o [19:11] k [19:12] we won't need to do any removal on touch since the file will just go away in the next image, though we probably ought to for desktops [19:12] not sure what's the best way of doing that though, adding an rm to some common package's postinst? [19:14] probably util-linux, I'd guess [19:14] * ogra_ sees live-build vanish from britney ... [19:14] yay [19:15] time for an image then :) === jhodapp is now known as jhodapp|afk [19:16] ogra_: did you see it publish (rmadison live-build)? [19:16] stgraber, if it is gone from tehg excuses page its pretty sure in, no ? [19:16] *the [19:17] hmm, I guess it should yes, I tend not to trust that and always triple check with rmadison :) anyway, live-build is fully published, so go ahead [19:18] (and since we moved the archive stuff to a new box, rmadison got much faster, so it's less of a pain to use nowadays) [19:19] well, just using madison after apt-get update should do as well [19:20] thats what i usually do [20:20] * stgraber takes lxc === jhodapp|afk is now known as jhodapp [21:45] I'll take that one, sounds like a reasonable use of my last 15min of work for the day :) [21:46] oh and it's an actual upload, not a sync, sweet! [21:47] well, looks like I'll need to find something else to do before my EOD, that one was way easier to review than I expected ;) === jhodapp is now known as jhodapp|afk [21:53] libhybris is in core? [21:54] apparently [21:54] also it seems to be building debs used by kubuntu, go figure [21:54] er, um [21:54] as in, daily-live, not supported :) [21:56] pulseaudio depends on libhardware2 [21:56] right [21:57] that'd make sense if seeded-in-ubuntu would also list it for say, every other flavours :) [21:57] do I need to do anything to get libhybris released or just wait for it to be published? [21:57] rsalveti: I accepted it in the archive, not sure if there's a block on it by the touch release team [21:57] are they doing armhf-based builds? [21:57] ah, that might be it, yes [21:58] yeah, kubuntu desktop builds on armhf [21:58] right, that's it then [21:58] and I haven't been building edubuntu armhf in a long long time, so that's why it's not listed [21:58] pushing new gstreamer-bad in a few minutes as well [22:00] so in theory, that means the FFe for libhybris in bug 1208989 isn't valid since some of the binaries are included in non-touch flavours, though that upload was a bugfix, so no problem with that. [22:03] (and I'm not seeing any obvious feature addition since FFe for packages affecting the Kubuntu images) [22:07] well, I wonder if that means the kubuntu desktop images don't actually have a working pulseaudio on armhf [22:07] and whether anyone's tested that [22:09] trying to get testing history data from the iso tracker to see if someone tested kubuntu desktop armhf lately [22:09] the pulseaudio patches to *use* libhybris seem to have been added post-FF with no FFe bug [22:09] hm, not sure if that was added after FF [22:10] that was to add support for modem/pcm using the android hal [22:10] no armhf desktop result for kubuntu since saucy opened apparently [22:10] 1:4.0-0ubuntu2 says "add patches for Ubuntu Touch"... that's the earliest mention I can see [22:12] yeah, aug 27 [22:12] that was the first one [22:12] oh, two days before feature freeze, I see :-) [22:13] :-) [22:14] still not ideal that non-touch flavours end up pulling that code too, can't that be done as a pulseaudio plugin in a separate package? (I have no idea how pulseaudio works besides the fact that it has modules ;)) [22:14] probably, need to ping diwic next monday [22:17] someone? ^^ :-) [22:18] that got auto-accepted [22:18] perfect [22:18] indeed [22:18] was thinking about the good subject [22:18] bad is not seeded [22:18] *subset [23:04] have the ubuntu GNOME cron jobs been switched back on? [23:05] no [23:05] I guess we should do that for all the products [23:05] let me do that quickly [23:06] all done [23:11] stgraber, thanks [23:13] stgraber, did you leave touch on manual ? [23:14] yep [23:14] :)