[00:17] -SwissBot:#ubuntu-news- ::Security:: Episode 195 @ https://ubuntusecuritypodcast.org/episode-195/
[17:13] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: Unravelling complexity in software-defined vehicles @ https://ubuntu.com//blog/unravelling-complexity-in-a-software-defined-vehicles-industry
[17:45] -SwissBot:#ubuntu-news- ::OMG!Ubuntu:: Want to Hide the Top Bar in Ubuntu? Here’s How @ https://www.omgubuntu.co.uk/2023/05/hide-top-bar-ubuntu (by Joey Sneddon)


[11:19] <wCPO> Should the cloud-init package enable the relevant systemd services or should the user do it?
[12:04] <meena> wCPO: depends?
[12:12] <wCPO> meena: Okay? What is best practice?
[12:13] <wCPO> cloud-init-generator only enables the cloud-init.target, the services still needs to be enabled manually AFAIK
[12:14] <meena> what's cloud-init-generator?
[12:15] <wCPO> meena: https://github.com/canonical/cloud-init/blob/master/systemd/cloud-init-generator.tmpl
[13:34] <smoser> meena: the services are wanted by the target
[13:34] <smoser> so the generator just controls whether or not hte target is active
[13:35] <smoser> so wCPO , the answer to your question is:
[13:37] <smoser>  on systemd system, the package should place the generator (cloud-init-generator) in /lib/systemd/systemd-generators
[13:37] <smoser> and should install the systemd units and target as is.
[13:38] <smoser> the services are 'WantedBy' cloud-init.target
[13:38] <smoser> and the target is not enabled by default.
[13:41] <wCPO> Are you sure? In.my testing the generator enables the target?
[14:18] <Odd_Bloke> The generator wouldn't have to enable the target if it were enabled by default.
[16:30] <johnsonshi_> Good morning folks! The 20.3 release recently exposed a new cloud-init bug that we've picked up from telemetry. The "report ready marker file" was being written before the "report ready call" actually happens while in preprovisioning. There have been several instances where the marker file is written but the report ready call fails. The fix is at https://github.com/canonical/cloud-init/pull/590
[16:52] <Odd_Bloke> johnsonshi: What is the impact of this issue on affected systems?
[17:03] <johnsonshi> Odd_Bloke: Upon the occasional random reboot initiated by the platform, after the VM comes back up, cloud-init sees that the "report ready marker file" already exists. It immediately moves to poll for reprovisiondata instead of attempting to report ready again in preprovisioning.
[17:03] <johnsonshi> This causes several preprovisioned VMs to fail.
[17:04] <Odd_Bloke> Aha, right, I missed "preprovisioning" in your first statement.  Presumably there is no user impact, if you're catching these instances before they're released?
[17:04] <johnsonshi> Yup there is no direct user impact
[17:04] <johnsonshi> They are being caught during preprovisioning of the VMs.
[17:05] <johnsonshi> Hehe the DataSourceAzure codebase is a mess which is why the incorrect report ready marker file bug was missed for years :D
[17:09] <johnsonshi> Odd_Bloke: which we are all working towrads improving. Thanks for the prompt reviews as always!
[17:15] <johnsonshi> Odd_Bloke: We'll be discussing internally and continue monitoring. We'll want to see if it causes too much trouble before evaluating the hot fix approach. I do think they're rare, the cloud images have been out for a week now.
[17:20] <wCPO> Odd_Bloke: So what is best practice? Should I ask the ArchLinux package maintainer to run "systemctl enable cloud-<something>" as part of the installation? The Redhat package does that: https://github.com/canonical/cloud-init/blob/master/packages/redhat/cloud-init.spec.in#L130
[18:01] <meena> I'm very curious to see these new integration tests!!
[18:45] <Odd_Bloke> meena: https://github.com/canonical/cloud-init/pull/592/ is the first test in the new style.
[18:48] <Odd_Bloke> (And https://cloudinit.readthedocs.io/en/latest/topics/integration_tests.html is the documentation.)
[18:49] <meena> Odd_Bloke, that looks really useful
[18:50] <Odd_Bloke> Yeah, falcojr did a really good job with the framework, I think.
[18:58] <Odd_Bloke> falcojr: Very small tweak to the PR template: https://github.com/canonical/cloud-init/pull/597
[19:47] <Odd_Bloke> wCPO: IIRC, an enabled service means "can be started", not "will be started", so I think they should be enabled.  Let me double check what the Ubuntu packaging does.
[19:48] <Odd_Bloke> Yep, looks like it's enabled there too.
[19:49] <meena> Odd_Bloke:  did you create https://bugs.launchpad.net/cloud-init/+bug/1884607 ?
[19:49] <meena> never mind, it's from june
[19:51] <Odd_Bloke> meena: Yep, I reported a bug for every function that needs refactoring, they're all tagged `net-refactor`.
[19:53] <meena> Odd_Bloke: i looked for it the other day, but couldn't find it
[19:56] <wCPO> Odd_Bloke: I see.. The setup.py script should probably "enable" them then..
[20:07] <Odd_Bloke> wCPO: We don't really expect people to use setup.py to install cloud-init into a system on which it should run; that should really be done via distro packages because of how closely integrated into boot cloud-init is, and so setup.py is more of a utility for packagers.
[20:08] <wCPO> Odd_Bloke: I'm not using setup.py the packager is, but setup.py should enable the services right?
[20:09] <Odd_Bloke> wCPO: I'm not familiar with many other projects that have systemd units to install, but I don't believe that would be standard for a setup.py installation: enablement is done by installing symlinks into paths that systemd "owns", and I don't think we can reliably do that in our packaging.
[20:10] <Odd_Bloke> (We don't even do that in our Ubuntu packaging; debhelper takes care of enabling services at install time automatically.)
[20:20] <wCPO> It shouldn't be that hard, but setup.py does not support symlinks it seems.
[20:22] <Odd_Bloke> Right; Python packages can be installed on Windows, they aren't the tool for packaging GNU/Linux system software.
[20:24] <wCPO> Kinda make sense. It would be nice though, if it could be documented that it is expected for the packer to enable the services.


[09:35] <sakrecoer_> hi cfhowlett :)
[09:36] <sakrecoer_> have you thought of a way to let users vote?
[09:40] <sakrecoer_> http://civs.cs.cornell.edu/ seems to be nice, it is zequence recomendation for PL, should work fine for contest?... there is a public vote option...
[09:43] <sakrecoer_> or should only the team vote?
[09:44] <sakrecoer_> hmm... well we still have few weeks to think about it :)
[10:18] <manifolder> good day
[10:22] <cfhowlett> greetings manifolder
[10:22] <manifolder> I just want to say US is my favourite distro. By a mile
[10:23] <manifolder> :P
[10:23] <manifolder> posting from south africa btw
[10:27] <cfhowlett> manifolder, from SA?  Then should you not say "by a kilometer"?  :)
[10:29] <manifolder> hahaha yeah but i'm super westernised
[10:30] <manifolder> anyway how can I contriboot ( I have no real programming xp)
[10:32] <sakrecoer_> hi manifolder :)
[10:32] <manifolder> hi
[10:32] <sakrecoer_> you don't need to be a programmer to contribute
[10:33] <sakrecoer_> for example, documentation could really need a hand :)
[10:34] <manifolder> Documentation for what? like Translation?
[10:34] <sakrecoer_> for example
[10:34] <sakrecoer_> or by making tutorials
[10:34] <sakrecoer_> or by haning arround in the IRC channel and the user list to help other users
[10:35] <sakrecoer_> do you have a Launchpad account?
[10:35] <manifolder> I can defs do that
[10:35] <manifolder> no
[10:35] <sakrecoer_> its a good idea to get one :)
[10:35] <manifolder> I have a lot of downtime at my office so I can hang around the channel
[10:35] <manifolder> and I'm a junior network engi so I'm sure I can poke around the wiki and and fill in stuffs
[10:36] <sakrecoer_> you can create an account here: https://login.launchpad.net/+logi
[10:36] <sakrecoer_> sorry
[10:36] <sakrecoer_> https://login.launchpad.net/+login
[10:36] <sakrecoer_> manifolder: poking arround the wiki would be great!!!
[10:36] <sakrecoer_> here is the wiki: https://wiki.ubuntu.com/UbuntuStudio/
[10:36] <manifolder> this it? https://wiki.ubuntu.com/UbuntuStudio
[10:37] <sakrecoer_> yes :)
[10:37] <manifolder> awesome
[10:38] <sakrecoer_> thank you for joining in! :) look arround, try to have fun and don't be affraid to ask :)
[10:38] <cfhowlett> manifolder, what sakrecoer_ said ...
[10:38] <manifolder> I actually do have an ubuntu one login
[10:39] <sakrecoer_> :) perfect!
[10:39] <sakrecoer_> are you subscirbed to the maling list?
[10:39] <manifolder> do you guys make music? have a soundcloud? what do you do with US
[10:40] <sakrecoer_> i do music and graphics
[10:40] <manifolder> what kind
[10:40] <sakrecoer_> this kind :) http://sakrecoer.com
[10:40] <sakrecoer_> i also use it to operate a little record company: http://basspistol.com
[10:41] <sakrecoer_> (sorry, no httpS yet :(, i've just been lazy...)
[10:41] <sakrecoer_> anyways, manifolder, for offtopic chat, we have #ubuntustudio-offtopic :)
[10:42] <sakrecoer_> no harm done by chatting, but its good to keep clarity here for other users backlog sake :)
[10:42] <manifolder> I have yet to figure out how to have multiple chats in irssi
[10:42] <manifolder> sure sure
[10:42] <sakrecoer_> alt+a number
[10:42] <sakrecoer_> or alt+arrowLEFT/arrowRIGHT
[10:42] <sakrecoer_> ;)
[10:43] <sakrecoer_> for multiple chats in irssi :)
[10:43] <sakrecoer_> to switch between... "channel tabs"
[10:43] <manifolder> thank you based sakrecoer
[10:43] <manifolder> what music is this
[10:43] <manifolder> its tripp
[10:44] <manifolder> trippy*
[10:44] <sakrecoer_> you tell me :) i hope it is a subgenre of "goodmusic" :D
[10:44] <manifolder> lol
[10:44] <manifolder> ok switching over


