[02:50] <paul_____> hello
[02:51] <paul_____> Recently installed ubuntu-touch on Nexus 5...
[03:13] <Bray90820> Would this be a good place to get help with loading ubuntu with 3rd party boot loaders
[03:35] <Mirv> slangasek: it seems that -c0 line hasn't been touched since the initial packaging in 2012 (http://anonscm.debian.org/gitweb/?p=pkg-kde/qt/qtbase.git;a=commit;h=9376975341a7aab662d3ffdc3a79b04bbd41749e) and was seemingly copied from qt4-x11
[03:47] <nhaines> Bray90820: on the desktop?  No, that'd be askubuntu.com or #ubuntu, probably.
[03:50] <rww> assuming you mean ubuntu on phone, #ubuntu's usual response to that is "lol go ask #ubuntu-touch"
[05:19] <slangasek> Mirv: ok.  I also found when I looked more closely that debian/rules was ignoring the return values of all the dh_makeshlibs calls except the last one... ;)  I'll be throwing patches towards the Ubuntu package branch soonish
[05:39] <duflu> slangasek: That systemd assert/crash, shouldn't something like that have rules to generate crash reports?
[05:40] <duflu> Oops, wrong channel
[05:45] <slangasek> duflu: well, there's a default rule that certainly should have covered it.  However, with logind failing, consolekit is probably also broken, so maybe the user is never given an opportunity to approve crash report submissions <sigh>
[06:56] <dholbach> good morning
[06:58] <mihir> dholbach, good Morning :)
[06:58] <dholbach> hi mihir
[06:58] <mihir> dholbach, hello :)
[08:37] <JamesTait> Good morning all; happy Friday and happy Walk to Work Day! :-D
[10:02] <dholbach> pitti, didrocks, jibel: do you know who could help give some answers to https://bugs.kde.org/show_bug.cgi?id=333041?
[10:53] <facundobatista> ogra_, ping, good morning! question: I'm using ubuntu-emulator... and since today it's starting with no network at all (I get the "Network" list empty, and in the notification I see the wifi signal all turned off and with a small x in the lower right corner)
[10:54] <facundobatista> ogra_, do you have an idea of how can I debug what's going on and try to get the network back in there?
[10:54] <facundobatista> ogra_, thanks!!
[10:56] <ogra_> facundobatista, i dont think the indicator ever showed any network connections ... the emulator doesnt emulate any mobile connections
[10:57] <ogra_> (including wlan)
[10:57] <ogra_> afaik it only has a virtual ethernet device the UI wont show you
[10:58] <facundobatista> ogra_, ah, ok, so it *should* have an internet connection even if the indicator is like that and Network list empty?
[10:58] <ogra_> right
[10:58] <facundobatista> ogra_, ah, fantastic, thank you very much!!
[11:36] <anpok> how can I restore the android bootloader?
[11:36] <ogra_> the bootloader ?
[11:37] <anpok> seems like I manage to break it
[11:37] <ogra_> err, how ?
[11:37] <anpok> no idea what caused it
[11:37] <ogra_> if you manage to break the bootloader you actually have a brick
[11:37] <anpok> only the bootloeader menu
[11:37] <ogra_> you cant boot with the volume down key held down ?
[11:37] <anpok> I mean - i can still boot the nexus 4
[11:38] <ogra_> ah
[11:38] <ogra_> so its not the bootloader
[11:38] <anpok> when I press volume +/- and power button after some time I see a red LED
[11:39] <ogra_> that is a dead battery
[11:39] <anpok> device is chared.. I can boot ubuntu touch..
[11:39] <ogra_> make sure to charge the device regulary on a wall charger (USB ports on a PC/laptop only provide 500mA)
[11:40] <anpok> oh
[11:40] <anpok> you are right
[11:40] <anpok> I had it plugged in a few hours this morning and i can enter the menu..
[11:40] <anpok> why would it refuse to go into that menu, but still boot ubuntu touch?
[11:46] <ogra_> anpok, i dont get what your issue is then, if ubuntu boots all should be fine ?
[12:06] <ffelgenh1> Hi *, I installed r250 on a nexus 7 right now with
[12:06] <ffelgenh1> ubuntu-device-flash --channel=trusty --bootstrap
[12:06] <ffelgenh1> is this correct when installing on a tablet? I could not find an of the special tablet things like sidestage or core apps adapted to landscape.  As you saw, some apps support a landscape mode. We're working on this though
[12:21] <ffelgenh1> greyback: thanx!
[12:42] <dholbach> can anyone help give some answers to https://bugs.kde.org/show_bug.cgi?id=333041?
[12:58] <dholbach> In 2m (13 UTC) we're going to have a feedback session about our HTML5 App Dev story on http://ubuntuonair.com/  - just a quick reminder.
[13:03] <dholbach> we're hanging out on #ubuntu-on-air - so feel free to ask your questions there and give your feedback there
[13:21] <ogra_> stgraber, bug 1302174
[13:21] <ogra_> oh, i should update the title
[13:22] <ogra_> changed :P
[13:58] <grepped> Hi, what are hardware requirements for ubuntu-touch
[14:01] <grepped> what are minimum hardware requirements for ubuntu-touch
[14:02] <pmcgowan> grepped, best results would be 1ghz+ processor and 2GB mem bit it could run with less
[14:05] <grepped> pmcgown, I thought of working on Ubuntu-touch port on my LG-P500. It has RAM of 512MB. But according to you, it seems to be far less than required
[14:16] <pmcgowan> grepped, it can work with 512MB but we do not have a current reference design with that much memory so no recent testing I know of, you could look at the ported devices list to see if others have done so
[14:17] <grepped> are you guys doing development in C++?
[14:18] <grepped> pmcgowan, I checked devices list. I could not find any device with 512MB RAM. All are on and above 1GB RAM.
[14:19] <annerajb> hello everybody
[14:19] <grepped> pmcgowan, I think I should give a try? what do you suggest?
[14:20] <JamesTait> pstolowski, I've updated the wiki page for Click Package Index with the proposed format for collections.  Not all the edits are done yet, and I could do with running it by a couple of other people, but I think it should be enough to get you started: https://wiki.ubuntu.com/AppStore/Interfaces/ClickPackageIndex#Departments
[14:20] <pmcgowan> grepped, it would be interesting to see if you are willing
[14:20] <JamesTait> alecu, ^^
[14:20] <annerajb> rsalveti, can I start porting 4.2 based devices now and is there a updated documentation for it??
[14:21] <rsalveti> you can already start porting to 4.4, we just need to update the doc =\
[14:21] <annerajb> rsalveti, is the process different than the doc by great lenghts??
[14:21] <brendand> is the new app switcher in -proposed or is it in devel now as well?
[14:21] <rsalveti> not much, no
[14:21] <grepped> pmcgowan, thanks! Do you want to point me to any particular beginners documentation?
[14:22] <annerajb> rsalveti, how do you specify that it has to checkout the 4.4 framework? is there a argument you pass?
[14:22] <pmcgowan> grepped, look at the porting guide in the topic if you have not
[14:22] <annerajb> or i have to go and update the repo.xml so it checksout a different branch?
[14:23] <rsalveti> repo init -u https://code-review.phablet.ubuntu.com/p/aosp/platform/manifest.git -b phablet-4.4.2_r1
[14:23] <pmcgowan> rsalveti, what do you think about a port to a device with 512MB
[14:23] <pstolowski> JamesTait, thank you
[14:23] <rsalveti> different manifest
[14:23] <rsalveti> pmcgowan: port should be fine, might just be an issue to run unity8 properly
[14:24] <rsalveti> but you can try to enable swap or zram
[14:24] <pmcgowan> grepped, ^^
[14:24] <pstolowski> JamesTait, I think in the departments section, the part which returns "Content-Type: application/json; " is a leftover from previous approach? the correct one is with "Accept: application/hal+json" ?
[14:25] <JamesTait> pstolowski, that's correct.  Sorry, I should also have referred to: https://wiki.ubuntu.com/AppStore/Interfaces/ClickPackageIndex#Response_Format
[14:25] <JamesTait> pstolowski, it's really just to maintain backward compatibility.
[14:26] <pstolowski> JamesTait, ah, I see
[14:26]  * JamesTait -> school run, etc.
[14:28] <grepped> pmcgowan, rsalveti, based on your comments, not sure if I should go for it
[14:29] <pmcgowan> grepped, right, better to find a different target and have it work well
[14:30] <grepped> pmcgowan, thanks. Which handset are you using for ubuntu touch? which one do you suggest? I will go for it if possible
[14:31] <pmcgowan> grepped, Nexus 4
[14:31] <pmcgowan> there is also a Nexus 5 port done by someone in the community
[14:32] <rickspencer3> hey scopers, if I am getting this error:
[14:32] <rickspencer3> Caught an error from create_query(): unity::scopes::TimeoutException: Request timed out after 300 milliseconds
[14:32] <grepped> ok
[14:32] <rickspencer3> shall I assume that means I have a call in my code that is blocking too long?
[14:33] <rickspencer3> seems I get that if I uncomment this: QDomDocument fridgeDoc;
[14:33] <alecu> JamesTait: great, thanks!
[14:35] <ogra_> stgraber, well, what do you suggest how to get any info about cgmanager if the system hardlocks beacuse of it
[14:36] <stgraber> ogra_: do you have a /var/log/upstart/cgmanager.log?
[14:36] <ogra_> stgraber, 4 people have been running reboots for the last two days to even get the info that reverting it fixes the hardlocks
[14:36] <stgraber> ogra_: booting the system in debug mode would be nice too so we could figure out what upstart is doing
[14:37] <stgraber> ogra_: I'm not saying there isn't a bug, I'm just saying we don't know what it is or where it is yet
[14:37] <ogra_> stgraber, right
[14:38] <ogra_> stgraber, i dont think it is necessarily cgmanager itself though
[14:38] <ogra_> http://paste.ubuntu.com/7203516/
[14:38] <ogra_> here is the log
[14:38] <rsalveti> got a bunch of cgmanager segfault when it tries to start on the emulator
[14:38] <ogra_> the system ran with debug for quite a while
[14:38] <rsalveti> need to debug that as well
[14:39] <ogra_> rsalveti, well. see bug 1302174 ... thats the one that killed the lab
[14:39] <rsalveti> interesting
[14:39] <stgraber> rsalveti: ah, a segfault seems nice, especially if you can get a coredump out of it somehow
[14:39] <ogra_> stgraber, in fact i first thought it is udev (and i still think it is involved)
[14:40] <ogra_> stgraber, since it started to massively impact us with image 274 where udev changed from 204-5ubuntu13 to 204-5ubuntu14
[14:41] <ogra_> there were apparently crashes before that since we switched to cgmanager (more than with cgroup-lite), but not at that frequency
[14:41] <ogra_> stgraber, it might even be that our re-ordered boot (udev only starting after the container etc) has impact
[14:42] <ogra_> but its clear that reverting to cgroups-lite fixes it
[14:42] <ogra_> *cgroup-lite
[14:42] <stgraber> ogra_: yeah, unfortunately reverting to cgroup-lite isn't something we can live with for very long... we're still working on getting upstart to use cgmanager
[14:43] <rsalveti> stgraber: will try to get the crash file
[14:43] <ogra_> stgraber, right, but we needed the lab back up ... thats why i opened the cgmanager task on the bug
[14:43] <stgraber> rsalveti: thanks. I'm updating my mako here to try and figure out what's going on
[14:43] <ogra_> and uploaded the lxc-android-config revert for now
[14:53] <sil2100> kgunn: hi!
[14:54] <kgunn> sil2100: yo!
[14:55] <sil2100> kgunn: so, not sure if michi or Mirv poked you about that already, but we have that unity8 crasher that's appearing on autopilot test runs
[15:02] <nik90> Ursinha: ping
[15:02] <nik90> Ursinha: (about https://bugs.launchpad.net/ubuntu-clock-app/+bug/1253836)
[15:03] <sil2100> kgunn: sorry, got context-switched - anyway, regarding that crasher
[15:03] <sil2100> kgunn: michi had a look at that one and said it look like a Mir bug in the end, and Mirv filled in a better crash file and trace as a separate bug
[15:04] <sil2100> kgunn: so, we suspect two bugs showing the same issue: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1256360 and https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1302550 (the new bug)
[15:05] <sil2100> Ah, I see LP already made it a duplicate now, it wasn't still 15 minutes ago
[15:05] <sil2100> kgunn: anyway, could you assign someone to that to take a look? I heard that management was thinking of making that a 'blocker'
[15:06] <kgunn> sil2100: i'm following...but on the phone
[15:06] <kgunn> will get on it
[15:06] <sil2100> Thanks :)
[15:21] <stgraber> ogra_: so it looks like the current proposed image has a broken systemd/logind so that won't help. I'm now manually updating everything in it to current trusty except for lxc-android-config, then will check that all the upstart jobs look sane and after that try your script to see if I can get it to hang.
[15:21] <ogra_> stgraber, new image is building atm
[15:21] <ogra_> should be ready in 45min or so
[15:21] <stgraber> ogra_: yeah but I don't want the new lxc-android-config
[15:22] <ogra_> well, trivial to change back :)
[15:23] <ogra_> stgraber, the prob is really that you can only trigger the issue every 80 boots or so ... it will be very time consuming
[15:32] <stgraber> ogra_: oh, right, so I forgot that ubuntu touch had a pretty old kernel and so you're using cgproxy as well as cgmanager, the lxc-android-config start condition is therefore wrong. Let me fix that before I stress test it
[15:32] <ogra_> stgraber, so it should have been cgproxy ?
[15:32] <ogra_> will that not eat precious boot time ?
[15:33]  * ogra_ is on a quest for faster boots :)
[15:35] <stgraber> ogra_: whether you need to start after cgmanager or cgproxy depends on the kernel you use, so I'm adding an extra upstart event that can be reliably used for that
[15:36] <stgraber> ogra_: cgproxy is single threaded, tiny and does nothing at start time, so it should basically only take the time required for an extra fork() and reading a few KBs from disk, nothing that should be visible
[15:36] <ogra_> stgraber, please dont roll back the lxc-android-config change before the next week though ... we have a massive backlog in testing due to all phones being dead in the lab
[15:37] <ogra_> ok, that sounds fine
[15:43] <stgraber> ogra_: so I think I managed to reproduce your hang, looks like a race between cgproxy and lxc, the rest of the system however seems to boot fine, you just don't get adb because it depends on the container being up
[15:43] <stgraber> trying to reproduce it again with adb starting on immediately on startup
[15:43] <ogra_> stgraber, nope, than it isnt the same hang
[15:44] <ogra_> stgraber, the hang we saw hung the device hard (we have an emergency adb in the image that fires off when the container cant start)
[15:46] <stgraber> ogra_: well, your backup adb assumes that cgmanager and cgproxy themselves start successfuly, otherwise lxc-android-config is never started so won't ever emit the failure to start
[15:47] <stgraber> I'm doing another batch of tests with adb starting on startup instead which should guarantee that if upstart starts at all, I'll get a shell
[15:47] <ogra_> oh, right
[15:47] <ogra_> cant fail if it never tries
[15:47] <stgraber> exactly
[15:48] <ogra_> i should probably switch over to it just having a timer ... if the container didnt start after $TIMEOUT we consider the boot broken and frie up the emergency shell
[15:49] <stgraber> yeah, that'd probably have helped quite a bit with this bug
[15:50] <rsalveti> ogra_: +1
[15:50] <ogra_> i*ll work on that next week ...
[15:50] <ogra_> (first i need to get that darn bootcharting done)
[16:02] <stgraber> ogra_: ok, so there was also a small race between cgmanager and cgproxy as their upstart jobs weren't quite right. I have now fixed all of that stuff and will run a reboot loop, hopefully things will work fine now.
[16:03] <ogra_> stgraber, \o/
[16:03] <stgraber> if they do, I'll upload the fix cgmanager and we can look into switch lxc-android-config back to cgmanager next week
[16:03] <ogra_> you rock !!!
[16:57] <tedg> jhodapp, So I grabbed silo6 and I'm not seeing the media player in the sound menu, do you expect it to be?
[16:57] <tedg> Or is that a future branch thing?
[16:58] <jhodapp> tedg, which menu are you referring to exactly?
[16:58] <tedg> jhodapp, The one in the top panel with the volume icon
[16:59] <jhodapp> tedg, I don't see that either, though I don't have anything to do with that feature
[16:59] <tedg> jhodapp, Is the media player exporting MPRIS?
[17:00] <jhodapp> tedg, no
[17:00] <tedg> jhodapp, Ah,okay. Will it soon? :-)
[17:00] <jhodapp> tedg: media-hub implements the MPRIS v2 interface (or most of it)
[17:01] <tedg> Ah, so a naming thing. Is the media-hub exporting the MPRIS interface on the bus in silo6?
[17:01] <jhodapp> tedg, yes, though there may be apparmor issues
[17:01] <tedg> jhodapp, Is media-hub confined?
[17:01] <jhodapp> tedg, jdstrand is looking into that right now
[17:02] <jhodapp> tedg, not sure...do we have a generic policy in place to confine by default and then relax things specifically? or is it the other way around?
[17:02] <tedg> No, it's the other way around.
[17:03] <jhodapp> tedg, hmm, then I don't know why it's not showing up...who wrote that menu functionality?
[17:03] <tedg> jhodapp, What name does the media hub register as?
[17:03] <sergiusens> tedg: media-hub isn't confined; it's started by upstart
[17:03] <sergiusens> app access to it may be though
[17:03] <tedg> jhodapp, Most recently me :-)
[17:04] <sergiusens> well, should be, as it's a new name on the bus that they would need to access
[17:04] <sergiusens> by upstart as part of the session that is
[17:04] <jhodapp> tedg, ok, let me get you the exported name string
[17:04] <ogra_> tedg, oh, so i can blame you that i have VLC and rhythmbox entries in that menu on my desktop ?
[17:04] <jhodapp> lol
[17:05] <tedg> ogra_, Heh, you're welcome to, but it's a feature not a bug :-)
[17:05] <ogra_> lol
[17:05] <sergiusens> ogra_: yeah, would be nice if they go wth nameownerlost :-)
[17:05] <ogra_> well, kind of "feature"
[17:05] <sergiusens> go away with nameownerlost
[17:05]  * ogra_ would prefer to only see the app he uses for music playback there
[17:06] <jhodapp> tedg, "core.ubuntu.media.*" where * is Service, Player, etc
[17:06] <tedg> I don't see a media-hub running, do I need to explicitly install it?
[17:06] <jhodapp> tedg, yes
[17:06] <jhodapp> apt-get install media-hub
[17:07] <jhodapp> also qtubuntu-media
[17:07] <tedg> Okay, that should help me to see it :-)
[17:07] <jhodapp> tedg, yes indeed
[17:10] <tedg> Hmm, music doesn't work at all now :-(
[17:10] <tedg> My song is "NaN:NaN"
[17:11] <tedg> jhodapp, Do I need to install anything else?
[17:11] <jhodapp> tedg, did you uninstall the *touch packages for qtmultimedia?
[17:12] <tedg> No
[17:12] <jhodapp> purge those
[17:12] <jhodapp> dpkg --get-selections | grep touch will list all of them (plus others, should be obvious which ones)
[17:16] <tedg> Hmm, still not playing :-/
[17:17] <jhodapp> tedg, sure you're running media-hub-server?
[17:17] <tedg> Yes
[17:18] <tedg> No upstart log for it.
[17:18] <jhodapp> tedg: run it like this once: "GST_DEBUG=*:4 media-hub-server"
[17:18] <tedg> But there's no name registered in dbus
[17:18] <tedg> Segfault
[17:19] <jhodapp> tedg, you're missing the hybris side of things
[17:19] <jhodapp> tedg, you need a new system.img
[17:21] <jhodapp> tedg, check out http://pastebin.ubuntu.com/718015/
[17:21] <tedg> jhodapp, Hmm, that sounds harder :-)
[17:21] <jhodapp> tedg, it's not too bad
[17:21] <tedg> jhodapp, I think that's missing a digit?
[17:21] <jhodapp> tedg, oops yeah, http://pastebin.ubuntu.com/7185015/
[17:22] <tedg> jhodapp, That's for flo, does it work on mako?
[17:23] <jhodapp> tedg, it should but I don't have one so I haven't tested it...I can build you a system.img for mako if you like
[17:24] <tedg> jhodapp, Hmm, what's your timeline for landing? Need to see why the sound indicator isn't just picking it up, but not sure I'll beat you.
[17:24] <jhodapp> tedg, this afternoon I'd like to land it
[17:24] <jhodapp> tedg, a mako image is building for you
[17:24] <tedg> jhodapp, Ah, okay. Let me just wait for it to land then.
[17:25] <jhodapp> ok
[17:25] <tedg> Worried that we may only support MPRIS v1
[17:27] <stgraber> ogra_: fixes pushed to cgmanager upstream, now running the new version on my mako and trying to get it to hang
[17:31] <jhodapp> tedg, it should be mostly v2
[17:31] <jhodapp> tedg, or most of rather
[17:35] <om26er> who to talk about ubuntu-system-image code ?
[18:01] <mhall119> RSS Reader meeting about to start in #ubuntu-touch-meeting
[18:10] <sergiusens> om26er: that's barry (as implicitly stated in the testplan) and the "UE Weekly QA Health Snapshot"
[18:11] <om26er> sergiusens, oh, it must be an oversight from my side, anyways thanks :)
[18:11] <sergiusens> np
[18:12] <om26er> barry, Hi! I am automating the system upgrade test plan, my initial test does drive the UI in ubuntu-system-settings though its only testing the upgrade side, so do you think its fine to keep that test code inside ubuntu-system-upgrade ?
[18:13] <barry> om26er: i'm sorry, i don't quite understand
[18:14] <om26er> barry, I am writing auto tests for this plan https://wiki.ubuntu.com/Process/Merges/TestPlan/ubuntu-system-image I am asking is it fine to propose the test addition inside ubuntu-system-upgrade codebase ?
[18:15] <barry> om26er: ah.  do you mean as additional unittests or something else?
[18:15] <om26er> barry, integration tests, rather. which will test the upgrades are working fine
[18:17] <barry> om26er: yeah, it probably does make sense to keep them close to the component you're testing.  if it's most convenient to do so, then by all means, let's do it.  why not put then in a top-level "integration-tests" directory?
[18:18] <barry> om26er: and then the question is, does this directory need to be included in the binary packages?
[18:18] <om26er> barry, we can probably create a separate deb for the test if its fine by you, something ubuntu-system-image-autopilot ?
[18:19] <barry> om26er: will these tests be run by autopilot then?
[18:19] <stgraber> ogra_: up to 65 reboots, no crash so far :)
[18:20] <stgraber> ogra_: my plan is to beat your 273 and call it stable
[18:21] <om26er> barry, its a sum of two. the autopilot tests will run from inside a python unittest which will first flash the device using ubuntu-device-flash, then tests will run on the phone/tablet with autopilot as we want to upgrade the image as a user would do
[18:22] <barry> om26er: so let's call the directory 'autopilot' and be sure to write them in python 3 :)
[18:23] <barry> and i'll add a -autopilot binary package
[18:23] <om26er> barry, oh yeah, for sure.
[18:23] <om26er> my code is already python3 :)
[18:24] <barry> \o/
[18:45] <ogra_> stgraber, hah, good luck :)
[18:47] <stgraber> ogra_: we got a crash after 80 or so runs, unsure what exactly happened since we don't get a crash file... trying to stres it in a more efficient way to figure it out
[18:47] <ogra_> k
[18:48] <ogra_> hmm, i cant remember having ever run tests on my flo ..
[18:48] <ogra_> but obviously i lost the available apps
[18:48]  * ogra_ only sees weird fake apps
[18:55] <davmor2> pmcgowan: in settings→security→dash search you have phone and internet as default and then phone only.  Is phone only meant to only search locally to the device
[18:55] <pmcgowan> let me look but sounds like it
[18:56] <pmcgowan> davmor2, and since its you asking I suspect it doesnt do that?
[18:56] <davmor2> pmcgowan: correct Toykeeper first spotted it
[18:57] <pmcgowan> although it used to, since it took us 30 mins to figure out why someone was not getting remote results
[18:57] <pmcgowan> ah may have broken with new scopes, I wonder
[18:58]  * pmcgowan boots 277
[18:58] <davmor2> pmcgowan: could be
[19:00] <davmor2> pmcgowan: so I had it on Phone only and in the scopes scope I put my home town and there are results :(
[19:03] <pmcgowan> davmor2, so it was working on march 14
[19:03] <pmcgowan> and the log should say online search is off
[19:04] <pmcgowan>  /home/phablet/.cache/unity-scope-click.log that is
[19:04] <pmcgowan> davmor2, do you see apps in the store?
[19:05]  * ogra_ sees fake apps
[19:05] <davmor2> ogra_: that is fixed now do a search it will refresh them
[19:06] <ogra_> was that server side ?
[19:06] <davmor2> ogra_: they did a roll out and accidentally copied over the staging server
[19:06] <ogra_> heh
[19:07] <davmor2> I let them know as soon as I saw it was fixed about 10 minutes ago
[19:10] <davmor2> pmcgowan: http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-04-04-200735.png and http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-04-04-200857.png and http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-04-04-200951.png
[19:14] <davmor2> pmcgowan: that is confirmation of the setting, app search and scopes scope search I can also open grooveshark and get content
[19:15] <pmcgowan> davmor2, sorry, so click scopes does show store apps when internet is off?
[19:15] <davmor2> pmcgowan: yeap if I do a search it gets content in the available section
[19:16] <pmcgowan> davmor2, ok so that is defintely broken in new scopes, it used to work
[19:18] <davmor2> pmcgowan: who's the best person to assign that too is it thomas strehl's team
[19:18] <pmcgowan> yes
[19:18] <davmor2> pmcgowan: thanks
[19:18] <davmor2> ToyKeeper: ^
[19:18] <davmor2> ToyKeeper: also well spotted :)
[19:20] <ToyKeeper> Sorry, I'm a bit behind on filing the bugs I've found...  have had a few other things filling up my time lately.
[19:21] <davmor2> ToyKeeper: if you want I can file you can confirm or visa versa if you're juggling too much
[19:22] <ToyKeeper> The juggling should get a lot easier in the near future.  :)
[19:22] <davmor2> ToyKeeper: NO it won't there is way too much to be getting on with ;)
[19:24] <ToyKeeper> At least 80% of the support load is going away...  but I still have a tendency to get involved in too much at once.
[19:35] <davmor2> ToyKeeper: no idea what you mean
[19:36] <davmor2> ToyKeeper: have you filed or did you want me too
[19:42] <pmcgowan> popey, happy birthday mate
[19:43] <pmcgowan> hes at the pub though ;)
[19:45] <stgraber> ogra_: came up with a much quicker way to test and debug. adb now spaws on startup, I have a reboot job which waits for the container and as soon as it's there, it does a sysrq-trigger to reboot (shortens the reboot by half)
[19:45] <davmor2> pmcgowan: https://bugs.launchpad.net/ubuntu/+source/unity-scopes-api/+bug/1302801
[19:46] <stgraber> ogra_: now a whole cycle takes around 20s here
[20:00] <taiebot> Hey guys i know this is a weird bug but it would be nice if the user experience could be improved just by making some cosmetic changes. https://bugs.launchpad.net/ubuntu-ux/+bug/1295993
[20:14] <popey> pmcgowan: thanks
[20:18] <popey> davmor2: do you know what package te music scope is?
[20:18] <taiebot> Euh is there a bug with the app store?
[20:19] <taiebot> i have very weird suggestions.
[20:19] <AskUbuntu> Can I install Ubuntu Touch on a Huawei Ascend P6? | http://askubuntu.com/q/443427
[20:24] <taiebot> Has the store been hacked? where are all the apps? i have evil app, fake clock, hammer,  test app
[20:26] <davmor2> taiebot: do a search your device just needs to update
[20:27] <davmor2> popey unity-scope-mediascanner2 off the top of my head
[20:28] <davmor2> taiebot: did that fix it?
[20:28] <taiebot> yep why those apps are appearing? are they test apps on my phone?
[20:29] <taiebot> sorry the app have reappeared as normal
[20:29] <davmor2> no staging apps on the server the wrong db got copied on an update
[20:30] <t1mp> taiebot: I want the evil app :)
[20:30] <davmor2> t1mp: you can't have the evil app it's evil :-P
[20:31] <taiebot> ok thanks. Do you know if it safe to upgrade to devel-proposed stuck on 251 for a while now need my daily dose of updates.
[20:31]  * davmor2 goes offline again
[20:32] <t1mp> taiebot: I thought devel is 250
[20:33] <taiebot> :) my wrong yep 250 is for devel.
[20:33] <t1mp> taiebot: I am running 277 now. Seems ok. In 276 some phones got stuck when rebooting, I don't know if that got fixed for 277
[20:34] <t1mp> maybe it is fixed https://bugs.launchpad.net/ubuntu/+source/lxc-android-config/+bug/1302174
[20:34] <t1mp> ah maybe it is this bug https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1302264
[20:35] <taiebot> can i go back to devel after switching to proposed and will i lose any of my data?
[20:35] <t1mp> taiebot: if you are on the phone mailing list, you can read about the bugs in [Ubuntu-phone] Landing team 04.04.14
[20:36] <t1mp> in theory you can go back, but if you are using the phone for anything else than development I would wait for the next image promoted to devel
[20:37] <t1mp> I don't want to be the one that gave you advice that caused you to lose your data ;)
[20:39] <taiebot> thanks do you have the command line for the upgrade?
[20:39] <t1mp>  ubuntu-device-flash --channel=devel-proposed
[20:39] <t1mp> on your desktop when the phone is connected
[20:40] <t1mp> on the phone I don't know
[20:40] <taiebot> oups i did it... :-D
[20:40] <t1mp> good luck :)
[20:45] <mhall119> does deleting files from /home/phablet/Pictures/ delete cached thumbnails?
[20:45] <mhall119> bfiller: ^^
[20:45] <mhall119> it doesn't appear to
[20:45] <mhall119> mhall@mhall-thinkpad:~/projects/Ubuntu/sdk/coreapps/ubuntu-weather-app$ adb shell ls /home/phablet/.cache/gallery-app/thumbnails/square/ |wc -l
[20:45] <mhall119> 349
[20:45] <mhall119> mhall@mhall-thinkpad:~/projects/Ubuntu/sdk/coreapps/ubuntu-weather-app$ adb shell ls /home/phablet/Pictures/ |wc -l126
[20:45] <mhall119> bah, formatting was off
[20:46] <mhall119> 349 thumbnails, 126 pictures
[20:46] <bfiller> mhall119: not sure about that
[20:47]  * mhall119 is deperate to find room on his N4
[20:48] <mhall119> currently I have 195M in .cache
[20:51] <popey> mhall119: does this help..  adb shell du -a /home/phablet | sort -n -r | head -n 10
[20:52] <mhall119> popey: du -ah /home/phablet | sort -h -r | head -n 10 works better, human-readable sizes FTW
[20:53] <mhall119> looks like webbrowser-app caching for all of these webapps is part of my problem too
[20:54] <mhall119> which I think I have a bug against already
[20:55] <mhall119> but now I can't find it
[21:01] <pmcgowan> davmor2, hey I cant get any images to display when I have wifi  off and just cell on
[21:01] <pmcgowan> the data like for apps is there but not icons
[21:01] <pmcgowan> and weather scope doesnt finish loading
[21:01] <mhall119> pmcgowan: are you sure you have cellular data?
[21:01] <pmcgowan> yes becuase browser is happy and snappy
[21:02] <pmcgowan> my home internet is just 4G anyway, so is the nexus 4
[21:02] <pmcgowan> should be the same
[21:02] <mhall119> I think the N4 is 3G only
[21:02] <pmcgowan> could be
[21:03] <pmcgowan> anyway browser is wicked fast
[21:03] <pmcgowan> and scopes never finish
[21:03] <pmcgowan> no icons at all
[21:03] <pmcgowan> mhall119, does it do better for you?
[21:04] <mhall119> pmcgowan: I'm seeing the same
[21:04] <mhall119> on r250
[21:04] <popey> http://popey.com/~alan/phablet/device-2014-04-04-220418.png
[21:04] <popey> like that?
[21:04] <mhall119> I have old scopes still
[21:05] <mhall119> I wonder if this is a bandwidth saving feature, to not download images over cellular
[21:05] <pmcgowan> seems busted
[21:05] <popey> http://popey.com/~alan/phablet/device-2014-04-04-220507.png
[21:05] <mhall119> Saviq: ^^
[21:05] <popey> videos scope
[21:05] <pmcgowan> mhall119, yeah its not trying to load them it seems, cause the connection I have is fast
[21:06] <pmcgowan> popey, right, off by default then, -1
[21:07] <mhall119> well now my click scope is gone completely :(
[21:08] <pmcgowan> mhall119, wait 10 secs
[21:08] <pmcgowan> known bug
[21:08] <pmcgowan> at least thats fixed in new scopes
[21:08]  * mhall119 has waited more than 10s
[21:08] <pmcgowan> ok happy hour - later
[21:09] <taiebot> How do i install a click app via adb shell?
[21:09] <popey> adb shell sudo -u phablet pkcon install-local /path/to/file.click
[21:10] <popey> after adb push file.click /path/to
[21:10] <taiebot> thanks
[21:37] <taiebot> Hey I would like to try https://github.com/Diogenesthecynic/FullScreenMario on my N4 i have downloaded the folder on my phone how do i make it start?
[22:15] <matv1> to anyone interested: I have been running ubuntu touch on  Galaxy Nexus and I have to see that it continued to run  really well on most dailys over the past month. Until today that is..
[22:16] <matv1> So just wondering  if anyone else was seeing major issues with build 277
[22:16] <matv1> like random reboots, screen going black, lots of flickering
[22:17] <matv1> If not, then I guess thats the end of Maguro finally


[00:04] <darkxst> doko, ok thanks
[00:33] <cyphermox> ugh, please reject multipath-tools in wily, that's wrong... :(
[00:44] <slangasek> cyphermox: done
[07:12] <Ian_Corne> cyphermox: hmm that's to the ubstable debian then, or?
[07:12] <Ian_Corne> ahno, SID probably?
[10:46] <cjwatson> snakefruit (various archive cron jobs, http://people.canonical.com/~ubuntu-archive/, etc.) going down soon for a RAM upgrade
[11:30] <cjwatson> snakefruit back
[11:45] <cjwatson> yofel: do you know who would be a good contact to receive Kubuntu image health check mails (which basically whinge about oversizedness, any uninstallable packages, etc. unless corrected)?  they're currently going to Riddell and ScottK, and at least Riddell has asked not to receive them any more and suggested "kubuntu-devel@ or someone relevant" - would this sort of cron mail be welcome on kubuntu-devel@ or could you suggest a ...
[11:45] <cjwatson> ... recipient or two?
[11:46] <yofel> good question, how frequent are those sent?
[11:47] <cjwatson> daily
[11:48] <yofel> can you please send them to me for now then? I don't think that's something we want to spam -devel with, and I'll come back to you once we have a better place
[11:49] <yofel> btw. with Riddell quitting as release manager, I (and sgclark as subsitute) would like to take over the job
[11:49] <yofel> anything/anywhere in particular we have to apply for to do this? Other than a mail to ubuntu-devel
[11:53] <cjwatson> I'm not sure, somebody techboardy should know, maybe infinity or stgraber
[11:53] <cjwatson> yofel: is your @kubuntu.org address OK?
[11:53] <yofel> cjwatson: it should be, yes
[11:54] <cjwatson> all right, done, thanks, can easily change on request
[11:54]  * xnox ponders who manages @kubuntu.org domain
[11:57]  * yofel assumed canonical
[11:57] <Odd_Bloke> xnox: "Registrant Organization:Canonical, Ltd."
[11:57] <yofel> at least the address updates are done in the same way as for @ubuntu.com
[11:57] <xnox> ah, cool. so probably done in bulk with the rest of them.
[15:49] <stgraber> cjwatson: IIRC ubuntu-release is basically self-managed, that is, existing members vote on new members. infinity could confirm.
[15:49] <stgraber> I believe the main requirement besides time is that you have to be a coredev
[15:53] <infinity> stgraber: Pretty much, yes.
[16:17] <yofel> stgraber: well, there are no kubuntu devs left that are core-devs, so we would have to do without being on the release team for now.
[16:17] <yofel> it's something we'll be aiming for in the future, but that'll take a while
[16:18] <infinity> yofel: You're not the only flavour without an ubuntu-release presence, it's not the end of the world, but you should certainly aim to get some core-devs again.
[16:19] <yofel> so, do we need to do anything beside that?
[16:19] <sgclark> yes I am aiming for that as is yofel
[16:48] <stgraber> FYI, I'll be releasing the network-manager SRU for wily in a couple of hours, I'm looking at the ppc64el regression (looks like the usual NM race, will retry the adt) and will do a bit of VM testing to make sure it doesn't break the world (but testing on xenial showed it's fine here)
[18:09] <bdmurray> arges: Could you have a look at that apport upload?
[18:11] <arges> bdmurray: yea
[18:12] <bdmurray> thanks
[18:59] <Ian_Corne> is there somewhere a template for a bugreport i can file to request a new version of a package being uploaded ?
[18:59] <Ian_Corne> I've tried going the reportbug way with -B debian, but it feels so much like a real bug report, i'm unsure if it's the good way to go
[19:20] <Logan> Ian_Corne: it's fine to report a bug like that
[19:20] <Logan> just make sure it has wishlist importance
[19:20] <Ian_Corne> ok, thank you
[19:20] <Logan> no problem!
[19:20] <Ian_Corne> I can do it like this?
[19:21] <Ian_Corne> Your version of ibus (1.5.10-1ubuntu1) is newer than that in Debian! Do you
[19:21] <Ian_Corne> icorne@topian:~$ reportbug -B debian ibus
[19:21] <Ian_Corne> sorry, pasted, wrong one
[19:21] <Logan> yes
[19:33] <Ian_Corne> damn, it's been submitted by icorne@topian
[19:33] <Ian_Corne> that's obviously not my email :p
[21:23] <arges> bdmurray: https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=systemtap can you review this, i've tested built it on a power8 machine and should unblock libguestfs
[21:25] <bdmurray> arges: is there an SRU bug for that?
[21:25] <arges> bdmurray: I suppose i need to add one for that
[21:26] <arges> bdmurray: let me add that and re-up
[21:31] <arges> bdmurray: ok please review now. Thanks
[21:38] <bdmurray> arges: waiting on the diff generation
[21:44] <cjwatson> bdmurray: *muttermutterserialisednonsense*
[21:44] <cjwatson> (it's currently processing a firefox diff, and has been for 20 minutes ...)
[22:57] <bdmurray> infinity: Could you review ubuntu-release-upgrader in wily-proposed?


[11:17] <adrien> rbasak: some time ago you said that you would probably enable the fix for deleted directories automatically; when would it be triggered? would it be post-commit?
[12:25] <sudip> I have asked in #ubuntu-bugs, but requesting here also - can anyone please mark LP: #1987073 as affecting Jammy please
[12:25] -ubottu:#ubuntu-devel- Launchpad bug 1987073 in linux-show-player (Ubuntu) "Failure to start on 22.04" [Undecided, Confirmed] https://launchpad.net/bugs/1987073
[13:18] <ginggs> sudip: .
[13:19] <sudip> thanks ginggs
[13:21] <sudip> ginggs: also, in your glibc 2.39 snapshot rebuild report I can see many packages failed to build, but there are no bug reports for many of them. is it expected that if someone is working on those ftbfs then they will file the bug first?
[13:21]  * sudip apologises in advance for the newbie question
[13:25] <rbasak> adrien: I don't recall that, sorry. Are you OK using the current workaround for now?
[13:34] <ginggs> sudip: i do not know. schopin? ^^
[13:35] <schopin> sudip: I'll send out a report tomorrow, but we've looked at those failures, and most of them are either unrelated to glibc or solved by a fresher glibc snapshot.
[13:36] <schopin> sudip: if you're impatient you can look at https://bugs.launchpad.net/ubuntu/+source/glibc/+bugs?field.tag=test-rebuild-glibc-noble for those we've identified as glibc-related.
[13:37] <schopin> And it's not a newbie question, it's perfectly legitimate to ask this :)
[13:38] <sudip> yeah, I have seen that bug list with the tag which had the link to ginggs's rebuild report and that led me to my question. so even if they are unrelated, they are still ftbfs, and quite a lot of them.
[13:39] <schopin> sure, but they were already FTBFS in the initial report for most of them, and for the others I believe ravikant_ filed bugs, just without the tag.
[13:41] <sudip> ok, thanks schopin
[13:58] <adrien> rbasak: yeah, definitely, I was just curious and also wondering if I would do such a change on my side too
[14:31] <adrien> can I ask for a review of https://code.launchpad.net/~adrien-n/ubuntu/+source/ruby3.1/+git/ruby3.1/+merge/459015 ? the issue is present in ruby3.0 < 3.0.7 (unreleased), ruby3.1 < 3.1.6 (unreleased), ruby3.2 < 3.2.3 (released 2024/01/18), ruby3.3 < 3.3.1 (unreleased)
[14:32] <adrien> all ruby tests fail due to that AFAIK; it might also make sense to put that in other ruby versions
[14:33] <adrien> just checked: jammy has 3.0 and subsequent versions have 3.1
[15:03] <philroche> LocutusOfBorg: \o We have current Ubuntu 24.04 Cloud Azure image build failures due to a recent change you uploaded for libtss2-mu-4.0.1-0 which depends on libtss2-mu0 (< 4.0.1-4) but libtss2-mu0 4.0.1-3ubuntu1 is the greatest package version in Ubuntu currently . I don't see anything in the uplaod queue. Is this something you are working on?
[15:27] <LocutusOfBorg> philroche, I wasn't
[15:27] <LocutusOfBorg> but I am now :D
[15:32] <philroche> Thank you
[15:32] <LocutusOfBorg> just question, what are you trying to install?
[15:33] <LocutusOfBorg> I see 4.0.1-7 in Debian queue, I might merge it
[15:33] <LocutusOfBorg> but I don't know if it will wolve or not
[15:33] <philroche> Attempted install of the following triggered the error: `libtss2-esys-3.0.2-0 libtss2-mu0 libtss2-rc0`
[15:33] <philroche> Error was: `The following packages have unmet dependencies:  libtss2-mu-4.0.1-0 : Breaks: libtss2-mu0 (< 4.0.1-4) but 4.0.1-3ubuntu1 is to be installed`
[15:34] <LocutusOfBorg> libtss2-mu0
[15:34] <LocutusOfBorg> who is installing that libtss2-mu0?
[15:34] <LocutusOfBorg> the package got renamed into  libtss2-mu-4.0.1-0
[15:34] <LocutusOfBorg> so no direct installations please
[15:35] <LocutusOfBorg> reverse-depends  -r noble libtss2-mu0
[15:35] <LocutusOfBorg> shows nothing
[15:35] <philroche> well that helps. Thank you.
[15:36] <philroche> Was there a similar recommendation for libtss2-rc0 ?
[15:37] <LocutusOfBorg> nope
[15:37] <philroche> I only see libtss2-rc0 for libtss2-rc* in noble
[15:37] <LocutusOfBorg> that one didn't get renamed
[15:37] <philroche> cool.
[15:37] <LocutusOfBorg> Affected: .depends ~ /\b(libtss2\-mu\-4\.0\.1\-0|libtss2\-mu0)\b/
[15:37] <LocutusOfBorg> this is what the transition says
[15:38] <philroche> That's me unblocked.
[15:38] <LocutusOfBorg> https://release.debian.org/transitions/html/auto-tpm2-tss.html
[15:38] <LocutusOfBorg> reason is that upstream broke ABI by removing one symbol used in python package
[15:38] <LocutusOfBorg> so, transition to make sure everything rebuilds
[15:38] <LocutusOfBorg> but please don't use direct packages if possible
[15:38] <philroche> +1
[15:39] <LocutusOfBorg> not sure if the -dev package can go in seeds, or if you can use some shlibs to detect such changes
[15:39] <LocutusOfBorg> sorry I don't really know that image building process :D
[15:39] <LocutusOfBorg> please ping in case I break something else
[15:39] <philroche> Using livecd-rootfs but the issue was in the closed source Azure binary hook
[15:40] <philroche> ack. Thanks for your help
[15:41] <LocutusOfBorg> so can it be adjousted, or does it need upstream to rebuild manually?
[15:41] <philroche> it can be adjusted - no action in archive required
[15:42] <LocutusOfBorg> nice to know!
[20:06] <arraybolt3> Long shot, but does anyone here have the ability to moderate the ubuntu-users list? A message of mine got stuck in moderation.
[20:12] <bdmurray> arraybolt3: oh my password still works
[20:30] <tsimonq2> ogayot: kitty is back ;) https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kitty
[20:36] <tsimonq2> wait... that didn't redir to archive-team did it hmm
[20:41] <helmut> Hi. On the Debian side, we are mitigating the effects of the /usr-move (DEP17) via https://salsa.debian.org/helmutg/dumat. I have run this tool against Ubuntu today and that results in https://subdivi.de/~helmut/ubuntu-20240125.yaml . would there be anyone interested in turning these diagnostics into actions on the Ubuntu side?
[20:43] <helmut> Quite a bit of what is detected there is also detected (and mitigated) in Debian, so that'll naturally trickle into Ubuntu, but there also is a bigger part of findings that are specific to Ubuntu and not present in Debian at all. In particular the amount of empty directory loss and the undeclared file conflicts are not to be found in Debian in that quantity
[20:43] <helmut> Back in may, I had paride perform an early test run of it, but he didn't seem to pick it up ever since.
[20:45] <tsimonq2> helmut: I think this is a great question. Could you please send an email to the ubuntu-devel list?
[20:45] <tsimonq2> In fact, I'm really curious how you set that up for Ubuntu specifically, if there is any magic.
[20:45] <helmut> tsimonq2: I am very happy to walk you through that and fixing bugs as we encounter them.
[20:46] <helmut> tsimonq2: I can also take it to email, yes.
[20:47] <helmut> tsimonq2: hw-wise running dumat requires 1 core, 1gb ram, 4gb disk space, and an unmetered connection to a full mirror.
[20:47] <helmut> I've done the full ubuntu import on my laptop today.
[20:48] <tsimonq2> Perfect, Lubuntu's sandbox server can definitely handle that.
[20:48] <helmut> if this is considered too niche for this channel, I am happy to accomodate ubuntu /usr-move discussions on oftc#debian-usrmerge
[20:49] <tsimonq2> Depends, is the setup fairly easy? (Am I just pointing mmdebstrap towards Ubuntu URIs, or is it more involved?)
[20:49] <helmut> what definitely needs tweaking for ubuntu is a little function in the analysis part called "is_supported" and I simply made it "return True" for the purpose of this report, so the size definitely is exagerated. tweaking this function is key to making the report useful
[20:50] <helmut> tsimonq2: I hope it is easy, but then I wrote it. it does not require root. running it as a dedicated useraccount is recommended. you need user namespaces + package uidmap
[20:53] <helmut> regarding adapting it to ubuntu, the archive is configured via the sqlite database. populating the "release" and "component" tables (which are otherwise treated as read-only) is key.
[20:53] <helmut> you may source my attempt at this configuration from my database dump at https://subdivi.de/~helmut/ubuntu-20240125.sql.zst
[20:54] <tsimonq2> Sounds good, I'll report back with something ASAP. :)
[20:54] <tsimonq2> (Same page re: is_supported, by the way.)
[20:55] <helmut> notably, the analysis is split into two phases: a feature extraction phase where .debs are downloaded analyzed and the results are stored in this database, and the actual analysis phase that only consumes the database and generates the report. in particular, this allows you to tweak the analysis without downloading lots of crap
[20:55] <helmut> the analysis runs in less than a minute on a fast cpu. so you can really iterate that and that is what contains "is_supported"
[20:57] <helmut> you'll notice that dumat will fail to import zstd-compressed .debs. this is fixed in a feature branch of the submodule, but cannot be merged yet, because I cannot require >= bookworm yet. just checkout switch the submodule to the feature branch
[20:58] <helmut> I expect that the feature extraction part (import_mirror.py + import_diversion.py) will just work for ubuntu, but the analysis.py (which also associates reported bugs) will need changes
[21:00] <helmut> before setting up a dumat instance, you might want to check that example yaml given first whether you find the report useful
[21:01] <helmut> maybe some of the problems that I see on the Debian side are considered non-problems for Ubuntu or you consider certain upgrade-paths as unsupported and so on.
[21:01] <tsimonq2> The only improvement I would do right off the bat (I'll send patches ... somewhere ... hopefully :) ) is adding a packageset.
[21:01] <tsimonq2> Plus, Lunar is EOL as of today, so I'll exclude that from my end.
[21:02] <helmut> sure, it can be deleted. I wasn't sure, so I included it
[21:03] <helmut> also it may not be clear to the uninitiated what these short "what: ..." descriptions mean in detail. I am happy to help with that
[21:03] <helmut> "what: undeclared file conflict" should be fairly clear though ;)
[21:05] <helmut> you may wonder why these are reported. undeclared file conflicts typically result in the addition of Replaces and Replaces may be rendered dysfunctional by the /usr-move. thus, missing Replaces may shadow a /usr-move problem
[21:06] <helmut> tsimonq2: any remaining questions for now?
[21:07] <tsimonq2> helmut: Where does the hash come from in the component table?
[21:07] <helmut> insert NULL. it's the hash of the current list from the dists/ folder
[21:07] <helmut> I lied about components being read-only
[21:08] <tsimonq2> okay :) then no, nothing else from me at the moment
[21:08] <helmut> good luck. do you still need a ubuntu-devel mail?
[21:08] <tsimonq2> I'll check back before tomorrow beginning of day with a link for you, I'd like someone from Canonical QA to help me put that somewhere more permanent. I'll likely be writing something easier to populate these two tables.
[21:09] <helmut> yeah, the plumbing isn't the best. dumat hasn't been set up that often (-:
[21:09] <tsimonq2> I'm really curious where you get your code style from ;)
[21:10] <helmut> mostly black + pylint
[21:11] <tsimonq2> ah okay :)(
[21:11] <tsimonq2> *:)
[21:11] <helmut> I am happy to rework it as needed, but thus far this code mainly had only one user.
[21:13] <helmut> tsimonq2: please highlight me for question or ask them over at the debian channel. I won't be following this channel actively.
[21:14] <tsimonq2> helmut: Will do :) thanks
[22:19] <dannf> Is there a way to trigger an autopkgtest to run with a specific kernel? i.e. install the kernel, reboot, and then start the test? Or does that require modifying the test to use the reboot protocol?
[22:31] <kajiya> I know there are no `pilots` in atm, but if anyone's got cycles can I get an upload to noble please? The bug's here: https://bugs.launchpad.net/ubuntu/+source/google-guest-agent/+bug/2050956
[22:31] -ubottu:#ubuntu-devel- Launchpad bug 2050956 in google-guest-agent (Ubuntu Noble) "Update d/control file with dependencies" [Undecided, New]
[22:40] <tsimonq2> kajiya: I gotcha, sec
[22:41] <kajiya> Cheers tsimonq2 :D
[22:43] <tsimonq2> kajiya: I'll sponsor, could you just throw this ( https://wiki.ubuntu.com/google-guest-agent-Updates ) in the desc like last time? https://bugs.launchpad.net/ubuntu/+source/google-guest-agent/+bug/2040945
[22:43] -ubottu:#ubuntu-devel- Launchpad bug 2040945 in google-guest-agent (Ubuntu Mantic) "[SRU] Update and backport google-guest-agent to 20231004.02" [Undecided, Fix Released]
[22:43] <tsimonq2> :)
[22:44] <kajiya> Ah my bad, I'll do that now :D
[22:48] <kajiya> All done!
[22:48] <tsimonq2> kajiya: And same :D https://launchpad.net/ubuntu/+source/google-guest-agent/20231004.02-0ubuntu2
[22:48] <tsimonq2> Sorry, I'm still less-fast with Git-based packaging ;)
[22:49] <kajiya> Thank you so much :D And don't worry, you're still faster than me xD
[22:50] <tsimonq2> Happy to help, I'll be floating around if you need help getting this to the release pocket :)
[22:51] <kajiya> I'll keep that in mind, thanks again for the help :D
[22:51] <tsimonq2> Of course!


