[08:39] <tgardner> cking, bug #818830
[08:39] <ubot2> Launchpad bug 818830 in linux "[Sandy Bridge] serious power regression from kernel 3.0.0-6 to 3.0.0-7 (rc6 disabled)" [Medium,Triaged] https://launchpad.net/bugs/818830
[08:57] <apw>         INTEL_VGA_DEVICE(0x0102, &intel_sandybridge_d_info),
[08:57] <apw>         INTEL_VGA_DEVICE(0x0112, &intel_sandybridge_d_info),
[08:57] <apw>         INTEL_VGA_DEVICE(0x0122, &intel_sandybridge_d_info),
[08:57] <apw>         INTEL_VGA_DEVICE(0x0106, &intel_sandybridge_m_info),
[08:57] <apw>         INTEL_VGA_DEVICE(0x0116, &intel_sandybridge_m_info),
[08:57] <apw>         INTEL_VGA_DEVICE(0x0126, &intel_sandybridge_m_info),
[08:57] <apw>         INTEL_VGA_DEVICE(0x010A, &intel_sandybridge_d_info),
[08:57] <apw> tgardner, ^^
[09:52] <Q-FUNK> smb: hiya :)
[09:52] <smb> Q-FUNK, morning
[13:17]  * ppisati bails out for a bit...
[13:19]  * ogasawara back in 20
[13:46] <morgs> Hi, I need to get an updated version of the e1000e driver on a lucid box. I'm struggling to find a guide to building this the Ubuntu way - been years since I compiled a kernel.
[13:46] <morgs> Can anybody point me in the right direction please?
[14:39] <ppisati> mdeslaur: ping
[14:39] <mdeslaur> ppisati: yes?
[14:39] <ppisati> mdeslaur: CVE-2011-2479
[14:39] <ubot2> ppisati: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2479)
[14:40] <ppisati> mdeslaur: are you it affects hardy, lucid and maverick too?
[14:41] <mdeslaur> ppisati: I don't know, I didn't look at ti
[14:41] <mdeslaur> s/ti/it/
[14:41] <ppisati> mdeslaur: can you give it a look?
[14:42] <ppisati> bug 869230
[14:42] <ubot2> Launchpad bug 869230 in linux-lts-backport-natty "CVE-2011-2479" [Medium,Fix committed] https://launchpad.net/bugs/869230
[14:42] <ppisati> actually you opened the lp bug for it
[14:42] <mdeslaur> ppisati: the kernel workflow script I use opened the bug
[14:43] <mdeslaur> ppisati: I'll ask jj to take a look at it when he arrives
[14:43] <ppisati> oook
[14:43] <ppisati> :)
[14:44] <herton> ppisati: you fsl-imx51 pull is adding debian/changelog back, it shouldn't
[14:44] <herton> *your
[14:45] <ppisati> crap
[14:48] <ppisati> herton: try now
[14:48]  * ppisati always screw up something...
[14:50] <herton> ppisati: it's ok now, but looking at the debian.fsl-imx51/changelog, it misses lucid-proposed, instead of UNRELEASED. also tracking bug is missing from the changelog
[14:50] <ppisati> grrr... :)
[14:50] <ppisati> wait
[14:51] <ppisati> than i forgot the Buglink in mvl-dove too
[14:51] <herton> sorry man, never tried verify-release-ready on topic branches but probably we should make them run against the arm branches to catch all these minor errors
[14:55] <ppisati> herton: what the lp bug for imx51?
[14:56] <ppisati> i already deleted the email
[14:56] <herton> ppisati: 873059
[14:56] <herton> but you can look also at http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html if you need to recall
[14:58] <ppisati> herton: ok, imx51 should be ok now
[14:58] <ppisati> herton: i fix the mvl-dove now
[15:06] <ppisati> herton: ok, and mvl-dove should be ok too now
[15:08] <herton> ppisati: looks good now. This should be the last mvl-dove update for lucid, after this no more tracking bugs will be created for it, I'll forward/cc you on the email
[15:09] <ppisati> herton: saw it, but we still need it for maverick
[15:10] <herton> ah ok. yes, the branch will have to still be maintained so the maverick rebase script can grab it
[15:12] <ppisati> yep
[15:40] <ogra_> apw, around ?
[15:41] <apw> s'up
[15:41] <ogra_> https://blueprints.launchpad.net/ubuntu/+spec/arm-p-optional-initrd
[15:41] <ogra_> have a look (its only a very rough draft yet)
[15:41] <ogra_> do you think it would be possible to teach the kernel to use UUIDs without initrd ?
[15:42]  * ogra_ wants to know if thats feasable, lese the spec is moot
[15:42] <ogra_> *else even
[15:47] <apw> ogra_, why so keen to get rid of the initrd ?
[15:47] <apw> ogra_, and have you considered building the initrd into the kernel
[15:47] <ogra_> apw, bootspeed
[15:48] <ogra_> and complexity on arm ...
[15:48] <ogra_> users coming from other distros are not familiar with the initrd concept
[15:48] <apw> if you build the initrd with only the needed stuff, how far from ideal would that be
[15:48] <ogra_> it will still switch the rootfs twice
[15:48] <ogra_> and process /init and then upstart
[15:49] <ogra_> we can work fine without initrd, the only two blockers are the packages that put stuff in there and actually need it before rootfs and the missing UUID support in the kernelö
[15:49] <apw> for me loading the initrd is the main cost, if you are goign to build everything in, won't the kernel just be a beast instead and take ages to load
[15:49] <ogra_> likely
[15:50] <apw> so have you meansured how much time you are going to save by not having
[15:50] <ogra_> why would i build anything beyond the basic boot stuff into the kernel anyway
[15:50] <ogra_> no, but thats scope of the spec
[15:50] <ogra_> i havent measured anything yet, currently its just a spec idea
[15:51] <apw> ogra_, define basic boot stuff
[15:51] <ogra_> the package stuff is easy to solve, but i have no clue about how much work it would be for the kernel side
[15:51] <ogra_> apw, well, the filesystems we use and the HW specific bits needed to mount /
[15:53] <ogra_> i'm looking from an arm prespective indeed
[15:53] <ogra_> where we dont have a kernel you re-use on multiple boards
[15:56] <mdeslaur> jjohansen: ppisati had a question about  CVE-2011-2479, could you please help him?
[15:56] <ubot2> mdeslaur: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2479)
[16:00] <jjohansen> ppisati: what can I do for you on CVE-2011-2479
[16:00] <ubot2> jjohansen: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2479)
[16:01] <ppisati> jjohansen: i gave it a look
[16:01] <jjohansen> ppisati: okay
[16:01] <ppisati> jjohansen: and it seems it's all about mm huge pages
[16:01] <jjohansen> hrmm
[16:01] <ppisati> jjohansen: but it seems to me we don't have that stuff in hardy/lucid/maverick
[16:02] <ppisati> i mean
[16:02] <ppisati> we have the hugetlbpages but no huge pages
[16:02] <ppisati> we don't even have the vm flag HUGE_PAGE
[16:02] <jjohansen> right
[16:02] <ppisati> so i was wondering if it affects that kernel too
[16:02] <ppisati> *kernels
[16:02] <jjohansen> ppisati: unlikely but I can take a look
[16:03] <ppisati> jjohansen: that would be nice
[16:03] <ppisati> jjohansen: btw, redhat said it doesn't affect their RHEL 4,5 releases
[16:03] <ppisati> jjohansen: but i didn't check what kernels they are using on these releases
[16:04] <jjohansen> ppisati: heh, I can never keep track, and have to go check but RHEL 4,5 feels anchient
[16:04] <jjohansen> 2.6.9
[16:04] <ppisati> ah ok
[16:04] <ppisati> :)
[16:05] <jjohansen> :)
[16:05] <ppisati> anyway, if you can take a look at it
[16:05] <ppisati> that would be nice
[16:05] <jjohansen> yep, I'll look, I expect they won't be affected though
[16:05] <ppisati> ok
[16:06] <ppisati> actually it could be that the huge page logic that is affected in natty "madvise_$whatever_hugepages" back then was in the general madvise() but the fact that we don't even have the vm HUGEPAGE flag made me think that, perhaps, these kernels are not affected
[16:07] <ppisati> anyway, i'll let you look at it
[16:08] <jjohansen> well without having looked I am expecting its in andrea's huge page patches that where introduced in 2.6.37/38 time frame
[16:14] <jjohansen> ppisati: as I expected its in the transparent huge pages stuff which was introduced in 2.6.38
[16:14] <ppisati> jjohansen: nice
[16:18] <ppisati> btw, is there a way to "skip" splash screen while booting? i've a machine where oneiric hangs
[16:18] <apw> ppisati, yep, change the set gfxpayload=xxx to =text and drop quiet splash from the command line replacing them with debug
[16:19] <ppisati> no grub here
[16:19] <ppisati> i mean something interactive
[16:20] <ppisati> or better, i don't have the interactive menu anymore
[16:22] <Q-FUNK> apw: welcome back!
[16:22] <Q-FUNK> apw: would you happen to know why 3.1 mainline kernels no longer ship vesafb?
[16:23] <apw> ppisati, holding shift as grub loads ?
[16:23] <apw> Q-FUNK, not specifically, does it still exist?
[16:23] <ppisati> apw: nice, didn't know
[16:28] <Q-FUNK> apw: by the looks of it, the Kconfig option still exists but, for some reason, it's not built in the mainline kernels we have prepackaged for testing.
[16:28] <Q-FUNK> apw: ogasawara thought that you might know why.
[16:31] <Q-FUNK> apw: on hosts without KMS drivers, it produces a blank screen on bootup.
[16:39]  * ppisati -> gym/workout
[17:22] <Q-FUNK> did the archive key just change or is my APT going nuts?
[17:32] <Q-FUNK> ah. right. congratulations to whoever just pushed one eric out the door.


