[00:30] sil2100: Ok, thanks for letting me know. [00:31] GunnarHj: sorry about this anyway, I noticed it too late and didn't get to running it manually, maybe I should have [00:31] Anyway, I just thought we'll get a batch this week [00:32] sil2100: I thought there was some kind of manual intervention to build the packages, but you say it will happen automatically? [00:33] sil2100: Or are you talking about the tarballs? [00:35] GunnarHj: well, the delta langpacks are happening automatically, a day after tarball exports [00:36] sil2100: Ah, didn't know that. [00:38] GunnarHj: as per the schedule https://dev.launchpad.net/Translations/LanguagePackSchedule [00:41] sil2100: Right, so there are weekly updates all over (when it works), and while the builds for the stable releases goes to the PPA, the builds for the development release make it directly to the archive. [01:59] lmao [01:59] tfw openrct2 dev team says you can't build openrct2 for Ubuntu, and package in deb file [01:59] tfw u literally JUST DID THAT === mthaddon` is now known as mthaddon [08:53] xnox: hey, you mentioned some xubuntu ubiquity plugin and such, I don't find them in the ubiquity source nor find other packages matching those descriptions [09:19] rbalint: https://launchpad.net/ubuntu/+source/mtd-utils/1:2.0.1-1ubuntu2 still ftbfs on ppc64el [10:28] When switching the one thing in main for a particular thing, what's the expected upgrade path for users usually? Leaving upgrading users with a packaging now in universe and release note it? Or something further? [10:29] When switching the one thing in main for a particular thing, what's the expected upgrade path for users usually? Leave upgrading users with a package now in universe and release note it? Or something further? [10:36] didrocks, sigh, need to search for it again then. maybe it was somebody else, like edubuntu or mythbuntu [10:36] rbasak, we do leave people with packages in universe typically. [10:37] rbasak, sometimes we promote the new thing via upgrade-manager quirks, but we stopped doing that, as it is fragile. seeding new stuff into metapackage works fine, as long as there is a clear successor. [10:40] xnox: so, I guess there is nothing, I see no plugins at all [10:43] I thought it was an ubuntustudio ubiquity plugin [10:43] didrocks: https://launchpad.net/ubuntustudio-live ? [10:44] https://launchpad.net/ubuntu/+source/ubuntustudio-live too [10:44] cjwatson: ah, thanks! the naming isn't the best. I'll check if there is the minimal install in it that xnox elluded to [10:47] /o\ studio [10:47] thanks colin! [10:48] yeah, it's not a minimal install checkbox, it's a view with checkbox to select/deselect installed packages [10:49] there may be some other plugin that exists that I forgot about [10:49] or maybe xnox's memory is failing ;) [10:49] grepping Contents also finds dell-recovery and edubuntu-live [10:50] didrocks, they do wipe your memory upon leaving Intel... [10:50] xnox: ahah :) [10:50] or so I was told.... I can't remember [10:50] thanks for the hints cjwatson :) [10:51] mythbuntu-live-autostart also used to exist [10:52] the edubuntu one is unsurprinsgly very close to ubuntustudio (full list of packages to select/remove from) [10:52] * didrocks looks at mythbuntu [10:53] xnox: thanks. In this case I don't think it's included in a metapackage (it's from server-supported) [10:53] ubiquity/plugins/myth-install-type.py, ah, promising :) [10:53] rbasak, ah, well, we do drop things on the floor (main->universe) and that is it =) [10:54] OK [10:54] rbasak, upon upgrade with like do-release-upgrade, it does mention that these are now community supported packages. [10:54] Good point [10:54] rbasak, so people can read it, and forget that list of things =) [10:54] xnox: ok, I confirm that the list per install type is hardcoded in mythubuntu [10:54] didrocks, lolz [10:55] didrocks, slangasek was like "no i have not heard about didrocks adventures" and he was like "chat with him to align" and I'm like "i did", everyone likes everything =) [10:55] didrocks, but need to do the actual coding with stacked squashfses.... [10:55] cjwatson: Hi Colin! I'm investiging a translation issue for util-linux together with seb128. Translations haven't been imported to LP in a long time (7 years). [10:55] The latest bionic build log claims that the tarball util-linux_2.30.2-0.1ubuntu1_amd64_translations.tar.gz was created. I'd like to see what it contains. Do you possibly know how to find it? [10:56] xnox: yeah, we still need something for the LTS, so let's go with the easy option as a fallback in case you don't get the stacked squashfses work on time [10:56] * Ship ubuntu-dgbsym key [10:56] xnox: sounds like easy enough, not a lot would be lost [10:56] xnox: Thnak you! [10:57] Unit193, your welcome. it is in a separate package though, just install that =) [10:58] GunnarHj: You should be able to dig it out from the queue. Let me see ... [10:58] Doesn't matter, it exists. There's a bug that can be closed now too. [10:58] GunnarHj: https://launchpad.net/ubuntu/bionic/+queue?queue_state=3&queue_text=util-linux [10:59] cjwatson: Thanks! [11:07] cjwatson, doing something like "ubuntu.getSeries(name_or_version='bionic').getPackageUploads(name='util-linux', version='2.30.2-0.1ubuntu1 ', custom_type='raw-translations')" from a lp-shell used to work but it doesn't seem to do what I expect now ... did that change/stop working? [11:07] seb128: That stray space in the version doesn't look likely to help. [11:08] shrug, indeed [11:08] cjwatson, thanks for spotting :) [11:08] and sorry for the noise [11:08] np [11:08] I expect there's more debugging to do here, but I think the relevant logs have expired at our end by now since the last attempt was a while ago [13:14] doko, on arm64, gcc: error: unrecognized command line option ‘-m64’ -> i guess one should not use that option, ever, right? [13:22] cpaelzer: FWIW, virt-manager 1.4.3 ftbfs on bionic [13:23] cpaelzer: I can give you my debdiff if you feel like investigating [13:23] cpaelzer: this is what I'm hitting: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888133 [13:23] Debian bug 888133 in libvirt "virt-manager FTBFS: test failures" [Serious,Open] [13:24] mdeslaur: I was just starting a merge a few minutes ago [13:24] mdeslaur: did you already start one? [13:25] cpaelzer: yes, then hit all the test failures in the debian bug [13:25] one sec [13:26] let me retry building it to see if anything changed [13:29] mdeslaur: guido marked it as found in libvirt 4.0 - so likely a change in behavior in there [13:29] mdeslaur: I might abandon my just started merge and better help you to get over that FTBFS [13:29] yeah, that's what I suspected...I looked through the virt-manager tree to see if there seemed to be any commits to address that, but I had not found any [13:30] perhaps it's worthwhile to try 1.5 [13:30] ok, still get the test failures...let me stick my source package somewhere for you [13:41] mdeslaur: 4224b092 or fe59c337 maybe [13:42] mdeslaur: FYI I can recreate the issue [13:42] * mdeslaur looks [13:43] cpaelzer: I had tried 8b4befae602779cbef2d579e4c532b9cd0f1fee9 [13:43] but yeah, perhaps combining them all [13:45] or just going to 1.5 [13:49] I try that atm [13:49] rather brute force, just to know if it would work [13:50] already building ... [13:56] mdeslaur: 1.5 is failing as well, but differently [13:56] :( [13:57] now around "Size must be specified for non existent volume" and ....img' does not exist [13:58] how silly of me to think that they would test the latest virt-manager on the latest libvirt ;P [13:58] hi ubuntu devs. I need help with launchpadlib. I need to retrive package's dsc information sorted by publish date [13:58] mdeslaur: all remaining issue son 1.5 have "/tmp/__virtinst_cli_exist1.img" being missing as the issue [13:59] veen the messages with the size track down to the same thing [13:59] oh, interesting [13:59] repositories are divided by main and contrib. Is there a way to retrive only from one repo? [14:11] Ubuntu doesn't have a "contrib" component; its equivalents are main/restricted/universe/multiverse. https://launchpad.net/+apidoc/devel.html#archive-getPublishedSources and similar calls can be given a component name to filter results. [14:12] (And I think that should answer your other question too.) [14:12] mdeslaur: of the cdrom cases only the s390x cases fail [14:12] cpaelzer, but s390x has no cdrom.... [14:12] =) [14:12] well you can pass a virtual one [14:13] cpaelzer: kill it with fire [14:13] the others are all with virt-clone [14:13] not sure yet, but they all seem to have the same "signature" so I hope it is one or two fixes at most [14:15] cpaelzer: ProTip: I always write xnox's name in the changelog when I break s390x stuff ;) [14:16] real Pro :-) [14:16] it is not any s390x specific thing in this case (other than by accident of names) [14:16] hehehe [14:16] just the tests that refer to /tmp/__virtinst_cli_exist1.img in their test xml fail [14:16] I assume the setup of said file fails [14:16] but it hides from me atm [14:18] ah there is an exist_images in clitest.py - that looks good [14:27] mdeslaur: this is a file that the test entry is supposed to prepare [14:27] mdeslaur: and it does [14:27] mdeslaur: but as a link to a non existing file [14:27] hrm [14:27] mdeslaur: I'll go on debugging and let you know what I find or if I give up [14:27] ack, thanks [14:28] cjwatson: ok i get it. It there a way to get history of package? I mean for example history of gimp package: what version was in 2014, what dependencies, what binaries had? [14:28] i see that prints current packages [14:31] pchamtaczke: That call returns publication records, which includes packages that have been superseded or deleted, so it's the basic building block for what you're asking for. [14:32] thanks, its nice. This answer is sufficient for me ;) [14:32] pchamtaczke: Though quite a bit of assembly will be required if you're trying to work out properties of binaries, and depending on what you're doing it may be easier to go through archive.getPublishedBinaries. [14:33] mdeslaur: ok, silly me [14:33] mdeslaur: that was actually an artifact of my "brute force 1.5" [14:33] mdeslaur: resolved the issue, well done 1.5 looks good now [14:33] inside my sbuild chroot [14:33] mdeslaur: if you'd go to a tarball of 1.5 it should be just good [14:35] cpaelzer: oh, awesome [14:35] cpaelzer: are you going to upoad it? [14:36] I'd need to clean up a lot [14:36] but yes I think I'll redo the merge you did and add 1.5 on top [14:36] unless you say it would be easy for you to add 1.5 on top of yours [14:37] reading your changelog it was just dropping upstrema changes on your rebase [14:37] I should be able to redo that quickly [14:37] mdeslaur: I'll set you as additional reviewer when I have something ok ? [14:40] cjwatson: i need to build api that retrieve information about binaries from fixed time interval. I need follow properties from binaries: name, version, architecture and publication date. Every property i have from received objects from `getPublishedBinaries`. That intervals will be problematic but i invent something [14:42] cpaelzer: sure [14:45] mdeslaur: you dropped use_qxl_for_ubuntu.patch I don't see the upstream change for it [14:45] other reasons to drop ? [14:47] oh was this 15.04 only? [14:47] it was dropped upstream [14:47] not sure how _is_related_to is evaluated [14:48] was that 984ba6b33e80f9a91b93677b991fcd7ee4831218 [14:48] yep [14:48] ok [14:48] yes === mmstick_ is now known as mmstick [15:32] xnox: yes [15:45] GunnarHj: pkgbinarymangle's tests fail [15:46] doko: I know. seb128 will look at that. [15:47] doko, do you have any idea what could be wrong? that doesn't look related to the change so was probably an existing issue in bionic [15:53] mdeslaur: 1.5 built fine now [15:53] cpaelzer: awesome [15:53] mdeslaur: I'll push a review as soon as calls leave me alone [15:55] seb128: sorry, no. just saw the ftbfs [15:55] maybe needs updates for new debhelper? [15:57] could be, it seems to fail to unpack some source [15:57] I don't know what changed in debhelper, need to have a look [15:58] "AssertionError: b"no entry control.tar.gz in archive\n\ngz[179 chars]nd\n" != b'' : b"no entry control.tar.gz in archive\n\ngzip: stdin: unexpected end of file\ntar" [16:03] mdeslaur: please review https://code.launchpad.net/~paelzer/ubuntu/+source/virt-manager/+git/virt-manager/+merge/337287 [16:03] mdeslaur: there is also a ppa building across arches to test, linked from the MP [16:05] ugh, how about a debdiff [16:08] cpaelzer: I'm in the middle of something, I'll pull it down in an hour and take a look [16:08] mdeslaur: due to timezones you'll have all of your day to do it [16:10] cool :) [16:32] How does one suspend from gnome on bionic? The power button only offers shutdown. [16:33] bdmurray: from the dropdown, hold Alt [16:33] bdmurray: iirc, it toggles from power off to suspend [16:33] super intuitive :) [16:33] bdmurray, i wish that was fixed becuase the "just close the lid" does not work on the desktop [16:33] that's crazy [16:34] bdmurray: did it change to a 'pause' for you? [16:34] nacc: yeah, hence my comment [16:34] bdmurray: yeah :0 [16:35] bdmurray: there's also a screen rotation thing if you have that, and it's equally unintuitive (does the icon it show mean that's the current state or what it would go to??) [16:35] it's *almost* like gnome doesn't care about users' sanity [16:41] seb128: I built pkgbinarymangler successfully on artful (locally). So there is indeed something with the builddep versions. [16:41] bdmurray: it's documented at https://help.ubuntu.com/stable/ubuntu-help/shell-exit.html#suspend :( [16:42] jbicha: Do you know if there is a bug report about the issue? [16:43] lol [16:43] it's a Feature [16:43] bdmurray, i think i made one. [16:44] you'd have to convince either GNOME Designers or the GNOME Shell developers of the behavior you want [16:44] or convince the Ubuntu Desktop team that it's worth diverging for [16:44] bdmurray, i wonder if there is an extension we can ship, and/or some such [16:44] one issue with adding an extra Suspend button there is that 5 buttons makes it crowded at the bottom of the menu [16:45] https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1697143 [16:45] bdmurray, jbicha: I got the same question in the Swedish loco, and provided the very same link to the docs. [16:45] Launchpad bug 1697143 in gnome-shell (Ubuntu) "GNOME Shell's Suspend feature is hidden in power menu" [Medium,Confirmed] [16:45] there was a proposal at some point that they shouldl all be togglles [16:45] (the 4th button is the auto-rotate button that shows up on certain hardware) [16:45] or something like that [16:45] jbicha, 5? which five? I only have three [16:45] xnox: i have 4 [16:46] xnox: and a suspend would be 5 [16:46] xnox: you only have 4 if you ahve a rotate-able screen [16:46] nacc, i have system settings, lock, shutdown. [16:46] xnox: there's a screenshot of the auto-rotation button on the bug report [16:46] nacc, that screen rotation button is well.... useless [16:46] xnox: right [16:46] xnox: it can be handy to have it disabled, fwiw [16:46] a suspend one >>> screen rotation [16:46] as otherwise your screen flickers a lot :) [16:47] nacc, imho it should be disabled by default, and if you enable it in setting, get the lock rotation button. [16:47] xnox: yes, that's basically how it works [16:47] you have to (on my hardware) install iio-sensor-proxy and configure it properly to get rotation [16:47] nacc, and imho settings button should be "System settings..." a line entry. [16:47] nacc: iio-sensor-proxy is installed by default [16:48] jbicha: ah ok, it wasn't at the time i installed :) [16:48] xnox: yes, the icons don't make anything clearer to me [16:48] nacc, ok, when you click power button, it should have "suspend", "hybernate" test buttons options.... [16:48] * jbicha points xnox to #gnome-design on irc.gnome.org … [16:48] heh [16:48] https://extensions.gnome.org/extension/826/suspend-button/ [16:48] but it's difficult getting change from GNOME Design, both because many of these issues have been presented many times [16:49] and because GNOME Design made all their radical changes for 3.0 and now are hesitant to make major changes ;) [16:51] "or simply long-click the power off button." what the?! [16:51] it sort of makes sense except that I can't think of anywhere else in GNOME that uses long-click [16:52] there is no indication that it is a long-clickble button [16:52] it could have been a GIF that animates