[00:14] <Ukikie> vorlon, Laney: Hey, would you guys like to try out ubot3 in here?  It's a clone like ubot5, but has support for gitlab/github issues as well as commits from those and cgit (though that can be turned off.)
[01:04] <teward> ummmmm.... 20.04.1's zsync for server ISOs seems... wrong/bad...
[01:04] <teward> zsync says it can't parse it and it's straight binary data
[01:05] <teward> neither of the zsync files work
[01:05] <teward> for 20.04.1
[01:05] <teward> is that normal?
[01:08] <teward> nevermind sounds like an HTTPS problem >.>
[02:35] -queuebot:#ubuntu-release- New binary: xfce4-settings [s390x] (hirsute-proposed/universe) [4.15.2-2ubuntu1] (xubuntu)
[02:36] -queuebot:#ubuntu-release- New binary: xfce4-settings [ppc64el] (hirsute-proposed/universe) [4.15.2-2ubuntu1] (xubuntu)
[02:37] -queuebot:#ubuntu-release- New binary: xfce4-settings [amd64] (hirsute-proposed/universe) [4.15.2-2ubuntu1] (xubuntu)
[02:39] -queuebot:#ubuntu-release- New binary: xfce4-settings [arm64] (hirsute-proposed/universe) [4.15.2-2ubuntu1] (xubuntu)
[02:45] -queuebot:#ubuntu-release- New binary: xfce4-settings [armhf] (hirsute-proposed/universe) [4.15.2-2ubuntu1] (xubuntu)
[05:17] -queuebot:#ubuntu-release- New binary: libcommonmark-perl [ppc64el] (hirsute-proposed/none) [0.290000-1] (no packageset)
[05:17] -queuebot:#ubuntu-release- New binary: wtype [ppc64el] (hirsute-proposed/none) [0.2-1] (no packageset)
[05:17] -queuebot:#ubuntu-release- New binary: libnet-dns-native-perl [ppc64el] (hirsute-proposed/none) [0.22-1] (no packageset)
[05:17] -queuebot:#ubuntu-release- New binary: wtype [s390x] (hirsute-proposed/none) [0.2-1] (no packageset)
[05:18] -queuebot:#ubuntu-release- New binary: aravis [s390x] (hirsute-proposed/universe) [0.8.1-1] (no packageset)
[05:18] -queuebot:#ubuntu-release- New binary: fcitx5-chewing [s390x] (hirsute-proposed/none) [5.0.1-1] (no packageset)
[05:18] -queuebot:#ubuntu-release- New binary: fcitx5-chewing [ppc64el] (hirsute-proposed/none) [5.0.1-1] (no packageset)
[05:18] -queuebot:#ubuntu-release- New binary: libnet-dns-native-perl [amd64] (hirsute-proposed/none) [0.22-1] (no packageset)
[05:19] -queuebot:#ubuntu-release- New binary: aravis [ppc64el] (hirsute-proposed/universe) [0.8.1-1] (no packageset)
[05:19] -queuebot:#ubuntu-release- New binary: php-league-mime-type-detection [amd64] (hirsute-proposed/universe) [1.5.1+ds-1] (no packageset)
[05:19] -queuebot:#ubuntu-release- New binary: libcommonmark-perl [amd64] (hirsute-proposed/universe) [0.290000-1] (no packageset)
[05:19] -queuebot:#ubuntu-release- New binary: wtype [amd64] (hirsute-proposed/universe) [0.2-1] (no packageset)
[05:20] -queuebot:#ubuntu-release- New binary: libcommonmark-perl [s390x] (hirsute-proposed/universe) [0.290000-1] (no packageset)
[05:20] -queuebot:#ubuntu-release- New binary: libnet-dns-native-perl [s390x] (hirsute-proposed/universe) [0.22-1] (no packageset)
[05:21] -queuebot:#ubuntu-release- New binary: aravis [amd64] (hirsute-proposed/universe) [0.8.1-1] (no packageset)
[05:22] -queuebot:#ubuntu-release- New binary: node-make-error [amd64] (hirsute-proposed/universe) [1.3.6-1] (no packageset)
[05:23] -queuebot:#ubuntu-release- New binary: fcitx5-chewing [amd64] (hirsute-proposed/universe) [5.0.1-1] (no packageset)
[05:23] -queuebot:#ubuntu-release- New binary: ruby-terser [amd64] (hirsute-proposed/universe) [1.0.2+dfsg-1] (no packageset)
[05:26] -queuebot:#ubuntu-release- New binary: wtype [riscv64] (hirsute-proposed/universe) [0.2-1] (no packageset)
[05:28] -queuebot:#ubuntu-release- New binary: libcommonmark-perl [riscv64] (hirsute-proposed/universe) [0.290000-1] (no packageset)
[05:28] -queuebot:#ubuntu-release- New binary: libnet-dns-native-perl [riscv64] (hirsute-proposed/universe) [0.22-1] (no packageset)
[05:30] -queuebot:#ubuntu-release- New binary: fcitx5-chewing [riscv64] (hirsute-proposed/universe) [5.0.1-1] (no packageset)
[05:35] -queuebot:#ubuntu-release- New binary: fcitx5-chewing [armhf] (hirsute-proposed/universe) [5.0.1-1] (no packageset)
[05:35] -queuebot:#ubuntu-release- New binary: wtype [armhf] (hirsute-proposed/universe) [0.2-1] (no packageset)
[05:37] -queuebot:#ubuntu-release- New binary: libcommonmark-perl [arm64] (hirsute-proposed/universe) [0.290000-1] (no packageset)
[05:37] -queuebot:#ubuntu-release- New binary: wtype [arm64] (hirsute-proposed/universe) [0.2-1] (no packageset)
[05:37] -queuebot:#ubuntu-release- New binary: libcommonmark-perl [armhf] (hirsute-proposed/universe) [0.290000-1] (no packageset)
[05:37] -queuebot:#ubuntu-release- New binary: libnet-dns-native-perl [arm64] (hirsute-proposed/universe) [0.22-1] (no packageset)
[05:38] -queuebot:#ubuntu-release- New binary: fcitx5-chewing [arm64] (hirsute-proposed/universe) [5.0.1-1] (no packageset)
[05:39] -queuebot:#ubuntu-release- New binary: libnet-dns-native-perl [armhf] (hirsute-proposed/universe) [0.22-1] (no packageset)
[05:44] -queuebot:#ubuntu-release- New binary: aravis [armhf] (hirsute-proposed/universe) [0.8.1-1] (no packageset)
[05:44] -queuebot:#ubuntu-release- New binary: aravis [arm64] (hirsute-proposed/universe) [0.8.1-1] (no packageset)
[05:46] -queuebot:#ubuntu-release- New binary: aravis [riscv64] (hirsute-proposed/universe) [0.8.1-1] (no packageset)
[05:50] -queuebot:#ubuntu-release- New binary: xfce4-settings [riscv64] (hirsute-proposed/universe) [4.15.2-2ubuntu1] (xubuntu)
[07:40] -queuebot:#ubuntu-release- New: accepted aravis [arm64] (hirsute-proposed) [0.8.1-1]
[07:40] -queuebot:#ubuntu-release- New: accepted aravis [riscv64] (hirsute-proposed) [0.8.1-1]
[07:40] -queuebot:#ubuntu-release- New: accepted fcitx5-chewing [armhf] (hirsute-proposed) [5.0.1-1]
[07:40] -queuebot:#ubuntu-release- New: accepted libcommonmark-perl [arm64] (hirsute-proposed) [0.290000-1]
[07:40] -queuebot:#ubuntu-release- New: accepted libcommonmark-perl [riscv64] (hirsute-proposed) [0.290000-1]
[07:40] -queuebot:#ubuntu-release- New: accepted libnet-dns-native-perl [armhf] (hirsute-proposed) [0.22-1]
[07:40] -queuebot:#ubuntu-release- New: accepted ruby-terser [amd64] (hirsute-proposed) [1.0.2+dfsg-1]
[07:40] -queuebot:#ubuntu-release- New: accepted wtype [armhf] (hirsute-proposed) [0.2-1]
[07:40] -queuebot:#ubuntu-release- New: accepted xfce4-settings [riscv64] (hirsute-proposed) [4.15.2-2ubuntu1]
[07:40] -queuebot:#ubuntu-release- New: accepted aravis [armhf] (hirsute-proposed) [0.8.1-1]
[07:40] -queuebot:#ubuntu-release- New: accepted fcitx5-chewing [riscv64] (hirsute-proposed) [5.0.1-1]
[07:40] -queuebot:#ubuntu-release- New: accepted libnet-dns-native-perl [arm64] (hirsute-proposed) [0.22-1]
[07:40] -queuebot:#ubuntu-release- New: accepted wtype [arm64] (hirsute-proposed) [0.2-1]
[07:40] -queuebot:#ubuntu-release- New: accepted fcitx5-chewing [arm64] (hirsute-proposed) [5.0.1-1]
[07:40] -queuebot:#ubuntu-release- New: accepted libnet-dns-native-perl [riscv64] (hirsute-proposed) [0.22-1]
[07:40] -queuebot:#ubuntu-release- New: accepted libcommonmark-perl [armhf] (hirsute-proposed) [0.290000-1]
[07:40] -queuebot:#ubuntu-release- New: accepted wtype [riscv64] (hirsute-proposed) [0.2-1]
[07:40] -queuebot:#ubuntu-release- New: accepted aravis [amd64] (hirsute-proposed) [0.8.1-1]
[07:40] -queuebot:#ubuntu-release- New: accepted aravis [s390x] (hirsute-proposed) [0.8.1-1]
[07:40] -queuebot:#ubuntu-release- New: accepted bazel-bootstrap [arm64] (hirsute-proposed) [3.4.0+ds-2]
[07:40] -queuebot:#ubuntu-release- New: accepted bazel-bootstrap [s390x] (hirsute-proposed) [3.4.0+ds-2]
[07:40] -queuebot:#ubuntu-release- New: accepted fcitx5-chewing [ppc64el] (hirsute-proposed) [5.0.1-1]
[07:40] -queuebot:#ubuntu-release- New: accepted libcommonmark-perl [amd64] (hirsute-proposed) [0.290000-1]
[07:40] -queuebot:#ubuntu-release- New: accepted libcommonmark-perl [s390x] (hirsute-proposed) [0.290000-1]
[07:40] -queuebot:#ubuntu-release- New: accepted libnet-dns-native-perl [ppc64el] (hirsute-proposed) [0.22-1]
[07:40] -queuebot:#ubuntu-release- New: accepted node-make-error [amd64] (hirsute-proposed) [1.3.6-1]
[07:40] -queuebot:#ubuntu-release- New: accepted wtype [amd64] (hirsute-proposed) [0.2-1]
[07:40] -queuebot:#ubuntu-release- New: accepted aravis [ppc64el] (hirsute-proposed) [0.8.1-1]
[07:40] -queuebot:#ubuntu-release- New: accepted bazel-bootstrap [ppc64el] (hirsute-proposed) [3.4.0+ds-2]
[07:40] -queuebot:#ubuntu-release- New: accepted fcitx5-chewing [s390x] (hirsute-proposed) [5.0.1-1]
[07:40] -queuebot:#ubuntu-release- New: accepted libnet-dns-native-perl [amd64] (hirsute-proposed) [0.22-1]
[07:40] -queuebot:#ubuntu-release- New: accepted php-league-mime-type-detection [amd64] (hirsute-proposed) [1.5.1+ds-1]
[07:40] -queuebot:#ubuntu-release- New: accepted wtype [s390x] (hirsute-proposed) [0.2-1]
[07:40] -queuebot:#ubuntu-release- New: accepted xfce4-settings [arm64] (hirsute-proposed) [4.15.2-2ubuntu1]
[07:40] -queuebot:#ubuntu-release- New: accepted xfce4-settings [ppc64el] (hirsute-proposed) [4.15.2-2ubuntu1]
[07:40] -queuebot:#ubuntu-release- New: accepted bazel-bootstrap [amd64] (hirsute-proposed) [3.4.0+ds-2]
[07:40] -queuebot:#ubuntu-release- New: accepted libcommonmark-perl [ppc64el] (hirsute-proposed) [0.290000-1]
[07:40] -queuebot:#ubuntu-release- New: accepted wtype [ppc64el] (hirsute-proposed) [0.2-1]
[07:40] -queuebot:#ubuntu-release- New: accepted xfce4-settings [armhf] (hirsute-proposed) [4.15.2-2ubuntu1]
[07:40] -queuebot:#ubuntu-release- New: accepted fcitx5-chewing [amd64] (hirsute-proposed) [5.0.1-1]
[07:40] -queuebot:#ubuntu-release- New: accepted xfce4-settings [amd64] (hirsute-proposed) [4.15.2-2ubuntu1]
[07:40] -queuebot:#ubuntu-release- New: accepted libnet-dns-native-perl [s390x] (hirsute-proposed) [0.22-1]
[07:41] -queuebot:#ubuntu-release- New: accepted xfce4-settings [s390x] (hirsute-proposed) [4.15.2-2ubuntu1]
[10:26] <doko> how did the autopkg queues go down from 3000-6000 to <1000 within two hours?
[10:27] <Laney> I really purged those jobs I said I purged yesterday and actually didn't
[10:33] <doko> Laney: please could you also give back all the /unkown ones?
[10:34] <Laney> I think all the in progress or regression perls should be retried, will do that shortly
[10:35] <doko> ta
[10:38] <Laney> doing
[11:34] <doko> the queues look "better" again, 4k+ ;p
[12:18] -queuebot:#ubuntu-release- Unapproved: busybox (groovy-proposed/main) [1:1.30.1-4ubuntu9 => 1:1.30.1-4ubuntu9.1] (core, i386-whitelist)
[12:29] <juliank> Laney: Seems armhf caught up now, so I'll retire the additional lxd remote
[12:32] <Laney> okey
[12:32] <doko> I wouldn't mind if the armhf queue gets empty earlier, then you can retry armhf stuff which fails under load
[12:34] <doko> mwhudson: the execuses_by_team report now has some very long "Requires:" lines ... maybe you could only list the first few ones, and then refer to update_excuses?
[12:34] <juliank> Laney: I removed it from lxd remotes and ran juju set, will the workers go away automatically eventually?
[12:34] <juliank> I should probably send them SIGHUP
[12:35] <Laney> unlikely
[12:35] <Laney> well, they go away if the socat one does iirc
[12:35] <Laney> stop, reset-failed, disable that one, then see what happens
[12:35] <doko> do you know how the i386 hints are normally handled?
[12:35] <Laney> might hav eto do that for the workers too
[12:35] <Laney> that stuff is buggy
[12:36] <Laney> doko: by vorlon usually, not sure if there's a script
[12:40] <juliank> If I keep the lxd worker instance around as stopped, does that affect our quota?
[12:40] <Laney> yep
[12:41] <juliank> OK, all arm stuff should be back to its usual self
[12:42] <juliank> doko: failures under load should be ignored not retried, full load is what we're aiming for anyway
[12:43] <juliank> Like once we have continuous baseline retesting, workers will be fully loaded all the time
[12:43] <Laney> juliank: which one did you delete, 45.21?
[12:43] <juliank> yes
[12:43] <Laney> units are still there
[12:44] <Laney> probably need to smite them manually
[12:44] <Laney> think the new implementation fixes that ... I started rebasing that the other day
[12:44] <juliank> Laney: They are disabled however, it should just be systemd remnants that need cleaning
[12:45] <juliank> well confusing stuff
[12:45] <juliank> they certainly were stopped but now are running again
[12:45] <doko> juliank: you're aiming for overload, not full load
[12:45] <Laney> make sure to disable them
[12:46] -queuebot:#ubuntu-release- Unapproved: busybox (focal-proposed/main) [1:1.30.1-4ubuntu6.2 => 1:1.30.1-4ubuntu6.3] (core, i386-whitelist)
[12:47] <juliank> Seem gone now
[12:47] <juliank> The worker processes got stuck
[12:48] <juliank> doko: well we want full load on our configuration, but that is overload of the quota
[12:48] <juliank> :D
[12:57] <rbalint> Laney, has there been a mass badtest hinting for the i386 false passes due to using amd64?
[12:57] <rbalint> Laney, if not i prep one
[12:57] <Laney> no, that would be welcome, it should be only bumping of previous hints I guess
[13:04] <rbalint> Laney, no, there are many missing hints see https://code.launchpad.net/~rbalint/britney/+git/hints-ubuntu/+merge/393510
[13:11] <Laney> rbalint: please scan the file, some of those are already in there and should be bumped, and in general I would prefer force-reset-test for these
[13:11] <rbalint> Laney, why?
[13:11] <Laney> why to which part?
[13:12] <Laney> if the latter, because we *accidentally* ran these and this is closest to pretending that didn't happen
[13:12] <rbalint> why preferring force-reset-test over badtesting all/i386
[13:13] <rbalint> Laney, even triggering the tests that did not pass in focal on i386 is a waste of resources
[13:15] <Laney> even if that's right, force-badtest vs force-reset-test doesn't help there
[13:15] <rbalint> Laney, they are dead, Jim :-)
[13:15] <Laney> they are executed anyway
[13:15] <rbalint> Laney, not now, but i'll propose not triggering badtests by default in a different topic
[13:16] <rbalint> Laney, for all arches
[13:17] <rbalint> Laney, but running periodic full-archive tests in an additional queue for tests not triggered for a long time
[13:17] <Laney> if we get to that point, we would want to evaluate the hints then
[13:17] <Laney> right
[13:18] <Laney> don't go rogue on that plan but implement it in consultation with the rest of us
[13:18] <Laney> it's been discussed with juliank and vorlon for a long time
[13:18] <rbalint> Laney, i can't is don't have a separate queue :-)
[13:18] <rbalint> Laney, the right step now is marking the false positive tests on i386 consistently, so the next steps will be easier
[13:20] <Laney> I don't think it holds that these ones should be picked for skipping forever because we accidentally ran them in this short period, the analysis needs to be more sophisticated than that
[13:20] <rbalint> Laney, bumping reset tests is just an ad-hoc patch over the false positives
[13:20] <Laney> please let's just use reset-test, and discuss your other idea in a measured way
[13:20] <Laney> rather than mixing the two things
[13:21] <Laney> gotta go eat lunch now
[14:09] <rbalint> Laney, LP: #1903867
[14:10] <rbalint> Laney, i'm away for the afternoon, feel free to bump the tests
[15:39] <Laney> rbalint: cheers
[15:39] <Laney> and if you want to work on those other ideas, maybe schedule calls and we can chat about how that would be best to do
[15:53] <juliank> ugh
[15:53] <juliank> I'm building stuff in autopkgtest and it's not building in parallel
[15:53] <juliank> ah now that I complain it's finishing
[16:08] <vorlon> Laney, doko: there's some scripting (present as a comment in the ubuntu-release hint file) to handle i386 hints that are auto-detectable (but that britney doesn't correctly auto-detect), i.e. the only binary on i386 is arch: all.  Otherwise it's manual.
[16:11] <Laney> nod
[16:11] <Laney> meanwhile I'll assume rbalint's list is correct and hint all of those :-)
[16:19] <vorlon> :)
[17:05] -queuebot:#ubuntu-release- Unapproved: grub2 (hirsute-proposed/main) [2.04-1ubuntu36 => 2.04-1ubuntu36] (core)
[17:25] -queuebot:#ubuntu-release- Unapproved: grub2 (hirsute-proposed/main) [2.04-1ubuntu36 => 2.04-1ubuntu36] (core)
[17:25] -queuebot:#ubuntu-release- New binary: ruby-simpleidn [amd64] (hirsute-proposed/universe) [0.1.1-1] (no packageset)
[17:25] -queuebot:#ubuntu-release- New binary: ycm-cmake-modules [amd64] (hirsute-proposed/universe) [0.12.0-1] (no packageset)
[17:44] -queuebot:#ubuntu-release- Unapproved: darktable (groovy-proposed/universe) [3.2.1-2build2 => 3.2.1-3~ubuntu<IP_ADDRESS>] (ubuntustudio)
[17:45] <Eickmeyer[m]> ^ SRU bug 1903892
[18:24] -queuebot:#ubuntu-release- New binary: llvm-toolchain-11 [armhf] (focal-proposed/universe) [1:11.0.0-2~ubuntu20.04.1] (i386-whitelist)
[18:38] <mwhudson> doko: i dispute the idea that because i worked on the first version of this script, i am responsible for it forever
[19:13] <doko> mwhudson: heh ...
[19:20] <rbalint> Laney, thanks for the hints
[19:21] <rbalint> Laney, could you please check my hints again? https://code.launchpad.net/~rbalint/britney/+git/hints-ubuntu/+merge/393626
[19:21] <rbalint> Laney, they contained other hints than just the i386 ones
[20:18] -queuebot:#ubuntu-release- New binary: llvm-toolchain-11 [arm64] (focal-proposed/universe) [1:11.0.0-2~ubuntu20.04.1] (i386-whitelist)
[21:04] <rbalint> vorlon, Laney, juliank, doko about 5-10% of load reduction would be the result of skipping never passing tests LP: #1903913
[21:05] <juliank> rbalint: we have to try them eventually otherwise we won't notice once they start working
[21:05] <rbalint> juliank, please see the bug, also there is not much to loose not noticing that quickly
[21:06] <juliank> rbalint: force-badtest ignoring is ok IMO, though we should try running the tests at least once a month or so
[21:07] <rbalint> juliank, yes, i'm proposing that
[21:07] <juliank> Well if we run them at least once a month, we can ignore all always failed tests
[21:07] <juliank> Without having to rely on continuous baseline retesting
[21:07] <rbalint> juliank, yes
[21:07] <juliank> Just have britney only schedule the test for an always-failed if it had no results for a month, essentially
[21:08] <rbalint> retesting everything is ~1200h on amd64 and ~3000h on arm64
[21:08] <rbalint> juliank, yes, and having a separate queue for that
[21:08] <juliank> rbalint: not a separate queue, no
[21:08] <rbalint> juliank, why?
[21:08] <rbalint> then which queue
[21:08] <juliank> The separate queue for the baseline retest
[21:09] <juliank> But I'm talking about the normal tests
[21:09] <juliank> e.g. foo has always failed
[21:09] <juliank> Bar triggers foo gets scheduled if we haven't run foo tests in a month
[21:09] <juliank> This avoids having to deal with the complicated continuous baseline retesting bits and extra queues
[21:10] <juliank> As an intermediate solution until we have baseline retesting, at which point we don't need that :(
[21:10] <juliank> Um :)
[21:10] <rbalint> if this is easier to implement, i like that
[21:10] <rbalint> bileto can always skip those
[21:11] <juliank>  Depends on whether britney has the data for it
[21:11] <rbalint> juliank, imo the force-badtest data is good for that
[21:11] <juliank> That one is easy I guess
[21:12] <rbalint> do we have a plan? ;-)
[21:12] <juliank> But also doing that for any test that is always failed and not run in a month would be more effective.
[21:12] <juliank> The question here is whether britney knows when a test last ran
[21:12] <juliank> Or whether it only knows that the test always failed
[21:12] <rbalint> autopkgtest.db does not seem to have dates
[21:13] <juliank> I think it downloads the database from autopkgtesr
[21:13] <juliank> Hmm
[21:13] <juliank> Id expect there to be a timestamp given that we see dates in the histor
[21:14] <rbalint> juliank, hm, it is encoded in run_id
[21:14] <rbalint> so that would work :-)
[21:15] <juliank> Now write a merge proposal :)
[21:16] <juliank> Also I have to have another look at britney triggers
[21:16] <rbalint> i hopes someone more familiar with britney would do it ;-)
[21:16] <juliank> Because it adds triggers that are in release pocket and that makes stuff noisy
[21:17] <juliank> Like tests had 20 triggers for perl migration but all I looked at ex perl where in release pocket
[21:18] <juliank> And due to how this is implemented in autopkgtest, it might even lead to false results, certainly the version was ignored somewhat in the past, so it might pick proposed versions instead of the specified release one
[21:20] <rbalint> juliank, i can just agree :-) LP: #1897317
[21:22] <rbalint> vorlon, doko unfortunately i need to upload glibc again, because the -prof changes FTBFS on riscv64, unless we can push in a binary version from bileto
[21:22] <vorlon> rbalint: well pushing binary versions from bileto is certainly allowed; it just doesn't avoid retriggering auotpkgtests
[21:23] <rbalint> vorlon, i mean a binary version only for riscv64
[21:23] <vorlon> I don't follow how you would do that
[21:23] <vorlon> is it the same source version as in the archive?
[21:24] <rbalint> vorlon, i'd fix the source in bileto with the same version, build only for riscv64, copy the binaries
[21:24] <vorlon> yeah no :)
[21:24] <rbalint> vorlon, i can do it with the same source, but patched dpkg
[21:24] <vorlon> you can't copy binaries unless the source matches, and the source won't match
[21:25] <vorlon> why wouldn't that be solved then by publishing the patched dpkg to the main archive and retrying the riscv64 build there?
[21:26] <rbalint> because that dpkg would just add a hack to fix up the riscv build in glibc :-)
[21:26] <rbalint> it is not failing tests, it is a mistake in the packaging of glibc
[21:27] <rbalint> definitely cheating
[21:29] <rbalint> but i don't really want to do that, i'd rather have the test skipping logic in place as discussed above then land glibc normally with 5-10% less triggered tests
[21:30] <vorlon> rbalint: yeah, please no bileto builds that depend on build-deps that aren't going to the archive
[21:30] <vorlon> as convenient as it might be
[21:31] <vorlon> anyway, it's riscv64, so even publishing source to the main archive and building on all archs and running tests will probably finish before riscv64 build completes ;P
[21:32] <rbalint> vorlon, the riscv build became quite quick with the dpkg really passing nocheck, it is on par with arm64 :-)
[21:33] <rbalint> vorlon, so how do you like juliank's ideas about the test skipping logic for fixing LP: #1903913 ?
[21:34] <rbalint> vorlon, i think they would be quick and efficient with an immedate return on next glibc upload
[21:35] <vorlon> rbalint: I'll have to look at that later, sorry
[21:36] <rbalint> vorlon, thanks, i'm EOD-ing anyway
[21:37] <tjaalton> new intel-microcode breaks dell systems https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1903883
[21:45] <juliank>   LG
[22:07] <vorlon> bdmurray, Laney: fwiw I fixed cron.NBS by cowboying archive-cruft-check back to python2.7; it depends on apt_pkg.version_compare for sorting, and I don't know of a python3-compatible key= equivalent
[22:18] <mwhudson> vorlon: the
[22:19] <mwhudson> vorlon: there's functools.cmp2key or something
[22:19] <mwhudson> vorlon: https://docs.python.org/3.8/library/functools.html#functools.cmp_to_key
[22:20] <mwhudson> (not the finest bit of python 3 design work)
[22:41] <vorlon> mwhudson: ah cheers
[22:54] <vorlon> mwhudson: looks like that does the trick
[23:17] -queuebot:#ubuntu-release- New binary: ruby-simpleidn [amd64] (hirsute-proposed/universe) [0.1.1-2] (no packageset)
[23:27] -queuebot:#ubuntu-release- New binary: dcmtk [s390x] (hirsute-proposed/universe) [3.6.5-1] (ubuntustudio)
[23:35] -queuebot:#ubuntu-release- New binary: dcmtk [ppc64el] (hirsute-proposed/universe) [3.6.5-1] (ubuntustudio)
[23:40] -queuebot:#ubuntu-release- New binary: dcmtk [amd64] (hirsute-proposed/universe) [3.6.5-1] (ubuntustudio)


