[00:00] <bmw> thanks
[00:00] <rbasak> bmw: once we have the test process defined and approved, then I can upload/accept the reviewed branches into the proposed pocket for building.
[00:04] <rbasak> bmw: I'd like the agreed test process to end up in https://wiki.ubuntu.com/StableReleaseUpdates/Certbot, but it's fine for that to refer to some other versioned document.
[00:25] <bmw> OK
[00:25] <bmw> I'll largely write the instructions there with a couple external links
[03:34] <snayzix> Hellp
[03:35] <snayzix> Is someone here ?
=== santa is now known as Guest98858
=== klebers_ is now known as klebers
[09:51] <doko> apw: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/armhf/l/linux/20170718_191215_9b786@/log.gz  is this temporary and should be retried?
[09:52] <apw> doko, i would say so, yes
[10:18] <doko> chrisccoulson: I see that indicator-messages was demoted, but thunderbird still depends on it. can it be built without indicator-messages?
[10:19] <didrocks> doko: we still want unity to use it
[10:19] <doko> didrocks: so promote it again?
[10:19] <didrocks> so, the unity session still ship the indicator
[10:19] <didrocks> hum
[10:19] <didrocks> I was told that packages in main can build-dep on packages in universe, and so, was ok to demote
[10:20] <didrocks> (and it's only a build-dep, no lib linking in any package in main)
[10:21] <didrocks> (I guess that's why it doesn't show as source wanted to migrate in main in component_mismatch if I'm correct)
[10:24] <doko> didrocks: right, but it has a runtime dep as well: thunderbird-gnome-support/amd64 unsatisfiable Depends: libmessaging-menu0
[10:25] <didrocks> doko: we should demote thunderbird-gnome-support
[10:26] <didrocks> that's why I dropped it to suggests
[10:26] <didrocks> (thunderbird suggests thunderbird-gnome-support and unity-session recommends thunderbird-gnome-support)
[10:26] <doko> didrocks: it's seeded
[10:27] <didrocks> by:
[10:27] <didrocks>   ubuntukylin-desktop
[10:27] <didrocks>   ubuntu-mate-desktop
[10:27] <didrocks> which as in universe
[10:27] <didrocks> is it seeded anywhere else? I don't see it in http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.artful/all
[10:28] <didrocks> I unseeded from supported in revno: 2550
[10:28] <didrocks> timestamp: Thu 2017-07-13 10:15:52 +0200
[10:28] <didrocks> is there anything else missing?
[10:28] <doko> hmm
[10:29] <didrocks> also, I did a ./change-override -c universe thunderbird-gnome-support thunderbird-gnome-support-dbg
[10:29] <didrocks> on that day
[10:29] <didrocks> unsure why it's again in main
[10:29] <didrocks>  thunderbird-gnome-support | 1:45.8.0+build1-0ubuntu1 | artful/universe | amd64, arm64, armhf, i386, ppc64el, s390x
[10:30] <didrocks> I guess a mismatch in publication between -proposed and release pocket
[10:30]  * didrocks demotes in artful-proposed as well
[10:30] <didrocks> and that should get it to the release pocket
=== Guest98858 is now known as santa_
[11:49] <smoser> mwhudson, doko cloud-init in archive is fine with 3.6
[11:56] <smoser> bah. it should have but it doesnt. uploading one that does now.
[11:58] <smoser> uploaded
=== JanC is now known as Guest74368
=== JanC_ is now known as JanC
[12:30] <jbicha> didrocks: it's listed in supported
[12:40] <didrocks> jbicha: where?
[12:40] <didrocks> would be nice to have a pointer :p
[13:18] <seb128> wgrant, hey, I think I hit that issue some cycles ago but any idea why evolution-data-server/evolution don't have their .po imported in launchpad for artful?
[13:19] <seb128> hum, and did launchpad change? my script doing getPackageUploads()[0].custom_file_urls hits a
[13:20] <seb128> AttributeError: https://api.launchpad.net/devel/ubuntu/artful/+upload/16007844 object has no attribute 'custom_file_urls'
[13:20] <seb128> that used to work :-/
[13:31] <cjwatson> seb128: custom_file_urls stopped being exported on the devel API version in 2012.  Either use 1.0, or (better) use the customFileUrls() method instead
[13:33] <cjwatson> seb128: (I made it stop being a property on devel for performance - in most cases where we want to serialise a PackageUpload to JSON we don't need to worry about computing those URLs, so moving them to a method that callers that explicitly need them can use performs better overall)
[13:34] <seb128> cjwatson, thanks, that works
[13:35] <wgrant> seb128: iirc eds puts its version in its template name, so each release needs manual approval. check its import queue
[13:35] <seb128> I tried that early but wrongly, I somewhat didn't see it was a method and used ".customFileUrls" and got confused
[13:35] <seb128> wgrant, we changed it to stop doing that, I accepted the unversionned template and fixed the template details afaik
[13:35] <seb128> wgrant, I wonder if I overlooked something
[13:36] <seb128> wgrant, well, https://translations.launchpad.net/ubuntu/artful/+source/evolution-data-server/+imports
[13:36] <seb128> no .po there
[13:36] <seb128> and we had a source upload yesterday after the new template was imported
[13:38] <seb128> wgrant, https://launchpad.net/ubuntu/artful/+upload/16007657/+files/evolution-data-server_3.24.4-0ubuntu1_amd64_translations.tar.gz
[13:38] <seb128> the build tarball has them
[13:39] <wgrant> seb128: what are the PO paths like in that tarball?
[13:39] <wgrant> (i'm on my phone)
[13:39] <seb128> wgrant, source/po/<locale>.po
[13:43] <wgrant> hmm. i'll have to debug tomorrow, unless cjwatson is feeling adventurous
[13:43] <seb128> I wonder if that's again an issue with the translations sharing option
[13:44] <wgrant> oh, possibly, yes
[13:44] <seb128> https://translations.launchpad.net/ubuntu/artful/+source/evolution-data-server/+sharing-details has " Automatic synchronization of translations is enabled. "
[13:46] <wgrant> i forget exactly how that logic works. it can never share atm since the template names don't match, but it probably doesn't hanske that case. might be best to unshare
[13:47] <cjwatson> I traced the upload path enough to check that the upload jobs were happening, but debugging translations sharing tends to be beyond me
[13:47] <seb128> seems other desktop apps have share enabled as well though
[13:47] <seb128> hum
[13:47] <seb128> http://bazaar.launchpad.net/~vcs-imports/evolution-data-server/trunk/view/head:/po/fr.po
[13:47] <seb128> download file gives me an empty file
[13:47] <seb128> I wonder if that's specific to that file or another new launchpad issue
[13:47]  * seb128 tries another code page
[13:48] <cjwatson> we haven't touched loggerhead in ages
[13:48] <wgrant> none of these are new launchpad issues
[13:48] <seb128> it works on other urls so I guess something about that file
[13:49] <wgrant> your script was half a decade out of date, and eds does translations weirdly
[13:49] <seb128> was doing
[13:49] <seb128> :p
[13:49] <seb128> but yeah, I know e-d-s is a weird case
[13:49] <seb128> should be better now that the domain stops changing
[13:49] <seb128> the fr.po being empty is not on my side though afaik
[13:50] <cjwatson> download> https://bugs.launchpad.net/loggerhead/+bug/1153721
[13:50] <ubottu> Launchpad bug 1153721 in loggerhead "File download fails (downloads empty file)" [Low,Triaged]
[13:51] <seb128> cjwatson, thanks
[13:51] <seb128> I didn't know "loggerhead" was the right project for that
[13:51] <seb128> now I do :-)
[13:52] <cjwatson> I can rename it to pit-of-despair if you like
[13:53] <seb128> heh
[14:02] <cjwatson> loggerhead's download thing looks broken in at least two ways
[14:02] <cjwatson> 1) the view assumes that the file-id is path-encoded but it isn't
[14:04] <cjwatson> 2) if you path-encode it manually (e.g. / => %2F) it then claims the file doesn't exist - I think it only works if the file-id is in the top directory of the branch, but I don't have a clear idea of why
[14:05] <seb128> k
[14:05] <seb128> well, I'm doing a checkout now
[14:06] <cjwatson> this must have been broken since at least 2012, possibly earlier, possibly forever for all I know
[14:43] <seb128> cjwatson, wgrant, translations import worked after unsetting the translations sharing box and doing an upload, https://translations.launchpad.net/ubuntu/artful/+source/evolution-data-server/+imports , I feel like we didn't do that before for a reason though but I can't remember so let's see if that has other side effects
[14:43] <seb128> thanks for the help!
[17:10] <dreamcat4> hi there. i'm a bit stuck with the installer, i ran it then selected 'continue testing'
[17:10] <dreamcat4> however /target is still mounted and will not unmount
[17:11] <dreamcat4> perhaps there is some /dev /proc stuff mounted into it?
[17:30] <dreamcat4> ok... nothing is working for me (and umount /target still fails)
[17:30] <dreamcat4> need help
[17:37] <wxl> dreamcat4: if you're looking for support, #ubuntu is the place to be
[17:39] <dreamcat4> wxl: oh nevermind then. but maybe you should know this to be a bug then?
[17:40] <dreamcat4> as it didnt happen with the 16.04 installer prior
[17:40] <wxl> dreamcat4: i know of no bug
[17:41] <wxl> dreamcat4: i would start by looking at the integrity of the image
[17:41] <dreamcat4> sounds like a complete waste of time to me...
[17:41] <wxl> well, best of luck
=== iulian_ is now known as iulian
[21:09] <dreamcat4> it happened only with the default option 'erase whole disk'
[21:11] <dreamcat4> when i instead started with 'ubiquity --no-bootloader', and then selected 'something else' (fresh install), and created only single ext4 partition (into a zvol). then /target was not left kept mounted anymore, upon selected 'continue testing' at end of installation
[21:11] <dreamcat4> ... seems to be a bug that only appears under certain conditions
[21:12] <dreamcat4> like i said: didnt happen with 16.04 installer
[21:12] <dreamcat4> this is current (17.10 nightly builds) desktop ISO