[00:20] <Fudge> would kubuntu now be accessible for orca use
[20:49] <skaet> hiya - just was wondering if there are any accessibility "blocker" bugs that I should know about?   Before we hit feature freeze, would like to know if there's some that need a little extra "love" to make sure that 12.04 beta is usable.
[20:58] <AlanBell> wonder if we can get an onboard release in
[21:04] <skaet> AlanBell,  Feature Freeze is Feb 16.   possible before then?
[21:05] <AlanBell> just trying to figure out how to contact the devs, might be possible, there is cool stuff in trunk
[21:15] <AlanBell> skaet: bug 927459 (which I think is against the wrong package) might be quite important
[21:15] <ubot2> Launchpad bug 927459 in alsa-driver "[ENS1371 - Ensoniq AudioPCI, playback] Sound volume set to 0 when booting from install CD" [Undecided,Confirmed] https://launchpad.net/bugs/927459
[21:15] <AlanBell> I have seen my system boot to a muted audio
[21:15] <AlanBell> I need to test it a few more times to find out what the exact scenario is
[21:16] <skaet> AlanBell,  thanks!  yes,  I've stumbled into it too, and it is annoying.
[21:16]  * skaet goes to flag it.
[21:30] <AlanBell> skaet: https://answers.launchpad.net/onboard/+question/187227
[21:33] <skaet> AlanBell, coolio.  Will keep an eye open for it.


[08:40] <dholbach> good morning
[13:18] <karname> i install zendstudio 5.5 in ubuntu when i start this program , i see a blank screen of zend studio , what do i do ?
[21:59] <safiyyah> i have a headache from trying to set up java on my hardy
[21:59] <safiyyah> is this the right place?


