=== salem_ is now known as _salem === Snow-Man_ is now known as Snow-Man === inaddy is now known as tinoco === Elimin8r is now known as Elimin8er === balkamos_ is now known as balkamos === tedg__ is now known as tedg_ === BrAsS_mOnKeY is now known as g2 === dobey_ is now known as dobey === manjo` is now known as manjo === alai` is now known as alai === happyaro1 is now known as happyaron === thegodfather is now known as fabbione === bigon_ is now known as bigon === _salem is now known as salem_ [10:58] hi, I was wondering to land a lib and a dependent together what the right steps are [10:59] in my case the lib is a sync from Debian and the dependent package would be a no-change rebuild to pick up the change [10:59] I know bileto can be used for such transitions, but I was wondereing if syncpackage ... --no-lp and then into bileto ppa would be ok given the amount of warnings about --no-lp in man syncpackage [11:03] cpaelzer: to copy straight into a PPA, you can use copypackage instead, from ubuntu-archive-tools. [11:03] If a core dev has a minute to review https://code.launchpad.net/~tribaal/livecd-rootfs/fix-ova-manifest/+merge/314682 it would be much appreciated. [11:03] cpaelzer: I've never used copypackage to source from Debian, but I presume that's possible. [11:04] cpaelzer: you don't need to use bileto though unless you want to. It's fine to syncpackage, and then upload a no-change rebuild for the dependent once the sync has built. It'll be stuck in proposed until it's all done, but that's the point of proposed so it's fine. [11:04] (There's also https://code.launchpad.net/~tribaal/livecd-rootfs/fix-ubuntu-ovf-attributes/+merge/314702 but the diff there is a bit chunkier.) [11:04] not *much* chunkier though :) [11:05] cpaelzer: no point in uploading the no-change rebuild early though - it'll rebuild without the update, so that's pointless. Have to wait until the synced package is built and the binary published. [11:05] thanks Odd_Bloke [11:05] cpaelzer: it's copy-package, sorry. [11:09] rbasak: thanks [11:11] `/win 35 [11:11] rbasak: and I just see - other than with dput these days for syncpackage you still have to call it $release-proposed instead of just the release name right? [11:12] cpaelzer: I'm not sure. Doing so would do no harm. But why would you use copypackage to copy into a -proposed pocket in this case? [11:16] rbasak: no syncpackage [11:16] rbasak: like "syncpackage --release=zesty-proposed --debian-version=16.11-1 --bug=1539775 --force --verbose dpdk" [11:21] tumbleweed: http://hpoussineau.free.fr/qemu/arc20081202-nt350-4.png that is :-) [11:21] Ah. [11:21] I believe zesty-proposed is implied. [11:22] I've never used --release [11:22] I think current-release is the default according to the doc [11:22] Yes, and it'll take the latest available version by default too [11:22] let check if it implies -proposed, because with --release=zesty it told me that I don't have permissions to do so [11:25] thanks everone, worked as it should now [11:25] I'm pretty sure it must imply -proposed, because it's succeeded and done the right thing for me in the past. [11:26] cpaelzer: :P === hikiko is now known as hikiko|ln [12:54] rbasak: dpdk sync worked just fine and I waited till the build said pblished in proposed >30 minutes ago. Yet the subsequent rebuild of openvswitch still pulled in the older version :-/ [12:55] cpaelzer: are you sure it was the binaries that were published rather than just the source? [12:55] rbasak: the solution is easy - upload another no-change, but I really want to avoid proliferating the numbers due to that - what is the hard check to go for if it is ready to pull the new package version [12:55] hmm checking [12:56] cpaelzer: the binaries aren't published - they're held in NEW. [12:57] harr, that got me - thanks for helping me to find the reason [12:57] yes it has a few new packages as the dpdk zoo of sublibraries grew [12:58] cpaelzer: you're welcome. On https://launchpad.net/ubuntu/+source/dpdk/16.11-1, it says "(New)" against the builds. IIRC it also tells you there when they are pending publication, but I'm not sure. === jdstrand_ is now known as jdstrand [12:58] rbasak: it does tell me there, I was wrongly checking published and build on https://launchpad.net/ubuntu/+source/dpdk/16.11-1 [12:59] but that only was source + build as you assumed [12:59] I can't see binary publsihed (or not) on that page [13:00] https://launchpad.net/ubuntu/+source/dpdk when you flip open the release thing tells me pending publication [13:01] well you can see it - by not seing anything - under the binaries list on https://launchpad.net/ubuntu/+source/dpdk/16.11-1 [13:02] That said the pending publication down there could be useful [13:02] I might file an LP bug for that [13:11] ok, I have abug for it now [13:11] thanks rbasak to help my finding my misassumption [13:27] infinity: hi, any chance you could upload 0.158 of ubuntu-dev-tools to debian? === hikiko|ln is now known as hikiko === scottt is now known as Guest69524 === JanC_ is now known as JanC [16:05] wgrant, hey, is there a bug# for the arm64 builders kernel issue? I'm afraid we're encountering the same in our CI, trying to enable arm64 there... [16:37] tjaalton: when do you plan to build mesa with llvm 3.9 in the stable releases? === herb_ is now known as herb [16:41] doko: only mesa 13 backport will [16:41] not the currently SRU'd 12.0.x [16:42] because there were some issues with it, though it was easy to get it build with 3.9 [16:42] mesa 13 is the first one that properly supports 3.9 === ratliff_ is now known as ratliff [17:12] should requestbackport work on xenial? [17:12] lazr.restfulclient.errors.BadRequest: HTTP Error 400: Bad Request [17:26] jbicha: So I want to fix a number of bugs by adding hidpi support to Humanity. Should I branch from lp:humanity or lp:~ubuntu-art-pkg/humanity/release ? [17:29] I'm assuming the latter since that's where commits have been lately. [17:47] i almost never say that anything needs "hidpi" support, but man, does the steam overlay stuff seriously need some improvement there === scottt is now known as Guest4936 [18:06] dobey: hmm...details? [18:12] dmj_s76: i mean i like small icons/text normally. but when playing games at 4K and then i open the steam overlay, everything is even tinier than it normally is in the steam client. the notifications for achievements are especially annoying, because they're super tiny and stuck hard to the far upper right corner. those would be much better if they ended up like standard notifications in ubuntu [18:13] dobey: Maybe this needs reporting to Valve. [18:13] probably yeah [18:14] i know you can't do anything about it. was just trolling a bit because everyone thinks my normal font size is tiny [18:14] In this case Humanity icons not supporting @2x is a problem, causing the wrong icons to be shown and graphical bugs in Ubiquity. [18:15] @2x? [18:15] Error: "2x?" is not a valid command. [18:15] err, thanks bot [18:16] i thought that was an apple thing [18:17] How you signal GTK, etc to use the normal icon and scale up rather than picking the bigger one (which can be the wrong metaphor) eg, "scale up the 24 px icon, not use the 48px icon" [18:18] It's a Linux thing too. [18:19] i know gtk+ has that scaling thing; i didn't realize it was doing dumb things with icons like appending @2x to the size [18:20] well, you basically just need @2x symlinks to the correct folders [18:20] and an update to the index.theme [19:51] Is there a maintainer for the wpa source package? [19:51] It just says "Ubuntu Developers" [19:53] jackpot51: the changelog lists a wide variety of folks https://launchpad.net/ubuntu/+source/wpa/+changelog [19:55] That is unfortunate. pitti: Since you did a change for the wpa_supplicant.service, would you talk to me about my changes? [19:56] pitti's moved to another employer in the meantime, it might be a while before he has time to review something not for new work [19:56] jackpot51: all packages in Ubuntu are team maintained. There are no individual maintainers. [19:57] jackpot51: if you need to talk to people about a proposed change, then you can do it here, on the mailing list, or in a bug. And any person (subject to appropriate permissions on that package) can upload any change. [19:57] the problem is that systemctl isolate kills wpa_supplicant.service [19:58] This is easily seen where it is used in the OEM installer - wifi connections are lost after oem-config finishes [19:58] isn't that the intention of isolate? [19:59] systemctl isolate graphical.target is used [19:59] graphical.target should depend on wpa_supplicant.service [19:59] ethernet connections are not lost due to network manager not being killed [19:59] wifi is lost due to wpa_supplicant being killed [20:01] related bug: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1576024 [20:01] Launchpad bug 1576024 in network-manager (Ubuntu) "Wifi "device not ready" after booting into OS for the 1st time" [Undecided,Confirmed] [20:01] How does network manager avoid getting killed? [20:01] *sits in* [20:02] Had that bug before [20:02] (didn't know it wasn't hardware-specific) [20:02] it is not hardware specific - system76 and dell laptops experience it on first boot [20:02] switching cards does not solve the issue [20:03] jackpot51: it sounds like you've done a great job pinning down the root cause. Thanks! If nothing else, please could you write that up in the bug? [20:03] jackpot51: nice :D [20:03] will do [20:04] jackpot51: as for the correct fix, should it be done the same way that network manager avoids getting killed? How is that, and doesn't network manager spawn wpasupplicant as a child, or is it really using a separate systemd service? [20:04] maybe NM systemd unit file needs adjusting to require wpa_supplicant.. [20:04] it is a seperate service - as a side note, bluetoothd has the same issue [20:04] Saviq: https://bugreports.qt.io/browse/QTBUG-54822 [20:05] I fixed it the "wrong" way by adding IgnoreOnIsolate=true to [Unit] in wpa_supplicant.service [20:05] jackpot51: and it'd be nice to have the relevant Debian maintainer's agreement if possible before fixing it in Ubuntu, so we can do it the same way and get additional review [20:05] Assuming the same bug exists in Debian and that they want to use graphical.target in the same way. [20:07] If urgent, we can always fix first of course. I'm just not confident enough in this area to confirm any fix is correct. [20:08] My fix would mean that going to a non-networking target would not kill wpa_supplicant [20:08] I don't think that happens in the real world often though [20:13] here is the most upstream service file: https://w1.fi/cgit/hostap/tree/wpa_supplicant/systemd/wpa_supplicant.service.in [20:13] and does NM depend upon it properly? [20:14] I am not sure: https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/data/NetworkManager.service.in [20:14] It isn't in the upstream service file [20:26] by the way, it is possible to trigger the bug running on your own system. All you have to do is run `sudo systemctl isolate default.target` while connected to WiFi === salem_ is now known as _salem