[03:10] <fabbione> jbehey dude
[03:10] <fabbione> whops
[03:10] <fabbione> jbailey: dude...
[03:10] <jbailey> fabbione: yayaya
[03:10] <jbailey> Fine, don't remember who I am.
[03:10] <jbailey> See if my feelings are hurt... 8'{ *cRy*
[03:10] <fabbione> (gdb) run
[03:10] <fabbione> Starting program: /root/a.out
[03:10] <fabbione> we are set
[03:10] <fabbione> Program received signal SIGUSR1, User defined signal 1.
[03:10] <fabbione> 0xf7e9536c in nanosleep () from /lib/v9v/libc.so.6
[03:10] <fabbione> (gdb) next
[03:10] <fabbione> Single stepping until exit from function nanosleep,
[03:10] <fabbione> which has no line number information.
[03:10] <fabbione> Program terminated with signal SIGILL, Illegal instruction.
[03:10] <fabbione> The program no longer exists.
[03:10] <fabbione> (gdb) That was all, folks
[03:10] <fabbione> this is bad..
[03:10] <fabbione> i can't figure why we are getting a SIGILL
[03:10] <fabbione> and only on Niagara machine
[03:11] <jbailey> SIGILL is a kernel or processor trap.
[03:11] <fabbione> i am afraid the last gcc updates are generating wrong code
[03:11] <fabbione> because it's not triggered on non Niagara machines
[03:11] <jbailey> That or the kernel is dissallowing something it should allow.
[03:11] <fabbione> and usually that's a sign of badly generated code
[03:11] <fabbione> unlikely
[03:11] <jbailey> Depends on how the protection bits all work on Sparc.
[03:11] <fabbione> i have seen a lot the other way around
[03:12] <jbailey> Is there a test failure in either LTP or glibc's testsuite for it?
[03:12] <fabbione> i have a reduced case
[03:12] <fabbione> and i am trying to reduce it even more
[03:12] <jbailey> Even better. =)
[03:12] <fabbione> no idea about LTP or glibc
[03:12] <fabbione> jbailey: can you get access to fluorine?
[03:12] <jbailey> Well, you're looking at a glibc function yes?
[03:12] <fabbione> from cr3?
[03:13] <jbailey> I can, but don't have time for 4 to 6 hours.
[03:13] <fabbione> i want to show you the code
[03:13] <fabbione> feh ok
[03:13] <jbailey> Sorry, my morning is lined up with customer appointments.
[03:13] <jbailey> Does your reduced testsuite still call nanosleep?
[03:13] <jbailey> Or have you extracted that out?
[03:20] <fabbione> i am pretty sure the problem is either gcc or binutils
[03:20] <fabbione> declaring an int foo; makes the code explode
[03:20] <fabbione> removing that line = works
[03:20] <fabbione> and that so should not happen
[03:21] <fabbione> root@fluorine:~# gcc -Wall -g -O0 main.c
[03:21] <fabbione> root@fluorine:~# ./a.out
[03:21] <fabbione> root@fluorine:~# gcc -Wall -g -O0 main.c
[03:21] <fabbione> main.c: In function 'main':
[03:21] <fabbione> main.c:36: warning: unused variable 'i'
[03:21] <fabbione> root@fluorine:~# ./a.out
[03:21] <fabbione> Illegal instruction
[03:21] <fabbione> doko: ping?
[03:23] <jbailey> Right, so once you've got that, do a disassemble and a stepi to find the offending instruction.
[03:25] <fabbione> do you recall the gdb sintax to do that?
[03:27] <jbailey> 'dis' I think.
[03:28] <fabbione> no that's disable..
[03:28] <jbailey> Hmm, lemme look it up after this call.
[03:28] <fabbione> sure thanks
[03:41] <jbailey> fabbione: disass
[03:41] <jbailey> You didn't try, did you? =)
[03:42] <jbailey> So break before the sigill.
[03:43] <jbailey> step to find the offending C statement.
[03:43] <jbailey> Do the disass there
[03:43] <jbailey> then stepi to the sigill.
[03:47] <fabbione> jbailey: ok
[03:48] <fabbione> dis was claiming disable.. but i might have been at the wrong point
[04:13] <fabbione> hoooowwwowowowoowow
[04:13] <fabbione> this is a mess
[04:22] <doko> fabbione: pong
[04:22] <fabbione> doko: do you have access to fluorine?
[04:23] <doko> no
[04:23] <fabbione> the T1000 at the london DC from -support?
[04:23] <fabbione> i was told you had acccess
[04:30] <doko> ohh right, didn't use it yet
[04:39] <fabbione> doko: see your email about that niagara test case
[04:39] <fabbione> it's possible to reproduce it on fluorine
[04:39] <fabbione> there is a feisty chroot in /src/chroots/feisty
[04:39] <fabbione> and the sources are in ~/root
[04:40] <doko> fabbione: could you check with gcc-4.2?
[04:40] <doko> what are working gcc/binutils versions?
[04:41] <fabbione> doko: i have been staring at that code for 10 hours now.. i can't look at it anylonger
[04:41] <fabbione> doko: i did test the latest in feisty... and no.. i didn't check back yet
[04:41] <fabbione> i thought it was a coding error
[04:41] <fabbione> but i just arrived at toolchain not too long ago when removing the int i;
[04:41] <fabbione> (unused)
[04:42] <fabbione> because i was killing code to the minimum to reduce the test case
[04:42] <fabbione> the original parted_server is 2200 lines :)
[04:42] <fabbione> also.. flourine has 32 threads.. it takes nothing to build gcc with make -j :)