[14:27]  * ComputerKid sets down his sword by the door "aw man*
[14:27] <ComputerKid> "
[14:57] <ItzSwirlz> meeting time
[14:57] <ComputerKid> Hello
[15:00] <slyon> o/
[15:00] <rbalint> o/
[15:00] <ItzSwirlz> o/
[15:01] <ItzSwirlz> so actually fridge says there are two meetings here.. foundations and translations
[15:01] <ItzSwirlz> (thinking)
[15:01] <bdmurray> Its actually the foundations meeting
[15:01] <bdmurray> #startmeeting Weekly Ubuntu Foundations team
[15:01] <meetingology> Meeting started Thu Aug  6 15:01:43 2020 UTC.  The chair is bdmurray. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:01] <meetingology> Available commands: action commands idea info link nick
[15:01] <rbalint> Lost in Translation ...
[15:01] <bdmurray> #topic Lightning rounds
[15:02] <bdmurray> echo $(shuf -e vorlon bdmurray xnox tdaitx doko sil2100 rbalint infinity mwhudson juliank waveform slyon)
[15:02] <bdmurray> bdmurray sil2100 vorlon tdaitx waveform slyon doko rbalint xnox infinity mwhudson juliank
[15:02] <bdmurray> submitted RT 127091 re autopkgtest, nova, and Canonistack
[15:02] <bdmurray> sponsored oops upload for waveform
[15:02] <bdmurray> investigated, tested a fix, and submitted a PR for LP: #1887544
[15:02] <ItzSwirlz> ?
[15:02] <vorlon> (skip me for a bit, in another meeting that's running over)
[15:02] <bdmurray> investigated, tested a fix (or two), and uploaded a fix for LP: #1889449
[15:02] <bdmurray> uploaded the above fix to the Focal SRU queue
[15:02] <bdmurray> investigation into and testing of LP: #1888916
[15:02] <bdmurray> investigation into daisy units OOPS'ing with crashes from whoopsie in -security
[15:02] <slyon> ItzSwirlz: its the foundations meeting
[15:03] <bdmurray> uploaded apport SRU fixing LP: #1861451 and LP: #1872059
[15:03] <bdmurray> ✔ done
[15:03] <bdmurray> tdaitx:
[15:03] <tdaitx> * openjdk-8 security update
[15:03] <tdaitx>   - packaged 8u265-b01, relased yesterday by security team
[15:03] <tdaitx>   - reduced build time test failure retries from 3 to 2
[15:03] <tdaitx>   - filtered some long running tests to improve autopkgtest and build times for armhf (clientvm, 21h -> 8h), powerpc (zerovm 42h -> 11h), and s390x (zerovm, 11h -> 3h)
[15:03] <tdaitx> * jck-11
[15:03] <tdaitx>   - update runtime testsuite job to use the know-to-pass tests baseline to detect regressions (while ignoring know failures)
[15:03] <tdaitx>   - jtdiff/jtreg 4.2 on bionic wrongly reports a diff for tests that passed, which is totally weird and not expected, does not happen on focal (jtreg 5.0)
[15:03] <tdaitx> (done)
[15:03] <slyon> - Upgrade testing 18.04 to 20.04.1 on 2nd notebook
[15:03] <slyon> - Prepared "Call for testing: iwd" discourse post & testplan
[15:03] <slyon>   * used upgraded notebook to test/verify the steps involved
[15:03] <slyon> - Reviewed ubuntu-release-upgrader, MP#388513
[15:03] <slyon> - Prepared debdiffs for command-not-found (groovy & focal)
[15:03] <slyon>   * bug #1875760, needs review/sponsoring
[15:03] <slyon> [15:03] <slyon> - User support on AskUbuntu/IRC
[15:03] <slyon> - Appended OVS spec for global settings tagging
[15:03] <slyon> - Got initial feedback for the NM plugin
[15:03] <slyon>   * only the basics were tested, working so far
[15:03] <slyon> - Merged IP addr labels, PR#89, bug #1743200, bug #1803203
[15:04] <slyon> - Debugged "OVS broken on first boot" issue
[15:04] <slyon>   * integration problem with cloud-init, bug #1870346
[15:04] <slyon>   * description & discussions in PR#157
[15:04] <slyon> - Continued working on Wireguard PR#113 a little
[15:04] <slyon>   * Finalized integration test for NM & networkd
[15:04] <slyon> (done)
[15:05] <bdmurray> doko:
[15:05] <doko> will go last, sorry
[15:05] <bdmurray> I think vorlon already called last. ;-)
[15:05] <bdmurray> rbalint:
[15:05] <vorlon> I'm here now, don't have to be last :)
[15:05] <rbalint> * verified unattended-upgrades SRU
[15:05] <rbalint> * partner work
[15:05] <ItzSwirlz> Pick one anyone, today's your lucky day
[15:05] <rbalint> * poked systemd through migration
[15:06] <rbalint> * +1 maintenance
[15:06] <rbalint> * uploads via Debian: unattended-upgrades 2.6 & 2.7
[15:06] <rbalint> * merged 246-2ubuntu1, uploading...
[15:06] <rbalint> * testing glibc 2.32
[15:06] <rbalint> * prepared glibc SRU for focal
[15:06] <rbalint> * bug gardening
[15:06] <rbalint> (done)
[15:06] <bdmurray> "gardening"?
[15:06] <bdmurray> there must be a better phrase
[15:06] <bdmurray> xnox:
[15:06] <xnox> Uploaded better resolved integration across isc-dhcp, ifupdown, resolvconf
[15:07] <xnox> Upload micorcode-initrd source NEW to allow microcode updates with initrd-less boot LP: #1890612
[15:07] <xnox> Prepared dual-signed & boothole proof UC20 gadget
[15:07] <xnox> Backport finalrd to xenial and provide a sample core16 build for Devices team to try with customer to help with shutdown issues
[15:07] <xnox> Worked with lukas on systemd vs cloud-init vs netplan.io units
[15:07] <xnox> Boothole retrospective and actions out of that.
[15:07] <xnox> Slacked on proposed migrations / transitions....
[15:07] <xnox> done
[15:07] <vorlon> I'll go
[15:07] <bdmurray> juliank:
[15:07] <vorlon>  * short week, was out Tuesday
[15:07] <vorlon>  * work on the fallout from hole-in-boot (LP: #1889556)
[15:07] <vorlon>  * +1 maintenance yesterday/today
[15:07] <vorlon>  * thinking about full-disk encryption in clouds
[15:07] <vorlon> (done)
[15:07] <juliank> * back from PTO last week
[15:07] <juliank> * shim uploaded to groovy  (LP: #1864223)
[15:07] <juliank> * apt: investigated doko's debian bug 967044 about rdepends not handling arch qualifiers
[15:07] <juliank> * apt: various http "fixing"
[15:07] <juliank> * grub for groovy (LP: #1831789, LP: #1878541, LP: #1878705, LP: #1882663)
[15:08] <juliank> grub SRU coming shortly, want to test a bit
[15:08] <juliank> (done)
[15:08] <bdmurray> vorlon:
[15:08] <vorlon> bdmurray: already snuck mine in above ;)
[15:08] <doko> - groovy test rebuild, pinged teams about ftbfs in main
[15:08] <doko> - investigated three gcc ICEs, armhf, s390x
[15:08] <doko> - GCC/python backports for groovy now ready to start the test rebuild
[15:08] <doko> - some MIR work
[15:08] <doko> - some merges
[15:08] <doko> - Debian now removed the python package as well, so we should be able to sync python2 related stuff again
[15:08] <doko> (done)
[15:09] <bdmurray> vorlon: Oh I knew that, I'm totally paying attention.
[15:09] <bdmurray> Any questions on status?
[15:10] <ItzSwirlz> for so far?
[15:10] <ItzSwirlz> (what we've been talking about)
[15:10] <bdmurray> okay, moving on
[15:10] <bdmurray> #topic Release incoming bugs
[15:10] <bdmurray> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-gg-incoming-bug-tasks.html#foundations-bugs
[15:11] <bdmurray> bug 1864571 isn't in the foundations section but caught my eye
[15:12] <bdmurray> This has been tagged rls-gg-incoming but it's really a regression bug
[15:12] <bdmurray> We should still card it as its our SRU though
[15:12]  * vorlon nods
[15:13] <bdmurray> tags fixed
[15:13] <bdmurray> bug 1887098
[15:13] <bdmurray> Are we going to do something about this?
[15:13] <ItzSwirlz> I think we're fine as long as the Python versios are specific, but what do I know
[15:15] <xnox> ItzSwirlz:  hi, this meeting is for ~ubuntu-foundations members only. If you have any topics to bring up, you may do so, at the end of the meeting under AOB.
[15:20] <bdmurray> Okay, let's take this
[15:20] <bdmurray> The other bug is the dbus desktop one
[15:20] <xnox> it's more than just symlinks
[15:21] <xnox> but yeah.
[15:21] <bdmurray> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ff-incoming-bug-tasks.html#foundations-bugs
[15:21] <mclemenceau> ok bdmurray, carded it
[15:21] <bdmurray> I don't see anything new here
[15:22] <xnox> i think all of them were discussed / are in progress no?
[15:22] <xnox> do we just need to card them all?
[15:22] <bdmurray> there are a couple that were already carded
[15:22] <bdmurray> so I've sorted out there tags
[15:22] <bdmurray> their
[15:23] <bdmurray> I think we talked about not fixing the irssi
[15:24] <vorlon> well apparently I'm affected
[15:24] <vorlon> so I might upload it
[15:25] <bdmurray> okay, but it doesn't seem worth carding
[15:25] <vorlon> ok
[15:26] <bdmurray> #topic Team proposed-migration report
[15:26] <vorlon> [LINK] https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#foundations-bugs
[15:26] <vorlon> numbers are going the wrong direction
[15:27] <vorlon> please make sure that if you're taking one of these that you make the time to work on it over the next week
[15:27] <rbalint> how about disabling tests in vim or in all packages on risc? ;-)
[15:27] <vorlon> vim is ... stuck with me I guess since no one else wanted it
[15:27] <vorlon> so we'll see
[15:28] <vorlon> bdmurray: mpfr4?
[15:28] <bdmurray> right
[15:29] <vorlon> sounds like doko is taking lintian because it needs some archive promotions to fix the failures
[15:29] <doko> ok
[15:29] <xnox> werkzeug is me
[15:29]  * vorlon nods
[15:30] <vorlon> dbus-python is mine again; I started working on the upload of the package that needed to drop python2 support, but I don't remember where it got to
[15:30] <xnox> bdmurray:  did you work on mercurila pygments?
[15:30] <xnox> i had gpgme1.0 and autodep8
[15:30] <bdmurray> xnox: I've recreated it a bit the mercurial tests are flaky
[15:30] <vorlon> gpgme1.0 was waveform, but he's out this week
[15:30] <bdmurray> #topic Team proposed-migration report
[15:31] <xnox> bdmurray: skip them and reupload?
[15:31] <bdmurray> wow
[15:31] <bdmurray> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956697
[15:31] <vorlon> bdmurray: so should we hint to ignore the tests?
[15:31] <xnox> cool
[15:31] <xnox> vorlon:  i think that's for the best.
[15:31] <rbalint> i also have several hints ready to be merged
[15:32] <vorlon> hinted mercurial
[15:33] <vorlon> xnox: autodep8 yours?
[15:33] <vorlon> slyon: you had software-properties last week; you still good to work on it?
[15:33] <vorlon> (and get it done this week)
[15:33] <slyon> vorlon: yes its on my list
[15:34] <vorlon> ok
[15:34] <vorlon> gce-compute-image-packages is mine, I had worked on it but apparently didn't get to the bottom of it
[15:34] <vorlon> icu... is the big transition
[15:34] <rbalint> vorlon, i guess the deps of gce- are mine
[15:34] <vorlon> elfutils is new
[15:35] <vorlon> rbalint: ah are these MIRs? Yeah I'll let you have this
[15:35] <rbalint> vorlon, do you plan filing all mirs?
[15:35] <vorlon> rbalint: pass ;)
[15:35] <slyon> vorlon: well actually, last week we decided to leave software-properties with the uploader (tsimonq2), shall I take it anyways?
[15:35] <vorlon> slyon: oh ok - yeah leave it with uploader
[15:35] <slyon> k
[15:35] <vorlon> elfutils vs makedumpfile - xnox do you want this?
[15:36] <rbalint> makedumpfile is flaky and i've filed a hint
[15:36] <xnox> vorlon:  sure.
[15:36] <vorlon> dpkg.. a couple of flaky tests, but sbuild seems to have regressed on all archs and needs looked at
[15:36] <vorlon> slyon: do you want this one?
[15:37] <slyon> yes. I take that
[15:37] <vorlon> json-c is also entangled with icu et al
[15:37] <vorlon> new glibc upload with a bunch of tests that need retried / burned down
[15:37] <xnox> vorlon:  slyon: sbuild regression, is actually procenv FTBFS with gcc-10, and i thought there was a bug against that in Debian / upstream. Fix procenv, unbreak sbuild, let stuff migrate.
[15:37] <rbalint> i'm on it, filed hints
[15:37] <vorlon> rbalint: is this yours to follow up on?
[15:37] <doko> my understanding is that we go directly to glibc 2.32?
[15:37] <vorlon> rbalint: ack
[15:37] <rbalint> bug would like to get glibc dropped
[15:38] <rbalint> but
[15:38] <vorlon> "dropped"?
[15:38] <slyon> xnox: thanks I will have a look at that
[15:38] <vorlon> cmake vs cups
[15:38] <rbalint> vorlon, from -proposed, because it is buggy and i'm preparing the next upload
[15:38] <vorlon> juliank: can you take this one?
[15:38] <juliank> ack
[15:38] <vorlon> rbalint: ah, I'll just remove it now then
[15:39] <vorlon> tdaitx: openjdk-8/armhf blocking cups, is this something you want to look at?
[15:39] <tdaitx> vorlon: yeah
[15:40] <doko> vorlon: that trigger is bogus
[15:41] <doko> stop triggering on all openjdk versions
[15:41] <vorlon> s390-tools and fwupd-signed are suspicious since they both involve signed binaries
[15:41] <doko> it's *always* run against the default openjdk
[15:41] <vorlon> doko: I haven't special-cased anything here
[15:41] <doko> it's in the britney code ...
[15:41] <vorlon> Impossible Depends: s390-tools -> libcrypto1.1-udeb/1.1.1f-1ubuntu3/s390x
[15:41] <xnox> huh?!
[15:43] <vorlon> possibly just a component-mismatch on the udeb, mislabeled
[15:43] <rbalint> i carded plymouth/systemd because it is a test bug in systemd
[15:45] <vorlon> mpclib3 just depends on mpfr4, already discussed
[15:45] <vorlon> plymouth/systemd, I guess is rbalint
[15:45] <vorlon> doxygen vs ghostscript: sil2100 could you take?
[15:47] <sil2100> Sure!
[15:47] <vorlon> util-linux vs gfs2-utils, I'll take
[15:47] <vorlon> and I think we'll stop there
[15:48] <vorlon> bdmurray:
[15:48] <bdmurray> #topic AOB
[15:48] <doko> https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20200728-groovy-groovy.html#foundations-bugs
[15:48] <bdmurray> I'll take whoopsie
[15:49] <slyon> I'll take netplan (already prepare a patch for it, needs sponsoring)
[15:49] <sil2100> Just assign 5 random packages from the list to me! Or can I pick those?
[15:51] <xnox> doko:  ok, need to screen them to exclude those without proposed, and then will do a lottery.
[15:53] <bdmurray> Alright
[15:53] <bdmurray> #endmeeting
[15:53] <meetingology> Meeting ended Thu Aug  6 15:53:06 2020 UTC.
[15:53] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2020/ubuntu-meeting.2020-08-06-15.01.moin.txt
[15:54] <rbalint> for AOB, i'll be out tomorrow
[16:53] <ItzSwirlz> Hello everyone
[16:53] <ItzSwirlz> Comm council


[00:41] <cjwatson> wgrant,mwhudson: 0 5,11,17,23 * * *
[00:42] <mwhudson> yummy cron syntax
[00:42] <mwhudson> every 6 hours, at a wild guess one hour offset from when gina runs?
[00:43] <cjwatson> gina is 05 4,10,16,22 * * *
[00:43] <cjwatson> so close enough, yes
[00:45] <Unit193> mwhudson: Is 42 */3 * * * any more fun? :3
[00:45] <mwhudson> Unit193: no it's all terrible
[00:45] <mwhudson> apart from @daily, @hourly etc i can remember what those mean :)
[00:46] <Unit193> Or @reboot in that case.
[01:42] <raymod2> Does anyone know how to send a drag-n-drop event to another application programatically?
[01:43] <raymod2> I'm trying to send multiple *.kml files to google earth to be displayed on the same map.  But when I use g_app_info_launch_default_for_uri() the 2nd and subsequent files are rejected and google earth emits an error saying that an instance is already open.
[01:45] <dobey> that's not DnD; seems like a bug in google earth that it doesn't support taking multiple kml files as command line args
[01:47] <raymod2> dobey - well the reason I am looking into DnD is because I can drag and drop additional *.kml files into the google earth window
[01:48] <raymod2> So I thought maybe my application can somehow send DnD events to a running instance of Google Earth to get it to do what I want.
[01:48] <raymod2> (rather than g_app_info_launch_default_for_uri)
[01:49] <dobey> well i'm not sure what you're trying to do exactly. why are you using g_app_info_launch_for_uri()?
[01:50] <raymod2> That's how I send the first *.kml file to Google Earth.  It launches a new window and the KML is displayed properly.
[01:50] <dobey> what happens if you run "google-earth foo.kml bar.kml" ?
[01:51] <dobey> faking DnD is not the right answer here. it's certainly possible, but quite ugly and would be very disturbing for any user of your app
[01:52] <raymod2> Hmmm, it says cann't open file for reading.
[01:52] <dobey> well, where foo.kml and bar.kml are two of the URIs you're trying to pass to google earth
[01:53] <dobey> and google-earth is whatever the actual command for running google earth is
[01:53] <dobey> but i don't think you want to run g_app_info_launch() anyway
[01:53] <raymod2> I hadn't tried opening a *.kml directly from a terminal prompt.  It doesn't work that way.
[01:53] <dobey> what doesn't work that way?
[01:54] <raymod2> It only seems to work with g_app_info_launch_default_for_uri().
[01:54] <raymod2> When I pass the *.kml on the command line Google Earth launches but then displays a dialog saying it can't open the file for reading.
[01:55] <raymod2> Just running "google-earth foo.kml" fails every time.
[01:55] <dobey> well, what does "xdg-open foo.kml" do then?
[01:55] <raymod2> Yes, that works.
[01:56] <dobey> and what happens if you do that while google earth is running?
[01:57] <raymod2> That tries to launch a new instance of Google Earth which outputs an error about another instance running - then the new instance crashes.
[01:57] <raymod2> "Google Earth appears to be running already. Please kill the existing process, or delete /home/dan/.googleearth/instance-running-lock if this is an error."
[01:58] <dobey> so then google earth is broken and doesn't support any rpc to tell it to open another file i guess
[01:59] <raymod2> sounds like it.... but what about my DnD idea?
[02:01] <raymod2> I don't think Google cares about Linux so I suppose I need to find some hack to work around this.
[02:02] <dobey> well i don't know what you're app is doing exactly, but i would suggest not relying on google earth being installed
[02:03] <raymod2> Well, it might be too much work to write a Google Earth clone from scratch!
[02:04] <raymod2> And how is it you don't know what my app is doing exactly?  I said what it is trying to do.  Load multiple *.kml files into Google Earth and display them simultaneously.  Do you know what a KML is?
[02:04] <dobey> i know what a kml is. i don't know why you're writing an app to load kml files into google earth, when google earth already internally has support for loading kml files
[02:04] <raymod2> Also, why do you keep saying I shouldn't use g_app_info_launch_default_for_uri() for this?  That seems like exactly what this API is for.
[02:05] <raymod2> dobey, my app generates the KML files.  I want to display them without writing Google Earth from scratch.
[02:05] <dobey> because you want to pass multilpe URIs, not run N instances of google earth (or whatever mapping app might be installed)
[02:06] <dobey> i presume you are using gtk+ or gnome libs?
[02:06] <raymod2> Well, I want to add these *.kml files at different times.  Not all at once.
[02:06] <raymod2> Yes, I am using GTK+ which of course gives me access to glib APIs.
[02:07] <dobey> you might want to look at using libchamplain, which provides a map widget, and i think has support for loading kml data
[02:08] <raymod2> That sounds like it will be a degraded user experience.  I've already got this working in Windows and OSX.  I'm just trying to port my application to Linux.
[02:09] <raymod2> I thought this would be easy since I am using GTK+.  Boy was I wrong.
[02:09] <raymod2> (this issue is one of many!)
[02:09] <raymod2> ...but it seems to be the last roadblock
[02:14] <raymod2> Why do you think DnD is a bad idea?  It seems to be my only hope.
[02:15] <dobey> because having the mouse move randomly across the screen is never good
[02:16] <dobey> and becasue it only increases the dependency on google earth existing
[02:16] <raymod2> I wasn't suggesting taking control of the mouse.  Surely there is an ABI for this.
[02:16] <dobey> how else would DnD work?
[02:17] <raymod2> How does the file manager send the DnD to the open application?  It doesn't need a user and a mouse to do this.
[02:17] <dobey> you have to initiate a drag, move the mouse to the other window, and then drop
[02:18] <dobey> i don't think what you are calling DnD, is DnD
[02:19] <raymod2> DnD is just a form of interprocess communication.  The details of mouse pointers and mouse clicks is just a user input method that directs the application to what the user wants.  Then the application initiates the actual DnD somehow programmatically.
[02:19] <raymod2> Presumably the window manager plays a part in all this.
[02:20] <dobey> DnD is not "just a form of IPC"
[02:21] <raymod2> My application accepts DnD events so I am not ignorant to how it works.  I need to send one rather than receive one.
[02:27] <raymod2> Does anyone else have anything to add?  I don't think dobey can help with this.
[04:10] <RAOF> raymod2: It *is* possible to send DnD events programattically, but this means you'll need to be implementing (one or more of) the (three) X11 DnD protocols.
[06:35] <tjaalton> anyone using apt-mirror to mirror trusty? it's giving weird errors here..
[06:42] <tjaalton> looks like the skel-directory was corrupt
[06:47] <sarnold> tjaalton: can you pastebin something? there were problems with the archive mirrors ~38 hours that might have caused trouble on downstream mirrors.. that problem should have been resolved 'everywhere' by now though
[06:49] <tjaalton> sarnold: nah this was there for some time now, I'll let it sync the mirror before checking again. at least the skel-directory looks better now
[06:49] <wgrant> skel-directory?
[06:49] <tjaalton> I think it's a local cache for apt-mirror
[06:49] <sarnold> tjaalton: btw, skel-directory? my (not atp-mirror based mirror) doesn't have anything matching '*skel*dir*' ..)
[06:49] <sarnold> ahh
[06:49] <wgrant> Ah
[06:49] <wgrant> Yeah, not an actual thing.
[06:49] <tjaalton> once it's in a consistent state the files are copied to the proper place
[06:50] <tjaalton> one thing I noticed though is that we're not generating Contents files like debian?
[06:50] <wgrant> Debian moved their Contents files a while ago, and we haven't followed suit.
[06:50] <tjaalton> right
[06:50] <tjaalton> ok
[06:50] <tjaalton> is it planned?
[06:50] <wgrant> Specifically, Debian's are now per-component.
[06:51] <wgrant> We have no specific plans to follow that change.
[06:51] <wgrant> But we're also not explicitly not.
[06:51] <tjaalton> okay
[06:51] <wgrant> There's just no pressing need to do that work, as far as we can tell.
[06:52] <tjaalton> what about doing .xz files?
[06:53] <tjaalton> Packages
[06:53] <wgrant> xenial added xz and dropped bz2.
[06:53] <wgrant> http://archive.ubuntu.com/ubuntu/dists/xenial/main/binary-amd64/
[06:53] <tjaalton> ah, indeed
[06:58] <seb128> slangasek, what's the status of https://launchpad.net/ubuntu/+source/command-not-found/0.3ubuntu16.04.1 ? there is no SRU bug so it looks like nobody in the SRU team is going to copy that over to updates, should a new upload be done? or the SRU team convinced to copy it without associated bug?
[10:16] <caribou> If I need to force an update of a package (kexec-tools) when new kdump-tools is installed, is a versionned Depends: sufficient or do I also need to add a Breaks: ?
[10:25] <rbasak> caribou: a versioned Breaks is sufficient I think, if a newer version of kexec-tools is available. A Depends would additionally force both packages to be installed.
[10:26] <caribou> rbasak: I'm currently using only a versionned depends which works correctly
[10:26] <caribou> rbasak: just curious to know if the Breaks is better
[10:28] <rbasak> I don't think you need the Breaks, at least not for that specific requirement.
[10:28] <rbasak> Are you familiar with https://wiki.debian.org/PackageTransition? It should cover most cases.
[10:34] <caribou> rbasak: that's what I tought also
[10:34] <caribou> rbasak: I think I read this one recently; I went through so much of the Debian documentation lately that I'm a bit lost in what I read or not
[10:37] <caribou> rbasak: thanks; I read part of it earlier but now it outlines another change in kexec-tools that needs to go in.
[10:37] <caribou> rbasak: so you are correct; according to that, only a Depends: is sufficient
[12:28] <brendand> can anyone think why there might be a clock skew from the host on a adt-virt-qemu created vm?
[12:40] <brendand> for some reason it seems to be a few hours behind the host time
[13:27] <caribou> Is it good practice to use distribution-specific variables (like $dist.Depends} in debian/control to avoid delta b/w Ubuntu and Debian ?
[13:28] <caribou> I have one kexec-tools dependancy that is specific to an Ubuntu delta that I'm getting rid of, but I'd like to avoid a delta in the depending package
[13:29] <caribou> sorry for all those questions, but I _really_ want weed out as much delta as possible b/w kdump-tools & kexec-tools
[13:42] <Odd_Bloke> I'm trying to add an upstart job (on trusty) between networking coming up and cloud-init running; cloud-init-nonet has "stop on static-network-up" and cloud-init has "start on ... and stopped cloud-init-nonet"; if I set "start on stopping cloud-init-nonet" will my job block cloud-init running?
[13:42] <Odd_Bloke> smoser: (You might be able to help me with ^)
[13:43] <smoser> probably not
[13:43] <Odd_Bloke> smoser: Do you know of a way of doing it?
[13:45] <smoser> looking
[13:46] <smoser> xnox, ^ ?
[13:46] <Odd_Bloke> xnox is on a boat this week, I believe.
[13:46] <smoser> hm.
[13:48] <smoser> Odd_Bloke, starting should work
[13:48] <smoser> (man starting)
[13:48] <smoser> init(8) will wait for all services started by this event to be running,
[13:48] <smoser> and maybe stopping too
[13:48] <smoser> as it has similar text.
[13:49] <smoser> so yes, i think you're right
[13:49] <smoser> i'd give it a try with a task that does sleep 90
[13:49] <Odd_Bloke> OK, I'll try putting a sleep in and see if things block as... that.
[13:49] <Odd_Bloke> ^_^
[13:50] <Odd_Bloke> smoser: Ah, http://upstart.ubuntu.com/cookbook/#task also has some relevant text.
[13:55] <Odd_Bloke> smoser: Yep, "start on starting cloud-init" and "task" blocks cloud-init from starting until the "script" block is done.  Thanks for the help!
[13:59] <Odd_Bloke> smoser: (And without "task" it doesn't block)
[14:01] <smoser> you could have probalby done it without task and a pre-start
[14:01] <smoser> but task is probably right
[14:01] <smoser> if it is somethign that shoudl run to completion and be done
[14:01] <smoser> like sleep 90
[14:01] <smoser> :)
[15:21] <nacc> slangasek: general question for you -- historically (and currently), do syncs occur from any release of Debian or primarily current testing, unstable and experimental? How exactly does experimental work? Are publishes in experimental considered part of the history of unstable (but a place to 'test' things for unstable?) I ask because the changelog entries for releases in each refer to the other series,
[15:22] <nacc> so I'm trying to decide how best to handle them in the importer
[15:22] <nacc> sigh, /me googles and maybe finds the relevant answers
[15:35] <infinity> nacc: autosyncs happen from unstable.  Manual syncs can happen from any of the three.
[15:35] <nacc> infinity: got it
[15:36] <infinity> nacc: A manual sync from experimental, however, will *not* track experimental, so manual syncing is required from thereon until unstable has a higher version.
[15:36] <infinity> (Perhaps a misfeature, but one we've lived with for a decade)
[15:36] <nacc> infinity: ah sure, that makes some sense, at least
[15:36] <nacc> infinity: luckily i'm not too worried about the process, i'm just trying to recreate the history in git :)
[15:37] <nacc> infinity: and our 'parent verification' doesn't work with debian's process yet, so i'm just trying to get my head around it
[15:37] <infinity> nacc: As for the Debian history of a package, that's muddier, as it's maintainer dependant.  Some people scrub experimental from history when uploading to unstable, some people don't.
[15:37] <nacc> infinity: yeah, that's what i'm noticing :)
[15:38] <nacc> infinity: up until now, we were only importing 'sid' explicitly ... but that led to us not finding syncs directly from experimental, if they never got pulled into sid at any time, so i'm adding experimental as a first step, but i'm realizing they are more intertwined than the ubuntu notion of series, so our existing code doens't dtrt
[15:38] <infinity> nacc: And to make it more exciting, some people will have revisions in there that have never existed in the Debian archive.  So, attempting to create a commit/tag for that revision won't work out too well. :P
[15:39] <nacc> infinity: yeah we've seen that a few times already :)
[15:39] <nacc> infinity: we only go of spph right now for creating tags
[15:39] <nacc> infinity:  we just do some sanity checks off the changelog entries
[15:41] <rlaager> nacc: By any chance, are you working on version control for all packages in the archive, with imports from Debian?
[15:42] <infinity> I suspect he's only working on a small subset he cares about.
[15:42] <infinity> Unless he's decided to do LP dev work and is actually making git package imports a thing for everyone.
[15:43] <nacc> rlaager: it works for any package
[15:43] <nacc> infinity: starting small, but there's no reason it can't be used by others :)
[15:43] <nacc> there are lots of corner cases :)
[15:43] <cjwatson> when I was doing version tracking in debbugs I decided that the correct thing to do was to infer the history from changelogs
[15:43] <infinity> nacc: You might want to poke cjwatson/wgrant and see if this overlaps with any future plans they had.
[15:44] <nacc> infinity: there are probably better ways to this fully w/in LP, my tool just takes the spph and applies an algorithm rbasak has devised
[15:44] <nacc> infinity: ack, will do!
[15:44] <infinity> cjwatson: That works better for debbugs than it does for attempting to actually break uploads into git commits, though.
[15:44] <cjwatson> it might be a useful component of what we need to do; there are several other pieces
[15:44] <cjwatson> infinity: the git case is more complicated, but knowing which versions are parented to which other versions is still useful, I think
[15:45] <nacc> cjwatson: yeah, we are treating the spph as "authoritative" and orphan'ing when things don't match that
[15:45] <nacc> cjwatson: so everything will get tag, but not everythign will have a full 'git' history necessarily
[15:45] <cjwatson> the spph doesn't tell you the parent version, unless you parse the changelog
[15:45] <nacc> cjwatson: right, in our algorithm, 'parent' is the previously published version
[15:45] <nacc> cjwatson: we verify it against chagnelog, and handle some specific cases where they don't agree
[15:45] <cjwatson> mm, which is sort of OK for a single distribution but doesn't deal with merges excellently
[15:46] <nacc> cjwatson: rbasak is probably better at explaining the thoughts behind the algorithm, but let me share the doc with you
[15:47]  * rbasak is otp
[15:47] <cjwatson> nacc: ok, I don't really have time for an extended discussion right now :)
[15:47] <cjwatson> was just drive-bying
[15:47] <nacc> cjwatson: np! i'm not doing it justice
[15:48] <nacc> cjwatson: i haven't hit a merge yet where the algorithm gets confused, but i've only tested a small set of packages
[15:48] <nacc> tbh, the issues we've hit so far have all been with just the normal history being ... unexpected :)
[15:52] <nacc> rbasak: if/when you are off the phone, would appreciate a minute of your time
[15:52] <rbasak> ack
[15:57] <slangasek> nacc: syncs can happen from any Debian suite, but autosyncs all happen from a single place (unstable, with I think only one historical exception for an LTS).  Syncs from experimental can be done individually (as we did last cycle for a few php packages).  Whether it's part of the "history" of unstable or not is entirely package-dependent; you can infer some of this from debian/changelog
[15:58] <nacc> slangasek: thanks
[15:58] <slangasek> seb128: command-not-found> gah, sorry, seems this fell off my radar.  publishing it now (Friday or not)
[15:58] <seb128> slangasek, thanks
[16:03] <rbasak> Unfortunately debian/changelog misses history some times, and I'd prefer the git history to show what was actually published and available to users rather than what the changelog shows.
[16:05] <rbasak> That makes it a little difficult to decide what the parent of a particular upload is. I think there's a fundamental dissonance between how the archive is organised and what I think git history should show. So I think it's necessary to do some heuristics to do a reasonable job in a bunch of common edge cases.
[16:05] <rbasak> nacc: ping. Hangout?
[16:12] <slangasek> rbasak: we're talking about a separate branch (unstable vs. experimental); unless you have an actual git repo, you can't infer anything about the merge topology /except/ by looking at debian/changelog
[16:12] <rbasak> slangasek: for an Ubuntu merge, we're doing something a little odd, but I think it works.
[16:12] <slangasek> hmm
[16:12] <rbasak> A merge ends up with two parents. One of them is the claimed parent in debian/changelog
[16:13] <rbasak> The other is what was previously in the pocket.
[16:13] <rbasak> I think.
[16:13] <nacc> yeah
[16:13] <slangasek> right, that doesn't sound odd to me at all, that sounds correct ;)
[16:13] <slangasek> and consistent with the prior art on this in UDD
[16:13] <rbasak> But except for the merge case, we're picking one parent.
[16:14] <rbasak> I favour picking the one in LP publishing history, because that's what users saw. It'd be confusing for it not to match I think, for example when working out why something happened from the history.
[16:15] <rbasak> Even though sometimes for example an Ubuntu uploader will not leave a deleted SRU proposed verification-failed entry in the changelog in an upload that supsersedes it.
[16:15] <slangasek> not sure I understand, "except for the merge case"
[16:15] <rbasak> Let me take an example. In sid, the maintainer uploads version A, there is an NMU of A.1, and then the maintainer uploads B.
[16:15] <rbasak> Sometimes when he uploads B, A.1 isn't in debian/changelog.
[16:16] <rbasak> If we rely on debian/changelog to determine the parent, then A.1 will be tagged but otherwise unreachable, and not in our imported history.
[16:16] <rbasak> (of the sid branch tip)
[16:17] <slangasek> er, right, yes
[16:17] <slangasek> in that case it's a single branch (unstable) and the history should match the upload history
[16:17] <rbasak> OK. I think we agree :)
[16:17] <slangasek> but unstable vs. experimental are different branches, just as unstable and Ubuntu devel series are different branches, and for *that*, you only have the changelog to hint you about the merge topology
[16:19] <rbasak> But, experimental could jump ahead. An experimental upload could be based on a newer unstable, or on the thing that was previously in unstable.
[16:19] <nacc> rbasak: https://launchpad.net/debian/+source/exim4/+publishinghistory?batch=75&memo=150&start=150 is the one i'm looking at now
[19:23] <mapreri> Laney: can you prod dep11-generator for scribus/xenial-proposed? /cc ximion
[19:25] <ximion> it really is time that I give Laney his immutable suites, so he doesn't have an excuse other than ENOTIME to switch to asgen...
[19:27]  * mapreri -eparse ximion's message, but guess it was not address to him anyway
[19:31] <ximion> appstream-generator is the new thing which doesn't have some of the flaws dep11gen has
[20:45] <worralph> when building debian packages is there a way to check for unpackaged files under debian/tmp?
[20:46] <cjwatson> dh_install --fail-missing is the usual approach
[20:57] <worralph> cjwatson: isnt fail missing the default and it only fails if you specified the file in *.install? i want to have the same behaviour as rpm which is something like unpackaged files
[21:03] <worralph> cjwatson: thanks i figured out i need to override dh_install
[21:06] <dobey> --fail-missing isn't the default no
[21:07] <Unit193> Not even --list-missing..
[21:08] <dobey> files listed in *.install which don't exist in the install path, do fail by default, but that is not the same as --fail-missing
[21:33] <worralph> thanks


