[00:18] <persia> nigelbabu: Ah,.  I was hoping for something including the derived statistics you've been working on.  That will come in time.
[00:19] <persia> bdmurray: Might make sense to reflect the ubuntu-sponsors merge in those graphs.
[00:20] <bdmurray> persia: yes, that's on my todo list
[00:20] <persia> Cool.  Just wanted to make sure :)
[03:17] <nigelbabu> bdmurray: no, I got mails from others too I think when someone added a patch tag.  Does that get in moderation queue?
[04:36] <bdmurray> nigelbabu: okay, I see that too now and I'm not certain what is happening there
[07:44] <nigelbabu> bdmurray: so, we're both equally lost :)
[07:59] <nigelbabu> I have no clue how, but now there are 1853 bugs with patches :o
[08:10] <dholbach> good morning
[08:30] <nigelbabu> heyya dholbach :)
[08:30] <dholbach> hey nigelbabu
[08:30] <dholbach> how are you doing?
[08:30] <nigelbabu> so far good :)
[14:59] <nigelbabu> cyphermox: hey, I spoke to starcraftman.  thank you :)
[19:35] <bdmurray> nigelbabu: duh, those other posters are subscribers to the mailing list
[21:03] <bdmurray> persia, nigelbabu: graphs modified now - http://qa.ubuntu.com/reports/patches/
[23:41] <nigelbabu> bdmurray: rocking :)
[23:42] <nigelbabu> bdmurray: ok so everything else gets stuck in moderation queue I suppose
[23:59] <bdmurray> nigelbabu: right I'd asked about that in the meeting we had
[23:59] <bdmurray> nigelbabu: maybe I wasn't clear though