[00:29] <blackboxsw> orndorffgrant: if you  are doing any UA testing for systemd daemon, add-apt-repository ppa:cloud-init-dev/daily on Jammy will get you /run/cloud-init/cloud-id-*
[00:30] <blackboxsw> for tomorow
[00:30] <blackboxsw> s/r/rr
[03:34] <blackboxsw> woo hoo thx for the reviews folks  Jammy update is accepted for tip of cloud-init [ubuntu/jammy-proposed] cloud-init 21.4-119-gdeb3ae82-0ubuntu1~22.04.1 (Accepted)
[14:10] <orndorffgrant> blackboxsw: Great! Yes that will make testing much simpler
[19:39] <apple-corps[m]> blackboxsw: I had removed the sudo commands from my cloud-init script. I tried adding a sleep statement regarding the filesystem initialization concerns. I'm seeing the same behavior. From the cloud-init.log it looks like the runcmd is written, but not executed as shown previously. Then I assume I will need to collect the logs to file a bug report.
[19:42] <blackboxsw> apple-corps[m]: yes I would have expected your logs to contain ""Running command ['/var/lib/cloud/instance/scripts/runcmd'] with allowed return codes [0] (shell=False, capture=False)""
[19:42] <blackboxsw> to show that cloud-init actually ran it. Has your system actually completed running cloud-init? You can check via `cloud-init status --wait --long`
[19:43] <blackboxsw> apple-corps[m]: I'm also presuming that you are using nitro system and maybe IPv6 only networking?
[19:44] <apple-corps[m]> blackboxsw: when I run `sudo cloud-init status --wait --long` it appears I get repeated periods ... displayed so does that suggest it has not completed?
[19:45] <blackboxsw> apple-corps[m]: yeah, it suggests cloud-init hasn't been able to get far enough to complete on the system. probably because something is happening in networking that is preventing cloud-init from moving to the next stage where it actually runs the runcmd
[19:46] <apple-corps[m]> Regarding nitro system, I am not aware regarding nitro-system, then I think not. Running a z1d.large ec2 instance type
[19:47] <blackboxsw> apple-corps[m]: runcmd module is only executed at the end of the "config" boot stage https://cloudinit.readthedocs.io/en/latest/topics/boot.html#config. So we we don't get that far on your system you'll never see that command execute.
[19:48] <apple-corps[m]> blackboxsw: should I go ahead and provide the log and file a bug report then? The last lines of the log. util.py[DEBUG]: cloud-init  mode 'modules' took 4.127 seconds(4.12)
[19:48] <blackboxsw> apple-corps[m]: what's /run/cloud-init/status.json should show a start and end time for each boot stage cloud-init has completed. If you have any stages which don't show an end time you know you are 'stuck' there. `cloud-init analyze show` might also help discern how far in boot you have gotten
[19:49] <apple-corps[m]> handlers.py[DEBUG]: finish: modules-config: SUCCESS: running modules for config
[19:49] <blackboxsw> apple-corps[m]: +1 on bug filing. if you have the ability to get /var/log/cloud-init*log and or `cloud-init collect-logs` it'd make this way easier
[19:49] <blackboxsw> if you had network connectivity from the instance I'd say run `ubuntu-bug cloud-init`
[19:50] <apple-corps[m]> I probably need to scrub the logs of any sensitive information.
[19:52] <blackboxsw> apple-corps[m]: +1 on a scrub, generally watch out for the included ./run/cloud-init/instance-data-sensitive.json ./run/cloud-init/instance-data.json files. The cloud-init.log itself should have "REDACTED" passwords from user-data for instance
[19:52] <apple-corps[m]> I see finished and start times on 3 modules. The other modules look like they have null values for both.
[19:53] <blackboxsw> my example status.json has start/end times for init, init-local, modules-config, modules-file
[19:53] <blackboxsw> my example status.json has start/end times for init, init-local, modules-config, modules-final
[19:54] <blackboxsw> if you don't get across modules-final something is holding things up. `cloud-init analyze show` or `cloud-init analyze blame` may help when looking at your first boot on the system
[19:54] <apple-corps[m]> mine has init, init-local, modules-config all show start / end times. modules-final and modules-init are both null
[19:55] <apple-corps[m]> for start / end times
[19:56] <apple-corps[m]> Ok, I will work on collecting and scrubbing the logs then.
[19:56] <falcojr> I believe systemd-analyze critical-chain should tell you if something if blocking the service from starting
[19:58] <blackboxsw> one other thing to double check on your image is whether cloud-init's systemd targets have all executed (sometimes systemd "ordering cycles" could have been introduced with other software on the node resulting in cloud-init system units being dropped/disabled from the boot target.
[19:58] <blackboxsw> for unit in cloud-init-local.service cloud-init.service cloud-config.service cloud-final.service; do systemctl status $unit; done
[19:58] <apple-corps[m]> I'll take a look. I can see at least some of the modules are running. The script was shellified by cloud-init, etc
[19:58] <blackboxsw> confirm they were all run. and confirm you don't see "Breaking ordering cycle" in journalctl -b 0
[19:59] <apple-corps[m]> When I run systemd-analyze critical-chain it says Bootup is not yet finished. Please try again later
[19:59] <blackboxsw> and `systemctl status network-online.target`
[20:00] <blackboxsw> as that'd block a number of cloud-init jobs
[20:01] <blackboxsw> I'm also thinking of checking active services still running/blocking with `systemctl --type=service --state=running` or something
[20:01] <apple-corps[m]> cloud-finlal service is loaded, enabled and dead from the for loop
[20:02] <apple-corps[m]> cloud-init.local.service doesn't exist. The others are enabled and active
[20:03] <blackboxsw> ok. good and it is a typo cloud-init.local.service should be cloud-init-local.service
[20:04] <blackboxsw> but yes given your status.json, I'd expect init-local to be "healthy"
[20:06] <blackboxsw> `systemctl list-jobs` may also point to something unfinished on your system boot
[20:07] <blackboxsw> hrm my cloud-final.service is      Active: active (exited) since Thu 2022-02-10 01:50:08 UTC; 1 day 18h ago
[20:07] <blackboxsw> again I think minimally your cloud-init.log will help us deduce what's happened here if possible
[20:08] <apple-corps[m]> Looking at cloud-init-local.service "my bad", I see it's active, enabled. From the journalctl logs for this I see cloud-init warning. dhcp.py[WARNING]: dhclient did not produce expected files: dhclient.pid, dhclient.leases . I see some logging related to a dhclient process. But I do see dhclient provided the leases
[20:09] <apple-corps[m]> looks like there were some permissions errors creating dhcp.eleases and dhclient.pid. But it's not clear that is blocking the service or not.
[20:10] <apple-corps[m]> I think if we expect cloud-final.service to execute the runcmd command, because it is dead and it's last run was much before today, then we know there is an issue there
[20:28] <apple-corps[m]> collecting the logs then and will file
[21:18] <apple-corps[m]> atteched to bug 1960678