[00:12] <nfm> The ubuntu-mozilla-daily PPA hasn't been updated since August 4th - anyone know what's going on?
[21:43] <dupondje> anyone awake?
[21:49] <dupondje> chrisccoulson: ?
[21:50] <dupondje> Was debugging why flashplayer didn't work in firefox since I updated to 14.10
[21:50] <dupondje> noticed alot of the following messages in syslog: Sep 19 23:47:05 laptop-jl kernel: [56384.537469] audit: type=1400 audit(1411163225.434:2596): apparmor="DENIED" operation="open" profile="/usr/lib/firefox/firefox{,*[^s][^h]}" name="/etc/ssl/openssl.cnf" pid=10890 comm="plugin-containe" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[21:50] <dupondje> added "/etc/ssl/openssl.cnf r," in the apparmor profile, and flashplayer starts working all in a sudden :)
[21:51] <dupondje> maby it would be cool to get it addded by default?


[08:22] <tjaalton> tseliot: do you know when the nvidia update in bionic will be built on arm?
[08:40] <tseliot> tjaalton: the builder says "Start in 2 hours"
[08:41] <tjaalton> armhf builders are offline still
[08:41] <tjaalton> was wondering if you had contacted lp admins
[08:41] <tjaalton> I've done that now
[08:41] <tjaalton> correction, all non-x86 builders are offline
[08:50] <tseliot> ok, thanks for checking, I had no idea
[08:51] <tjaalton> it's blocking mesa :)
[08:52] <tjaalton> I'll upload 17.2.8 to xenial/artful despite that..
[10:03] <tjaalton> tseliot: building now
[10:04] <tseliot> tjaalton: great :)
[10:13] <ricotz> tseliot, hi, https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-340/340.106-0ubuntu1
[10:14] <tseliot> ricotz: hi, Was that a question?
[10:14] <ricotz> tseliot, did you made this armhf build get bumped too?
[10:15] <tseliot> tjaalton: ^
[10:18] <tjaalton> no, just the one blocking mesa
[10:19] <ricotz> tjaalton, please do the same for this one
[10:19] <tjaalton> it
[10:19] <tjaalton> it
[10:20] <tjaalton> huh
[10:20] <tjaalton> it's something only lp admins can do, manually
[10:20] <tjaalton> poke wgrant then
[10:22] <ricotz> tseliot, ^
[10:31] <tseliot> ricotz, tjaalton: done
[10:32] <ricotz> thanks