[12:53] <schopin> at_work: it is the right place to ask, it just happens that a lot of people are travelling at the moment (Ubuntu Summit)


[05:55] <pabs3> infinity: lets discuss here. the 12.04.2 alternate installer seems to have dropped the ability to preseed base-installer/kernel/image to something that is release-agnostic, the only options (this is for precise) now are linux-generic-lts-quantal linux-image-generic-lts-quantal and linux-image-3.5.0-23-generic
[05:55] <pabs3> we were preseeding linux-server before, which works with 12.04 and 12.04.1
[05:55] <infinity> pabs3: linux-server should still work...
[05:56] <infinity> pabs3: Oh, do you mean the ISO?
[05:56] <pabs3> yeah, we remaster the iso
[05:56] <infinity> pabs3: If you're remastering the ISO, remaster it with the right d-i bits.
[05:57] <infinity> http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-amd64/current/images/
[05:57] <infinity> pabs3: ^-- Note /cdrom/ and /quantal-cdrom/
[05:58] <infinity> pabs3: The first uses the 3.2.0 kernel (what you'd get with linux-server or linux-generic), the second uses the HWE kernel (linux-generic-lts-quantal)
[05:59] <pabs3> sounds a lot more complicated than what we are currently doing (preseed file plus adjusting some names)
[05:59] <infinity> Well, you could keep using the 12.04.1 media, if you don't want to actually remaster completely.
[06:00] <pabs3> yeah, thats the current solution
[06:00] <infinity> Honestly, I'm shocked to find anyone uses ISOs instead of PXE for this sort of thing. :P
[06:00]  * pabs3 too :)
[06:00] <infinity> The world never ceases to amaze me.
[06:02] <pabs3> that said, we rely on non-techs to do installs at customer sites, a CD works better than having to add install infra at every install site
[06:02] <infinity> Yeah, that's fair for one-offs.
[06:02] <infinity> I was picturing a more datacetery sort of thing.
[06:02] <infinity> Where I still hear some people put CDs into CD drives.
[06:02] <infinity> And then I die a little inside.
[06:03] <pabs3> :)
[06:04] <infinity> Anyhow, remastering with different d-i bits and different packages isn't enormously difficult, but it's also not entirely trivial.  So, using the old media is certainly the simpler way to go, and it's not like upgrading at the end of the install is a huge deal.
[06:04] <infinity> Gets lost in the noise in 3 months anyway, when there've been a bunch of SRUs past .2
[06:04] <pabs3> its a bit slow on ADSL connections but yeah, not a huge deal
[06:05] <infinity> Oh, right.  Australia.
[06:05] <infinity> Maybe I can ship you some CDs with SRUs on them.
[06:05] <infinity> Or possibly some DAT tapes.
[06:05] <pabs3> :)
[06:06] <pabs3> will stick with 12.04.1 media until the next release upgrade
[06:09] <infinity> pabs3: The "what did I do now?" comment was that you said something about our kernel practices, just as I'd been in the process of urgent kernel security releases for the second time in a week.
[06:10] <infinity> pabs3: So, I was somewhat curious if I'd just broken your computer or something. :P
[06:10] <pabs3> I see :)
[06:11] <pabs3> I got a bit confused at a precise iso talking about quantal kernel images, its understandable now
[06:15] <infinity> It gets so much scarier.  There's also a full backport of the X/mesa/dri stack from quantal in 12.04.2
[06:15] <infinity> Because this was the only sane(?) way to support new hardware.
[06:16] <infinity> So, yeah, people who want the old kernel and the old X stack should just stick with 12.04.1 forever, or master their own media.
[06:16] <infinity> Or netboot.
[07:40] <hychen> Does iso-scan of ubuntu-installer  support NTFS filesystem?
[10:21] <psivaa> cjwatson: Reported bug 1133199 for tomcat server installation failures, due to unmet dependencies. Would be helpful if you could reassign it to the server team if appropriate
[10:22] <ubot2> Launchpad bug 1133199 in debian-installer (Ubuntu) "Unmet dependancies fail to install raring tomcat server " [Undecided,New] https://launchpad.net/bugs/1133199
[10:36] <cjwatson> psivaa: sure, fixing
[10:36] <psivaa> cjwatson: thanks
[10:38] <xnox> cjwatson: i see.
[10:38] <xnox> thanks.
[10:38] <cjwatson> psivaa: in general various things are broken today - I suggest not bothering to report bugs about individual image weirdnesses
[10:38] <cjwatson> (for today)
[10:39] <psivaa> cjwatson: ack, thanks
[10:39] <cjwatson> looks like I'm going to be spending my morning auditing differences and respinning
[10:40] <cjwatson> (I ported another chunk of cdimage to unit-tested Python; this should improve things in the future but there are some temporary teething troubles)
[10:41] <cjwatson> in particular the bridge between the bits of cdimage that are still in shell and the bits that are now in Python is a bit wonky
[10:42] <cjwatson> converting it all at once would have been easier in that sense but would also have been logistically impossible to land :)