[02:45] <SWAT> are there any good 'power-management' tools around? (since Ubuntu shortens the 'usage-time' of my battery)
[02:46] <Burgundavia> SWAT: in what sense?
[02:48] <SWAT> well, I have a celeron and CPU scaling isn't possible (which sucks). Then I can't undervolt my CPU, since my CPU doesn't support it (which also sucks)
[02:48] <SWAT> I don't know if possible to scale my CPU down anyway?
[02:49] <Burgundavia> no idea, sorry
[02:49] <SWAT> or perhaps 'tweak' my component (primarily HD) usage? I guess that would be the component using the majorty of power which could be tweaked
[02:49] <Burgundavia> I have a celeron M, which might support it
[02:49] <Burgundavia> nah, the issue is mostly using the exisitng power management features
[02:50] <Burgundavia> if you right click on the battery iocn and choose preferences
[02:50] <Burgundavia> there is a "battery life over performance" switch
[02:50] <SWAT> Burgundavia, if you can run powernowd etc. you probably have scaling possibilities. I don't, afaik (I also should have Celeron M if I remember correctly)
[02:50] <Burgundavia> I don't deviate from stock config
[02:50] <jldugger_> SWAT, you say ubuntu shortens usage time
[02:50] <jldugger_> compared to windows?
[02:51] <SWAT> jldugger_, yes, and I'm not the only one who experiences this
[02:51] <Burgundavia> again, the issue is mostly using the existing power management features
[02:52] <Burgundavia> bug your vendor to support linux better
[02:52] <jldugger_> SWAT, sure. but the question is what windows is doing that Ubuntu doesn't. and usually its frequency scaling etc
[02:52] <jldugger_> gnome's power management stuff in 2.16, along with the new power-management-backend seem pretty nice
[02:52] <SWAT> I had a discussion about this with a LUG member
[02:52] <jldugger_> so/
[02:53] <jldugger_> you're having a discussion about it with one right now :P
[02:53] <SWAT> Windows apparently has 'tweaked' their power managed far better
[02:53] <SWAT> s/managed/management/
[02:53] <jldugger_> i get pretty much the same battery life in windows vs linux
[02:53] <Burgundavia> nah, it is not that
[02:54] <Burgundavia> windows has vendor support, so windows can use all the shiny features like spinning down disks, slowing down fans, etc.
[02:54] <Burgundavia> hardware controlled stuff that is vendor-dependant
[02:54] <jldugger_> if it were "tweaks" that linux was missing, i'd expect the opposite
[02:54] <SWAT> my classmates (2) and a LUGmember confirmed my suspicions
[02:55] <SWAT> Burgundavia, yes, I would guess so
[02:55] <jldugger_> SWAT, there's clearly things that can be done, as one of the SUSE developers pointed out in a talk a few months ago
[02:56] <SWAT> well, undervolting hardware is tricky to get to work, but a friend of mine got it to work (and that also saves a bit of power)
[02:57] <jldugger_> http://lwn.net/Articles/181888/
[02:58] <SWAT> if laptops would be more efficient, more people would probably used it. If more people use it, it would get 'seen' in action more often, which would create a larger userbase
[02:59] <Burgundavia> usebase is only part of the issue
[02:59] <Burgundavia> we need developers and vendor support
[02:59] <SWAT> vendor support will come if the userbase is big enough
[03:00] <SWAT> otherwise they would be cutting into their own userbase
[03:00] <jldugger_> thats not nessecarily true
[03:01] <jldugger_> vendors would still resist open source even if there is a user base to justify addressing the problem
[03:01] <Burgundavia> vendor support does not come from single users
[03:01] <Burgundavia> vendor support comes from big orgs buying 10k laptops at once
[03:01] <Burgundavia> who say "I am buying this to run Linux on it. Make certain it is feature comparable"
[03:04] <SWAT> OK, guys, thanks for the chat. I'm off (sleepy-time). Thanks for the quick chat. Have a nice sunday
[03:05] <jldugger_> aha
[03:05] <jldugger_> http://www.linuxsymposium.org/2006/linuxsymposium_procv1.pdf
[03:06] <jldugger_> page 127 =(
[11:11] <KenSentMe> Is it possible to automaticly switch of the synaptics touchpad when a usb mouse is plugged in?
[04:29] <eternal_p> good morning, does anyone here have some experience with Bluetooth devies and ubuntu?
[12:03] <sk1nny> hi guys i've just 'inherited' a toshiba satellite pro a10 laptop and have been trying to install dapper 6.06 on it (first from a downloaded live cd, then from a downloaded alternative cd) but to no avail. The live cd install hangs on the first page, and the alternative appeared to work until it reboots and then i'm told "Missing Operating System". Is there any chance of getting ubuntu onto this machine without hauling out hardware?
[12:04] <Burgundavia> sk1nny: have you tried 6.10?
[12:04] <sk1nny> no, not yet, i figured i'd probably be safest with dapper.
[12:04] <sk1nny> does edgy have better laptop support?


[00:38] -queuebot:#ubuntu-release- New binary: grandorgue [riscv64] (jammy-proposed/universe) [3.5.0-0-1] (no packageset)
[00:51] -queuebot:#ubuntu-release- New binary: lomiri-thumbnailer [riscv64] (jammy-proposed/universe) [3.0.0-1] (no packageset)
[01:34] -queuebot:#ubuntu-release- New binary: halide [riscv64] (jammy-proposed/universe) [13.0.3-1] (no packageset)
[02:25] -queuebot:#ubuntu-release- Unapproved: gallery-dl (focal-backports/universe) [1.20.0-1~bpo20.04.1 => 1.20.1-1~bpo20.04.1] (no packageset)
[05:19] -queuebot:#ubuntu-release- New binary: catgirl [amd64] (jammy-proposed/universe) [2.0-2] (no packageset)
[05:19] -queuebot:#ubuntu-release- New binary: catgirl [s390x] (jammy-proposed/universe) [2.0-2] (no packageset)
[05:20] -queuebot:#ubuntu-release- New binary: catgirl [ppc64el] (jammy-proposed/universe) [2.0-2] (no packageset)
[05:21] -queuebot:#ubuntu-release- New binary: catgirl [arm64] (jammy-proposed/universe) [2.0-2] (no packageset)
[05:21] -queuebot:#ubuntu-release- New binary: catgirl [armhf] (jammy-proposed/universe) [2.0-2] (no packageset)
[05:22] -queuebot:#ubuntu-release- New binary: grandorgue [amd64] (jammy-proposed/universe) [3.5.0-1-1] (no packageset)
[05:23] -queuebot:#ubuntu-release- New binary: grandorgue [s390x] (jammy-proposed/universe) [3.5.0-1-1] (no packageset)
[05:25] -queuebot:#ubuntu-release- New binary: grandorgue [ppc64el] (jammy-proposed/universe) [3.5.0-1-1] (no packageset)
[05:30] -queuebot:#ubuntu-release- New binary: grandorgue [armhf] (jammy-proposed/universe) [3.5.0-1-1] (no packageset)
[05:31] -queuebot:#ubuntu-release- New binary: grandorgue [arm64] (jammy-proposed/universe) [3.5.0-1-1] (no packageset)
[05:33] -queuebot:#ubuntu-release- New binary: catgirl [riscv64] (jammy-proposed/universe) [2.0-2] (no packageset)
[06:34] -queuebot:#ubuntu-release- New binary: grandorgue [riscv64] (jammy-proposed/universe) [3.5.0-1-1] (no packageset)
[07:30] <cpaelzer> hi ubuntu-archive - DPDK in excuses complains (correctly) about missing armhf builds
[07:30] <cpaelzer> But that is intentional as https://launchpad.net/ubuntu/+source/dpdk/21.11-1 has "* d/control: drop armhf builds"
[07:31] <cpaelzer> could we remove the armhf binaries of the former DPDK version so that this can continue to try migrating?
[07:33] <cpaelzer> Furthermore, only some of DPDKs binaries are in main - we promoted all and relied on the auto-demotion to sort things out
[07:34] <cpaelzer> But if someone of the ubuntu-archive touches DPDK anyway, those three are in main (due to the promote all, and let them auto-demot later) and cause component mismatches.
[07:35] <cpaelzer> Demoting those (librte-compress-isal22, librte-compress-octeontx22, librte-crypto-ipsec-mb22) to universe in jammy-proposed would further help
[07:35] <cpaelzer> that matches their predecessors with the ...21 suffix
[09:07] -queuebot:#ubuntu-release- New: accepted catgirl [riscv64] (jammy-proposed) [2.0-1]
[09:07] -queuebot:#ubuntu-release- New: accepted catgirl [arm64] (jammy-proposed) [2.0-2]
[09:07] -queuebot:#ubuntu-release- New: accepted catgirl [ppc64el] (jammy-proposed) [2.0-2]
[09:07] -queuebot:#ubuntu-release- New: accepted catgirl [s390x] (jammy-proposed) [2.0-2]
[09:07] -queuebot:#ubuntu-release- New: accepted grandorgue [arm64] (jammy-proposed) [3.5.0-1-1]
[09:07] -queuebot:#ubuntu-release- New: accepted grandorgue [ppc64el] (jammy-proposed) [3.5.0-1-1]
[09:07] -queuebot:#ubuntu-release- New: accepted grandorgue [s390x] (jammy-proposed) [3.5.0-1-1]
[09:07] -queuebot:#ubuntu-release- New: accepted ocaml-odoc-parser [arm64] (jammy-proposed) [1.0.0-1]
[09:07] -queuebot:#ubuntu-release- New: accepted ocaml-odoc-parser [riscv64] (jammy-proposed) [1.0.0-1]
[09:07] -queuebot:#ubuntu-release- New: accepted catgirl [s390x] (jammy-proposed) [2.0-1]
[09:07] -queuebot:#ubuntu-release- New: accepted catgirl [riscv64] (jammy-proposed) [2.0-2]
[09:07] -queuebot:#ubuntu-release- New: accepted grandorgue [armhf] (jammy-proposed) [3.5.0-1-1]
[09:07] -queuebot:#ubuntu-release- New: accepted manpages-l10n [amd64] (jammy-proposed) [4.12.1-2]
[09:07] -queuebot:#ubuntu-release- New: accepted ocaml-odoc-parser [s390x] (jammy-proposed) [1.0.0-1]
[09:07] -queuebot:#ubuntu-release- New: accepted catgirl [armhf] (jammy-proposed) [2.0-2]
[09:07] -queuebot:#ubuntu-release- New: accepted grandorgue [riscv64] (jammy-proposed) [3.5.0-1-1]
[09:07] -queuebot:#ubuntu-release- New: accepted grandorgue [amd64] (jammy-proposed) [3.5.0-1-1]
[09:07] -queuebot:#ubuntu-release- New: accepted ocaml-odoc-parser [armhf] (jammy-proposed) [1.0.0-1]
[09:08] -queuebot:#ubuntu-release- New: accepted catgirl [amd64] (jammy-proposed) [2.0-1]
[09:08] -queuebot:#ubuntu-release- New: accepted catgirl [armhf] (jammy-proposed) [2.0-1]
[09:08] -queuebot:#ubuntu-release- New: accepted catgirl [amd64] (jammy-proposed) [2.0-2]
[09:08] -queuebot:#ubuntu-release- New: accepted ntirpc [arm64] (jammy-proposed) [3.5-1]
[09:08] -queuebot:#ubuntu-release- New: accepted ntirpc [riscv64] (jammy-proposed) [3.5-1]
[09:08] -queuebot:#ubuntu-release- New: accepted ocaml-odoc-parser [amd64] (jammy-proposed) [1.0.0-1]
[09:08] -queuebot:#ubuntu-release- New: accepted catgirl [arm64] (jammy-proposed) [2.0-1]
[09:08] -queuebot:#ubuntu-release- New: accepted ntirpc [amd64] (jammy-proposed) [3.5-1]
[09:08] -queuebot:#ubuntu-release- New: accepted ntirpc [s390x] (jammy-proposed) [3.5-1]
[09:08] -queuebot:#ubuntu-release- New: accepted catgirl [ppc64el] (jammy-proposed) [2.0-1]
[09:08] -queuebot:#ubuntu-release- New: accepted ocaml-odoc-parser [ppc64el] (jammy-proposed) [1.0.0-1]
[09:08] -queuebot:#ubuntu-release- New: accepted ntirpc [ppc64el] (jammy-proposed) [3.5-1]
[09:08] -queuebot:#ubuntu-release- New: accepted llvm-toolchain-13 [amd64] (jammy-proposed) [1:13.0.1~+rc1-1~exp4]
[09:09] -queuebot:#ubuntu-release- New: accepted llvm-toolchain-13 [i386] (jammy-proposed) [1:13.0.1~+rc1-1~exp4]
[09:09] -queuebot:#ubuntu-release- New: accepted llvm-toolchain-13 [s390x] (jammy-proposed) [1:13.0.1~+rc1-1~exp4]
[09:09] -queuebot:#ubuntu-release- New: accepted lomiri-thumbnailer [arm64] (jammy-proposed) [3.0.0-1]
[09:09] -queuebot:#ubuntu-release- New: accepted lomiri-thumbnailer [ppc64el] (jammy-proposed) [3.0.0-1]
[09:09] -queuebot:#ubuntu-release- New: accepted lomiri-thumbnailer [s390x] (jammy-proposed) [3.0.0-1]
[09:09] -queuebot:#ubuntu-release- New: accepted llvm-toolchain-13 [ppc64el] (jammy-proposed) [1:13.0.1~+rc1-1~exp4]
[09:09] -queuebot:#ubuntu-release- New: accepted lomiri-thumbnailer [armhf] (jammy-proposed) [3.0.0-1]
[09:09] -queuebot:#ubuntu-release- New: accepted lomiri-thumbnailer [amd64] (jammy-proposed) [3.0.0-1]
[09:09] -queuebot:#ubuntu-release- New: accepted lomiri-thumbnailer [riscv64] (jammy-proposed) [3.0.0-1]
[09:09] -queuebot:#ubuntu-release- New: accepted django-graphene [amd64] (jammy-proposed) [2.15.0-1]
[09:09] -queuebot:#ubuntu-release- New: accepted grandorgue [amd64] (jammy-proposed) [3.5.0-0-1]
[09:09] -queuebot:#ubuntu-release- New: accepted grandorgue [riscv64] (jammy-proposed) [3.5.0-0-1]
[09:09] -queuebot:#ubuntu-release- New: accepted python-django-parler [amd64] (jammy-proposed) [2.2.1-1]
[09:09] -queuebot:#ubuntu-release- New: accepted foot [amd64] (jammy-proposed) [1.10.3-1]
[09:09] -queuebot:#ubuntu-release- New: accepted node-shell-quote [amd64] (jammy-proposed) [1.7.3+~1.7.1-1]
[09:09] -queuebot:#ubuntu-release- New: accepted grandorgue [ppc64el] (jammy-proposed) [3.5.0-0-1]
[09:09] -queuebot:#ubuntu-release- New: accepted python-djangorestframework-flex-fields [amd64] (jammy-proposed) [0.9.6-1]
[09:10] -queuebot:#ubuntu-release- New: accepted bkchem [amd64] (jammy-proposed) [0.14.0~pre4+git20211228-1]
[09:10] -queuebot:#ubuntu-release- New: accepted highway [amd64] (jammy-proposed) [0.15.0-4]
[09:10] -queuebot:#ubuntu-release- New: accepted indi-mi [arm64] (jammy-proposed) [1.8-1]
[09:10] -queuebot:#ubuntu-release- New: accepted indi-playerone [amd64] (jammy-proposed) [0.4-1]
[09:10] -queuebot:#ubuntu-release- New: accepted indi-playerone [armhf] (jammy-proposed) [0.4-1]
[09:10] -queuebot:#ubuntu-release- New: accepted python-django-pint [amd64] (jammy-proposed) [0.6.3-1]
[09:10] -queuebot:#ubuntu-release- New: accepted grandorgue [s390x] (jammy-proposed) [3.5.0-0-1]
[09:10] -queuebot:#ubuntu-release- New: accepted indi-mi [armhf] (jammy-proposed) [1.8-1]
[09:10] -queuebot:#ubuntu-release- New: accepted ntirpc [armhf] (jammy-proposed) [3.5-1]
[09:10] -queuebot:#ubuntu-release- New: accepted indi-mi [amd64] (jammy-proposed) [1.8-1]
[09:10] -queuebot:#ubuntu-release- New: accepted indi-playerone [arm64] (jammy-proposed) [0.4-1]
[09:10] -queuebot:#ubuntu-release- New: accepted halide [riscv64] (jammy-proposed) [13.0.3-1]
[09:22] <RikMills> morning
[09:23] <RikMills> sil2100: I have a KDE plasma SRU for focal in preparation. will you be able to look at it this week if I upload?
[09:24] <RikMills> note that it is only 14 out of the 40+ plasma source that are beign updated, as only they have actual bugfixes
[09:42] -queuebot:#ubuntu-release- Unapproved: libreoffice (impish-proposed/main) [1:7.2.3-0ubuntu<IP_ADDRESS> => 1:7.2.5-0ubuntu<IP_ADDRESS>] (ubuntu-desktop)
[09:42] -queuebot:#ubuntu-release- New: accepted oem-stella.cmit-deoxys-meta [sync] (focal-proposed) [20.04~ubuntu1]
[09:43] -queuebot:#ubuntu-release- New binary: oem-stella.cmit-deoxys-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (canonical-oem-metapackages)
[09:46] -queuebot:#ubuntu-release- New: accepted oem-sutton.newell-carleton-meta [sync] (focal-proposed) [20.04~ubuntu2]
[09:47] -queuebot:#ubuntu-release- New: accepted oem-stella.cmit-deoxys-meta [amd64] (focal-proposed) [20.04~ubuntu1]
[09:47] -queuebot:#ubuntu-release- New binary: oem-sutton.newell-carleton-meta [amd64] (focal-proposed/none) [20.04~ubuntu2] (canonical-oem-metapackages)
[09:49] -queuebot:#ubuntu-release- New: accepted oem-sutton.newell-carleton-meta [amd64] (focal-proposed) [20.04~ubuntu2]
[09:59] -queuebot:#ubuntu-release- Unapproved: accepted openvswitch [source] (hirsute-proposed) [2.15.2-0ubuntu1]
[09:59] <sil2100> RikMills: hey! Yes, I think I should be able
[10:00] <sil2100> I'm still getting back on track after my EOY-vacation, but I should be able to get back to full force soon
[10:03] <ricotz> hey RikMills sil2100 :)
[10:04] <ricotz> there is a libreoffice SRU ready at https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1956044
[10:14] -queuebot:#ubuntu-release- New binary: log4cxx [amd64] (jammy-proposed/universe) [0.12.1-4] (no packageset)
[10:15] -queuebot:#ubuntu-release- New binary: log4cxx [ppc64el] (jammy-proposed/universe) [0.12.1-4] (no packageset)
[10:15] -queuebot:#ubuntu-release- New binary: log4cxx [s390x] (jammy-proposed/universe) [0.12.1-4] (no packageset)
[10:16] <sil2100> ricotz: let me try getting to it too o/
[10:17] -queuebot:#ubuntu-release- New binary: log4cxx [armhf] (jammy-proposed/universe) [0.12.1-4] (no packageset)
[10:44] -queuebot:#ubuntu-release- New binary: log4cxx [riscv64] (jammy-proposed/universe) [0.12.1-4] (no packageset)
[10:48] <ricotz> sil2100, great thank you o/
[10:51] <ricotz> sil2100, please ignore that the version is lower than in jammy
[11:21] -queuebot:#ubuntu-release- New binary: log4cxx [arm64] (jammy-proposed/universe) [0.12.1-4] (no packageset)
[11:36] -queuebot:#ubuntu-release- New binary: node-browserify [amd64] (jammy-proposed/universe) [17.0.0+ds-1] (no packageset)
[11:50] -queuebot:#ubuntu-release- Unapproved: linux-firmware (focal-proposed/main) [1.187.24 => 1.187.25] (core, kernel)
[12:43] -queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (focal-proposed) [1.187.25]
[13:29] -queuebot:#ubuntu-release- Unapproved: mesa (focal-proposed/main) [21.0.3-0ubuntu0.3~20.04.5 => 21.2.6-0ubuntu0.1~20.04.1] (core, i386-whitelist, xorg)
[14:00] -queuebot:#ubuntu-release- Unapproved: mesa (impish-proposed/main) [21.2.2-1ubuntu1 => 21.2.6-0ubuntu0.1] (core, i386-whitelist, xorg)
[14:01] -queuebot:#ubuntu-release- Unapproved: rejected mesa [source] (focal-proposed) [21.2.6-0ubuntu0.1~20.04.1]
[14:02] -queuebot:#ubuntu-release- Unapproved: rejected mesa [source] (impish-proposed) [21.2.6-0ubuntu0.1]
[14:03] -queuebot:#ubuntu-release- Unapproved: mesa (impish-proposed/main) [21.2.2-1ubuntu1 => 21.2.6-0ubuntu0.1] (core, i386-whitelist, xorg)
[14:04] -queuebot:#ubuntu-release- Unapproved: mesa (focal-proposed/main) [21.0.3-0ubuntu0.3~20.04.5 => 21.2.6-0ubuntu0.1~20.04.1] (core, i386-whitelist, xorg)
[14:05] <tjaalton> sil2100: ^ mesa for 20.04.4, finally..
[14:05] <tjaalton> bugfix release for impish too
[14:33] <cpaelzer> re-ping ubuntu-archive for help on DPDK, a few binaries need to move to universe (librte-compress-isal22, librte-compress-octeontx22, librte-crypto-ipsec-mb22) and armhf isn't build anymore (intentionally) hence we need to remove the former binaries on armhf in jammy (update excuses shows both issues)
[14:47] -queuebot:#ubuntu-release- Unapproved: grub2-unsigned (jammy-proposed/main) [2.06-2ubuntu4 => 2.06-2ubuntu4] (core, i386-whitelist)
[14:54] -queuebot:#ubuntu-release- Unapproved: grub2-unsigned (jammy-proposed/main) [2.06-2ubuntu4 => 2.06-2ubuntu4] (core, i386-whitelist)
[15:15] <sil2100> tjaalton: \o/
[15:18] <mapreri> sil2100: do you think I could trouble you to look at the telegram-desktop SRU situation? :(
[15:20] <mapreri> (it got to the point that besides pinging single people I don't think it will move…)
[15:22] -queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (impish-proposed) [1:7.2.5-0ubuntu<IP_ADDRESS>]
[15:29] <sil2100> mapreri: hm hm, is that some SRU in the queue? I can try looking into it later, but I'd appreciate some context (or pointers to where I can get the context!)
[15:32] <mapreri> sil2100: yes, it's in the queue, and it has been for months.  bug is  LP:#1942699   (also see https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2022-January/019133.html)
[15:50] -queuebot:#ubuntu-release- New: accepted gallery-dl [amd64] (focal-backports) [1.20.0-1~bpo20.04.1]
[15:56] -queuebot:#ubuntu-release- Unapproved: accepted gallery-dl [source] (focal-backports) [1.20.1-1~bpo20.04.1]
[16:46] -queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (impish-proposed) [21.2.6-0ubuntu0.1]
[16:50] -queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (focal-proposed) [21.2.6-0ubuntu0.1~20.04.1]
[16:51] <vorlon> sil2100, bdmurray: the continuous emails about oversized images are annoying; it wouldn't get rid of the emails, but is there any reason for me to not nuke the bionic dailies that are currently out there?
[16:57] <sil2100> vorlon: I can't think of a reason why someone would use the bionic dailies since we stopped building new ones, so I think I'm +1 on that
[17:11] <bdmurray> vorlon: aren't there also issues with the MATE image sizes in that email? It'd be nice to get those bumped Wimpy
[17:24] <vorlon> it sure would; I've pinged multiple times over the past year+ and never gotten a response on IRC
[18:56] -queuebot:#ubuntu-release- Unapproved: ubiquity (focal-proposed/main) [<IP_ADDRESS> => <IP_ADDRESS>] (core)
[20:53] <bdmurray> vorlon: Given that the nvidia-prime version in focal-updates was included on the 20.04.3 installation media could you fully phase it? This will resolve the inconsistency between fresh installs and upgraded systems.
[21:04] <Eickmeyer> General licensing question: is CC-NC ok for inclusion in the archive? Just for the artwork, but it's a question that was presented to me that I'm not 100% on.
[21:04] <Eickmeyer> Would be for a potential package.
[21:44] <Odd_Bloke> doko: slyon: I see you were the two most recent people to touch kpatch; are there any plans to bring in a newer version for the LTS?
[21:48] <vorlon> bdmurray: done
[21:48] <bdmurray> Odd_Bloke: you might check with the person who actually did the 0.8.0 update - Ben Romer
[21:49] <bdmurray> vorlon: thanks!
[21:50] <Odd_Bloke> bdmurray: Fair point; any idea of an IRC nick?
[21:50] <Odd_Bloke> (Matthis mentioned 0.9.2 in his last changelog entry, which is why he got a ping. :)
[21:51] <Odd_Bloke> (I have asked in #ubuntu-kernel, probably the more sensible option.)
[21:53] <bdmurray> Odd_Bloke: it looks like it is ben_r
[22:02] <bdmurray> hellsworth: I noticed that groovy is still in the config.json file for appstream-cloud. Shouldn't it go away with its EoL?
[22:03] <hellsworth> bdmurray: you are most certainly right. let me fix that.
[22:03] <bdmurray> hellsworth: Also hirsute is going EoL next week. Would anything bad happen if it was removed early?
[22:06] <hellsworth> re hirsute, idk so i'm inclined to leave it and make it go away next week :)
[22:07] <hellsworth> bdmurray: i'd like to remove xenial since it reached EOL last April but Laney would have already removed it if there wasn't a reason to keep it. thoughts?
[22:11] <bdmurray> hellsworth: I'm in a meeting for the next 60 minutes. I'll get back to you after that.
[22:11] <hellsworth> np
[22:46] -queuebot:#ubuntu-release- Unapproved: neutron (impish-proposed/main) [2:19.0.0-0ubuntu1 => 2:19.1.0-0ubuntu1] (openstack)
[22:46] -queuebot:#ubuntu-release- Unapproved: octavia (impish-proposed/universe) [1:9.0.0-0ubuntu1 => 1:9.0.1-0ubuntu1] (openstack)
[23:07] <bdmurray> vorlon: actually your unsubscribe script might need an improvement as it just unsubscribed us from raqm which is currently undergoing an MIR for jammy
[23:08] <bdmurray> and swtpm and libtpms


[07:14] <davidcalle> Morning o/
[08:49] <lesamourai> implementing telepathy observer client properties without .client file , any help?(have implemented AbstractClientObserver)
[10:32] <karni> zbenjamin: hey buddy. got a question. how does the qmake project translation extraction work exactly? does it just look for tr() calls? cose I realized on Friday I can't wrap strinsg for translation in tr() calls, because it's a QObject method on its own. I was wondering if you had any suggestions on the matter.
[10:34] <zbenjamin> karni: we use that command xgettext -o $$template_pot.target --qt --c++ --from-code=UTF-8 --add-comments=TRANSLATORS --keyword=tr --keyword=tr:1,2 --keyword=N_
[10:35] <karni> zbenjamin: what is that last one, N_ ? like a C macro?
[10:36] <zbenjamin> karni: tbh i modeled it after the cmake projects which used that, i just applied what the cmake projects do to qmake :(
[10:36] <karni> zbenjamin: but I take N_ is like a C macro? N_("string to stranslate")?
[10:36] <zbenjamin> karni: probably like a define yes
[10:37] <zbenjamin> karni: something like "#define N_(String) gettext_noop (String)"
[10:37] <karni> zbenjamin: cose we can't use QObject's tr() because that's the .ts not .po translations
[10:37] <karni> zbenjamin: right
[10:37] <zbenjamin> karni: yeah right oO
[10:37] <zbenjamin> karni: bad choice to use tr i guess
[10:37] <zbenjamin> karni: anyhow N_ should work
[10:38] <karni> zbenjamin: what about if I need to translate a plural though? I mean, if we have tr and N_, I can't use same for plural translation, can I? (I mean the N_ one) I can't overload macros, right
[10:38] <zbenjamin> karni: maybe i should add a possibility that you guys can pass additional arguments to xgettext
[10:39] <zbenjamin> karni: yeah i guess thats what the tr1:2 should do *facepalm*
[10:39] <zbenjamin> karni: clearly until you guys noone used the tr stuff in C++
[10:40] <karni> zbenjamin: right. turns out, there's a pretty common use case. :( qmake based scope (I know the SDK doesn't provide that template yet though)
[10:40] <zbenjamin> karni: well scopes usually do not use QObjects
[10:40] <karni> actually.. the problem I have is in the push helper
[10:40] <karni> which uses signals/slots
[10:40] <karni> zbenjamin: yes, I take that back
[10:40] <karni> the push helper - translation of notifiation messages
[10:40] <zbenjamin> karni: waaaaait
[10:41] <zbenjamin> karni: did you try to specify the global namespace?   ::tr()  ?
[10:41] <karni> zbenjamin: I have not, not sure how I go about it?
[10:41] <zbenjamin> karni: that tells the compiled not to use the QObjects tr , but I do not know if xgettext still pulls the string
[10:41] <karni> oh
[10:41] <zbenjamin> karni: well in your function just use ::tr("MyString")
[10:42] <karni> ha, I will definitely check it out right now :)!
[10:42] <zbenjamin> karni: lets just hope xgettext speaks proper C++ :D
[10:42] <karni> ;D
[10:44] <karni> zbenjamin: how does that fit into the macro story? I currently have strings wrapped in _(...) in that QObject push helper, and #define _(value) gettext(value)
[10:45] <karni> zbenjamin: if I used ::tr(), would it still be a proper macro call, if I renamed the #define above to tr(...) ?
[10:46] <karni> zbenjamin: parallel question - is the translation of desktop files in qmake projects released already for the 15.04 SDK?
[10:46] <zbenjamin> karni: good question with the macro, however you could have a global function named tr() :D
[10:47] <karni> lol. haha, we're taking this to the extreme. /me will try
[10:48] <zbenjamin> karni: i'm not 100% sure, we currently try to figure out how to release that stuff .... its complicated :D
[11:12] <om26er_> zbenjamin, Hi! what's element is the handle of a slider ?
[11:12] <om26er_> I need to drag the handle for some test
[11:19] <om26er_> t1mp, Hi!
[11:20] <t1mp> om26er: hello. I'm in a meeting for the next 30m
[11:20] <om26er> t1mp, ok, will wait till then.
[11:29] <zbenjamin> om26er: thats a question for t1mp :)
[11:34] <aquarius> Any QML experts around to explain how to do schema version upgrades for LocalStorage sqlite databases? I don't think I understand it.
[11:58] <om26er> t1mp, Hi! are you free :)
[11:59] <t1mp> yeah
[12:00] <t1mp> hmm
[12:00] <t1mp> om26er: it is not good to refer to internal implementation in the tests, normally you have to use the autopilot custom proxy objects for that
[12:00] <t1mp> I see there is no CPO for slider... :(
[12:02] <t1mp> om26er: I'm checking the slider implementation, but the thumb doesn't have an objectName that you can use to select it...
[12:06] <t1mp> om26er: the proper solution is that we add an autopilot CPO for Slider which has a dragTo(value) function
[12:06] <t1mp> om26er: can you report a bug for that on https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit
[12:06] <t1mp> om26er: because you know your specific requirements best
[12:09] <om26er> t1mp, i'll report the bug but whats the element name of the thumb?
[12:09] <om26er> t1mp, right now if i have the slider then I can definitely select the thumb and rely on it
[12:11] <t1mp> om26er: it is an UbuntuShape, but it does not have an objectName
[12:11] <om26er> t1mp, oh, well maybe i can rely on its colors as a secondary parameter ?
[12:12] <t1mp> om26er: http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/src/Ubuntu/Components/Themes/Ambiance/1.3/SliderStyle.qml
[12:13] <t1mp> om26er: do you need to use the thumb for the test? It is also possible to just set the value of the slider
[12:14] <t1mp> om26er: it is not ideal, but the Slider.__styleInstance.thumb Item may work for you? but only until we have the proper CPO
[12:14] <t1mp> because it depends very much on the internals of Slider which may be changed
[12:15] <om26er> t1mp, i need the thumb because I want to slide incremental, relative to the previous position
[12:17] <t1mp> om26er: what I propose is to report the bug, and in your test use Slider.__styleInstance.thumb but add a note there referring to the bug. So if we change the SliderStyle implementation and the test breaks it is easy to track down the problem
[12:17] <t1mp> om26er: or for now use slider.value = slider.value + dv
[12:19] <om26er> t1mp, or the simples is to just add the objectName for the thumb ?
[12:19] <om26er> *simplest
[12:21] <om26er> t1mp, will this work slider.select_single('__styleInstance').select_single('thumb')  ?
[12:22] <t1mp> om26er: you cannot select by id, so we normally add an objectName string
[12:22] <t1mp> om26er: the flaw with adding an objectName is that if we would change the implementation not to have that object any more, then tests will break
[12:22] <t1mp> so having a function in autopilot like Slider.dragThumbTo(value) would be best
[12:23]  * t1mp bbl, lunch.
[12:58] <mhall119> bzoltan: oSoMoN: the ubuntu-sdk isn't installable on wily at the moment because of some unmet oxide dependencies
[12:59] <mhall119> liboxideqt-qmlplugin : Depends: liboxideqtcore0 (= 1.9.1-0ubuntu1) but 1.9.2-0ubuntu<IP_ADDRESS> is to be installed Depends: liboxideqtquick0 (= 1.9.1-0ubuntu1) but 1.9.2-0ubuntu<IP_ADDRESS> is to be installed
[13:12] <aquarius> Saviq, do you understand how DB upgrades in QML LocalStorage are meant to be done? I don't think i get it.
[13:15] <Saviq> aquarius, never did, but looking at the docs... you open the db as usual in the lower version, call .changeVersion(from, to, callback(tx)) on it, and in the call back you perform any sql you need on the transaction passed
[13:16] <Saviq> aquarius, seems it's Web API, so http://www.w3.org/TR/2009/WD-webdatabase-20091029/#introduction has some examples
[13:16] <aquarius> Saviq, yeah. What I don't think I get is... how this builds up. Like... I do openDatabaseSync(name, version), but what happens if it's not *at* the version I supply?
[13:16] <aquarius> ah!
[13:16] <aquarius> that's useful, thank you pal!
[13:17] <Saviq> aquarius, right, it raises, so you probably need to try and catch the exception
[13:17] <Saviq> aquarius, OTOH it will have to be at that version since you need to open it first, and you open a particular version
[13:18] <aquarius> and then loop until I find what version it *is * at? gordon bennett.
[13:18] <aquarius> Once I've worked this out I think I may need to write a blog post explaining it all :)
[13:18] <Saviq> aquarius, so IIUC, you try and open at the highest version, then downgrade until the open call succeeds, and run the upgrade there
[13:18] <oSoMoN> mhall119, indeed there’s no oxide 1.9.2 in wily, only in the vivid overlay PPA
[13:18] <aquarius> Saviq, that makes sense
[13:19] <aquarius> the documentation is utterly, utterly unclear about this :)
[13:19] <oSoMoN> bzoltan, any idea why the ubuntu SDK tries to pull in a version of oxide that’s not available in wily?
[13:19] <Saviq> aquarius, db.changeVersion('', 'foo'...) seems to be used to initialize the db
[13:19] <oSoMoN> chrisccoulson, see ^^, it would be good to push oxide 1.9.2 to wily
[13:20] <Saviq> aquarius, hum hum, actually, open...() will not raise, but create the database
[13:20] <bzoltan> oSoMoN: No idea .. some dependency magic in the deep
[13:20] <aquarius> Saviq, now I'm way confused
[13:20] <Saviq> aquarius, yeah, me too
[13:21] <aquarius> Saviq, this is why I was hoping that someone had done this and documented it :)
[13:21] <Saviq> aquarius, but I'm starting to feel like you need to call changeVersion('', '$expected') to see if the database is fresh
[13:21] <aquarius> http://www.gajdos.sk/ubuntuapps/qml-sqlite-upgradedb-change-db-version-using-changeversion/ is about the only example I can find, and it doesn't explain anything, because he opens the DB with an empty version number
[13:22] <aquarius> and if that's what you're *meant* to do to make anythnig work, then I don't understand why you'd bother designing an API which takes a version number parameter at all :)
[13:22] <Saviq> aquarius, and if so, initialize it, otherwise catch and go down your expected schema numbers
[13:22] <mhall119> oSoMoN: bzoltan: I assume that the SDK is landing in both the overlay PPA and wily at the same time, so any of it's dependencies should be as well
[13:23] <mhall119> oSoMoN: is there any reason not to get oxidd 1.9.2 into wily?
[13:23] <Saviq> now I wonder how do you open a db that's in current schema... changeVersion($current, $current...)??
[13:23] <oSoMoN> mhall119, no other reason than "it hasn’t happened yet"
[13:23] <Saviq> aquarius, http://stackoverflow.com/questions/18052225/db-changeversion-doesnt-work-as-expected
[13:23] <bzoltan> mhall119: oSoMoN: i do not really land on wily... as UITK does not compile on wily due to a gcc black magic
[13:24] <mhall119> bzoltan: we're a month away from release, we should probably make sure the SDK is installable and working :)
[13:24] <aquarius> ah, that looks useful. And by rpadovani too! ping :)
[13:25] <bzoltan> mhall119: there is UITK in wily .. but not as new as on the phone releases
[13:25] <mhall119> bzoltan: ok, that needs to be fixed then
[13:26] <bzoltan> mhall119:  and since wily will _never_ land as an upgrade on any phone/tablet device I have hard time to beleive that it si super urgent to bring up the UITK to the level of the OTA releases on Wily
[13:26] <mhall119> bzoltan: wily is going to be a supported release on the desktop, it will be supported when vivid id EOL, it needs to have the UITK and SDK
[13:26] <bzoltan> mhall119: It would be super nice to see a synced UITK, but the build failure  is way beyond my knowledge
[13:27] <aquarius> "Hi! I'm an Ubuntu app developer, and I'd like to be able to test my application on my desktop before running it on the phone, because it's one thousand times easier to do it that way. Can you explain why the SDK doesn't work on my desktop? I thought we were one Ubuntu now?"
[13:27] <aquarius> there's a reason :)
[13:27] <mhall119> ^^
[13:28] <bzoltan> aquarius: we went through this zillions of time... there is no OS what provides you such developer experience. It is not a sustainable development model
[13:28] <mhall119> bzoltan: no, we went through this in the opposite direction, and we agreed you didn't have to support new development from *old* releases of Ubuntu
[13:28] <aquarius> I get that I, a person who wants to stick on the LTS, get "supported" by having to have a device to test on, but I didn't think that applies to everybody everywhere -- that desktop development of apps is officially declared impossible and not supported...
[13:28] <mhall119> but the Ubuntu SDK *must* be installable and working in the *latest* stable release of Ubuntu
[13:28] <rpadovani> aquarius, pong?
[13:29] <bzoltan> mhall119:  aquarius -> https://developer.ubuntu.com/en/blog/2015/03/18/everything-you-always-wanted-know-about-kits-were-afraid-ask/
[13:29] <aquarius> rpadovani, got a few minutes to talk about version upgrades to QML LocalStorage databases? You seem to be the expert, looking at http://stackoverflow.com/questions/18052225/db-changeversion-doesnt-work-as-expected which is the best documentation anywhere on the internet ;)
[13:30] <mhall119> bzoltan: I can't use a Kit if I can't even install the SDK!
[13:30] <bzoltan> mhall119:  there is a fully functional and working UITK + IDE on Wily
[13:30] <mhall119> bzoltan: no, there isn't, that's what I'm saying
[13:30] <mhall119> apt-get install ubuntu-sdk *fails*
[13:30] <popey> mhall119: in the archive or the ppa?
[13:30] <mhall119> popey: archive + sdk-team PPA
[13:31] <popey> erk
[13:31] <popey> well that's not good
[13:31] <mhall119> following instructions on https://developer.ubuntu.com/en/start/ubuntu-sdk/installing-the-sdk/
[13:31] <bzoltan> mhall119: what is the failure?
[13:31] <rpadovani> aquarius, sure thing, it's  a long time I don' t take a look, but feel free to ask
[13:31] <mhall119> bzoltan: the dependencies issue with oxide I originaly pinged about
[13:32] <bzoltan> mhall119: could you please pastebin the logs?
[13:32] <aquarius> My objection is that even if the SDK is installable, that exact document says " You simply change from the LTS Desktop Kit to the 15.04 based armhf target and you have a whole different compiler toolchain and API set at your service." and should say "don't bother to install any sort of LTS Desktop Kit because you can't use our stuff to develop desktop applications at all; we do phones" :-) But mhall119's issue
[13:32] <aquarius>  is way more important here!
[13:32] <popey> mhall119: seems I dont have that ppa enabled, and sdk works for me (currently) on wily :S
[13:32] <mhall119> bzoltan: http://paste.ubuntu.com/12514263/ is the root cause
[13:33] <aquarius> rpadovani, I don't think I understand how it's all meant to work. Which version number do I pass to openDatabaseSync, for example?
[13:33] <mhall119> priority #1 is to get the package deps fixed so I can isntall the SDK
[13:34] <mhall119> but we still need to have the latest supported UITK working in wily, it's crazy to not have the latest supported version of our own toolkit not working in the latest supported version of our own distro
[13:35] <bzoltan> mhall119: I have  no idea what has caused the dependency problem. It is  not something I have changed ... actually we do not change anything there.
[13:35] <rpadovani> aquarius, that's a good question. I leave "" usually, because it seems it's not used
[13:36] <bzoltan> mhall119: Well.. the UITK issue is related to the toolchain upgrade
[13:36] <rpadovani> aquarius, like LocalStorage.openDatabaseSync("app", "", "", 5000);
[13:36] <mhall119> bzoltan: ok, and that's not in your wheelhouse, fair enough, but who is working on fixing it?
[13:36] <bzoltan> mhall119: but keep in mind that the Desktop environment is _NOT_ supported as runtime environment quite yet.
[13:37] <bzoltan> mhall119:  somebody who made that change and broke the sdk
[13:37] <mhall119> bzoltan: do you know who that is and are you tracking their work on fixing it?
[13:37] <bzoltan> mhall119: I have heard about it just now
[13:38] <bzoltan> mhall119:  I wonder who landed '1.9.2-0ubuntu<IP_ADDRESS>' oxide on Wily ...
[13:39] <mhall119> bzoltan: nobody did, I believe that's the problem I hit
[13:39] <bzoltan> mhall119:  I will check with the CI folks ...
[13:40] <aquarius> rpadovani, ah, so if you want to support upgrades, you *have* to open with a blank version? got it.
[13:41] <bzoltan> and back to aquarius :) my favourite developer :) so... when you are developing an android app on Win10 .. do you expect the app to be running on Windows? I guess no :) When you develop and iOS app OSX, do you expect the app to run on OSX? I think no...because runtime env and devtime env are different.
[13:41] <mhall119> bzoltan: falrse comparison, android never claims to be capable of that
[13:41] <bzoltan> aquarius: and actually we are quite lucky that at certain level we can use the dev environment as runtime
[13:42] <mhall119> we advertise that we do
[13:42] <aquarius> bzoltan, indeed I do not. Because they're running different OSes. We've been very clear that Ubuntu phone and Ubuntu desktop are not different things and it's all one Ubuntu, from IOT devices to phones to tablets to desktops to supercomputers.
[13:42] <bzoltan> mhall119:  and so we should not do either .. because we are not
[13:42] <rpadovani> aquarius, maybe :P
[13:42] <bzoltan> aquarius: that is the target of the convergence ambitions we have. We are moving to that direction, but we are not there
[13:42] <mhall119> bzoltan: that has been our strategy and goal for several cycles now
[13:42] <aquarius> if that's not the case -- if Ubuntu phone and Ubuntu desktop are fundamentally different -- then the message needs changing :)
[13:42] <rpadovani> aquarius, I never studied the thing, I just found a working way
[13:42] <bzoltan> mhall119: and are we there yet? :)
[13:43] <mhall119> bzoltan: we were in vivid
[13:43] <mhall119> and in utopic before that
[13:43] <aquarius> rpadovani, ok, cheers :)
[13:43] <bzoltan> mhall119:  precisely
[13:43] <mhall119> and we should be in wily upon release
[13:43] <mhall119> otherwise we're regressing
[13:43] <bzoltan> mhall119:  and vivid env is not the same as wily or OTA6
[13:44] <seb128> bzoltan, if you don't break forward compat then the wily version of the uitk should be able to run old code just fine
[13:44] <mhall119> I understand the rationale behind using vivid+overlay for phones, rather than upgrading them to wily, but that doesn't give us a pass on supporting wily on the desktop
[13:45] <Laney> do you have some PPAs enabled?
[13:45] <Laney> I don't see an oxide 1.9.2 in the archive
[13:45] <bzoltan> seb128:  it is perfectly compatible that way
[13:45] <mhall119> Laney: it isn't in wily currently
[13:46] <Laney> do you have some PPAs enabled?
[13:46] <Laney> erm, sorry
[13:46] <bzoltan> mhall119:  it is not about giving pass or not... the UITK does not build on wily since few weeks due to the toolchain change.
[13:46] <Laney> where's the uninstallability then?
[13:48] <mhall119> Laney: the ubuntu-sdk package depenency chain as some point required oxide =19.1
[13:48] <mhall119> 1.9.1
[13:48] <Laney> but you have a PPA which is giving 1.9.2
[13:48] <Laney> how's that a problem within wily?
[13:48] <mhall119> not >= 1.9 or >= 1.9.1
[13:49] <mhall119> I have 1.9.2 installed from vivid before I upgraded
[13:50] <Laney> not vivid
[13:50] <Laney> maybe some PPA like the "stable phone overlay"?
[13:50] <seb128> mhall119, https://launchpad.net/distros/ubuntu/+source/oxide-qt
[13:50] <mhall119> Laney: ah, that could be
[13:50] <seb128> 1.9.1 is what is on the different series
[14:01] <mhall119> looks like uninstalling oxide allows ubuntu-sdk to install properly, so just conflicts between the vivid overlay PPA and upgrading to wily
[14:01] <bzoltan> mhall119:  apt-cache policy can tell you where your package is from and what is the competition between installation candidates
[14:01] <mhall119> bzoltan: yup, got it installing now
[14:02] <bzoltan> mhall119: I doubt that overlay PPA is meant or tested for/on desktop
[14:02] <mhall119> bzoltan: it isn't, I installed it to get some latest something
[14:02] <mhall119> bzoltan: so the failure ot install ubuntu-sdk was entirely my fault, not yours :)
[14:03] <mhall119> but still, getting the UITK fixed on wily is important, so glad that things are happening on that front
[14:12] <bzoltan> mhall119: I have checked ... Wily is on rev1627 and the UITK staging trunk is on 1642 ... so the diff is not significant. The  Wily release is two weeks old. So an eary September release from the upstream trunk would not be a shame for 15.10 .. but let's hope that the gcc 5.3 fix will land and Wily gets a UITK update.
[14:13]  * bzoltan is not happy with the new toolchain :(
[14:13] <mhall119> thanks bzoltan, does 1642 contain Ubuntu.Components 1.3?
[14:13] <bzoltan> mhall119:  the 1.3 is already available in Wily
[14:13] <mhall119> cool, that's the most important thing
[14:14] <bzoltan> mhall119:  1.3 was released with rev1510 back in May
[14:14] <mhall119> especially since the new API docs will be pulled from their wily packages
[14:14] <bzoltan> mhall119:  since then we just add more APIs and fix bugs + we do convergence features
[14:57] <karni> zbenjamin: I had to change -g template to -g $${UBUNTU_TRANSLATION_DOMAIN} near the intltool-update call
[14:58] <karni> zbenjamin: also, I'm seeing weird thing that the msgid "Telegram" from all over the app appears twice in the pot file. the second instance is for the desktop file, msgid "Telegram" (app name)
[14:58] <karni> which causes fatal error when calling intltool-update
[14:59] <zbenjamin> karni: hmm
[14:59] <zbenjamin> karni: weird, you see that i just use the commands to update that file
[14:59] <karni> right, I'm looking for where the issue is
[16:27] <lesamourai> i want to run a shell command as root with c++ , tried using system() function , got this ERROR: sudo: no tty present and no askpass program specified
[16:27] <lesamourai> .
[16:29] <ogra_> lesamourai, that is correct ... root is locked down and you would have to provide a UI to sudo to recieve the PIN/PW
[16:30] <ogra_> and even then it would break app confinement i guess ... an app cant actually do anything outside of its installation dir
[16:30] <ogra_> jdstrand, ^^^ right ?
[16:31] <ogra_> (i guess not even via sudo)
[16:32] <lesamourai> its running in unconfined mode , so is it possible?
[16:33] <lesamourai> assuming password and uname are known already
[16:34] <jdstrand> the confinement restricts escalating to root
[16:35] <jdstrand> whether via system installed sudo or something else
[16:35] <lesamourai> its running as 'unconfined'
[16:36] <jdstrand> oh
[16:36] <jdstrand> if it is unconfined there is nothing that would prevent that-- that is a normal running sudo from within your app issue (which I don't have the answer to, but others here might)
[16:37] <ogra_> well, you still need a UI app as askpass command to hand over the password/PIN
[16:37] <lesamourai> I want to run a script as sudo from c++ , username and password to be incorporated withing the script.
[16:38] <ogra_> or dynamically create a shell snippet to point the ASKPASS variable to that echos the PW/PN into sudo
[16:38] <ogra_> lesamourai, see the manpage of sudo (specifically the -A option ) and read up about askpass scripts
[16:39] <lesamourai> Ohk
[16:40] <ogra_> you can ship a shellscript that simply echos the PW/PIN and point to it in the SUDO_ASKPASS env var ... that you need to export to sudo before calling it with -A
[16:41] <ogra_> http://bazaar.launchpad.net/~phablet-team/phablet-tools/trunk/view/head:/citrain see line 96/97 and the sunsequent lines
[16:41] <ogra_> *subsequent
[16:43] <lesamourai> Sorry I am not very pro at that, can you give a tiny example
[16:43] <ogra_> i just did
[16:44]  * ogra_ wonders how to be more detailed than that
[16:46] <lesamourai> I don't understand this part 'point to it in SUDO_ASKPASS en var' , yes it was detailed
[16:46] <ogra_> see what the code above does
[16:47] <ogra_> line 100 is a good example hos you call sudo in that case
[16:47] <ogra_> (everything after "adb shell" )
[16:47] <ogra_> line 96 creates a shellscript that echos the password to stdout
[16:48] <ogra_> line 97 makes that script executable -...
[16:48] <ogra_> line 100 uses sudo with that script to obtain the password from the script
[16:49] <lesamourai> ohk
[16:49] <ogra_> the "script" doesnt need to be shell ... you could as well write a mini C++ thing that prints the PW to stdout
[16:49] <ogra_> "mini"
[16:50] <ogra_> :)
[16:51] <ogra_> important is that you call sudo with -A and that the SUDO_ASKPASS var points to your script/tool/C++ program that echos the PW
[16:51] <lesamourai> I see
[16:52] <ogra_> also be aware that you cant really upload unconfied apps to the store ... (well, you can, but it will never be accepted)
[16:53] <lesamourai> ohk
[16:53] <lesamourai> thank you for helping me understand the concept :)
[16:53] <ogra_> :)
[17:30] <rpadovani> popey, is your branch attached to this bug ready to be merged?
[17:30] <rpadovani> https://bugs.launchpad.net/reminders-app/+bug/1452924
[17:33]  * popey proposes
[17:35] <rpadovani> ty
[17:37] <lesamourai> ogra , prob stays unsolved
[17:38] <lesamourai> script runs fine in terminal , but in C++ ERROR is
[17:38] <lesamourai> sudo: no tty present and no askpass program specified
[17:58] <rschroll> t1mp, zsombi: Do either of you feel like fielding questions on drag-and-drop with the new ListItems?  Or anyone else?
[18:03] <mhall119> rschroll: can you put them in askubuntu and then post the links here? I'm sure the answers you get will be useful to a lot of developers
[18:05] <popey> it doesn't help that tim and zsomb i are in inconvenient timezones for rpadovani
[18:05] <popey> er rschroll
[18:08] <mhall119> that too
[18:13] <rschroll> Whoever I am.
[18:14] <rschroll> Some of them are possible bugs -- I'm not sure about the desired behavior.
[18:14] <rschroll> Is it better to post questions or bugs about them, if I can't check with the devels first?
[18:17] <rschroll> mhall119 or popey ^^
[18:17] <mzanetti> popey, rpadovani: https://code.launchpad.net/~rpadovani/reminders-app/integration/+merge/271846/comments/685038
[18:18] <rpadovani> mzanetti, so set up reminders to accept things from content-hub? We need to set up it also for links
[18:18] <rpadovani> https://bugs.launchpad.net/reminders-app/+bug/1398426
[18:18] <rpadovani> could work for me
[18:18] <mzanetti> rpadovani, it can do most of the things already
[18:18] <mzanetti> IIRC I implemented support for text already
[18:19] <mzanetti> rpadovani, right, links is missing
[18:19] <mzanetti> actually no
[18:19] <mzanetti> contenthub.json says:     "destination": [
[18:19] <mzanetti>         "pictures",
[18:19] <mzanetti>         "links",
[18:19] <mzanetti>         "text"
[18:19] <mzanetti>     ]
[18:20] <mzanetti> rpadovani, ah right... I remember what the issue with that bug is:
[18:20] <mzanetti> rpadovani, the browser supports only "share" but not "export"
[18:20] <rpadovani> oh, I see
[18:20] <mzanetti> and as the notes app is not sharing anything with other people, it's only destination
[18:21] <rpadovani> mzanetti, about my fix: with 'Text' type is possible to set a title?
[18:21] <rpadovani> I'm thinking about exporting an email from Dekko: user expects the note to have the same name of the mail
[18:21] <mzanetti> don't think... it will just append the text to a note
[18:21] <mzanetti> mhm
[18:21] <mzanetti> we could do that, yes
[18:21] <mzanetti> rpadovani, ContentItem has a name field
[18:22] <mzanetti> if dekko sets the subject to that, we could use it for the note title
[18:22] <rpadovani> dinner time, sorry, talk to you later
[18:22] <mzanetti> same here
[18:22] <mzanetti> bbl
[18:23] <mhall119> rschroll: if you can phrase it as "How do I ..." then use askubuntu, but if it's "... doesn't work as expected" file a bug
[18:24] <rschroll> Ok.  I'll make my best judgement.
[18:24] <rschroll> But what I expect and what others expect may not be the same things... :)
[18:25] <mhall119> rschroll: that's fine, others can re-post it somewhere more appropriate if they want
[18:32] <rschroll> First question: http://askubuntu.com/questions/676750/how-do-you-detect-the-end-of-a-live-drag-with-the-new-listitem
[18:41] <rschroll> Second question: http://askubuntu.com/questions/676755/how-do-you-make-the-background-of-a-dragged-listitem-opaque
[18:42] <cwayne> has anyone else found the delete action in a listview has a really small touch target on mx4?
[18:51] <rpadovani> mzanetti, if we want to continue talking I'm available again :-)
[18:56] <rschroll> First bug: https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1498138
[19:03] <rschroll> Second bug: https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1498143
[19:58] <popey> cwayne: yes
[19:58] <popey> cwayne: nik90 had a bug about it on the tookit
[20:03] <cwayne> popey: ah great, thanks
[20:09] <dobey> hmm
[20:09] <dobey> is there an easy way to build multiarch clicks now?
[20:17] <popey> dobey: no, i build all three arches and then smoosh them together with a script
[20:21] <dobey> oh :-/
[20:36] <GreatDanton> Heya, if anyone is familiar with Ubuntu sdk and Pyqt5, I need a little bit of help here:  http://ubuntuforums.org/showthread.php?t=2295677
[20:37] <mzanetti> rpadovani, still around?
[20:37] <rpadovani> mzanetti, sure thing :-)
[20:37] <mzanetti> rpadovani, heh :)
[20:37] <mzanetti> rpadovani, so, what do you think about the suggestion to use ContentItem's title property for the note title?
[20:38] <rpadovani> mzanetti, seems a very good idea, less code on our side and a more strong implementation
[20:38] <mzanetti> rpadovani, I feel like transmitting whole note content through an URI seems abusing it.
[20:39] <mzanetti> rpadovani, also feels fragile when it comes to special chars, escaping etc
[20:39] <rpadovani> agree on all
[20:40] <mzanetti> rpadovani, only odd thing is that we can't share text and image in one go through contenthub (afaik, didn't ever really try)
[20:40] <mzanetti> otherwise we could even include attachments
[20:41] <mzanetti> but the uri-handler wouldn't give us that either
[20:41] <mzanetti> rpadovani, anyhow, if you want to give it a go, the only missing thing should be to actually make use of the title
[20:41] <rpadovani> well, but we can't neither via URI
[20:41] <rpadovani> so we aren't missing a functionality
[20:41] <rpadovani> mzanetti, ok, in next days I'll take a look
[20:41] <mzanetti> rpadovani, this can share text: https://code.launchpad.net/~mzanetti/+junk/contenthubtest
[20:42] <mzanetti> rpadovani, but you probably need to include the title property thing in the contenthub test tool too
[20:42] <rpadovani> mzanetti, okay, if I'm able I'll do a patch
[20:42] <mzanetti> I'm sure you are :D
[20:43] <rpadovani> mzanetti, about https://bugs.launchpad.net/reminders-app/+bug/1485948 I think the only way to fix it I found is deleting note's cache every time user saves it - otherwise, we have to parse the note and calculate a diff - or, again, implement a way to delete from the disk the attachment and then check if the attachmetn has been deleted
[20:43] <rpadovani> so, since deleting the cache when a note is saved is one line change
[20:44] <rpadovani> I think is the better solution atm :D
[20:49] <mzanetti> rpadovani, not happy about your suggestion... but I understand this is a tricky one...
[20:49] <rpadovani> mzanetti, I understand, other possible approaches?
[20:50] <mzanetti> rpadovani, pretty sure this can be fixed by emitting a changed signal in the right place
[20:50] <mzanetti> we need to make the tagline refresh
[20:51] <rpadovani> okay, I'll try to take a look on this direction - but I promise nothing
[21:36] <nemo> mcphail: hey, if you're around, could I have the contents of your ppas.sh ?
[21:51] <mcphail> nemo: http://termbin.com/d86l , if that helps. Won't have time to look at this further for quite a while, though
[22:11] <nemo> mcphail: 'k :-/
[22:12] <nemo> well... maybe I can rope Locutus into trying this


[01:00] <cjohnston> mhall119: daker http://<IP_ADDRESS>/summit-coverage/ not as bad as I figured it would be
[01:16] <daker> :)
[01:24] <daker> nigelb: kick tarmac plz
[12:44] <cjohnston> daker: they still wont be merged
[12:44] <daker> they are now
[12:45] <cjohnston> now that I did something
[12:46] <daker> i mean merged 8 hours ago