[04:02] <spiv> Want codebrowse to generate OOPS reports?  Then please review https://code.edge.launchpad.net/~spiv/launchpad/codebrowse-oops-84838/+merge/31007 :)
[04:17]  * mwhudson looks
[04:19] <mwhudson> spiv: er
[04:19] <mwhudson> + Strictly speaking this isn't 100% correct WSGI middleware, because it
[04:19] <mwhudson> 99	+ doesn't respect the return value from start_response (the 'write'
[04:19] <mwhudson> 100	+ callable), but using that return value is deprecated and nothing in our
[04:19] <mwhudson> 101	+ codebrowse stack uses that.
[04:19] <mwhudson> loggerhead in fact uses that callable
[04:19] <spiv> mwhudson: heh
[04:19] <spiv> mwhudson: so I just noticed!
[04:19] <spiv> mwhudson: see latest push
[04:20] <spiv> mwhudson: for some reason that didn't show up until my last-minute-before-I-push cleanups :(
[04:20] <spiv> Sorry for the noise.
[04:20] <mwhudson> heh
[04:21] <spiv> There's also something funny I'm seeing with the very first request I make to the server after starting it giving a weird HTTP error, but I'm not sure that's related to this branch.
[04:25] <spiv> I'll confess to thinking this isn't the most beautiful code I've ever written :)
[04:27] <thumper> mwhudson: I have a couple of small branches if you have a few minutes
[04:27] <thumper> https://code.edge.launchpad.net/~thumper/launchpad/fix-mirror-failure-story/+merge/31010
[04:27] <mwhudson> spiv: heh heh
[04:27] <thumper> https://code.edge.launchpad.net/~thumper/launchpad/stop-factory-mirroring/+merge/31011
[04:28] <spiv> I feel so wonderfully old-school with all these mutable variables destined to be mutated by nested functions, though!
[04:29] <mwhudson> you've been wsgi-ed!
[04:29] <spiv> Possibly there's enough going on there that I can profitably refactor out an actual object.  Initially it was just the one little variable, but well, wsgi...
[04:30] <thumper> I plan one day soon to take more of a look at loggerhead
[04:30] <mwhudson> spiv: blurgh
[04:31] <mwhudson> spiv: we shouldn't return a 200 when we're reporting an error
[04:34] <spiv> mwhudson: ah ok, I wondered about that, I meant to ask
[04:34] <spiv> I'm happy to ape whatever lpnet does here, if you happen to know :)
[04:35] <spiv> I was hoping to avoid spelunking through the layers of zope publication internals more than necessary
[04:36]  * mwhudson attempts to trigger a timeout
[04:37] <mwhudson> spiv: this timeout has a http 503
[04:38] <spiv> I'm happy to change it to 500 Internal Server Error.
[04:39] <mwhudson> spiv: please
[04:39] <spiv> I guess if some IE users get a boilerplate "IE noticed that the server broke, but I won't show you any helpful details the server may have sent about that" page then that's their problem ;)
[04:40] <mwhudson> yeah, i think that's a potential issue
[04:40] <mwhudson> but i agree with your conclusion
[04:40] <mwhudson> spiv: i reviewed the branch btw
[04:42] <spiv> Thanks!
[05:17] <thumper> mwhudson: another relatively brainless review https://code.edge.launchpad.net/~thumper/launchpad/bzr-format-matching-refactoring/+merge/31014
[05:17] <thumper> mwhudson: although more thought needed than the other two :)
[05:18] <mwhudson> thumper: looking
[05:19] <mwhudson> thumper: "# The default branch format is unrecognized."
[05:19] <mwhudson> thumper: this caused mental jarring; the default branch format is 2a, surely?
[05:19] <thumper> mwhudson: ah
[05:19] <thumper> mwhudson: hmm...
[05:20] <thumper> the idea is that if we don't recognise it, it is unrecognized
[05:20] <thumper> a rename perhaps
[05:20] <thumper> so for the test methods s/default/unrecognized/
[05:21] <mwhudson> thumper: +1
[06:19] <thumper> mwhudson: last for the day... https://code.edge.launchpad.net/~thumper/launchpad/merge-directive-handling-no-request-mirror/+merge/31019
[06:21]  * mwhudson waits for the diff
[06:23] <mwhudson> thumper: done
[06:23] <thumper> mwhudson: thanks
[06:27]  * thumper kicks off 4th ec2 land run
[12:20] <jelmer> wgrant, hi
[12:20] <wgrant> jelmer: Evening.
[12:22] <jelmer> wgrant: Any particular reason for returning None rather than raising an exception in your refactor-nuf-creation branch?
[12:23] <wgrant> jelmer: Hm, not really.
[12:24] <wgrant> Not sure which exception is appropriate, though.
[12:27] <jelmer> Probably a new one. ValueError would work too, but is perhaps a bit too generic.
[12:27] <wgrant> Right. Is it worth creating a new exception for that?
[12:28] <jelmer> Personally I think so, it'd be clearer if people come across that error. I can see the argument either way though.
[12:28] <jelmer> s/it'd/it'll/
[12:42] <jelmer> bac`: hi
[13:41] <bigjools> mars: I just send an MP mail, can I add myself to your queue please
[13:45] <bac> hi jelmer
[13:46] <jelmer> bac: 'morning!
[13:46] <jelmer> bac: I was wondering if you'd seen my follow-up to https://code.edge.launchpad.net/~jelmer/launchpad/600153-qafix/+merge/30790
[13:47] <bac> jelmer: done
[13:47] <bac> thanks for the reminder
[13:48] <jelmer> bac: thanks for the review :-)
[14:17]  * flacoste is back.
[15:31] <jtv> hi mars, thanks for reviewing me
[15:31] <mars> np
[15:52] <gary_poster> benji: I'll see how far I get.  To start:
[15:53] <gary_poster> - I'd suggest making a local release of this release of batchnavigator and integrate it with Launchpad.  Then you can see if the change to the endNumber behavior is problematic
[15:54] <gary_poster> - in lines 55 and 59 of the diff, why do you call len(batch) outside of the assertions?
[15:55] <benji> re. local release: good idea
[15:56] <gary_poster> - I don't see the value of the behavior described in lines 68-74 of the diff
[15:56] <gary_poster> shouldn't prevBatch try again, or at least puke?
[15:56] <gary_poster> as it is, it seems like an odd edge case designed to bite people unexpectedly :-)
[15:57] <gary_poster> - I like the new endNumber behavior.  I also like the new comments.
[15:57] <benji> re. len: that's cruft that shouldn't be there; removing
[15:58] <gary_poster> cool
[15:58] <gary_poster> also cruft: line 115 (#print "_get_length called (EXPENSIVE)")
[15:59] <benji> re. 68-74: me neither, I just added comments that describe what is being testsed; I don't think the behavior is useful, but I don't believe that strongly enough to remove the tests
[15:59] <gary_poster> - line 120: the Lazy decorator is supposed to mean that you just "return self._get_length(self.list)"
[15:59] <gary_poster> you shouldn't have to also set the _listlength value
[16:00] <gary_poster> 68-74: but...that's new test for this branch
[16:00] <gary_poster> maybe this is something that leonard added for this branch?
[16:00] <gary_poster> if so, my question goes to him
[16:00] <benji> the reason we set _listlength is so we can use it if available; avoiding calling listlength if not
[16:01] <benji> let me look at 68-74 again
[16:02] <gary_poster> _listlength: ah ok.  Maybe remove the @Lazy then, since I suspect it adds processing cost for the reader for little to no advantage for speed?
[16:02] <benji> gary_poster: right, Leonard added the test, I added the comment
[16:03] <gary_poster> ok.  do you want me to ping him, or do you want to pursue on your own so you feel you understand it first?
[16:03] <gary_poster> (where "pursue on your own" == "you ping Leonard" in my book, but as you wish :-) )
[16:03] <benji> re. _listlength: +1
[16:03] <gary_poster> cool
[16:03] <benji> I'll pursue
[16:04] <gary_poster> cool thanks
[16:05] <gary_poster> I don't understand "return len(self._sliced_list) - 1" yet: why -1?  Maybe I'll see soon...
[16:05] <gary_poster> (line 139)
[16:08] <gary_poster> - another cruft but: #print "sliced_list called (EXPENSIVE)" (line 206)
[16:08] <gary_poster> s/but/bit/
[16:42] <henninge> mars: Hi, I added myself to the queue and it would be great if you could get to my branch but I will also have to leave in 30 min. So I don't mind it waiting around till tomorrow, either.
[16:43] <henninge> ;-)
[16:44] <henninge> oops, confilcts ...


[14:31] <cpaelzer> o/
[14:31] <jbicha> o/
[14:31] <cpaelzer> #startmeeting Weekly Main Inclusion Requests status
[14:31] <meetingology> Meeting started at 14:31:54 UTC.  The chair is cpaelzer.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[14:31] <eslerm> o/
[14:31] <meetingology> Available commands: action, commands, idea, info, link, nick
[14:31] <sarnold> good morning
[14:32] <cpaelzer> Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage ( eslerm dviererbe )
[14:32] <slyon> o/
[14:32] <cpaelzer> #topic current component mismatches
[14:32] <cpaelzer> Mission: Identify required actions and spread the load among the teams
[14:32] <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[14:32] <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[14:32] <joalif> o/
[14:32] <cpaelzer> To keep things in consumable chunks the first 6 of the perl deps for spamassassin are now up
[14:32] <cpaelzer> see the red color
[14:32] <dviererbe> o/
[14:32] <cpaelzer> we'll get to that when assigning new MIR cases for review
[14:32] <cpaelzer> nvmse-stas was considerd ready, but waiting dor dasbus
[14:33] <cpaelzer> which is on security atm
[14:33] <cpaelzer> nothing else new here AFAICS
[14:34] <cpaelzer> even nothing new in proposed
[14:34] <cpaelzer> which feels right given we are in feature freeze
[14:34] <slyon> libei is now ready for security, too (but also some TODOs for jbicha)
[14:34] <cpaelzer> good to know
[14:34] <sarnold> now I wonder about the flood of FFEs :)
[14:34] <jbicha> 👍
[14:34] <cpaelzer> dracut also is ok, will enter security later on (for next cycle)
[14:35] <cpaelzer> but for now we agreed on a package splitting that allows to pass just a minimal thing without
[14:35] <slyon> nice!
[14:35] <cpaelzer> it is back on bdrung to get this in place
[14:35] <slyon> ACK
[14:35] <cpaelzer> #topic New MIRs
[14:35] <cpaelzer> Mission: ensure to assign all incoming reviews for fast processing
[14:35] <cpaelzer> #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&assignee_option=none&field.assignee=&field.subscriber=ubuntu-mir
[14:36] <cpaelzer> uh wow 10
[14:36] <cpaelzer> so much for "not much because of FF"
[14:36] <cpaelzer> but as I said
[14:36] <cpaelzer> 6 of them are meant to be trivial perl cases
[14:36] <cpaelzer> back in the day they almost got no review, that isn't how we should do it again
[14:36] <cpaelzer> but really, structurally they are mostly a mechanical repack of the perl modules
[14:36] <cpaelzer> with auto-autopkgtest and usually good test sets
[14:37] <cpaelzer> with small and well defined use cases
[14:37] <sarnold> being on the hotpath for handling email they deserve a reasonable look
[14:37] <cpaelzer> So I'd wonder if we can distribute those to just one person as they'd all feel very similar
[14:37] <sarnold> lintian modules are something else
[14:37] <cpaelzer> indeed
[14:37] <cpaelzer> I was just going there sarnold
[14:38] <cpaelzer> It will not be no review, but by structurally sharing that much there likely would be a huge efficiency gain by one doing them all
[14:38] <cpaelzer> that is what I wanted to say :-)
[14:38] <sarnold> that makes sense, yes
[14:38] <cpaelzer> so I'm looking for a volunteer for 6xsupposed-to-be-simple cases
[14:38] <slyon> I could probably take 2-3 of those for next week, assuming they are small. But probably not all of them
[14:38] <joalif> I can also take some
[14:39] <cpaelzer> it is actually 8, so how about 4 each but no complaining stares if not all of them are done next week?
[14:39] <slyon> +1
[14:39] <joalif> sure
[14:40] <cpaelzer> assigned
[14:41] <bdrung> cpaelzer, I just uploaded dracut 059-4ubuntu2 that splits out dracut-install. Should I assign the ticket back to you?
[14:41] <cpaelzer> update the bug, set it back to new and unassign yourself
[14:41] <cpaelzer> bdrung: ^^
[14:42] <cpaelzer> and I guess make the seed or dependency change that will pull it in
[14:42] <cpaelzer> once all is in place ping one from the team here to ack for the promotion of dracut-install
[14:42] <bdrung> thanks. I am working on the initramfs-tools change now.
[14:42] <cpaelzer> we'll set the state to "in progress" reflecting that
[14:42] <cpaelzer> Then subscribe ubuntu archive admins to do the promotion
[14:43] <cpaelzer> ok
[14:43] <cpaelzer> ok, in terms of reviews two more to g
[14:43] <cpaelzer> go
[14:43] <cpaelzer> I'll take gnome-clocks, because why not
[14:43] <cpaelzer> leaved https://bugs.launchpad.net/ubuntu/+source/pappl-retrofit/+bug/2031814 unassigned
[14:43] -ubottu:#ubuntu-meeting- Launchpad bug 2031814 in pappl-retrofit (Ubuntu) "[MIR] pappl-retrofit" [Undecided, New]
[14:43] <cpaelzer> missing didier who is out atm
[14:44] <cpaelzer> we have assigned more than we commted to be able to do each week (due to those perly things)
[14:44] <cpaelzer> so I think this one has to wait
[14:44] <cpaelzer> s/commted/committed/
[14:44] <slyon> I agree
[14:45] <cpaelzer> and of course this is a late "needs to be in 23.10" *sigh*
[14:45] <cpaelzer> but still we are humans and have plenty of other tasks
[14:45] <cpaelzer> I think that is ok, re-eval next week
[14:45] <cpaelzer> #topic Incomplete bugs / questions
[14:45] <cpaelzer> Mission: Identify required actions and spread the load among the teams
[14:45] <cpaelzer> #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.subscriber=ubuntu-mir
[14:45] <cpaelzer> dracut was clarified above
[14:46] <cpaelzer> s390x-tools and rust has gotten a block-proposed update
[14:46] <cpaelzer> most recent actual change is https://bugs.launchpad.net/ubuntu/+source/dotnet6/+bug/2023531
[14:46] -ubottu:#ubuntu-meeting- Launchpad bug 2023531 in dotnet6 (Ubuntu) "[MIR] dotnet6" [Undecided, Incomplete]
[14:46] <cpaelzer> hmm, that is a response to the review
[14:46] <cpaelzer> I need to read that with some time
[14:46] <cpaelzer> since I've done the review
[14:47] <cpaelzer> opic Process/Documentation improvements
[14:47] <cpaelzer> Mission: Review pending process/documentation pull-requests or issues
[14:47] <cpaelzer> #link https://github.com/canonical/ubuntu-mir/pulls
[14:47] <cpaelzer> #link https://github.com/canonical/ubuntu-mir/issues
[14:47] <dviererbe>  Greet new contributers on first issue/pr #37 https://github.com/canonical/ubuntu-mir/pull/37
[14:47] -ubottu:#ubuntu-meeting- Pull 37 in canonical/ubuntu-mir "Greet new contributers on first issue/pr" [Open]
[14:48] <cpaelzer> that is a nice idea, but also so new the tests didn't run yet right?
[14:48] <dviererbe> Github queue seems to be long today, the Ci was just not run yet
[14:49] <cpaelzer> I generally like this idea
[14:49] <slyon> Maybe s/GMT/UTC/, otherwise lgtm.
[14:49] <cpaelzer> where you able to pre-test this somehow dviererbe?
[14:50] <dviererbe> Kind of yes here: https://github.com/canonical/ubuntu-mir/actions/runs/5939665817/job/16106543321 but I oriented myself on the config of other repos that used the action
[14:50] <cpaelzer> ok, nice
[14:50] <dviererbe> https://grep.app/search?q=%20%20%20%20%20%20uses%3A%20actions/first-interaction%40v1
[14:50] <slyon> dviererbe: do we need to install the "secrets.GITHUB_TOKEN" somehow?
[14:51] <cpaelzer> how about this - fix the GMT/UTC and allow time to pass for any potential further reviewers
[14:51] <dviererbe> No this is a environment variable that gets injected by the action runner
[14:51] <cpaelzer> then we can land once tests also have ran e.g. in next weeks meeting
[14:51] <slyon> ok
[14:51] <dviererbe> Than I also should replace it in the Readme.md
[14:51] <dviererbe> Thats where I took it from
[14:52] <cpaelzer> is that what we have oO
[14:52] <cpaelzer> let me look at the invite what TZ we have set for real
[14:52] <slyon> well.. yeah. It's more of a nitpick. We can also keep it as-is.
[14:52] <cpaelzer> it is actually "4.30pm CET"
[14:52] <slyon> cpaelzer: I think giving the real TZ make sense, as that would account for time shifts
[14:52] <cpaelzer> how about chaning .md and this to that value
[14:52] <dviererbe> https://github.com/canonical/ubuntu-mir/blob/bb1087152706f72aa0c535a20dde5c72a442033b/README.md?plain=1#L1073
[14:52] <sarnold> hah, it's in there twice
[14:52] <cpaelzer> so that git matches the calendar
[14:52] <sarnold>  (Tuesdays 15:30-16:00 GMT) near the end
[14:53] <dviererbe> I change it
[14:53] <sarnold> 2023-08-22 14:52:58 < sarnold>  (Tuesdays 15:30-16:00 GMT) near the end
[14:53] <cpaelzer> well and this PR, other than adding the nice welcome
[14:53] <sarnold> funny enough, that second one is just plain wrong part of the year :)
[14:53] <cpaelzer> could sync all those mentions with the calendar entry we have
[14:53] <cpaelzer> dviererbe: ok with that?
[14:53] <dviererbe> Yes :)
[14:54] <cpaelzer> next is https://github.com/canonical/ubuntu-mir/pull/36
[14:54] -ubottu:#ubuntu-meeting- Pull 36 in canonical/ubuntu-mir "Add an ask about isolation features" [Open]
[14:54] <sarnold> woot, thanks dviererbe :)
[14:54] <cpaelzer> which we had some approval when discussing
[14:54] <cpaelzer> but now have  PR actually writing about it
[14:54] <cpaelzer> no need to read it now
[14:54] <cpaelzer> but before next week an ack or feedback would be nice
[14:54] <cpaelzer> ok?
[14:54] <sarnold> ack
[14:54] <cpaelzer> ok, the rest is old/draft
[14:55] <cpaelzer> #topic MIR related Security Review Queue
[14:55] <cpaelzer> Mission: Check on progress, do deadlines seem doable?
[14:55] <cpaelzer> Some clients can only work with one, some with the other escaping - the URLs point to the same place.
[14:55] <cpaelzer> #link https://bugs.launchpad.net/~ubuntu-security/+bugs?field.searchtext=%5BMIR%5D&assignee_option=choose&field.assignee=ubuntu-security&field.bug_reporter=&field.bug_commenter=&field.subscriber=ubuntu-mir
[14:55] <cpaelzer> #link https://bugs.launchpad.net/~ubuntu-security/+bugs?field.searchtext=[MIR]&assignee_option=choose&field.assignee=ubuntu-security&field.bug_reporter=&field.bug_commenter=&field.subscriber=ubuntu-mir
[14:55] <cpaelzer> Internal link
[14:55] <cpaelzer> - ensure your teams items are prioritized among each other as you'd expect
[14:55] <cpaelzer> - ensure community requests do not get stomped by teams calling for favors too much
[14:55] <cpaelzer> #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594
[14:55] <cpaelzer> never heard of semgrep_rules_manager
[14:55] <cpaelzer> why is that in this kanban board at all?
[14:55] <eslerm> I'll add libei to our jira board
[14:55] <cpaelzer> thanks eslerm
[14:56] <cpaelzer> about dracut
[14:56] <cpaelzer> while we split things out and promote a very small subset now
[14:56] <cpaelzer> this would also want to be added to the security board tracking
[14:56] <cpaelzer> even not yet being assigned to you on the bug
[14:56] <cpaelzer> that is https://bugs.launchpad.net/ubuntu/+source/dracut/+bug/2031304
[14:56] -ubottu:#ubuntu-meeting- Launchpad bug 2031304 in dracut (Ubuntu) "[MIR] dracut" [Undecided, Incomplete]
[14:56] <cpaelzer> would you be able to add that as well?
[14:56] <eslerm> can do
[14:56] <cpaelzer> the rest looks kind of "as expected"
[14:57] <cpaelzer> heif and siblings to fully complete soon or 24.04 the ltest
[14:57] <cpaelzer> stuff in progress
[14:57] <cpaelzer> all good AFAICS
[14:57] <cpaelzer> keeping time in mind let me call for
[14:57] <cpaelzer> #topic Any other business?
[14:57] <sarnold> none here
[14:57] <eslerm> heif had a block last week, let me find it
[14:57] <slyon> eslerm: I added some update comments to the heif related MIRs
[14:58] <slyon> pfsmorigo: I was wondering about the state of cargo?
[14:58] <eslerm> ack, thanks I'll follow up
[14:58] <cpaelzer> I didn't want to ask about cargo given the time, but you are right to do so ... :-/
[14:58] <eslerm> Seth, can you answer for Paulo please
[14:59] <sarnold> slyon: pfsmorigo has written a report on it, and I've not yet had the time to read his report :(
[14:59] <slyon> sarnold: can we see that report somewhere, or is it still internal?
[14:59] <sarnold> slyon: yeah I could bounce you a copy
[14:59] <slyon> that be great, thanks
[15:00] <slyon> nothing else from my side
[15:00] <cpaelzer> next meeting is starting and nothing else
[15:00] <sarnold> eek thanks for the 'next meeting' reminder
[15:00] <sarnold> I swear if my head weren't bolted on..
[15:00] <cpaelzer> hehe
[15:00] <dviererbe> :D
[15:01] <cpaelzer> thanks
[15:01] <cpaelzer> see you all
[15:01] <cpaelzer> #endmeeting
[15:01] <meetingology> Meeting ended at 15:01:07 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-08-22-14.31.moin.txt
[15:01] <eslerm> thanks all o/
[15:01] <dviererbe> thanks everyone!
[15:01] <slyon> thanks all! o/
[15:01] <dviererbe> o/
[15:01] <joalif> thanks all!
[18:55]  * vorlon waves
[18:56] <vorlon> https://wiki.ubuntu.com/TechnicalBoardAgenda says 'next meeting 7/25', have we missed all the meetings since then?
[19:00] <rbasak> o/
[19:00] <amurray> o/
[19:00] <rbasak> No meetings until July 2025? :-)
[19:00] <seb128> checking irclog it seems the 7/25 - 8/8 ones didn't have quorums
[19:02] <vorlon> then I guess rbasak is chair today
[19:02] <rbasak> #startmeeting Technical Board
[19:02] <meetingology> Meeting started at 19:02:12 UTC.  The chair is rbasak.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[19:02] <meetingology> Available commands: action, commands, idea, info, link, nick
[19:02] <rbasak> #topic Action Items
[19:02] <rbasak> ACTION: seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage
[19:02] <rbasak> I've seen some text. Is that ready?
[19:04] <seb128> hum
[19:05] <seb128> do we need Ken to reply to your comments?
[19:05] <rbasak> There are some comments, and also I've seen a suggestion from timhm to drop the current use of the branches that auto-close.
[19:05] <rbasak> I pinged timhm but he's only back from PTO today.
[19:05] <vorlon> fwiw the text there is different than the original rationale for the ubuntu-YY.MM tracks
[19:05] <rbasak> I was going to ping Ken today but I found that he's out for a few days too
[19:06] <rbasak> > The complete channel name can be structured as three distinct parts separated by slashes:
[19:06] <rbasak> > <track>/<risk>/<branch>
[19:06] <vorlon> i.e. they weren't intended to be a committment to "bugfix+security only changes", they were only intended to be an escape hatch if there was a per-release regression due to integration issues
[19:06] <rbasak> Currently I believe we're using *branch*
[19:06] <rbasak> Which autocloses after 30 days
[19:06] <vorlon> ah
[19:07] <rbasak> "Requirement B: Ubuntu developers will be able to override and patch the package"
[19:07] <vorlon> yes, sorry, I assumed this was referring to the stuff we were currently using and second-guessed myself on track vs branch :)
[19:07] <rbasak> That would be fulfilled by the current use of the branch I think.
[19:07] <rbasak> And is sort of similar to the escape hatch rationale you mention but not quite the same.
[19:07] <seb128> the current use is to set our snap to follow stable/ubuntu-<xx.yy> right?
[19:07] <vorlon> right
[19:07] <seb128> so that means following stable
[19:08] <seb128> but what we would like is rather to follow a serie specific track
[19:08] <vorlon> "we would like" - who would like that and why?
[19:09] <seb128> like for GNOME 45 we should set mantic to follow 45/ stable
[19:09] <seb128> 45/stable
[19:09] <seb128> well, if the goal is to have a behaviour similar to what we have today with debs
[19:09] <rbasak> I think that would be fine
[19:10] <seb128> following latest/stable would mean mantic users would get GNOME 46 updates when those are flagged stable
[19:10] <rbasak> But it would need to be 45/stable/ubuntu-24.04 or similar
[19:10] <amurray> the reason I suggested tracks rather than branches is to avoid the issue of branches auto-closing - and the reason I put in the bug/security fixes only is to try and have the same expectation for snaps as debs from an end-users perspective
[19:10] <rbasak> So using <branch> like we already do, but also adding <track>.
[19:11] <rbasak> amurray: so I think the pushback from the store admins would be that this overloads the purpose of tracks and the idea that snaps are supposed to be distro-agnostic.
[19:11] <rbasak> AIUI, there was a similar resistance to using branches in this way, but it did end up happening.
[19:11] <rbasak> There's another important behaviour to keep in mind here.
[19:12] <rbasak> snapd can "track" firefox latest/stable/ubuntu-22.04 for example, but if that doesn't exist, then it just falls back to use "latest/stable" instead.
[19:12] <vorlon> 45 is not an Ubuntu version, of course.  If we are using tracks based on the versioning of the application upstream, that will cause more work on the Ubuntu side to keep track of the tracks; if we wanted consistency on the Ubuntu side to always use tracks such as ubuntu-23.10/stable (the current suggested text?) that puts more work on the snap publisher
[19:12] <rbasak> Replace "latest" with a track if you like.
[19:12] <rbasak> So we don't usually have to publish to the branch, so auto-closing isn't much of a concern in practice.
[19:13] <rbasak> If we used the escape hatch, _only then_ would we need to make sure we keep republishing within 30 days, or see about changing that feature.
[19:13] <vorlon> fwiw firefox has been using the branches
[19:13] <vorlon> as has subiquity
[19:13] <rbasak> On this machine I have:
[19:13] <rbasak> tracking:     latest/stable/ubuntu-22.04
[19:13] <vorlon> just in case anyone thought this was a vestigial feature
[19:14] <rbasak> Oh yes and my revno is different from the channels that are publicly visible.
[19:14] <amurray> yep but I thought there was pushback from the desktop team that they found it onerous that the branches autoclose
[19:14] <rbasak> To make progress with the doc in general, I suggest that we document what we're currently doing, and make sure that before we change what we're doing everyone involved reaches consensus first?
[19:15] <amurray> it sounds like we are choosing between two problems - either we use branches and that puts the burden on the publisher to keep publishing else they auto-close - or we use tracks which gets pushback from the store team..?
[19:15] <vorlon> amurray: well, I think that's a valid objection and maybe worth revisiting with the store team?  but for this discussion, wrt track naming I'll point out that a firefox upstream version would not be suitable for the track if you wanted it to be different for 22.04 and 23.04
[19:16] <vorlon> why would the store team push back on the use of tracks?
[19:17] <rbasak> AIUI, they don't want Ubuntu-specific tracks. The store is supposed to be distro-agnostic, so the tracks should be what makes sense to the upstream.
[19:17] <vorlon> ok
[19:17] <vorlon> then tracks are unsuitable for firefox
[19:18] <vorlon> because the differences between the snaps on the different branches right now are about base+content snap, not upstream version branches
[19:18] <rbasak> I don't mind how this is implemented, but I think that our base requirements are reasonable and the snap ecosystem needs to be able to figure out how to support them :-/
[19:19] <vorlon> the store team doesn't want to accomodate branches that don't auto-close, but nothing says that the publishers can't set up timers to auto-refresh those branches and keep them open
[19:20] <vorlon> but, as rbasak points out, the implementation is not really a TB question
[19:21] <vorlon> wrt this point on the agenda, it doesn't seem we're ready to close anything out?
[19:21] <rbasak> Agreed.
[19:21] <rbasak> But can we agree on next steps?
[19:21] <amurray> same
[19:21] <rbasak> I had a suggestion on that bove
[19:22] <vorlon> "document what we're doing" - +1 from me
[19:22] <seb128> +1
[19:22] <rbasak> Could someone who understands exactly what we're doing please take that action? :)
[19:23] <vorlon> I think seb128 is best positioned
[19:23] <seb128> alright :p
[19:23] <rbasak> OK so let's carry the action
[19:23] <rbasak> #action seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage
[19:23] <meetingology> ACTION: seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage
[19:23] <rbasak> ACTION: rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification
[19:24] <rbasak> I'll carry this over again
[19:24] <rbasak> #action rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification
[19:24] <meetingology> ACTION: rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification
[19:24] <rbasak> (I'm not aware for any reason for this to be a priority right now)
[19:24] <rbasak> ACTION: rbasak to follow up on finding consensus on question of test plans for third party apps
[19:24] <rbasak> Hmm. I don't remember this.
[19:25] <vorlon> IIRC there was a question about what should be required wrt test plans for seeded snaps, vs. the MIR requirements for autopkgtests
[19:26] <rbasak> Just found the logs
[19:26] <rbasak> OK looks like I knew the details once, so I'll carry that over and I don't think I'm blocked
[19:26] <rbasak> #action rbasak to follow up on finding consensus on question of test plans for third party apps
[19:26] <meetingology> ACTION: rbasak to follow up on finding consensus on question of test plans for third party apps
[19:26] <rbasak> ACTION: rbasak to restructure the third-party repo doc to make the status clearer
[19:26] <rbasak> This one's done I think?
[19:26] <rbasak> ACTION: rbasak to open wider discussion on third-party repo policy
[19:27] <rbasak> I started writing up a post for a call for wider discussion and feedback.
[19:27] <rbasak> I feel a little blocked on a comment from Ken in the doc. I intend to follow up with him his week or next week after he's back from PTO.
[19:27] <rbasak> #action rbasak to open wider discussion on third-party repo policy
[19:27] <meetingology> ACTION: rbasak to open wider discussion on third-party repo policy
[19:27] <rbasak> ACTION: seb128 to follow up with SRU, AA, Release, Backporters and Security teams to document their membership process and link to it from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations
[19:28] <seb128> carry over please
[19:28] <rbasak> #action seb128 to follow up with SRU, AA, Release, Backporters and Security teams to document their membership process and link to it from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations
[19:28] <meetingology> ACTION: seb128 to follow up with SRU, AA, Release, Backporters and Security teams to document their membership process and link to it from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations
[19:28] <rbasak> #topic Packages in the archive that download and run software from the Internet, and third-party repository requirements
[19:28] <rbasak> (vorlon)
[19:28] <vorlon> hi
[19:29] <vorlon> the reason I put this on the agenda was that I happened to just notice that the lutris package in multiverse downloads software from possibly arbitrary locations on the Internet to be run
[19:29] <vorlon> and I think that's bad and was going to dig into it to see just how bad and whether it should be thrown out of the archive
[19:30] <vorlon> and then I realized I didn't have a written policy on this stuff that I could point to
[19:30] <rbasak> I'm reminded of flashplugin-downloader or whatever it was called
[19:30] <rbasak> Also torbrowser-launcher
[19:30] <vorlon> flashplugin-downloader at least had the constraints that it would only download files with known hashes that were embedded in the packaging
[19:30] <rbasak> That one's in universe.
[19:31] <vorlon> the fact that it downloaded at install time rather than shipping in the package was a concession to redistribution constraints
[19:31] <amurray> hmm is this a slippery slope? we also have say emacs which can be configured to download emacs lisp packages from arbitrary locations
[19:31] <amurray> (just as an example)
[19:31] <rbasak> I was going to point at wget :-P
[19:31] <vorlon> heh
[19:31] <seb128> or you can download anything to install from a webbrowser...
[19:32] <rbasak> So, where's the line?
[19:32] <rbasak> Does being in multiverse make it OK?
[19:34] <amurray> does lutris do any sandboxing internally? perhaps if it did then that would lessen the risk here
[19:34] <vorlon> well lutris is effectively a package shipping a "store" for third-party games from the Internet
[19:35] <rbasak> Sounds like the flatpak package :-P
[19:35] <rbasak> (although it doesn't default to a store I don't think!)
[19:35] <rbasak> So snapd
[19:35] <vorlon> well, right, and clearly we have expectations about what the snapd package should present as a store :)
[19:36] <rbasak> One could argue that a user understands that installing lutris opts them in to a specific store
[19:36] <vorlon> the bit that irked me was actually watching it download a mame tarball from the Internet when we have mame as a deb
[19:37] <vorlon> rbasak: I don't think our users should be expected to assess the security design of every store someone puts in the Debian or Ubuntu archive as a deb and that we should have some common guidelines
[19:38] <vorlon> does lutris have cryptographic verification of the games it downloads from the Internet? is that based on ssl or on some sort of signing of a store payload? who manages that?  is there sandboxing? etc
[19:38] <rbasak> lutris is synced from Debian though?
[19:38] <amurray> common guidelines sound reasonable
[19:39] <rbasak> So while I understand your concern and would like to see improvement there, I'm not sure we could really be effective unless Debian is also doing it, so it seems like we would need consensus in Debian
[19:39] <rbasak> OTOH the other stuff involving third party requierements are mostly Ubuntu-specific differences
[19:40] <rbasak> Like we might as well document "if Debian do it then it's acceptable for Ubuntu by default because autosync" in our doc
[19:40] <vorlon> well even if there is a policy we'd likely be playing whack-a-mole for a while in either Debian or Ubuntu
[19:40] <vorlon> I would still like to see some documented principles of what we expect from packages in the Ubuntu archive
[19:40] <rbasak> I have no objection to having the TB endorse something like that.
[19:41] <vorlon> (btw lutris actually completely failed to download and install the game I was trying to get running on my kid's system, and I wound up grabbing a zip file of the DOS program and running it directly under dosbox :P)
[19:41] <rbasak> vorlon: would you like an action to write some guidelines?
[19:41] <vorlon> rbasak: sounds like you're suggesting .. ^ that :)
[19:41] <vorlon> yes
[19:42] <rbasak> #action vorlon to write up draft guidelines for packages in the archive that download from the Internet
[19:42] <meetingology> ACTION: vorlon to write up draft guidelines for packages in the archive that download from the Internet
[19:42] <rbasak> ^ that wording is deliberately open. You can figure out how to define the scope when you write it up :)
[19:42] <rbasak> Any further discussion on this topic?
[19:43] <vorlon> fwiw I think there's other historical precedent of e.g. disabling browser plugin stores by default in browsers
[19:43] <vorlon> or of disabling vendor auto-update mechanisms
[19:43] <rbasak> This will be quite slippery to define I think.
[19:43] <vorlon> all related :)
[19:43] <vorlon> yep. challenge accepted, thanks
[19:43] <rbasak> #topic Scan the mailing list archive for anything we missed (standing item)
[19:44] <rbasak> #info No recent ML posts
[19:44] <rbasak> #topic Check up on community bugs and techboard bugs
[19:44] <rbasak> #info No new bugs; existing bugs are all being handled through existing action items
[19:45] <rbasak> #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members)
[19:45] <rbasak> #info Next chair will be seb128 with vorlon as backpu
[19:45] <rbasak> #indo
[19:45] <rbasak> #undo
[19:45] <meetingology> Removing item from minutes: INFO
[19:45] <rbasak> #info Next chair will be seb128 with vorlon as backup
[19:45] <seb128> ack
[19:45]  * vorlon nods
[19:45] <rbasak> #topic AOB
[19:46] <rbasak> Anything else from anyone?
[19:46] <vorlon> nothing here
[19:46] <rbasak> #endmeeting
[19:46] <meetingology> Meeting ended at 19:46:35 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-08-22-19.02.moin.txt
[19:46] <rbasak> Thanks all!
[19:46] <seb128> thanks!
[19:46] <vorlon> fwiw I'm going to have another request to twiddle the weeks due to my availability changing again, but that's not until after the next meeting
[19:46] <rbasak> ack
[19:46] <vorlon> thanks!
[19:46] <amurray> thanks for chairing rbasak


 Telegram just got multi-window support
 When it gets real
 Yup
 That was one of the guys TV where I was last night
 It was a crazy big and nice house
 does anybody have a 2TB hdd they are not using? or selling?
 Not i
 aw, ok
 Not  I, in fact looking for one as well
 Or larger if I can
 anybody having issues with the telegram desktop app?
 Not really but I'm using the snap one
 ok
 @AbMind beer party?
 @RazPi around?
 Love ya Google
 Hi what
 did you get that email about the Alain?
 Alain's birthday dinner
 Oh I didn't
 I saw your name on it
 I am painting my bedroom ceiling pink...
 any reason?
 Are you going to add ponies?
 There will NOT be ponies
 Not amazing so far
 http://www.geekbuying.com/item/MINIX-NEO-Z83-4-Fanless-4G-RAM-Windows-10-Licensed-MINI-PC-372395.html?utm_source=newsletter&utm_medium=EDM&utm_content=&utm_campaign=DMCAH_holiday_20160924
 Kangaroo makes a few that are a lot better than that
 Yeah, I removed that. I noticed it was way too expensive
 Mm 19℅ now
 Ubuntu month coming up


[12:20] <sakrecoer> i still get the blueman crash at start up on my dev install...
[12:21] <sakrecoer> am i missing something?
[12:35] <kryten> sakrecoer: Not if you think it's not fixed yet, nope :P - LP bug 1533206.
[12:55] <zequence> Just told this is offtopic channel. Going to abandon any work on -controls for this release. Maybe do a backport later.
[12:55] <zequence> Have rewritten the application from scratch, but only added a new feature. It is not ready though, which is why I haven't put it up yet
[12:55] <zequence> s/is/on
[13:36] <OvenWerk1> understood.
[13:36] <OvenWerk1> zequence: -controls as it sits is still quite useful.
[13:37] <OvenWerk1> I look forward to the changes.
[13:41] <OvenWerk1> sakrecoer: the blueman crash... I think is just blueman exiting due to not finding HW. So the problem is that the system picks it up as a crash.
[13:43] <OvenWerk1> I will try setting up my Wiimote later. If that still works then the system is workable.
[13:59] <sakrecoer> if you are arround krytarik maybe we can continue where we left of on that lightDM thing? :)
[13:59] <sakrecoer> later thsi evening that is...
[13:59] <sakrecoer> anyways, i have to run now! o/~
[14:00] <kryten> I'll be around, yes - that'd be nice.
[21:12] <sakrecoer> got a mail from madeinkobaia. in french. very nice, gave a very different tone somehow.
[21:13] <sakrecoer> zequence, he said that he was willing to do some efforts to work in a more teamoriented way. if i got it right, what is keeping him from it is language barrier
[21:14] <sakrecoer> keeping him from it = keeping him from being more engaged in the team.
[21:14] <sakrecoer> he also said that until may he hasn't got the time-space to do anything, unfortunately..
[21:18] <sakrecoer> zequence: too bad for the controls. i guess i can relate with the feeling of being uninspired... Whish i could ring on your dorbell with some tacos and beers and help you do it... or bring a cheerleader robot team with pompoms to do some motivation dance under your window
[21:19] <sakrecoer> been wanting to say it would be an awesome legacy as you step down, but i'm affraid it would just pressure you instead..
[21:21] <sakrecoer> so, i organised a robot cheerleading team instead:
[21:21] <sakrecoer> └|ﾟεﾟ|┐ ┌|ﾟзﾟ|┘ └|ﾟεﾟ|┐ ┌|ﾟзﾟ|┘ └|ﾟεﾟ|┐ ┌|ﾟзﾟ|┘
[21:22] <sakrecoer> it isn't techincaly under your window, but hey, it is IN your irssi window :p
[21:54] <knome> sakrecoer, can you confirm me something?
[21:54] <knome> sakrecoer, when you log in to the ubuntustudio.org web admin, do you have administrator access?
[21:56] <sakrecoer> let me check
[21:57] <sakrecoer> ehm... atm all i see on ubuntustudio.org is a white page with an orange ubuntu header
[21:57] <knome> i notice that too
[21:57] <knome> but can you just log in?
[21:58] <sakrecoer> i'm in, but how do i tell what type of account i have?
[21:58] <knome> sakrecoer, can you see the menu "appearance -> menus" ?
[21:58] <sakrecoer> yes
[21:59] <knome> ok, great
[21:59] <knome> then you can likely see "appearance -> themes" too
[21:59] <sakrecoer> yes
[22:00] <knome> sakrecoer, you should be able to switch to the correct ubuntu studio theme from that page
[22:01] <sakrecoer> knome: buntu Loco Light Theme ?
[22:01] <sakrecoer> Ubuntu Loco Light Theme, even
[22:01] <knome> no
[22:01] <knome> should be very prominently ubuntu studio
[22:01] <knome> if it isn't available... sigh
[22:01] <sakrecoer> no such theme i am affraid...
[22:02] <knome> if you want, you can add me to the team that has the admin rights on ubuntustudio.org and i can try to debug it directly with the IS
[22:03] <sakrecoer> sure, i have never done that before tho, knome.
[22:03] <knome> ok, so the membership is linked to a certain LP team
[22:03] <knome> do you know what that is or should i help you figure out?
[22:03] <sakrecoer> i reckon it is this one: https://launchpad.net/~ubuntustudio-website
[22:03] <sakrecoer> but i don't know for sure..
[22:04] <knome> sakrecoer, you can make sure @ settings -> openid teams
[22:04] <knome> you want the line with role administrator and the ubuntustudio team
[22:05] <sakrecoer> yeah that would be the team
[22:05] <knome> great
[22:06] <sakrecoer> your lp is ~knome ?
[22:06] <knome> yes
[22:07] <sakrecoer> strange, i can add you, but i'm not a member of that team...
[22:07] <sakrecoer> oh, maybe it doesn't list me if i look from my own account or something adding you now anyways
[22:08] <sakrecoer> knome: done!
[22:08] <knome> thanks
[22:08] <knome> sakrecoer, you're a member of the core team, which is admin, so you have indirect membership as an admin
[22:09] <sakrecoer> ok, i added you, knome but i don't see you listed either...
[22:09] <sakrecoer> oh, now i do :)
[22:14] <zequence> knome: Our old theme has been replaced
[22:14] <zequence> Don't think that was the idea, right?
[22:15] <knome> zequence, not at all; i'm debugging it as we speak with the IS
[22:15] <knome> zequence, if they even replaced it with the new theme, not the outdated one
[22:16] <zequence> knome: Well, we still need to have our old theme there, until we have prepared for the new one, which we haven't yet
[22:16] <knome> zequence, yes, i'm working on that
[22:16] <zequence> Yeah, saw that, sorry
[22:16] <knome> zequence, i just just saying this is the worst situation ;)
[22:17] <zequence> Has to happen to somebody :)
[22:20] <zequence> Back to normal
[22:20] <knome> ok, should be good now
[22:20] <knome> yep
[22:20] <zequence> sakrecoer: Ok, so madeinkobaia won't be around for any work for a while, then
[22:22] <sakrecoer> zequence: yup, and he is willing to teamwork, but it seems he doesn't really feel capable due to language...
[22:23] <knome> phew. it was close - weekend soon and nobody from the IS around..
[22:23] <zequence> I'm sure he'll warm up to it :)
[22:23] <zequence> knome: :D
[22:23] <knome> we can begin talking finnish with zequence to make him feel more comfortable with french
[22:24] <zequence> Babel all over again
[22:28] <zequence> knome: Weird that they can't add another source
[22:29] <zequence> Where are the theme configs saved, anyway? We need to prepare it on a staging site before we publish it anyway
[22:29] <zequence> We should make those settings first, have them in a repo, and upload from that
[22:30] <knome> zequence, they are saved in the database
[22:31] <zequence> knome: Ah. In a specific table, right?
[22:31] <knome> zequence, yep, _options iirc
[22:32] <zequence> We could just set up a front page saying "we're doing maintenance right now, come back later"
[22:32] <knome> well,
[22:32] <knome> considering if/as you can coordinate a specific time when you want to set the theme up to make sure the IS and you are both available, sure
[22:32] <zequence> Else, do both theming and database migration at once
[22:33] <knome> if both themes were available, you could see the new theme in the customization/live preview
[22:33] <knome> and make sure everything is right there
[22:33] <knome> and once you are ready, kick in the new theme
[22:33] <knome> but if you can only ever have one of the two themes available, that's not possible..
[22:33] <knome> well unless you switch to, say, twenty sixteen in between
[22:34] <knome> but that seems silly
[22:35] <zequence> Ok. I haven't actually tried making changes to a theme before switching to it
[22:37] <knome> that's a relatively recent addition
[22:37] <knome> but yeah, you can handle it from the GUI now
[23:05] <zequence> knome: Thanks for setting this up, btw.
[23:05] <knome> np
[23:05] <knome> if you don't mind, i'll stay in the web team until you got the migration done to make sure there isn't anything fishy going on
[23:06] <zequence> knome: You are welcome to stay there as long as you want on my account.
[23:06] <knome> :)
[23:06] <knome> i try to remove some hats anyway..
[23:07] <zequence> Try cutting of one or two ears first
[23:07] <zequence> off*
[23:07] <knome> i'm out of all appendages and limbs by that analogy already