[01:52] <Moon_Cheetah> 早~
[01:55] <penghuan> happyaron: 关于在系统中添加识别ubuntukylin的配置文件的事进展怎么样，系统中“Ubuntu”字样的替换还没进展
[02:43] <ypwong> 软件中心直接推荐 steam 就好啦
[02:44] <ypwong> 去 valve 官网下太饶了
[02:58] <freeflying> ypwong: lol
[03:02] <ypwong> freeflying, hey
[03:02] <ypwong> how's life?
[03:03] <freeflying> ypwong: lits good, can't complain anything
[03:03] <freeflying> ypwong: so you back?
[03:03] <ypwong> awesome
[03:03] <ypwong> not yet
[03:04] <ypwong> but soon
[03:04] <freeflying> ypwong: cool, maybe I'll see you in hk soon :)
[03:04] <ypwong> freeflying, what event?
[03:05] <freeflying> ypwong: no event
[03:05] <ypwong> freeflying, hk is too congested now
[03:06] <freeflying> ypwong: heh, come back to Beijing
[03:06] <freeflying> ypwong: you'll have more space
[03:06] <ypwong> yes i want to
[03:07] <freeflying> ypwong: compare with Macao, HK is ok la
[03:07] <ypwong> 不敢出去，会被挤死
[03:07] <ypwong> macao has far fewer population
[03:07] <ypwong> and tourists
[03:14] <freeflying> ypwong: I don't think so, its getting more and more crowded in Macao too
[03:14] <freeflying> ypwong: even worse than hk now
[03:15] <ypwong> that's crazy
[03:17] <freeflying> ypwong: Zhuhai is not bad, small city, less population
[03:18] <freeflying> ypwong: low living cost
[03:18] <ypwong> freeflying, may be a good choice
[03:18] <freeflying> ypwong: yep, estate price looks affordable
[03:32] <penghuan> ypwong:UK 软件中心的源是要集成到版本里面吗
[03:40] <ypwong> penghuan, 對，你覺得呢？
[03:42] <penghuan> ypwong，我确认下，我得试试在哪里实现比较好
[03:42] <ypwong> penghuan, 因爲放到版本就很簡單
[03:42] <penghuan> ypwong，嗯，是的，我们先确认在default-settings包里面能否实现
[03:43] <ypwong> penghuan, 一定可以啦，之前做過了
[03:44] <penghuan> ypwong，签名比较麻烦
[03:44] <ypwong> penghuan, 不是都弄過了？
[03:44] <penghuan> ypwong，之前是优客助手自己做的
[03:45] <penghuan> 代码里面弄的
[03:45] <penghuan> ypwong，签名做成包的话，得先安装
[03:48] <penghuan> 我在考虑考虑吧，先去吃饭了
[03:52] <ypwong> penghuan, -default-settings 依賴就好
[04:10] <penghuan> ypwong，依赖包是要先被安装的吧，源又要通过default-settings添加，源添加成功了才能安装签名包依赖吧
[04:15] <ypwong> penghuan, 把 key 都放進 -default-settings?
[04:16] <penghuan> ypwong, 可以考虑这么做，不知道这样好不好
[04:17] <penghuan> ypwong, 之前default-settings包这样试过，但没有入库，http://bazaar.launchpad.net/~ubuntukylin-members/ubuntukylin-default-settings/trunk/revision/59
[04:22] <ypwong> penghuan, 是的，那時候沒談好 archive 的事
[04:23] <ypwong> penghuan, 源要放在 /etc/apt/sources.list.d 的新文件
[04:23] <ypwong> 不要直接修改 /etc/apt/sources.list
[04:24] <penghuan> ypwong, 嗯，那就在default-settings里面实现了
[04:24] <ypwong> penghuan, 問問 aron
[04:24] <ypwong> happyaron, ping
[04:25] <ypwong> happyaron, archive key 放在 -default-settings 怎樣？
[04:25] <ypwong> 像 http://bazaar.launchpad.net/~ubuntukylin-members/ubuntukylin-default-settings/trunk/revision/59
[04:28] <penghuan> happyaron, ping
[07:01] <happyaron> penghuan ypwong 最好不要。
[07:02] <happyaron> JackYu: 你几号去搜狗？
[07:02] <ypwong> happyaron, 有何建議？
[07:02] <happyaron> ypwong: 还是单独做个包，仿照ubuntu-keyring
[07:02] <ypwong> happyaron, FFe to ubuntu?
[07:02] <happyaron> ypwong: y
[07:03] <ypwong> happyaron, 雖然可以，但覺得有點奇怪
[07:03] <ypwong> happyaron, 你有空弄嗎？
[07:04] <happyaron> ypwong: 我可以弄，但是key从哪里来呢。
[07:04] <ypwong> from NUDT la
[07:04] <JackYu> happyaron, 待定，可能是周四过去。怎么呢？
[07:04] <happyaron> ypwong: 得是用来签名仓库的key
[07:04] <happyaron> JackYu: 江疆找你呢。:D
[07:04] <JackYu> happyaron, ypwong, penghuan,  我觉得还是放在default-settings中比较好，这次时间也比较紧了，以后可以考虑单独出来。
[07:05] <JackYu> happyaron, 他有何指示？
[07:05] <happyaron> JackYu: 做包不用多少时间啦。。。
[07:05] <happyaron> JackYu: 没说。
[07:05] <JackYu> happyaron, 主要是单独一个包去入库比较麻烦:(，要把UKSC的事情说两遍.
[07:06] <JackYu> happyaron, got it. 他欠我酒。
[07:06] <ypwong> lol
[07:06] <happyaron> JackYu: 其实还好吧，那样会避免被人说闲话。
[07:07] <JackYu> happyaron, ypwong, 今天打算提交UKSC的入库申请了，等下我先提个Bug，大家一起来顶啊
[07:07] <happyaron> 嗯。
[07:09] <JackYu> ypwong, happyaron, 你们今晚UDS有节目没？
[07:10] <ypwong> JackYu, no
[07:11] <JackYu> app和client部分都seems interesting
[09:00] <pishuilu> happyaron:代码修改后bzr push到LP上了，现在想回退一个版本，怎么操作呀？
[09:00] <happyaron> pishuilu: 是本地退回，还是要在LP上删除一个版本？
[09:01] <pishuilu> happyaron: LP上删除一个版本
[09:01] <happyaron> pishuilu: 再push个新版本吧……
[09:01] <happyaron> pishuilu: 基本就是这样了。
[09:02] <pishuilu> happyaron: 那本地怎么退回？
[09:02] <happyaron> pishuilu: bzr revert -r
[09:02] <happyaron>  -r 后面加上版本号
[09:02] <pishuilu> happyaron: 好的，谢谢！
[09:02] <happyaron> :)
[10:08] <ypwong> 宅男神器 https://apps.ubuntu.com/cat/applications/btresourcesearch/
[10:19] <happyaron> lol
[10:34] <JackYu> :)
[10:42] <ypwong> uksc 能推薦嗎？
[10:42] <ypwong> lol
[17:06] <happyaron> FJKong: https://i169107110.restricted.launchpadlibrarian.net/169107110/buildlog_ubuntu-trusty-amd64.fcitx-qimpanel_0.1.4%2Br12-0~201403111851~ubuntu14.04_FAILEDTOBUILD.txt.gz?token=0d78a1cc918173e25f9653d62ee8b798
[17:07] <happyaron> FJKong: 今天的qimpanel，cmake有问题。
[17:25] <maclin> happyaron, hi
[17:25] <maclin> python的程序要如何打包成deb？