[12:15] <lissyx> jbicha, I downgraded a few packages from lunar-proposed, including linux-image-generic (and deps) and linux-firmware
[12:15] <lissyx> jbicha, I think there might be a regression in <IP_ADDRESS>.23 vs <IP_ADDRESS>.20
[12:16] <lissyx> err in <IP_ADDRESS>.23
[12:16] <lissyx> my ax210 wifi interface was unable to connect to 6GHz bands
[12:16] <lissyx> reverting seems to have fixed
[12:18] <lissyx> not sure how I can use ubuntu-bug to file it since I have uninstalled <IP_ADDRESS>.23
[15:43] <tjaalton> chiluk: hi, if you use chrome, could you check if the mesa from ppa:tjaalton/test works for you? I guess chromium snap has the workaround already
[18:20] <KGB-0> gnome-control-center signed tags 5cbaaad Jeremy Bicha upstream/44.2 * Upstream version 44.2 * https://deb.li/RHNx
[18:20] <KGB-2> gnome-control-center upstream/latest 25cf559 Jeremy Bicha * pushed 27 commits (first 5 follow) * https://deb.li/3zvEE
[18:20] <KGB-2> gnome-control-center upstream/latest c19f767 Pablo Correa Gómez panels/network/connection-editor/ ce-page-ip4.c ce-page-ip6.c ip4-page.ui ip6-page.ui * network: keep track of radio buttons in connection editor with action * https://deb.li/33Ixl
[18:20] <KGB-2> gnome-control-center upstream/latest 2db95d1 Lukáš Tyrychtr panels/common/ cc-list-row.c cc-list-row.ui * a11y: Present the checked state on the list row itself * https://deb.li/iO0eI
[18:20] <KGB-2> gnome-control-center upstream/latest 7de263c Balázs Úr panels/firmware-security/cc-firmware-security-dialog.ui * firmware-security: Mark button label as translatable * https://deb.li/UHXc
[18:20] <KGB-2> gnome-control-center upstream/latest 2d737cf Ray Strode panels/background/cc-background-panel.c * background: Clear out dconf if user picks defaults * https://deb.li/37vLy
[18:20] <KGB-2> gnome-control-center upstream/latest e970f15 Felipe Borges panels/universal-access/cc-ua-hearing-page.c po/POTFILES.in * universal-access: Make Hearing page string translatable * https://deb.li/mIWG
[19:22] <KGB-2> gnome-control-center signed tags d97f07c Jeremy Bicha upstream/43.6 * Upstream version 43.6 * https://deb.li/xIZy
[19:22] <KGB-2> gnome-control-center upstream/43.x 61a827f Jeremy Bicha * pushed 26 commits (first 5 follow) * https://deb.li/iwvll
[19:22] <KGB-2> gnome-control-center upstream/43.x 5a434b0 Mohammed Sadiq panels/wwan/cc-wwan-data.c * wwan: Set apn access method before adding to list * https://deb.li/KH0s
[19:22] <KGB-2> gnome-control-center upstream/43.x d8ae7f6 Mohammed Sadiq panels/wwan/cc-wwan-data.c * wwan: Update operator code when 3gpp operator code changes * https://deb.li/3PvSU
[19:22] <KGB-2> gnome-control-center upstream/43.x 0159135 Nicolai Syvertsen panels/display/cc-display-config-dbus.c * display: Fix monitor order * https://deb.li/sI2n
[19:23] <KGB-2> gnome-control-center upstream/43.x 92834df Hari Rana panels/user-accounts/cc-add-user-dialog.ui * user: Remove duplicate group property * https://deb.li/3n097
[19:23] <KGB-2> gnome-control-center upstream/43.x 94b7a7d Jan Pokorný panels/display/cc-display-settings.c * display: Add 32:9 to known aspect ratios * https://deb.li/9vqM
[19:23] <KGB-2> gnome-control-center pristine-tar 7d5117e Jeremy Bicha gnome-control-center_43.6.orig.tar.xz.delta gnome-control-center_43.6.orig.tar.xz.id * pristine-tar data for gnome-control-center_43.6.orig.tar.xz * https://deb.li/cui0
[19:26] <KGB-0> gnome-boxes signed tags 2144b6e Jeremy Bicha upstream/43.4 * Upstream version 43.4 * https://deb.li/3vxvl
[19:26] <KGB-0> gnome-boxes upstream/43.x e07e8d8 Jeremy Bicha * pushed 9 commits (first 5 follow) * https://deb.li/vJBi
[19:26] <KGB-0> gnome-boxes upstream/43.x a967967 Mathias Magnusson src/media-manager.vala * media-manager: Add OVF to list of supported install media formats * https://deb.li/3CJzj
[19:26] <KGB-0> gnome-boxes upstream/43.x bd873a1 Felipe Borges src/ installed-media.vala media-manager.vala * installed-media: Use mime-type when validating OVA file * https://deb.li/oZD4
[19:26] <KGB-0> gnome-boxes upstream/43.x 88c3cad Felipe Borges src/installed-media.vala * installed-media: Fix typo in the vmdk format/suffix * https://deb.li/368sD
[19:26] <KGB-0> gnome-boxes upstream/43.x a7c001b Nart Tlisha po/ab.po * Update Abkhazian translation * https://deb.li/OZd0
[19:26] <KGB-0> gnome-boxes upstream/43.x 6b62dba Felipe Borges NEWS meson.build * Release 43.3 * https://deb.li/3KV32
[19:27] <KGB-0> gnome-boxes pristine-tar b708862 Jeremy Bicha gnome-boxes_43.4.orig.tar.xz.delta gnome-boxes_43.4.orig.tar.xz.id * pristine-tar data for gnome-boxes_43.4.orig.tar.xz * https://deb.li/3sMKh
[19:31] <KGB-2> gnome-builder signed tags 1a291a4 Jeremy Bicha upstream/43.7 * Upstream version 43.7 * https://deb.li/4MvE
[19:31] <KGB-0> gnome-builder upstream/43.x 3b6a840 Jeremy Bicha * pushed 35 commits (first 5 follow) * https://deb.li/3WZ7e
[19:31] <KGB-0> gnome-builder upstream/43.x f875fa1 Christian Hergert src/plugins/ctags/ide-ctags-completion-provider.c * plugins/ctags: ignore comments/strings/path context * https://deb.li/exnI
[19:31] <KGB-0> gnome-builder upstream/43.x 6c2cf50 Christian Hergert src/plugins/ctags/ide-ctags-completion-provider.c * plugins/ctags: allow user-requested for ctags anywhere * https://deb.li/3AJdA
[19:31] <KGB-0> gnome-builder upstream/43.x 2be9735 Christian Hergert src/plugins/c-pack/ide-c-indenter.c * plugins/c-pack: fix vim `o` to insert with indent * https://deb.li/FJsR
[19:31] <KGB-0> gnome-builder upstream/43.x a25c1dd Christian Hergert src/libide/foundry/ide-pipeline.c * libide/foundry: fix va_list access * https://deb.li/3dMFv
[19:32] <KGB-0> gnome-builder upstream/43.x 18bac5b Christian Hergert src/libide/foundry/ide-build-system.c * libide/foundry: keep freeme in outermost scope * https://deb.li/uVUz
[19:32] <KGB-0> gnome-builder pristine-tar 4d447b9 Jeremy Bicha gnome-builder_43.7.orig.tar.xz.delta gnome-builder_43.7.orig.tar.xz.id * pristine-tar data for gnome-builder_43.7.orig.tar.xz * https://deb.li/i4x1s
[19:52] <KGB-0> gnome-maps signed tags e54014b Jeremy Bicha upstream/43.5 * Upstream version 43.5 * https://deb.li/fZPd
[19:53] <KGB-2> gnome-maps pristine-tar 289d2aa Jeremy Bicha gnome-maps_43.5.orig.tar.xz.delta gnome-maps_43.5.orig.tar.xz.id * pristine-tar data for gnome-maps_43.5.orig.tar.xz * https://deb.li/DZRj
[19:56] <KGB-2> gnome-remote-desktop signed tags eabe7c1 Jeremy Bicha upstream/43.4 * Upstream version 43.4 * https://deb.li/i3M7z
[19:56] <KGB-0> gnome-remote-desktop upstream/43.x ea52893 Vasil Pupkin po/ LINGUAS be.po * Add Belarusian translation * https://deb.li/QJT2
[19:57] <KGB-0> gnome-remote-desktop upstream/43.x 67a5461 Jonas Ådahl meson.build * build: Bump version to 43.4 * https://deb.li/3HMPC
[19:57] <KGB-0> gnome-remote-desktop upstream/43.x 1db9a32 Jeremy Bicha meson.build po/LINGUAS po/be.po * New upstream version 43.4 * https://deb.li/VVOh
[19:57] <KGB-0> gnome-remote-desktop pristine-tar 09f3dd5 Amin Bandali gnome-remote-desktop_44.2.orig.tar.xz.delta gnome-remote-desktop_44.2.orig.tar.xz.id * pristine-tar data for gnome-remote-desktop_44.2.orig.tar.xz * https://deb.li/3Txmc
[19:57] <KGB-0> gnome-remote-desktop pristine-tar 3f85e1d Jeremy Bicha gnome-remote-desktop_43.4.orig.tar.xz.delta gnome-remote-desktop_43.4.orig.tar.xz.id * pristine-tar data for gnome-remote-desktop_43.4.orig.tar.xz * https://deb.li/LO37
[19:58] <chiluk> tjaalton checking your ppa now.
[19:59] <KGB-2> gnome-remote-desktop signed tags 6b82875 Jeremy Bicha upstream/44.2 * Upstream version 44.2 * https://deb.li/3qJJd
[20:17] <chiluk> tjaalton so far so good. I'm not getting any corruption with the mesa upgrade in your test ppa.
[20:20] <chiluk> tjaalton... sorry I haven't had enough time to be more involved.
[20:23] <KGB-2> gvfs signed tags bb7a682 Jeremy Bicha upstream/1.50.4 * Upstream version 1.50.4 * https://deb.li/XMds
[20:32] <KGB-0> libhandy-1 pipeline Jeremy Bicha 532864 * pending (extract-source: running; build: created; build i386: created; build source: created; test-build-any: created; test-build-all: created; test-crossbuild-arm64: created; reprotest: created; lintian: created; autopkgtest: created; blhc: created; piuparts: created)
[20:32] <KGB-0> libhandy-1 pipeline Jeremy Bicha 532864 * running (extract-source: running; build: created; build i386: created; build source: created; test-build-any: created; test-build-all: created; test-crossbuild-arm64: created; reprotest: created; lintian: created; autopkgtest: created; blhc: created; piuparts: created)
[20:59] <tjaalton> chiluk: that's fine, thanks
[21:05] <KGB-2> evolution-data-server signed tags 9246f93 Jeremy Bicha upstream/3.48.2 * Upstream version 3.48.2 * https://deb.li/reiz
[21:05] <KGB-2> evolution-data-server pristine-tar 84da71a Amin Bandali evolution-data-server_3.48.2.orig.tar.xz.delta evolution-data-server_3.48.2.orig.tar.xz.id * pristine-tar data for evolution-data-server_3.48.2.orig.tar.xz * https://deb.li/ISq1
[21:11] <KGB-0> evolution signed tags 1705890 Jeremy Bicha upstream/3.48.2 * Upstream version 3.48.2 * https://deb.li/3eswN
[21:12] <KGB-2> evolution pristine-tar 5d501f5 Amin Bandali evolution_3.48.2.orig.tar.xz.delta evolution_3.48.2.orig.tar.xz.id * pristine-tar data for evolution_3.48.2.orig.tar.xz * https://deb.li/ipiCv
[21:12] <KGB-0> evolution upstream/latest c3ec0e1 Jeremy Bicha * pushed 16 commits (first 5 follow) * https://deb.li/ZSeD
[21:12] <KGB-0> evolution upstream/latest 3886781 Milan Crha CMakeLists.txt * Post-release version bump * https://deb.li/0Y0R
[21:12] <KGB-0> evolution upstream/latest 91e2138 Milan Crha src/modules/rss/camel-rss-store-summary.c * rss: Fix recently introduced memory leaks * https://deb.li/i7iEg
[21:12] <KGB-0> evolution upstream/latest 813adc9 Milan Crha src/modules/tnef-attachment/e-mail-parser-tnef-attachment.c * I#1810 - TNEF attached message decoded incorrectly * https://deb.li/psIl
[21:12] <KGB-0> evolution upstream/latest 4fc69f7 Milan Crha src/ e-util/e-web-view.c mail/e-mail-display.c * I#2332 - Mail: Recalc preview iframe heights more often * https://deb.li/3jtiI
[21:12] <KGB-0> evolution upstream/latest d4b8388 Milan Crha src/e-util/e-attachment.c * I#1463 - Updated attachments are shown as updated, but sent in old version * https://deb.li/YiAE
[21:21] <KGB-0> vte2.91 signed tags f61fb65 Jeremy Bicha upstream/0.70.5 * Upstream version 0.70.5 * https://deb.li/BsZC
[21:21] <KGB-2> vte2.91 upstream/0.70.x cbcb64c Jeremy Bicha * pushed 7 commits (first 5 follow) * https://deb.li/dtWF
[21:21] <KGB-2> vte2.91 upstream/0.70.x 26c3d4a Christian Persch meson.build * build: Post release version bump * https://deb.li/31Y81
[21:21] <KGB-2> vte2.91 upstream/0.70.x d02c5fc Christian Hergert src/fonts-pangocairo.cc * fonts: keep layout text available for cairo * https://deb.li/3pSLd
[21:21] <KGB-2> vte2.91 upstream/0.70.x c851dda Christian Persch src/fonts-pangocairo.cc * fonts: Keep the PangoLayout unchanged * https://deb.li/iQ56V
[21:21] <KGB-2> vte2.91 upstream/0.70.x e7f8f85 Christian Persch meson.build * build: Post release version bump * https://deb.li/xthA
[21:21] <KGB-2> vte2.91 upstream/0.70.x aa024f2 Christian Persch src/ vte.cc vteinternal.hh widget.cc * widget: Fix cursor blink timeout * https://deb.li/3lY5i
[22:05] <KGB-2> evolution-ews signed tags 3e780ad Jeremy Bicha upstream/3.48.1 * Upstream version 3.48.1 * https://deb.li/39iIx
[22:05] <KGB-2> evolution-ews pristine-tar 5f7f31b Jeremy Bicha evolution-ews_3.48.1.orig.tar.xz.delta evolution-ews_3.48.1.orig.tar.xz.id * pristine-tar data for evolution-ews_3.48.1.orig.tar.xz * https://deb.li/3wslg