[16:00] <juliank> o/
[16:00] <ravikant_> o/
[16:01] <Skia> o7
[16:01] <mateus-morais> o/
[16:01] <juliank> #startmeeting Weekly Ubuntu Foundations team
[16:01] <meetingology> Meeting started at 16:01:39 UTC.  The chair is juliank.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[16:01] <xypron> \o
[16:01] <bdrung> \o
[16:01] <meetingology> Available commands: action, commands, idea, info, link, nick
[16:01] <juliank> #topic Lightning rounds
[16:01] <ginggs> o/
[16:01] <juliank> #link https://discourse.ubuntu.com/t/foundations-teams-updates-thursday-2024-03-07
[16:02] <pushkarnk> o/
[16:02] <schopin> o/
[16:02] <ogayot> o/
[16:02] <upils> o/
[16:04] <mkukri> o/
[16:04] <zhsj> o/
[16:04] <liushuyu> o/
[16:05] <adrien> \o
[16:14] <juliank> #topic Release incoming bugs
[16:14] <juliank> #link http://reports.qa.ubuntu.com/reports/rls-mgr/rls-nn-incoming-bug-tasks.html#foundations-bugs
[16:14] <juliank> bug 2056375
[16:14] -ubottu:#ubuntu-meeting- Bug 2056375 in mokutil (Ubuntu) "Ubuntu Studio ISO fails to build: '/usr/sbin/grub-probe: error: failed to get canonical path of `overlay'.'" [Critical, Fix Committed] https://launchpad.net/bugs/2056375
[16:15] <juliank> vorlon: you tagged this but it's basically waiting for mokutil to migrate which has a dep-wait on armhf, where we don't even use mokutil and forced grub through
[16:15] <juliank> or rather force deleted grub
[16:15] <juliank> should we just force delete mokutil in armhf?
[16:16] <vorlon> juliank: I don't follow how it's a mokutil issue, how would that force the removal of packages?
[16:16] <vorlon> I can certainly force delete mokutil on armhf, I don't mind
[16:16] <vorlon> I just don't follow how you figured that out
[16:17] <juliank> vorlon: grub is removed because it is built against libefivar1t64, and we install mokutil from release pocket which still uses libefivar1
[16:17] <juliank> migrating new mokutil with libefivar1t64 depends fixes issue
[16:17] <vorlon> except the libefivar1 dep should be satisfied by libefivar1t64 Provides: libefivar1
[16:18] <vorlon> if promoting mokutil works around it, that's fine, let's just do that
[16:18] <vorlon> and we can move on to the next bug here :)
[16:18] <juliank> APT being stupid I suppose
[16:18] <juliank> bug 2055720
[16:18] -ubottu:#ubuntu-meeting- Bug 2055720 in ubuntu-release-upgrader (Ubuntu) "Edubuntu upgrade removed universe repo mantic -> noble" [High, New] https://launchpad.net/bugs/2055720
[16:19] <enr0n> The main reason I tagged this is that when u-r-u doesn't find valid sources, it offers to setup default sources. Currently that means configuring main and restricted. That's just wrong, right?
[16:19] <enr0n> At the very least it's inconsistent with the default sources described in https://discourse.ubuntu.com/t/spec-apt-deb822-sources-by-default/29333
[16:19] <juliank> Indeed
[16:20] <schopin> Do we enable universe by default?
[16:20] <schopin> On a new install, I mean.
[16:20] <waveform> we used to
[16:21] <waveform> there was an issue where they were disabled ... I think that came up in mantic with ubuntu-image produced builds but it was fixed before release I believe
[16:21] <enr0n> ogayot and dbungert would probably know what we do on default installs
[16:21]  * Eickmeyer chimes
[16:22] <Eickmeyer> Flavors require universe on new installs
[16:22] <waveform> yes, LP: #2037018
[16:22]  * Eickmeyer chimes out
[16:22] -ubottu:#ubuntu-meeting- Launchpad bug 2037018 in ubuntu "universe and multiverse missing from apt sources" [Undecided, Fix Released] https://launchpad.net/bugs/2037018
[16:23] <vorlon> enr0n: "default" sources should include universe, for all install types
[16:23] <enr0n> vorlon: cool thanks
[16:23] <upils> ubuntu-image is setting main,restricted by default but some (ex. ubuntu-server-pi-arm64) configurations do override it to add universe and multiverse
[16:23] <vorlon> I think multiverse should also be enabled though the history there is a bit muddled
[16:23]  * juliank relatedly is also working with josch to get a hook added to mmdebstrap that auomtatically enables universe on Ubuntu systems
[16:23] <vorlon> upils: well there's a bug about it being wrong to use the same set of components for the image build and the post-install sources
[16:24] <waveform> indeed -- it shouldn't be enabled during the image build itself, but patched in at the end
[16:24] <juliank> I see bootstraps of any sorts are main/restricted only, and then enable universe/multiverse? before building final image
[16:25] <juliank> so we don't install packages from them into the image :)
[16:25] <vorlon> juliank: bootstraps of *Ubuntu* are main/restricted only
[16:25] <upils> vorlon: which is now fixed (see LP: 2038111)
[16:25] -ubottu:#ubuntu-meeting- Launchpad bug 2038111 in ubuntu-image "must be able to distinguish between components for image build and target sources.list in image definition" [Medium, Fix Released] https://launchpad.net/bugs/2038111
[16:25] <vorlon> flavors include universe
[16:25] <juliank> hmm
[16:25] <vorlon> upils: ok :)
[16:25] <enr0n> Okay, well for the case of ubuntu-release-upgrader, which is *not* building images, I am going to just add universe to the default components.
[16:25] <juliank> +10
[16:26] <enr0n> I'll untag etc.
[16:26] <vorlon> enr0n: (and multiverse)
[16:26] <enr0n> vorlon: ack
[16:26] <juliank> And next is another enr0n thingie: bug 2055806
[16:26] -ubottu:#ubuntu-meeting- Bug 2055806 in openssh (Ubuntu) "sshd.service ssh.socket systemd-tmpfiles-setup:Before= - Missing privilege separation directory: /run/sshd" [Undecided, New] https://launchpad.net/bugs/2055806
[16:27] <vorlon> analysis on the bug, seemed like it was a slam dunk to fix?
[16:28] <enr0n> vorlon: does that mean you agree with my comment (https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2055806/comments/8)
[16:28] -ubottu:#ubuntu-meeting- Launchpad bug 2055806 in openssh (Ubuntu) "sshd.service ssh.socket systemd-tmpfiles-setup:Before= - Missing privilege separation directory: /run/sshd" [Undecided, New]
[16:28] <vorlon> enr0n: well it made sense to me :)
[16:28] <enr0n> vorlon: ack, I will upload a fix today then
[16:28] <juliank> +1
[16:28] <vorlon> so I agree but have thought deeply about it independently!
[16:28] <vorlon> *not
[16:29] <juliank> If that fails some way we can always add the After= :D
[16:29] <juliank> OK that's it for incoming bugs, the other releases did not have anything for us
[16:29] <juliank> #topic Team proposed-migration report
[16:30] <juliank> #link https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses_by_team.html#foundations-bugs
[16:30]  * juliank hands the talking stick to vorlon
[16:30] <dbungert> does it crash the browser today?
[16:30] <upils> yup
[16:30] <vorlon> 480 packages needing attention
[16:30] <vorlon> hasn't crashed my browser *yet*
[16:31] <vorlon> let's go ahead and assign some of these out
[16:31] <vorlon> and everybody can share in the time_t fun
[16:31] <vorlon> libselinux: adrien please
[16:31] <vorlon> vim: bdrung
[16:31] <bdrung> ack
[16:32] <vorlon> initramfs-tools vs klibc: cpete
[16:32] <adrien> btw, as I mentioned on mattermost, if it crashes your browser, download the page, and atler the page with: sed 's/<a href="https:\/\/.*-perl.*">\(.*\)<\/a>/\1/'
[16:32] <vorlon> procps: dbungert:
[16:32] <dbungert> ack
[16:32] <cpete> ack
[16:32] <vorlon> python-ldap: waveform
[16:32] <adrien> vorlon: I'm scared :D
[16:32] <waveform> ack
[16:32] <vorlon> libgtk3-perl: dviererbe:
[16:32] <dviererbe> ack
[16:33] <vorlon> dviererbe: fwiw that seems to be a general pango1.0 ppc64el issue, based on the list of regressions - so you'll probably need to fix pango1.0 itself
[16:33] <dbungert> adrien: my go-to is to just look at it in `links` on such days
[16:33] <vorlon> libbsd: Skia
[16:33] <dviererbe> okay
[16:33] <Skia> ack
[16:33] <waveform> or good ol' w3m
[16:33] <vorlon> libapt-pkg-perl: ginggs
[16:33] <ginggs> aye aye
[16:33] <vorlon> packagekit: xypron
[16:33] <adrien> dbungert: I know some do but I find it less readable; this sed call reduces the memory usage byt 75% currently, probably more when the page is worse
[16:34] <vorlon> python-apt: juliank
[16:34] <vorlon> dnspython: mkukri
[16:34] <mkukri> ack
[16:34] <vorlon> python-cups: mateus-morais
[16:34] <juliank> hooray
[16:34] <mateus-morais> ack
[16:34] <vorlon> curl: I'm just going to take this one myself because I know what that bootstrap chain looks like :)
[16:34] <Skia> for information, initramfs-tools vs klibc, there already is a fix here: https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/91
[16:34] -ubottu:#ubuntu-meeting- Merge 91 in kernel-team/initramfs-tools "d/t/test-common: fix finding klibc.so" [Opened]
[16:34] <vorlon> publicsuffix: enr0n
[16:35] <enr0n> ack
[16:35] <cpete> skia: perfect, thanks
[16:35] <vorlon> Skia: great, then someone can cherry-pick :)
[16:35] <Skia> yes, I think bdrung wanted to have a look, and certainly got sidetracked
[16:35] <vorlon> apt vs db5.3: ogayot
[16:35] <ogayot> vorlon: ack
[16:35] <vorlon> apt vs xz-utils: upils
[16:35] <upils> ack
[16:36] <vorlon> ccache: pushkarnk
[16:36] <pushkarnk> ack
[16:36] <vorlon> ogayot: let's make that db5.3 in general please, there are several packages that need retested with --all-proposed or such (assuming they're fixed to depend on libdb5.3t64)
[16:37] <vorlon> elfutils: ravikant_:
[16:37] <vorlon> fwupd vs xz-utils: schopin
[16:37] <schopin> vorlon: ack
[16:37] <vorlon> libtirpc: liushuyu
[16:37] <vorlon> libuv1: mwhudson
[16:37] <liushuyu> vorlon: okay
[16:37] <vorlon> pycurl: vpa1977:
[16:37] <ravikant_> vorlon: I am ooo next week, can sombody else take it?
[16:37] <bdrung> cpete, please give me initramfs-tools vs klibc. you get vim instead. i have a pending initramfs-tools upload where i can include the fix from Skia (and yes, i missed to pick that fix)
[16:37] <vorlon> and the rest of xz-utils to zhsj
[16:38] <vorlon> bdrung: done for now
[16:38] <zhsj> ack
[16:38] <cpete> bdrung: ack
[16:38] <schopin> nice, I got a non-armhf regression!
[16:38] <adrien> vorlon: so, umockdev armhf build fails (it failed a couple minutes ago) due to t64; are there general guidance there?
[16:38] <juliank> vorlon, ravikant_ I can take elfutils too I suppsoe
[16:38] <vorlon> adrien: do we need to get umockdev rebuilt? if so, make that happen.  or if we need to retest with --all-proposed, do that
[16:38] <ravikant_> juliank: thanks
[16:39] <adrien> vorlon: ack, thanks
[16:39] <vorlon> adrien: ah you said the build fails.  So yes, you need to make it not fail :-)
[16:39] <vorlon> if you're lucky that's maybe a simple retry with new apt, or a copy to the bootstrap archive and back
[16:39] <vorlon> if you're unlucky you should sign up to learn how to trace bootstrapping horrors with me
[16:40]  * schopin will try to attend that workshop
[16:40] <adrien> thanks, I'll see, it's either t64 or something else yet to be fully identified
[16:40] <bdrung> Skia, I included your fix in the 0.142ubuntu20 upload which is still in -proposed
[16:40] <Skia> bdrung: great!
[16:41] <vorlon> adrien: you're unlucky, umockdev depends on glib
[16:42] <vorlon> adrien: or maybe you're lucky, because that means you probably don't have anything to do there and maybe should leave it to mwhudson or doko or myself
[16:42] <adrien> haha, I'll also try to get up to speed with what's going on with glib
[16:43] <vorlon> adrien: there's a terrible bootstrap loop between glib2.0 and gobject-introspection
[16:43] <adrien> (well, at least for t64 because I never want to get deep into glib :) )
[16:43] <adrien> doh
[16:43] <vorlon> I got as far as building glib2.0 without gir
[16:44] <vorlon> and then I had to leave it there to work on other stuff and didn't look any deeper at bootstrapping gobject-introspection
[16:44] <vorlon> so jbicha reverted it because it was blocking things on !armhf in -proposed
[16:44] <vorlon> juliank: back to you
[16:44] <adrien> thanks for the summary, yeah, it's complicated
[16:44] <adrien> and long
[16:45] <juliank> #topic aob
[16:47] <pushkarnk> tomorrow is a public holiday in India
[16:48] <bdrung> and in Berlin
[16:48] <juliank> not here :(
[16:48] <juliank> but on the bright side it's going to be sunny
[16:48] <juliank> (pun intended)
[16:49] <ravikant_> It is International Women's Day
[16:49] <bdrung> we got this public holiday because Berlin has fewer public holidays than other regions in Germany
[16:50] <juliank> some celebrate women, other celebrate shiva
[16:51] <pushkarnk> :D
[16:53] <juliank> final call!
[16:53] <juliank> 32
[16:53] <juliank> 3
[16:53] <juliank> 2
[16:53] <juliank> 1
[16:53] <juliank> #endmeeting
[16:53] <meetingology> Meeting ended at 16:53:29 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2024/ubuntu-meeting.2024-03-07-16.01.moin.txt
[19:12] <ravage> hi leftyfb . thanks for joining. so now i know my bridge works 🙂
[19:24] <arraybolt3> looking forward to the coming meeting :)
[19:29] <ravage> \o
[19:33] <oerheks> :-)
[19:33] <ravage> oh already here
[19:55] <ic3br34ker27> Hi Everyone=D
[19:55] <oerheks> hi ic3br34ker27
[19:55] <ravage> \o
[19:55] <Bashing-om> ic3br34ker27: :D Hey-ya - Hang on a bit and we get started.
[19:56] <lucyllewy> hello all
[19:56] <naudy> Hello 👋
[19:56] <arraybolt3> I'm not quite here yet :P
[19:56] <oerheks> and hi lucyllewy
[19:56] <arraybolt3> I have four minutes, I need those!
[19:56] <ravage> i can see you arraybolt3 !
[19:57] <oerheks> 3 minutes..
[19:57] <arraybolt3> nifty
[19:57] <ilvipero> Hi all
[19:57] <linaporras> Hi all!
[19:58] <ic3br34ker77> Hi everyone:D  , Greetings
[19:58] <arraybolt3> two minutes... getting there
[19:58] <arraybolt3> great, I broke IRC
[19:59] <arraybolt3> !ping
[19:59] <lucyllewy> hi arraybolt3
[19:59] <arraybolt3> alright, got it back :P (hit a wrong button in WeeChat)
[19:59] <arraybolt3> and I am finally here.
[19:59] <lucyllewy> hi linaporras
[19:59] <oerheks> !yay
[19:59] <oerheks> 10...9..8..7..6..
[20:00] <arraybolt3> -5, -6, -7...
[20:00] <lucyllewy> who do we have in from the board this evening?
[20:02]  * Bashing-om present
[20:02] <lucyllewy> me too
[20:02] <ic3br34ker77> My name is Carlos Maestre, nice to meet you everyone. I´m from Barranquilla, Colombia.:D
[20:04] <lucyllewy> we will need to wait to see if any more members can arrive. We have three potential voters right now (1 via proxy) but we need four to meet quorum
[20:04] <arraybolt3> mesebrec: o/
[20:04] <oerheks> arraybolt3, Bashing-om, lucyllewy and me..
[20:04] <oerheks> we do have 4
[20:05] <arraybolt3> I'm not on the UMB?
[20:05] <lucyllewy> oerheks: arraybolt isn't Larry
[20:05] <mesebrec> Hi everyone! o/
[20:05] <arraybolt3> I'm here to advocate for ravage's application, not vote :P
[20:05] <oerheks> Larry?
[20:05] <oerheks> oh sorry
[20:06] <Bashing-om> oerheks: Larry aka Wildman :D
[20:06] <lucyllewy> mapreri: are you about?
[20:07] <Bashing-om> Kilos ^ same
[20:08] <lucyllewy> we need either fenris, mapreri, or Kilos to be here as well
[20:09] <lucyllewy> might need to petition the cc to allow cc members to vote in case they can fill a quorum quota in future meetings
[20:09] <arraybolt3> only additional member I see who's in the room is mapreri
[20:09] <arraybolt3> oh wait
[20:09] <lucyllewy> yup
[20:09] <arraybolt3> I see I missed stuff
[20:10] <arraybolt3> somehow my IRC client stopped scrolling down.
[20:12] <mesebrec> Maybe ping some people via Telegram, for example?
[20:12] <mesebrec> I see Mattia hasn't been online here for a while, but he's online on Telegram
[20:14] <oerheks> Is Mark himself online?
[20:15] <lucyllewy> mapreri already indicated they might not make it
[20:19] <lucyllewy> we might have to defer the meeting :'( we have the 22:00 slot today as well if any applicants can shift, but I'm not sure if anybody extra will be able to make that who hasn't managed this meeting
[20:19] <lucyllewy> the alternative is the board members vote via our mailing list
[20:20] <ravage> i am here if needed. dont know about the others
[20:21] <ic3br34ker77> o/
[20:21] <ic3br34ker77> I would like to submit the link to my UBM application.
[20:21] <ic3br34ker77> https://discourse.ubuntu.com/t/carlos-maestre-membership-application/41783
[20:22] <arraybolt3> ic3br34ker77: ravage isn't on the UMB, he's seeking Ubuntu Membership this meeting.
[20:22] <oerheks> ic3br34ker77, thanks, nice pictures!
[20:22] <ic3br34ker77> oh, cool just like me:D
[20:23] <linaporras> Good idea the mailing list
[20:24] <lucyllewy> we're well into the scheduled hour, and I don't want to keep you if there's not much likelihood of getting the required Quorum by the end of the time slot to be able to start the meeting, so if you'd all like I can either move you to the later meeting today (1.5 hours from now at 22:00 GMT) or take the vote to email
[20:24] <ic3br34ker77> Thanks oerheks
[20:25] <lucyllewy> waiting is another option if you would prefer that
[20:25] <ic3br34ker77> by my side, I don´t have any problem.
[20:26] <mesebrec> I'm not sure I understand the quorum rules
[20:26] <mesebrec> Membership board has 6 voting members
[20:26] <mesebrec> if 3 are present, isn't that enough?
[20:26] <lucyllewy> mesebrec: I think it is 50%+1 unless 50% is already an odd number
[20:27] <lucyllewy> so floor(50%+1)
[20:27] <mesebrec> So that's 3
[20:28] <lucyllewy> oops. I explained that bad. I meant integer, not odd
[20:28] <mesebrec> The number here is wrong because the CC is part of the team (for technical reasons) https://launchpad.net/~ubuntu-membership-board/+members#active
[20:30] <lucyllewy> as we have 6 members it's floor((6/2)+1) = floor(3+1) = 4. if we had 7 it'ld be floor((7/2)+1) = floor(3.5+1) = 4
[20:31] <mesebrec> oh
[20:37] <cangreja533> Hello, warm greetings from Colombia
[20:37] <mesebrec> Ok, the Matrix Council is having a meeting now, but we can jump back here if quorum is reached
[20:37] <lucyllewy> ok
[20:38] <lucyllewy> we'll try to get things sorted via email asap if that's the decision
[20:38] <lucyllewy> we also still have the second meeting slot today if we can't get quorum by the end of this slot
[20:38] <lucyllewy> so sorry about this
[20:39] <mesebrec> No problem, it happens!
[20:39] <mesebrec> If it's a persistent problem, feel free to ask the CC for help and we can see if we can do interim elections or provide some replacements.
[20:40] <ic3br34ker77> no worries lads, It's understandable, it happens.
[20:40] <Bashing-om> cangreja533: Welcome - are you too going to be a participant in FLiSoL Barranquilla ?
[20:43] <lucyllewy> thank you, mesebrec. I'll chat with the board to see what we want to do
[20:43] <cangreja533> I would love to, but I am organizing FLISOL in Manizales
[20:43] <lucyllewy> we'll then mail the CC with those ideas and request advice or help
[20:44] <ic3br34ker77> 8)  FliSoL Manizales, with the smell of coffee =D
[20:46] <oerheks> meanwhile, a fresh kernel update on 22.04
[20:46] <Bashing-om> cangreja533: For visibility be good to post to Discourse that Manizales will be a part: eg - https://discourse.ubuntu.com/t/flisol-barranquilla-2024/42702 :D
[20:57] <lucyllewy> that's about the time slot finished. we'll bump everyone to the next slot in 1 hour unless you request to take your application through to email
[21:08] <ravage> we can wait
[21:12] <ic3br34ker77> Yeah sure.
[21:14] <oerheks> brb
[22:00] <ic3br34ker77> Welcome gschiano !
[22:00] <gschiano> Hello :)
[22:00] <lucyllewy> okie dokie. time for round two. hopefully we can get quorum this time.
[22:01] <ic3br34ker77> Round 2XD
[22:01] <lucyllewy> we need two of: Bashing-om, mapreri, Kilos, fenris
[22:01] <lucyllewy> I have a proxy for wildman so with two others and myself we can meet quorum.
[22:02] <ravage> sounds promising 🙂
[22:02]  * Bashing-om present
[22:02] <oerheks> :-)
[22:02] <lucyllewy> 1 met
[22:02] <lucyllewy> need 1 more
[22:02] <gschiano> Stars aligning
[22:02]  * arraybolt3 kicks stars
[22:02] <ilvipero> hello!
[22:02] <lucyllewy> hi ilvipero
[22:02] <gschiano> Hey ilvipero
[22:03] <lucyllewy> mapreri: has ducked out for certain
[22:03] <lucyllewy> that leaves either Kilos or fenris
[22:04] <gschiano> *invokes fenris* (because his name sounds like an invocation)
[22:05] <ic3br34ker77>  Fenris woow, the mythological wolf of ragnarok.
[22:05] <sarnold> awoooooo
[22:05] <gschiano> \O/
[22:05] <lucyllewy> haha
[22:05] <arraybolt3> is "fenris" known as "myfenris" on Telegram?
[22:05] <arraybolt3> If so, I just pinged him
[22:05] <lucyllewy> yes.
[22:05] <arraybolt3> (via #kubuntu-devel)
[22:06] <lucyllewy> I'm confused as to names. silly memory is broken. We need Wild_Man
[22:06] <arraybolt3> fenris already voted?
[22:06] <lucyllewy> yeh
[22:06] <lucyllewy> sorry about that. I can't equate people's telegram display names to irc nicks unless they are the same :P
[22:09] <ic3br34ker77> I'm sorry how do you vote? I'm also trying to vote for UM but I don't understand... apologies in advance.
[22:11] <ic3br34ker77> correction, I'm sorry how do you vote? I'm also trying to find out if you vote for me to be UM but I don't understand... apologies in advance.**
[22:11] <arraybolt3> The Ubuntu Membership Board votes on whether people become Ubuntu Members or not. So far we have two people here and a third has already voted in advance, we need one more person...
[22:12] <lucyllewy> ic3br34ker77: we need a "quorum" of board members to be able to run a meeting
[22:12] <arraybolt3> ...and that one more person isn't showing up yet.
[22:12] <lucyllewy> it's only the board members that may vote on membership applications in this process
[22:12] <Bashing-om> ic3br34ker77: 6 members of the board - upon examining your application each cast a yea or nay vote for acceptance. usually in this channel.
[22:13] <ic3br34ker77> ohh oh, I get it, thank you very much for clarifying, it's just that it's my first day. xD
[22:13] <lucyllewy> no worries
[22:14] <ic3br34ker77> thanks lucyllewy
[22:14] <gschiano> If fenris already voted I invoked the wrong one. I need to call for Kilos then
[22:14] <lucyllewy> yeh that's my fault.. I got names mixed up in my head
[22:15] <gschiano> *Rise, Kilos, in mystic might: unveil the hidden light!*
[22:16] <ic3br34ker77> hehe
[22:18] <gschiano> So without a quorum, we're in a split brain situation right ?
[22:18] <arraybolt3> yup
[22:18] <gschiano> *scale down unit 3"
[22:18] <gschiano> *scale down unit 3*
[22:18] <mesebrec> I think it's difficult to get >50% of people to show up when people are in all timezones.
[22:19] <mesebrec> Statistically speaking, at least 50% of people will be asleep
[22:19] <lucyllewy> just had confirmation from WildMan that they can't make it
[22:19] <gschiano> Indeed
[22:20] <mesebrec> I think the membership board has a lot of people, to make sure enough people can show up
[22:20] <lucyllewy> ravage, ic3br34ker77, gschiano, can each of you choose whether you'd like to move your application to email or a future meeting?
[22:20] <ravage> email
[22:20] <gschiano> How is it processed if the application is managed by email ?
[22:21] <lucyllewy> we'll also contact the CC about quorum numbers and get that properly documented what we need and the calculation for that number
[22:22] <gschiano> Well I think email is fine
[22:22] <lucyllewy> gschiano: we'll vote on our internal mailing list and CC the results to each applicant as soon as we can. Sometimes we might want to ask questions, but if we can we'll vote without
[22:23] <ic3br34ker77> Guys; ravage, gschiano if you agree by mail, I'll join you too. I haven't gone home. xD
[22:23] <ravage> email is totally fine with me
[22:23] <lucyllewy> I'm so sorry to all of you for the failures today
[22:23] <gschiano> No worry :)à
[22:24] <lucyllewy> can you each DM me an email you are happy for us to use if you don't have it publicly shown on your launchpad profile?
[22:24] <lucyllewy> email address**
[22:24] <ic3br34ker77> Email too, no worries lucyllewy it happens:)
[22:24] <gschiano> Any of my launchpad email address are fine
[22:25] <lucyllewy> gschiano: it looks like your launchpad email is hidden from public view, so I can't see it
[22:25] <gschiano> Ok, let me DM you
[22:25] <lucyllewy> cool
[22:25] <ic3br34ker77> lucyllewy my email<EMAIL_ADDRESS>[22:27] <lucyllewy> thank you, ic3br34ker77
[22:27] <ic3br34ker77> Thanks to you lucyllewy have a good one.
[22:28] <ic3br34ker77> have a good one everyone. see ya!
[22:28] <gschiano> Thanks all, see you :)
[22:28] <lucyllewy> thank you so much everyone. And I'm really sorry again.
[22:29] <ravage> no worries
[22:29] <mesebrec> No worries lucy, you're amazing!
[22:29] <gschiano> Really no worryies
[22:32] <ic3br34ker77> my launchpad just in case, https://launchpad.net/~ic3br34ker hehe have a good one. see ya!


[07:38]  * utkarsh2102 is happy that everything got sneaked in at the right time, before FF :)
[07:55] <mirespace> good morning
[08:49] <mnasiadka> good morning
[08:50] <mnasiadka> UCA people - regarding python3-openvswitch package in UCA Yoga - I think there's some issue with that showing up on Kolla-Ansible OVN job (https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_c8b/830844/3/experimental/kolla-ansible-ubuntu-source-ovn/c8bee38/primary/logs/kolla/neutron/neutron-server.txt). Basically it's showing up as version 2.16.90 (while PyPI only has 2.16.0)... Do
[08:50] <mnasiadka> you have any idea what is wrong?
[08:50] <mnasiadka> fnordahl: ^^
[10:09] <athos> good morning!
[10:16] <athos> mnasiadka: https://www.openvswitch.org/download/ says 2.17.0 is out
[10:16] <athos> also: https://github.com/openvswitch/ovs/commit/4703bc67b78cbbac0d6c418d09de2992521979e1
[10:19] <ViSI0n> Hi Guys, I have installed application but it seems to be application installed from snap.  I created directory at the root to mount all my smb paths.  But it's not reachable from the snap application. Is there way to able to make everything bellow /smb folder avialable to snap or is the only option to remove the snap application and use different repo which installs classic old fasion way?
[10:52] <fnordahl> mnasiadka: OpenStack Yoga has not been released yet so the archive currently contains snapshots from upstream Git branches. The Open vSwitch and OVN projects use a x.x.90 version in their Git branches to signal it's a unreleased version.
[10:52] <fnordahl> mnasiadka: This will be resolved once we get closer to the release.
[11:55] <Walex2> ViSI0n: snaps hardcode access only to '/home/'; you can use a 'mount --bind' to relocate your mounts to appear under '/home/'.
[11:58] <Walex2> ViSI0n: https://bugs.launchpad.net/snappy/+bug/1620771/comments/56
[12:02] <ViSI0n> I removed the snap version and installed it again from software repo.  snap sound great for desktop os but server os..
[14:51] <ogra> ViSI0n, well, snaps were originally developed for server, embedded, industrial, automotive etc ... desktop support only came 2y later (shortly before fedora announced flatpak) ...
[14:53] <ogra> ViSI0n, server snaps all have their writable paths in /var/snap/<snapname>/current (for all versioned files, i.e. configs and such, so on auto-rollback the server still works) and /var/snap/<snapname>/common for all payload data ...
[14:53] <ogra> dont use /home for server stuff 🙂
[16:16] <bryceh> athos, php-klogger and php-malkusch-lock have ftbfs built against php-psr-log 3, that should be investigated.  I've never worked on those packages so don't know much about them, but keep in mind you may have the option to drop them if nothing significant requires them and if there aren't easy fixes at hand
[16:17] <bryceh> I'll let you know if I spot other packages
[16:17] <athos> bryceh: ack; thanks :)
[16:17] <bryceh> note that I think Debian has chosen to stay on PSR 1, while upstreams have sometimes added PSR 3 support, sometimes not
[17:16] <bryceh> @athos, a third package that goes with those, and potentially also will have similar psr compatibility trouble:  civicrm.
[17:17] <bryceh> interesting complication with it, is that when I try to 'debuild -S' a no-change rebuild, it is apparently getting stuck in recursion during the lintian check.  Maybe you'll have better luck but something's weird with it.
[17:17] <bryceh> Warning in processable ./civicrm_5.33.2+dfsg1-1build1.dsc: Complex regular subexpression recursion limit (65534) exceeded at /usr/share/lintian/lib/Lintian/Check/Cruft.pm line 773.
[17:17] <bryceh> I get that repeated indefinitely
[17:18] <bryceh> anyway, if you can, upload a no-change rebuild of civicrm, and see if it builds ok or not against p-p-log 3
[17:19] <bryceh> civicrm is kind of a leaf package, so a potential brute force solution would be to remove it from the archive (along with wikipedia-civicrm, which seems the main rdepends)
[17:20]  * bryceh -> breakfast, bbl
[19:38] <mnasiadka> fnordahl: thanks :)
[20:26] <ahasenack> sergiodj: that smbclient/backuppc bug, did you add something to it yet?
[20:41] <ahasenack> hi server team, freeradius' radtest crash fix from upstream, with tests: https://code.launchpad.net/~ahasenack/ubuntu/+source/freeradius/+git/freeradius/+merge/416109
[20:49] <sergiodj> ahasenack: not yet, sorry.  have been running errands for the past couple of hours or so
[20:49] <sergiodj> I'll get to it soon
[20:49] <ahasenack> but you have it in your memory? :)
[20:50] <sergiodj> ahasenack: I do
[20:50] <ahasenack> ok, I'll look at the adsys failures
[20:50] <ahasenack> take the opportunity to get acquainted with that project
[20:50] <sergiodj> great
[20:50] <ahasenack> thanks for the help
[20:50] <sergiodj> I'll let you know when I update the bug
[20:50] <sergiodj> yw
[23:33] <jr_web_dev> so i have ubuntu server installed on a blade server, it doesnt have a desktop environment.  However, i want to install and then x forward gui applications onto my mac.. is it possible to do this without having to install a desktop environment?
[23:42] <tomreyn> it could work where X forwarding still works. you'd need an X server, probably xorg
[23:43] <jr_web_dev> right so a desktkop environment on the server will not matter then
[23:44] <tomreyn> it would matter, but it should not be needed to make X forwarding work
[23:45] <jr_web_dev> ok thanks ill just go ahead and install xorg server


[09:10] <kraut> moin
[11:09] <bryce> @schedule
[11:09] <ubotu> Schedule for Etc/UTC: 16 Aug 20:00: Ubuntu Development Team | 20 Aug 22:00: Forum Council meeting | 21 Aug 15:00: Kernel Team | 22 Aug 12:00: Edubuntu | 22 Aug 20:00: Xubuntu Developers | 23 Aug 15:00: Ubuntu Development Team
[11:09] <bryce> @schedule PDT
[11:10] <bryce> @schedule America/Los_Angeles
[11:10] <ubotu> Schedule for America/Los_Angeles: 16 Aug 13:00: Ubuntu Development Team | 20 Aug 15:00: Forum Council meeting | 21 Aug 08:00: Kernel Team | 22 Aug 05:00: Edubuntu | 22 Aug 13:00: Xubuntu Developers | 23 Aug 08:00: Ubuntu Development Team
[12:15] <kraut> @schedule berlin
[12:15] <ubotu> Schedule for Europe/Berlin: 16 Aug 22:00: Ubuntu Development Team | 21 Aug 00:00: Forum Council meeting | 21 Aug 17:00: Kernel Team | 22 Aug 14:00: Edubuntu | 22 Aug 22:00: Xubuntu Developers | 23 Aug 17:00: Ubuntu Development Team
[01:38] <dendrobates> @schedule New York
[01:38] <ubotu> Schedule for America/New_York: 16 Aug 16:00: Ubuntu Development Team | 20 Aug 18:00: Forum Council meeting | 21 Aug 11:00: Kernel Team | 22 Aug 08:00: Edubuntu | 22 Aug 16:00: Xubuntu Developers | 23 Aug 11:00: Ubuntu Development Team
[04:40] <DarkSun88> Hi all.
[04:41] <DarkSun88> @schedule rome
[04:41] <ubotu> Schedule for Europe/Rome: 16 Aug 22:00: Ubuntu Development Team | 21 Aug 00:00: Forum Council meeting | 21 Aug 17:00: Kernel Team | 22 Aug 14:00: Edubuntu | 22 Aug 22:00: Xubuntu Developers | 23 Aug 17:00: Ubuntu Development Team
[04:44] <DarkSun88> See you tonight.
[04:44] <DarkSun88> By all.
[05:04] <bryce> morning
[05:07] <Hobbsee> morning bryce!
[05:35] <s-x-u> it is afternoon here :-)
[08:39] <calc> there is a really bad storm headed my way if i fall offline then that would be why
[09:51] <calc> pong
[09:55] <Riddell> how's the storm calc?
[09:55] <calc> doing ok so far
[09:55] <Riddell> is it like at the start of wizard of oz?
[09:55] <calc> i think it died down when it finally got here, i'm north of houston about 60km or so
[09:57] <Riddell> ArneGoetje: aren't you stuck in a storm too?
[09:58] <ArneGoetje> Riddell: yes... but still OK here...
[09:59] <iwj> Evening.
[09:59] <evand> hello
[09:59] <dendrobates> hey all.
[10:00] <calc> my wife nearly didn't get home, the doctors office was surrounded a few blocks away by water on all sides
[10:00] <Keybuk> it occurred to me today that while we have a New Starters section in the agenda, we don't have a Leavers section
[10:00] <calc> Keybuk: so they can quietly run away? ;)
[10:00] <Riddell> Keybuk: it's good to be optimistic
[10:01] <Mithrandir> you can check out but you can never leave.  (See lamont)
[10:01] <Riddell> we could have a fabbione tribute agenda item
[10:01] <keescook> 'allo
[10:01] <bryce> heya all
[10:01] <bdmurray> Heyyy!
[10:01] <amitk_> hello
[10:01] <mathiaz> hi
[10:01] <mdz_> howdy all
[10:01] <tkamppeter> hi
[10:01] <ogra> Riddell++
[10:01] <pedro_> hello
[10:02] <heno> welcome pedro_ :)
[10:02] <ogra> hey pedro_
[10:02] <pedro_> heno: thanks you, glad to see you around :-)
[10:02] <pedro_> hey ogra
[10:04] <mdz_> Keybuk: thanks for putting the agenda together
[10:04] <mdz_> thursdays have become such a nightmare schedule-wise
[10:04] <mdz_> shall we get started?
[10:04] <Keybuk> just thursdays?
[10:05] <mdz_> thursdays especially
[10:05] <Keybuk> I had to write off Wednesday (getting things done before Thursday) and Friday (getting things done that I didn't do on Thursday) as well
[10:05] <mdz_> I just got off my going-home-on-the-train conference call, and now onto my during-dinner meeting
[10:05] <mdz_> #startmeeting
[10:05] <MootBot> Meeting started at 19:58. The chair is mdz_.
[10:05] <MootBot> Commands Available: [TOPIC] , [IDEA] , [ACTION] , [AGREED] , [LINK] , [VOTE]
[10:05] <mdz_> [TOPIC]  pedro!
[10:05] <MootBot> New Topic:  pedro!
[10:05] <Mithrandir> mdz_: luckily, you only dropped off once and the noise wasn't that bad. :-)
[10:05] <mdz_> pedro_: welcome!
[10:06] <pedro_> mdz_: thanks a lot :-)
[10:06] <mdz_> you probably all know pedro by now
[10:06] <ogra> he's the guy with his own topic :)
[10:06] <mdz_> but he is on a mission
[10:06] <mdz_> to wipe out desktop bugs
[10:07] <ogra> \o/
[10:07] <mvo> welcome pedro_!
[10:07] <pedro_> thanks mvo! :-)
[10:07] <mdz_> onward and upward!
[10:07] <bryce> it'll be nice no longer having desktop bugs
[10:07] <mdz_> [TOPIC]  feature freeze status
[10:07] <MootBot> New Topic:  feature freeze status
[10:07] <mdz_> or as we like to call it...
[10:07] <mdz_> ...THE RECKONING
[10:08] <seb128> bryce: indeed ;)
[10:08] <pedro_> hehe yeah
[10:08] <mdz_> so, raise your hand if all of your feature goals are on target
[10:08] <Riddell> ...
[10:08] <agoliveira> Sorry guys, I'm late
[10:09] <mdz_> raise them louder!
[10:09] <asac> i uploaded ubufox 0.4~beta1 today with a cool new plugin finder wizard and an integration to install extensions through gnome-app install :)
[10:09] <Mithrandir> my own are quite ok, but UME as a whole is late.
[10:09] <Riddell> mostly mine are, some are blocked on main inclusion reports though and some split out into "to be deferred" specs
[10:09] <Keybuk> mvo: yours were all done, don't be shy :)
[10:09] <mathiaz> apparmor is on target
[10:09] <calc> i expect to have a new openoffice with the hang issue resolved (among lots of other fixes) uploaded in the next few days
[10:09] <keescook> all of my assigned features are in.  ;)
[10:09] <iwj> I'm pleased I managed to get round to, and finish (sort of) triggers.  I'm still waiting for the bugs to start rolling in.
[10:09] <bryce> one is done, one 99% done, and one is still waiting on upstream
[10:10] <ogra> ltsp is in fine state ... all new and shiny and full of fresh bugs :)
[10:10] <kylem> the kernel is mostly looking ok.
[10:10] <iwj> ogra: pedro will be pleased; otherwise he might feel there wasn't enough for him to be doing.
[10:10] <bryce> (the 99% one is bulletproof-x - I just need to flip it on in gdm now)
[10:10] <mdz_> this all sounds very good
[10:10] <ScottK> Minor in the scheme of things, but GPG and S/MIME by default for Kmail/Kontact is done.
[10:11] <mdz_> but if everyone has at least one thing not on track, we must have issues to talk through :-)
[10:11] <Keybuk> mdz: nothing alarming from my team
[10:11] <mdz_> tell me your troubles
[10:11] <iwj> mvo: thanks again for fixing up that silly ftbfs, btw.
[10:11] <ogra> iwj, ltsp is a *server* (in case of pedro and bugs at least :))
[10:11] <bryce> at some point I would like to talk about xorg 7.3, and whether to do the xserver 1.4 upgrade
[10:11] <iwj> ogra: *grin*
[10:11] <ogra> ;)
[10:11] <Riddell> slow main inclusion report processing
[10:11] <mvo> iwj: no problem, apt is a bit ... sometimes
[10:11] <asac> well network-manager is a spec ... but that was a bug spec in the first place ... so it doesn't qualify for todays freeze
[10:12] <amitk_> I need to kickstart the laptop testing team with help from heno
[10:12] <mdz_> amitk_: and jono
[10:12] <amitk_> re-kickstart, even
[10:12] <amitk_> right
[10:12] <heno> virtual-machine-on-cd is not going to happen, but windows-installer should
[10:12] <iwj> I'd like to chat to someone who knows about ld.so, with a view to triggerising ldconfig.
[10:12] <evand> indeed, all the bits are in place for windows-installer
[10:12] <heno> amitk_: see email from me this evening
[10:12] <Riddell> ScottK: that's the sort of fiddly thing we like to see fixed
[10:12] <Keybuk> iwj: hello :-)
[10:12] <amitk_> heno: sure
[10:13] <iwj> Keybuk: Hi :-).  Excellent.  Catch you on irc tomorrow ?
[10:13] <ScottK> Riddell: Thanks.
[10:13] <Keybuk> iwj: sure
[10:13] <mdz_> Riddell: are the main inclusion reviews blocking on pitti?  he's been quite busy
[10:13] <Keybuk> [ACTION]  iwj to talk to keybuk tomorrow about ldconfig
[10:13] <Keybuk> oh, bah
[10:13] <Keybuk> sudo mdz ...
[10:13] <ogra> heh
[10:13] <mdz_> [ACTION]  iwj to talk to keybuk tomorrow about ldconfig
[10:13] <MootBot> ACTION received:  iwj to talk to keybuk tomorrow about ldconfig
[10:13] <ogra> su would suffice
[10:13] <mdz_> would have done it sooner if you didn't scroll out from under my mouse...
[10:13] <Riddell> mdz_: yes, he did promise to do them before his honeymoon so we'll see
[10:14] <mdz_> isn't someone else working on MIR apart from pitti?
[10:15] <mdz_> I thought we expanded that team
[10:15] <iwj> I do some MIRs occasionally but I've been very head-down the last week or so.
[10:15] <ogra> iwj, did you stop doing MIRs ?
[10:15] <mdz_> iwj: with pitti going on holiday, he could use the help now more than ever I think
[10:16] <iwj> mdz_: Yes.
[10:16] <iwj> I should really take that over, probably.
[10:16] <iwj> Looking at the mails about the wiki changes, it's basically been just pitti and if he goes it'll just all stop.
[10:16] <iwj> So consider me volunteered.
[10:16] <mdz_> keescook: given that a good chunk of it is security review, you might consider helping out with that in the medium term
[10:17] <iwj> I might want a second opinion occasionally.  There's, shall we say, a political aspect to it.
[10:17] <keescook> mdz_: okay, I can have at it.
[10:17] <iwj> Particularly from a security pov.  So kees, would you mind helping out ?
[10:17] <iwj> Ah, excellent.
[10:17] <keescook> iwj: sure :)
[10:17] <mdz_> keescook: perhaps more after your cloning
[10:18] <keescook> yes please
[10:18] <iwj> For now I'd like to encourage anyone to chase me up if you need a MIR done.
[10:18] <mdz_> heno: who handled milestone testing while you were away?
[10:19] <Riddell> iwj: kiosktool, obexftp, kvkbd, opensync are the ones I'm blocking on
[10:19] <iwj> Riddell: I'll email myself that list and take a look tomorrow.
[10:19] <heno> I asked stgraber to take a more active role in that, but I think pitti and hobsee also did much of it
[10:19] <ogra> mdz_, we all did, lead by pitti and Hobsse
[10:20] <ogra> stgraber was very active as well, yes
[10:20] <mdz_> ogra: are there summary results available?
[10:20] <Riddell> "hobbsee" (took me a while to remember which letters were doubled)
[10:20] <ogra> on the iso tracker i think
[10:20] <mdz_> ah, front page
[10:20] <Mithrandir> Riddell: usually a lot easier when she's around, since then you can just tab-complete
[10:21] <heno> https://iso.qa.stgraber.org/isotesting/report/6
[10:21] <mdz_> I'm not sure how to read "7/7 (12) (1)"
[10:21] <mdz_> but I can guess what all of the insect icons mean :-)
[10:21] <heno> 7 of 7 test complete
[10:21] <heno> 12 tests submitted in total
[10:22] <mdz_> ?
[10:22] <heno> more documentation would be useful, yes
[10:22] <ogra> well
[10:22] <mdz_> 7 out of 7 out of 12
[10:22] <ogra> there are headers on the table columns
[10:22] <mdz_> yes, that one says "test status" :-)
[10:22] <heno> 7 out of 7, with some tested more than once
[10:23] <heno> full coverage + some
[10:23] <ogra> mdz_, you are on the wrong page
[10:23] <mdz_> ah, 7 test cases, rather than 7 tests?
[10:23] <heno> right, sorry
[10:24] <mdz_> ok, so general feature freeze status sounds fairly ominous
[10:24] <mdz_> I will review in more detail with Keybuk and cjwatson (when he returns)
[10:24] <mdz_> no agenda items were submitted
[10:25] <mdz_> presumably everyone has been too busy pushing for feature freeze
[10:25] <Keybuk> ominous in a good way or a bad way?
[10:25] <iwj> Anything that we needed help with needed fixing before the meeting :-).
[10:25] <mdz_> Keybuk: ominous in a big scary uncertain sort of way
[10:25] <bryce> ominous can be in a good way?
[10:25] <Keybuk> mdz_: EWBO
[10:26] <mdz_> but anyway, this is a good opportunity to get help if you have FF-related issues
[10:26] <mdz_> since everyone is here
[10:26] <bryce> mdz_, I'd like to chat about xorg 7.3 FF-related issues
[10:27] <mdz_> bryce: by all means
[10:27] <calc> also anyone who has the ipw3945 wifi please not if you have it and if it works
[10:27] <mdz_> [VOTE]  does your ipw3945 work?
[10:27] <MootBot> Please vote on:  does your ipw3945 work?.
[10:27] <bryce> well, we're still waiting on xserver 1.4, but it's scheduled to come out this month, and I'm guessing soon
[10:27] <calc> I do, doesn't work much with NM
[10:27] <agoliveira> +1
[10:27] <MootBot> +1 received from agoliveira. 1 for, 0 against. Count is now 1
[10:27] <Keybuk> -1
[10:27] <MootBot> -1 received from Keybuk. 1 for, 1 against. Count is now 0
[10:27] <kylem> 4965 works fine.
[10:27] <kylem> :)
[10:27] <calc> -1
[10:27] <MootBot> -1 received from calc. 1 for, 2 against. Count is now -1
[10:27] <bdmurray> +1
[10:27] <MootBot> +1 received from bdmurray. 2 for, 2 against. Count is now 0
[10:27] <mdz_> a dead heat
[10:28] <bryce> mdz_, however it's going to necessitate rebuilding much of the X componentry due to ABI changes
[10:28] <calc> ok
[10:28] <mdz_> bryce: how soon is 'soon'?
[10:28] <Keybuk> agoliveira, bdmurray: what wireless network do you use?
[10:28] <bryce> mdz_, I don't have an exact date but am estimating within the week
[10:28] <mvo> 0 (don't use NM)
[10:28] <bdmurray> wep
[10:28] <mdz_> bryce: and how deep are the changes?  is this a major feature release compared to what we have?
[10:28] <calc> my situation is NM doesn't work with open or WPA/WPA2 but ifup works (keybuk mentioned events issue)
[10:28] <agoliveira> Intel Corporation PRO/Wireless 3945ABG Network, wap
[10:28] <bryce> mdz_, I think it could be done, but I'm quite concerned about regressions, and lack of time to get them addressed
[10:29] <mdz_> #endvote
[10:29] <MootBot> Final result is 2 for, 2 against. Total: 0
[10:29] <Keybuk> for me, it doesn't work with open but tends to work with WEP/WPA
[10:29] <bryce> mdz_, yes it's a major release, that adds input hotplugging
[10:29] <calc> Keybuk: does it work with open if using ifup instead of NM?
[10:29] <bdmurray> mine worked in the london office too
[10:29] <mdz_> bryce: what's the main use case for input hotplugging?
[10:29] <mdz_> [TOPIC]  X.org 7.3
[10:29] <MootBot> New Topic:  X.org 7.3
[10:30] <bryce> mdz_, it will allow being able to leave out the keyboard, mouse, wacom tablet, etc. entries in xorg.conf and xorg will figure them out automatically
[10:30] <bryce> mdz_, however as I understand it, support will need to be added for the drivers to take advantage of that anyway
[10:30] <mdz_> bryce: handy, but won't resolve much for users
[10:30] <bryce> right
[10:30] <calc> Keybuk: bug 128360 is open about nm failing with open (but in my case its even more generally failing)
[10:30] <ubotu> Launchpad bug 128360 in network-manager "[ipw3945]  nm fails to connect to open network" [Undecided,Incomplete]  https://launchpad.net/bugs/128360
[10:30] <bryce> there are also some pixmap optimizations vis-a-viz cairo which *may* help with compiz performance
[10:31] <mdz_> bryce: have you raised the question with upstream?  what do they recommend that we do, given our schedule?
[10:31] <bryce> but I think at this stage we may be more concerned about compiz stability/featurefulness than performance
[10:31] <heno> oh, that might fix bug 83860 :)
[10:31] <ubotu> Launchpad bug 83860 in gdm "Accessible GDM broken with our wacom setup" [Medium,Confirmed]  https://launchpad.net/bugs/83860
[10:31] <Keybuk> calc: yes
[10:31] <bryce> mdz_, I talked with alex about it, and he said sticking with 1.3 "would be just fine" for our purposes, but of course as an upstream would love if we ran their latest code
[10:32] <mdz_> bryce: if they stand behind it strongly, and will be there to help us beat the bugs out of it, then it might be feasible
[10:32] <mdz_> bryce: if it's up to us, then I think perhaps not
[10:32] <mdz_> bryce: are you aware of any high-visibility bug fixes in it?
[10:33] <bryce> I know that debian has been working on packaging it but has been having various mesa-related issues
[10:33] <Mithrandir> it's required for display hotplugging, isn't it?
[10:33] <mdz_> Mithrandir: I thought that was in 1.3
[10:33] <bryce> it's a long changelog, but there are a number of bug fixes that would be nice to have.  I've got a handful listed for backporting if we choose not to update
[10:33] <bryce> display hotplugging was 1.3, and we already have it
[10:34] <Mithrandir> ok, then I haven't been paying proper attention
[10:34] <bryce> users are reporting very good results with it too, when deleting their xorg.confs.  :-)
[10:34] <Mithrandir> bryce: only people using US keyboards, then, I presume?
[10:34] <mdz_> bryce: I think this is largely your call to make.  if the backporting list is less scary than the update, then we can hang back
[10:34] <Keybuk> Mithrandir: or using GNOME
[10:34] <ogra> Mithrandir, you can set it in gnome
[10:35] <Keybuk> Mithrandir: since if you set in the gnome settings, it will adjust it on login
[10:35] <bryce> Mithrandir: right; the input hotplugging with xserver 1.4 I think will set up the keyboard better
[10:35] <Mithrandir> Keybuk: and not having any special characters in your password, then.
[10:35] <mvo> Keybuk: will that help in gdm?
[10:35] <ogra> mvo, nope
[10:35] <Keybuk> heh, that never occurred to me
[10:35] <Keybuk> but then I auto-login
[10:35] <mvo> heh :)
[10:35] <Keybuk> (brief check to see whether elmo saw that)
[10:35] <ogra> heh
[10:35] <bryce> mdz_, ok, I would like to avoid the risk and stay with what we have.  I think it would be keen to have the latest code, but I think the time would be better spent squashing bugs and giving users more stability
[10:36] <mdz_> does anyone have a strong feeling about X server 1.4 that they'd like to share?
[10:36] <mdz_> one way or the other?
[10:36] <Mithrandir> it doesn't matter for what drivers we'll have available?
[10:36] <Mithrandir> s/matter for/affect/
[10:37] <Keybuk> mdz_: "woo, bleeding edge, woo" ?
[10:37] <bryce> Mithrandir: not really, although alex says longer term if users wish for newish features, they may miss out
[10:37] <seb128> better to get the new version earlier than during a lts cycle?
[10:37] <mdz_> we don't offer new features post-release anyway
[10:37] <Mithrandir> seb128: that's a good point.
[10:37] <mdz_> seb128: we can have it from day 0 in gutsy+1
[10:38] <seb128> mdz_: still, gutsy+1 will not get real user testing for months
[10:38] <Keybuk> bryce: how do upstream feel about 1.4 ?
[10:38] <mdz_> bryce: do you feel confident updating it at the start of the next cycle?
[10:38] <bdmurray> seb128: I am personally surprised at the number of people running Gutsy
[10:39] <bryce> Keybuk: alex sounded more optimistic about it than I expected, but I haven't done a thorough survey
[10:39] <bryce> mdz_, yes
[10:39] <seb128> bdmurray: we are not early in the cycle
[10:39] <bryce> Keybuk: debian reports a variety of issues relating to mesa have cropped up
[10:39] <heno> yeah we need to tap into the user base running the latest crack better
[10:39] <mdz_> seb128 is correct, we don't get the kind of varied testing we need for something like a new X server until later
[10:39] <heno> seb128: but they start early
[10:39] <bryce> Keybuk: which I think is why they still have not released it to experimental, which is a worry
[10:40] <mdz_> bryce: will there be another major release during gutsy+1?  or can we plan to release 8.04 with 1.4 as well?
[10:41] <bryce> I think it's highly likely there'll be another major release during gutsy+1
[10:41] <mdz_> if it comes this late, we'd almost certainly have to pass over it
[10:41] <bryce> yup
[10:42] <mdz_> bryce: I support staying back if you think that gives us the best chance at quality
[10:42] <mdz_> that's the most important thing at this point
[10:42] <Keybuk> that could mean we ended up with 1.3 in gutsy+1
[10:42] <bryce> yes, good, that's my feeling as well
[10:43] <Keybuk> do we want 1.3 that late? and jump to 1.5 in +2 ?
[10:43] <mdz_> Keybuk: I don't see why it has to mean that
[10:43] <mdz_> especially if some other distros help stabilize it meanwhile
[10:43] <Keybuk> errr, yes, sorry, I'm on crack
[10:44] <mdz_> bryce: I encourage you to get more input from upstream, though.  explain the situation and try to get honest opinions of what's best to help you make the decision
[10:44] <bryce> ok will do
[10:44] <mdz_> ok
[10:44] <mdz_> next topic?
[10:44] <agoliveira> mdz_: No mootbot? :)
[10:44] <mdz_> agoliveira: it was a question
[10:45] <mdz_> calc: I hear we're expecting a late oo.o release as well
[10:45] <heno> I added an item to the wiki
[10:45] <calc> mdz_: yes, generally oo.o has released a month before ubuntu
[10:45] <heno> Tribe 5 testing commitments - [WWW]  https://iso.qa.stgraber.org now has the facility to subscribe testers to individual tests (as we did in the past on the wiki). I'll be asking distro team members and community testers to subscribe from tribe-5 testing onwards so we can track coverage better.
[10:45] <calc> mdz_: looking back at the old release schedules for oo.o vs ubuntu
[10:46] <mdz_> [TOPIC]  Tribe 5 testing commitments
[10:46] <MootBot> New Topic:  Tribe 5 testing commitments
[10:46] <calc> mdz_: rc is due next thursday
[10:46] <calc> mdz_: final release is scheduled for sept 4
[10:47] <mdz_> heno: good idea, to track coverage of known testers vs. test cases
[10:47] <mdz_> calc: bugfix release or feature release?
[10:47] <calc> mdz_: feature release 2.3.0
[10:47] <calc> the .1 releases are bugfix releases for oo.o
[10:47] <heno> right, for the later milestones we'll have to do that to ensure coverage
[10:48] <heno> and we have to double up coverage
[10:48] <mdz_> heno: will you go around and see that canonical folks are signed up to ensure coverage of the most important cases?
[10:49] <doko> compared to the current snapshot, oo.o shouldn't have new features for the next milestone
[10:49] <doko> I would propose to have packages in a ppa first before uploading to the distro
[10:50] <heno> mdz_: yes, that was the plan. I'll email the distro list
[10:50] <mathiaz> heno: stgraber created server.qa.stgraber.org.  I'd like to use it to track hardware testing.
[10:51] <mathiaz> heno: should this be done on iso.qa instead ?
[10:51] <mdz_> ok
[10:51] <calc> doko: ok will do
[10:51] <mdz_> any other business for the meeting?
[10:51] <heno> mathiaz: can we take this to email/phone?
[10:51] <ogra_> yes
[10:52] <mathiaz> heno: ok.
[10:52] <Riddell> are we ready for tribe 5 next week?
[10:52] <ubotu> Launchpad bug 130330 in linux-source-2.6.22 "Please re enable oss audio drivers for use on thin clients" [Undecided,Confirmed]  https://launchpad.net/bugs/130330
[10:52] <ogra_> it will be a major regression if we dont have them in ltsp ... many embedded clients only have oss drivers
[10:52] <mdz_> next kernel team meeting is tuesday
[10:53] <ogra_> so sound will just stop working for them
[10:53] <Riddell> calc: do you have an openoffice upload pending for tribe 5?
[10:53] <ogra_> mdz_, oki, i'll attend there
[10:53] <mdz_> ogra_: and BenC will be back from holiday
[10:53] <ogra_> yup
[10:53] <tkamppeter> I would like to hear about bug 35638 from the kernel team.
[10:53] <ubotu> Launchpad bug 35638 in linux-source-2.6.22 "Hl-1050 is not detected properly" [Medium,New]  https://launchpad.net/bugs/35638
[10:53] <rtg_> ogra_: send an email to Ben 'cause he had some opinions about it.
[10:53] <mdz_> Riddell: good question for our release manager to answer when he gets back from getting married ;-)
[10:53] <Riddell> kylem etc: any linux uploads planned for tribe 5?
[10:53] <mdz_> I'm told there's a kernel upload planned
[10:54] <calc> Riddell: still working on it right now, i'll see if i can get it done before the end of the weekend
[10:54] <Mithrandir> today or tomorrow is the rumour I've heard
[10:54] <calc> Riddell: the next upload won't have that annoying hang in any case
[10:54] <Riddell> any last minute major gnome features being added? :)
[10:54] <rtg_> kylem is in the middle of producing an upload right now.
[10:54] <Riddell> calc: you're my hero
[10:54] <ogra_> rtg_, well, if he's at the meeting i'm fine to discuss it there, there is no hurry as long as we have a decision before release
[10:54] <calc> Riddell: heh :)
[10:55] <mdz_> kernel uploads in advance of the freeze make for happy release managers
[10:55] <calc> Riddell: any news about the nspluginviewer getting a fix similarly?
[10:55] <Riddell> calc: nothing :(
[10:55] <calc> ugh :\
[10:55] <Riddell> and of course we have plenty of other bugs marked for tribe 5 https://bugs.launchpad.net/ubuntu/+milestone/tribe-5
[10:55] <calc> Riddell: well if the code is cleanly separated then you can check for calls to glib/gdk/gtk and determine if it is initialized beforehand, adding initialization will probably fix it
[10:56] <mdz_> Riddell: should we have a tribe 5 bug round-up early next week?
[10:56] <mdz_> Riddell: gather the people working on those bugs?
[10:56] <Riddell> mdz_: would need to be very early next week
[10:57] <mdz_> tomorrow?
[10:57] <mdz_> I think it would be good to review them one-by-one, but there's no time here
[10:57] <Riddell> can do
[10:57] <mdz_> [TOPIC]  tribe 5
[10:57] <MootBot> New Topic:  tribe 5
[10:57] <bdmurray> tkamppeter: we could talk about that bug a bit if you want
[10:57] <ogra_> why is tribe5 so early ?
[10:57] <tkamppeter> bdmurray, would be nice.
[10:57] <Riddell> ogra_: it's what the schedule says
[10:58] <ogra_> only two weeks between the two
[10:58] <mdz_> ogra_: because we need testing
[10:58] <ogra_> Riddell, right, i just wonder why ...
[10:58] <mdz_> ok, we're out of time
[10:58] <mdz_> anything else, follow up on the mailing list
[10:58] <tkamppeter> bdmurray, should we talk here or better at another place in this IRC?
[10:58] <Riddell> others were three weeks between them but there's no time for three week gaps before beta
[10:59] <mdz_> thanks, everyone
[10:59] <mdz_> #endmeeting
[10:59] <MootBot> Meeting finished at 20:51.
[10:59] <mdz_> MootBot: your watch is slow
[10:59] <ogra_> well, i'm missint the one week to fix my tribe bugs :)
[10:59] <bdmurray> tkamppeter: another place probably
[10:59] <agoliveira> Bye all
[10:59] <mvo> bye
[10:59] <ogra_> since i'm busy with building and testing isos then ...
[10:59] <kwwii> thanks all
[10:59] <ogra_> thanks
[10:59] <ubotrans-it> thanks all
[10:59] <seb128> 'night
[11:00] <ubotrans-it> goodnight
[11:00] <asac> night all
[11:00] <ArneGoetje> night
[11:00] <evand> bye
[11:01] <tkamppeter> bdmurray, I have opened I private chat.
[11:02] <iwj> Goodnight all.
[11:03] <heno> 'night
[11:04] <bdmurray> tkamppeter: have you seen my reply?
[11:04] <tkamppeter> bdmurray, no reply appeared.
[11:06] <tkamppeter> bdmurray, will restart my xchat and try again.


[00:03] <ScottL> persia, did I really do a horrible job with zynjacku?  It certainly feels so
[00:03] <persia> Not at all.
[00:04] <persia> I reject about 80% of the packages I get on REVU, and I tend to only really review the ones that either have gotten prior reviews, or for which I've previously done an eyeball review and the uplaoder has fixed stuff.
[00:04] <persia> I'm really picky :)
[00:05] <persia> Since I hit your package without that layer of prior fixing, you got a *lot* of comments.
[00:06] <ScottL> i felt more or less comfortable with fabrice's comments (they seemed to be more about form) but your's is addressing some stuff that I have never heard of before
[00:06] <ScottL> which isn't really hard really considering i've only been trying to help for a couple of months and never used linix before Ubuntu
[00:14] <ScottL> don't take that as I'm giving up, 'cause I'm not :)  I'm still having a good time learning and helping with what I can
[00:17] <persia> Do you have some time in about 15 minutes?  I'd be happy to go over each item individually.
[00:18] <ScottL> we can try, i'm getting dinner and kids are running around so I might need to take a couple of minute breaks now and then
[00:20] <ScottL> i know your time is valuable right now and I probably will not get to working on it again until almost the end (or even after) February
[00:20] <ScottL> i need to write and record another seven songs before the end of the month ;P
[00:21] <ScottL> so basically we can do it at your leisure but no need to rush on my account
[00:30] <persia> heh.  I'll go through them now, but won't expect you to fix them soon :)
[00:31] <persia> OK.  So the description is just a matter of form.  Some package managers use that cloze to present "user friendly" messages.
[00:31] <ScottL> works for me, i'll be sure to log this also
[00:31] <persia> If you don't add double-spaces, package managers are free to line-wrap in ways that may not make sense.
[00:31] <persia> This is important for lists, and unimportant for prose
[00:32] <persia> GTK/GTK+ is just because upstream complains when it's not used right.
[00:32] <persia> manpages may seem silly, especially for GUI stuff, but people really use them.
[00:33] <persia> Also, manpages end up building index files, and get mirrored to web pages, which means that the application is more discoverable.
[00:33] <persia> creating them is usually fairly easy: ask in #ubuntu-motu for help.
[00:33] <ScottL> I think i'll need it for the man pages :)
[00:34] <persia> The icon size and number of colors stuff is to support non XDG-compliant menu systems, which some people use for very lightweight environments.
[00:34] <persia> fluxbox is probably the most popular environment requiring this to be right in the audio community.
[00:34] <persia> fluxbox also requires that the menu files be just right, which documentation is in /usr/share/doc/menu after installing the menu package.
[00:35] <persia> I'm not sure why usr/bin/lv2rack ended up in zynjacku, but that's probably related to the install file stuff (which we'll come back to later)
[00:36] <persia> The dependency on python is fairly straightforward: it's possible (but very difficult) to create an Ubuntu install without python.
[00:37] <persia> "#! /usr/bin/python" or non-executable is to prevent users from shooting themselves in the foot (and they have a special knack for this)
[00:37] <persia> "#! (interpreter)" at the top of a script just tells the shell to run that script with that interpreter.
[00:37] <persia> Sometimes people don't insert the space, and most shells understand, but there *should* be a space.
[00:38] <persia> The wiki page explains why .la files are bad more than I could.  Easiest way to deal with them is not to install them.
[00:38] <persia> (they also aren't correct, but we don't either care or have to care if we don't ship them)
[00:39] <persia> We generally put shared libraries in /usr/lib/${PACKAGE}/ or directly in /usr/lib because the library loading system knows to look there for stuff.  Putting it somewhere else might work, but if so, it only works by accident.
[00:39] <persia> So putting it in the right place is another way to avoid toe removal.
[00:40] <ScottL> speaking of /user is it common for prefix=/usr or prefix=/usr/local?
[00:40] <ScottL> s/user/usr
[00:40] <persia>  /usr
[00:40] <persia>  /usr/local/ is for local stuff the sysadmins install directly.
[00:40] <ScottL> roger
[00:40] <persia> The distribution isn't supposed to mess with that
[00:40] <persia> (and sysadmins aren't supposed to mess with /usr)
[00:41] <persia> So, most upstream makefiles will be set up to install to /usr/local/ by default when building from source (this is correct)
[00:41] <persia> But when we package it, we install to /usr instead
[00:41] <persia> Having the library call exit() directly just ends the program without warning the user in any way.
[00:42] <persia> This can be confusing :)
[00:42] <persia> But that's hard to fix, and changes the behaviour and requirements for code that uses the library: it deserves an upstream bug, but there's nothing you need to do for it.
[00:43] <persia> (well, other than file the bug).
[00:43] <persia> Do you understand the bug?
[00:43] <ScottL> nedko has been hot and cold about interacting with me but i'll file the bug
[00:44] <persia> nedko is an odd, brilliant man.  I think he has mixed feelings about all the rest of us, perhaps in part because we don't have his depth of comprehension :)
[00:44] <persia> But his code is *wonderful* and well worth trying to understand.
[00:45] <persia> He might even have a really good reason to do it this way, although it's usually not ideal.
[00:45] <ScottL> well, i've started understanding the makefile ;P  it's a start
[00:45] <persia> heh :)
[00:45] <persia> The long description for lv2jack just doesn't make sense to anyone who isn't already steeped in the environment.
[00:46] <persia> It's fine for you and I, but my mother won't install that package because she won't understand that she wants it.
[00:46] <ScottL> yeah, i felt bad about that because i just stole it from his website and it's was rather terse
[00:46] <persia> Cribbing from the zynjacku and jackrack descriptions, I suspect you can come up with something better.
[00:47] <persia> (because it's a mix of the two, really)
[00:47] <persia> changelog comment is just a form thing.  The syntax (LP: #nnnn) closes the bug, so you don7t need to explicitly declare that.
[00:48] <persia> You can get more on optional/extra from policy, but I think my comment (which I put in about 50% of packages I review) sums it up.
[00:48] <persia> Uploaders: only means anything in Debian.
[00:49] <persia> The LGPL-2.1 bit is because you listed the Files as LGPL-2+ and LGPL.  The idea of that copyright file format is to make it machine-readable, so you really need to worry about making the strings match.
[00:49] <persia> There's two ways to solve it: either change the License: tags for the Files: stanzas, or for the License: stanza.
[00:50] <ScottL> what about files that did not define copyright?
[00:50] <persia> Putting in the short-form of the licenses and referencing /usr/share/common-licenses is intended to save space on user harddrives (nobody needs 2000 copies of the GPL)
[00:50] <persia> Files that don't define copyright, or have licensing can't be distributed.
[00:51] <ScottL> re: /usr/share/common-license   that's what I did originally but dep5 seemed to imply that the _entire_ license should be there, which seemed silly to me
[00:52] <persia> It's times like that you should ask in here or in -motu for help :)
[00:52] <ScottL> i saw some .h files and some .c files without copyright     http://revu.ubuntuwire.com/report.py/legal?upid=7861
[00:52] <ScottL> i shall
[00:52] <ScottL> ask for help, that is
[00:52] <persia> double-check those: at least the few I examined were just licensecheck parse failures.
[00:53] <persia> "public domain" isn't valid in many countries (especially ones with civil law rather than common law).  A good example of how to release rights to source in all jurisdictions is http://revu.ubuntuwire.com/revu1-incoming/ccscript-1001231639/ccscript-4.1.3/cmodel.sh
[00:53] <persia> That's another upstream bug
[00:54] <persia> Also, you didn't identify the public domain stuff in debian/copyright (needs it's own section)
[00:55] <persia> (it's not legal for me to use it, but it is legal for Ubuntu to distribute, just because of where I live and where the Ubuntu main mirrors are)
[00:55] <ScottL> i went off the legal link i posted earlier and didn't see any public domain stuff :(
[00:55] <persia> Yeah, that's only the output of licensecheck.  You're supposed to read all the source files to check :)
[00:55] <persia> (which is different from reading all the source: you ought be able to tell at a glance if something has a license, etc.)
[00:56] <ScottL> well, next time i package i'll be choosing an app with fewer files then LOL
[00:56] <persia> When licensecheck works, it's lovely, but when it doesn't work, we fall back to human intelligence.
[00:56] <persia> We're just better at understanding prose than licensecheck.
[00:56] <persia> I usually do something like `less $(find . -print)` and press :n lots.
[00:57] <persia> I keep a separate editor window open to take notes
[00:58] <persia> The ,desktop file bits are just based on my past experience with .desktop files.  Doesn't make that much difference, but can make things nicer.
[00:58] <persia> Same for the 8-bit xpm, and using a nicer graphic.
[00:58] <persia> And dh_install is tricky.
[00:58] <persia> So, the way dh_isntall works is as follows:
[00:59] <persia> The package builds, and installs everything to debian/tmp/...
[00:59] <persia> Then you have several .install files.
[00:59] <persia> Each consists of a set of lines, in either of two formats.
[00:59] <persia> A single pathname with no leading / will grab a file or a directory from debian/tmp/ and copy it to debian/${PACKAGE}/
[01:00] <persia> For example if debian/lv2rack.install contained the line "usr/bin/lv2rack", that file would be put in the lv2rack directory.
[01:00] <ScottL> because no leading /
[01:01] <persia> A pathname followed by whitespace followed by another path will move files, using either files in the source directory or in debian/tmp as the source of the move, and debian/${PACKAGE} as the target.
[01:01] <persia> Right, so .../debian/tmp/usr/bin/lv2rack -> .../debian/lv2rack/usr/bin/lv2rack
[01:03] <persia> For example, if debian/zynjacku had the line "debian/zynjacku.xpm usr/share/pixmaps" this would copy that file to that directory under debian/zynjacku
[01:04] <persia> You can also add stuff from debian/tmp if you like, so you can do a two statement line like "usr/lib/zynjacku/*.so usr/lib/zynjacku" to install the .so file (assuming it got put in debian/tmp/usr/lib/zynjacku/ in the first place)
[01:05] <persia> Or if it got installed to the wrong place, "usr/share/misc/zynjacku*so usr/lib/zynjacku/" would put it in the right place.
[01:06] <persia> When the binary packages get built, the tree of files to install is taken from debian/${PACKAGE}
[01:06] <persia> this is probably why you end up with extra stuff in the zynjacku package and not enough in the lv2rack package (because of the DESTDIR setting)
[01:07] <persia> That all make sense?
[01:08] <ScottL> lol, well not ALL...at least not yet
[01:08] <persia> Heh.  Questions?
[01:08] <persia> I think I covered all my comments.
[01:09] <ScottL> a side question that perhaps you will not be able answer about when I did get zynjacku and lv2rack isntalled
[01:09] <ScottL> i can run either from the terminal and it will start jack if jack isn't already running
[01:09] <persia> OK.
[01:09] <ScottL> but when i picked it from the menu both would not start because jack wasn't running
[01:10] <persia> Right.
[01:10] <persia> I've never understood that issue.
[01:10] <ScottL> if jack was already running both would start from the menu
[01:10] <persia> I ended up not maintaining a package in Debian bacause of it.
[01:10] <ScottL> is it something I bring up with nedko?
[01:10] <persia> JACK can't always be running : it blocks the sound card, which many people don7t like (including my mother).
[01:11] <persia> No need.  We tell the users to use qjackctl
[01:11] <ScottL> other apps have the same issue i believe
[01:11] <persia> As hansfbaier gets his set of stuff in shape, we can recommend that instead (if it' ready)
[01:11] <persia> Yeah, everything has the same issue.
[01:12] <ScottL> what is hansfbaier working on?
[01:12] <persia> I think it has something to do with the way the GUI starts stuff.
[01:12] <persia> jackpanel
[01:12] <persia> and some other similar stuff.
[01:12] <ScottL> oh yeah, i read you two talking about that a few days ago
[01:12] <persia> Really cool UI, but unfortunately needs packaging help, and he's trying to do both upstream and packaging.
[01:13] <ScottL> jackpanel is a gui lv2 host?
[01:13] <persia> http://www.hans-baier.de/wordpress/jackpanel
[01:15] <ScottL> huh, it's not what I thought it was then, but it lets you do connections also right?
[01:15] <persia> That's still under development.
[01:15] <persia> But connections != hosts.
[01:15] <persia> But it means one doesn't have to run qjackctl & patchage
[01:16] <persia> That can all be in the panel, and one can then keep screen real-estate open for plugins, ardour, etc.
[01:16] <ScottL> i (think) i just came to grips with patchage and now it's going away!   kidding
[01:17] <persia> I don't think it's going away.
[01:17] <persia> But I think most people don't really need all of it.
[01:17] <persia> And nedko has a prettier one available anyway.
[01:17] <ScottL> well it's somewhat true, i just set up a template for Ardour and patchage for my most common connections
[01:17] <persia> Right.
[01:17] <ScottL> which one of nedko's are you talking about?
[01:18] <ScottL> the prettier one
[01:18] <persia> My mother mostly just opens patchage to connect her mic & instrument inputs & hydrogen to muse, and then leaves it on a different desktop.
[01:18] <persia> She only uses it because the qjackctl connection tool confused her.
[01:18]  * persia hunts for a link
[01:18] <ScottL> your mother uses ubuntu studio to record music?  that's fantastic!
[01:19] <ScottL> do you record music as well?
[01:19] <ScottL> i wondered about your connection to ubuntu studio - well, everyone who frequents this channel actually
[01:19] <persia> No.  I just fool with syntheised and mangled loops :)
[01:20] <persia> I used to spend lots of time playing with hydrogen and freqtweak, but much less now.
[01:20] <persia> I got involved with Studio because I kept patching packages that we shipped.
[01:20] <persia> My mother uses it because I work on it, and she likes the ideas behind Ubuntu (plus, it's good enough for her)
[01:20] <persia> http://ladish.org/wiki/lpatchage
[01:22] <ScottL> yes, i've seen that before but didn't really look at it closely to be honest, nedko has done quite a bit of programming
[01:22] <persia> Indeed.
[01:22] <persia> And *lots* of it work that directly improves the set of software available to our users.
[01:22] <ScottL> i'm so retro in some ways, maybe not 'retro' but simplistic, i find what works and tend not to deviate
[01:23] <persia> heh.
[01:23] <ScottL> i know I can make connections in ardour but i tend to still use qjackctl -> connect and just moved over to patchage
[01:23] <ScottL> because I already know how to do it and i don't want to waste time dorking with something that mgiht not work when i need it to
[01:23] <persia> I totally understand.  I intentionally avoid making connections in muse because I like separation of concerns.
[01:24]  * persia should really review ardour again, but the MIDI bits never seem to quite be there
[01:25] <ScottL> of course this mentality is why i also stayed with hardy and wanted to backport jack and ardour to it
[01:25] <ScottL> it seemed like audio tended to break each update (it probably didn't but it seemed it was)
[01:26] <ScottL> and i finally got my system where flash (with sound) and sound in general all worked and didn't want to have to dork with it anymore
[01:27] <ScottL> but karmic (in general) seems much more in line so I have high hopes for further releases of ubuntu studio and i'll probably upgrade each release
[01:27]  * ScottL needs to get daughter to do her spelling homework
[01:29] <persia> ScottL: If you have time to test lucid along the way, that's the best way to make sure the upgrade would be clean.
[01:29] <persia> Of course, this requires an extra computer, or extra hard drive, or some such :)
[01:30] <ScottL> well, i currently have four partitions but i'll be eliminating two (hardy) soon :)   but yes, I plan on getting rid of the karmic one and testing lucid in its place
[01:31] <ScottL> but that will have to wait until after February though
[01:34] <persia> Fair enough: you've all those songs to write :)
[01:37] <ScottL> that'll be easy, stock drum pattern, two passes of rhythm guitar, one bass and a solo (over most of it) and I'll be done but I want to
[01:37] <ScottL> do more vocal stuff which is not as easy for me as the previously listed formula
[01:41] <ScottL> but this is all an optional, voluntary project just to do it
[01:42] <ScottL> http://www.rpmchallenge.com/ is the project
[01:43] <ScottL> i'm even looking forward to next years challenge and transcribing some of my acoustic stuff, putting it into muse (or something similar) and having it done on piano...or tuba
[01:43] <TheMuso`> Why not use lilipond?
[01:44] <ScottL> hey ckontros, how are you doing, you're on kinda late tonight
[01:44] <ckontros> TheMuso`: Can you merge this and upload a new package? https://code.launchpad.net/~psyke83/ubuntustudio-look/UbuntuStudio/+merge/18821
[01:44] <ScottL> TheMuso`, i can do that, i haven't done any music other than recording live instruments (except for hydrogen) so far
[01:44] <ckontros> ScottL: I'm well. Just tinkering a little.
[01:44] <TheMuso`> ckontros: Is there an official merge request on launchpad for that?
[01:45] <ScottL> i have until next february to get those things (midi, etc) under my belt :)
[01:45] <ckontros> TheMuso: Isn't that it? :)
[01:45]  * TheMuso` looks
[01:45] <TheMuso`> ckontros: yes it is
[01:46]  * TheMuso` reviews
[01:47] <ckontros> TheMuso: Last couple of dailies I've grabbed wouldnt boot in VM. Are yours working fine?
[01:47] <TheMuso`> ckontros: Haven't tested.
[01:48] <ckontros> Ok. Ill pull a fresh one tomorrow and test.
[01:51] <TheMuso`> ckontros: Merged, and uploading new package now.
[01:51] <ckontros> killer
[01:51] <ckontros> Did stochastic or anyone figure out a new wallpaper?
[01:53] <TheMuso`> not afaik
[01:58] <ckontros> So, I see a little about what's going on because of bug reports but can anyone fill me in? Anything going on like, pulse audio getting built with JACK support? :)
[02:00] <ScottL> well, the jack MIR is still going on and we (meaning stochastic) was supposed to get patches together for building a few apps with jack support
[02:02] <ckontros> Yeah. That's most of the bug-mail Ive got. Anything else?
[02:03] <ScottL> TheMuso`or stochastic (or the janitor) should have more depth on that than me :P
[02:03] <TheMuso`> Not shipping RT kernel on discs, because its 2.6.31 and is hard to maintain post release. So going preempt kernel for amd64, no flavour for i386 because the kernel team don't want any more than 2 i386 flavours/.
[02:04] <ckontros> TheMuso: So we're shipping stock -generic for i386?
[02:04] <TheMuso`> ckontros: Yeah seems so.
[02:05] <TheMuso`> alessio is maintaing RT in a PPA though which will be noted in release notes.
[02:05] <ckontros> Wait. Why the hell do they even care since we're maintaining it?
[02:06] <TheMuso`> ckontros: the maintenance issue is with SRUs post release
[02:06] <TheMuso`> and security
[02:07] <ckontros> Sure but the kernel team isn't responsible for -rt. Shouldnt matter.
[02:07] <TheMuso`> ckontros: nothing to do with the kernel team
[02:07] <TheMuso`> its called lack of man power.
[02:07] <ckontros> And hell, SRU's wouldnt be an issue if they got around to reviewing and approving them.
[02:08] <TheMuso`> If I had enough time to push RT SRUs, I would, but I don't.
[02:08] <ckontros> Ahh. You said "because the kernel team don't want any more than 2 i386 flavours" so, that's what I was going on.
[02:09] <TheMuso`> right I was talking about the separate rt package
[02:10] <ScottL> i'll be able to upgrade my recording box now, i'll "have" to...at least that's what i'll tell my wife :)
[02:10] <ckontros> ? Im confused. :)
[02:10] <ckontros> TheMuso: Is the kernel team stopping us from having -rt in the archive and on disk?
[02:10] <TheMuso`> ckontros: we are not shipping the rt kernel on the discs due to lack of manpower with maintenance.
[02:11] <TheMuso`> ckontros: no
[02:11] <ckontros> Ok. Gotcha.
[02:12] <ckontros> I'd *almost* shutdown the project to restructure. At this stage, shipping -generic feels, dirty.
[02:12] <ckontros> :P
[02:13] <ckontros> Like it shouldnt be.
[02:13] <ckontros> (shipping generic)
[02:13] <TheMuso`> I know what you mean
[02:14] <ScottL> can the ubuntu studio ppa already be in the repositories for ubuntu studio? off of a clean install i mean?
[02:15] <TheMuso`> ScottL: not easily.
[02:16] <ScottL> so all users who want to upgrade to -lowlatency (or -preempt or whatever) will have to do it manually :(
[02:17] <TheMuso`> It will be in the release notes.
[02:25] <ScottL> TheMuso`, is it worth it to start a release notes wiki page?
[02:26] <ScottL> rather than wait until the day before release?
[02:29] <ckontros> Sure.
[02:34] <TheMuso`> ScottL: yes
[03:04] <TheMuso`> Jack MIR has been given thumbs up.
[03:15] <ScottL> yay - that's a pretty big accomplishment :)
[03:26] <persia> \o/
[03:47] <crimsun> and I've just uploaded pulse with jack enabled
[03:48] <crimsun> (along with other fixes recommended by Lennart)
[03:49] <crimsun> I think I owe mterry a few beers
[03:57] <TheMuso`> I think we all do.
[03:57] <TheMuso`> So pulse will be dep wait till the packages are promoted then.
[03:58] <crimsun> indeed
[04:17] <ScottL> so how will pulse and jack work now?  doesn't pulse automagically stop when jack is started?
[04:17] <ScottL> currently:  pulse stop when jack is started that is
[04:19] <TheMuso`> ScottL: Not quite. Hopefully we can get jack2 into lucid+1 and use dbus to tigh them together.
[04:21] <ScottL> so, until jack2 is ready then pulse and jack will continue to act the same as they do now?
[04:22] <ScottL> and is jack2 going into debian first? or will we have it first?
[04:23] <TheMuso`> ScottL: This is what needs to be worked out. I'd like it in Debian first.
[04:23] <TheMuso`> ScottL: The issue is whether we want jack2 to sit alongside of jack, or replace jack.
[05:47] <jussi01> wow! great work lads!
[07:30] <crimsun> ...and alsa-plugins uploaded with jack enabled
[07:30] <jussi01> crimsun: ++
[07:30] <jussi01> nice work
[07:37]  * abogani waves
[07:55] <jussi01> hi abogani"
[07:56] <abogani> jussi01: Hi!
[09:42] <stochastic> Can anyone with upload powers look at the patch for building xine against jack on Bug #152487 <- TheMuso` crimsun persia etc... before feature freeze becomes solid?
[09:48]  * abogani listen Frankie goes to Hollywood...
[10:36] <stochastic> also Bug #360590
[12:03] <ScottL> it also looks like libffado also made it into the main :)
[12:23] <crimsun> yep, due to it being one of j-a-c-k's build-deps
[12:23]  * crimsun fixes alsa-plugins
[18:23] <ScottL_> i added to the working release notes wiki page      https://wiki.ubuntu.com/UbuntuStudio/WorkingReleaseNotes
[18:23] <ScottL_> i started one for lucid and was able to add a lot more than I thought I would :)
[18:28] <persia> ScottL_: realtime won't be default for amd64 : preempt will be default.  Realtime will be available for in the PPA for both i386 and mad64
[18:29] <persia> Also, I'm not sure we applied to be part of the Long Term Release.
[18:29] <persia> So there may be no guarantee that our applications will get long-term support.
[18:29] <persia> (we could try ourselves, but I'm not confident we have enough developers)
[18:29] <ScottL_> i will change the wiki then :)         thanks for the checking and feedback
[18:35] <ScottL_> quick fix - i'll reread back over it later (i had made the original during lunch but I'm back at work now)
[18:39] <ScottL_> if there is anything that should be added, i'll be happy to make any additions, moderations or deletions if you just want to say something here about it (e.g. I know TheMuso` and persia are probably really, really busy right now)
[18:39]  * persia is kinda recovering from the pre-FF marathon, so not particularly busy, but similarly not particularly inclined to do much right now
[19:22] <ScottL_> persia: just to clarify -realtime vs -preempt, in synaptic the package says -rt but is that just semantics?  it really is preempt kernel?
[19:23] <persia> No.
[19:24] <persia> The -rt kernel is different, but not up-to-date (I think)
[19:24] <persia> Oh, it is kinda up-to-date, but not perfectly.
[19:24] <persia> But that's not the -preempt kernel.
[19:28] <stochastic> hey fabrice_sp and persia is there any chance one of you could look at Bug #360590 and Bug #152487 ?
[19:28] <stochastic> patches are ready to be uploaded.  Do we need FFE bugs as well now?
[19:29] <persia> stochastic: That requires main upload rights, which neither of us have.
[19:30] <stochastic> persia, where would be the best place to poke someone about this?
[19:30] <ScottL_> dtchen might have those rights, no?
[19:30] <persia> Have you subscribed ubuntu-main-sponsors to the bugs?
[19:30] <stochastic> yes
[19:30] <persia> he does, as do others.
[19:30] <persia> But subscribing the sponsors is the best right now.
[19:31] <persia> Otherwise, wait, and either of the core-devs who are regularly in this channel will probably see it in backscroll.
[19:31] <stochastic> okay, I'll sit and wait then
[19:32] <persia> I think we all know we want it, so it's just a matter of time.
[19:32] <persia> If freeze exceptions are required, they ought breeze through.
[21:06] <TheMuso`> Building portaudio with jack support may need to be considered carefully. DOing so will put libjack onto the CD which may be a problem.
[21:06] <TheMuso`> Xine is not a problem however.
[21:08] <persia> Doesn't kubuntu pull xine as a phonon backend still?
[21:08] <ScottL_> why would libjack on the cd be a problem?
[21:08] <TheMuso`> I don't know.
[21:08] <TheMuso`> ScottL_: Space for one.
[21:09] <ScottL_> i'm guessing that libjack isn't necessarily that big, but that the cd is rather full already
[21:09] <persia> 187k, which adds up fast over time.
[21:10] <persia> Right.
[21:10] <persia> TheMuso`: libjack0 is already in Task: ubuntu-desktop
[21:10] <persia> It may be that it's already on the CD
[21:11] <TheMuso`> persia: hrm ok. Probably won't know till the next daily images.
[21:11] <persia> Gets pulled by libasound2-plugins at least
[21:12] <TheMuso`> Point.
[21:12] <TheMuso`> Although I was hoping that would be a separate package.
[21:12] <persia> Maybe later, but not as currently implemented.
[21:12] <TheMuso`> No need for jack anything to be on the CD by default, most people don't need it.
[21:13] <persia> For jackd & friends, I agree.  WIth the way shared libraries work, the core lib might end up there.
[21:15] <TheMuso`> right
[21:15] <TheMuso`> In which case portaudio linking against jack won't be bad.
[21:16] <persia> Well, it's 187k, but we're probably going to end up with that there anyway.
[21:17] <TheMuso`> yeah
[21:17]  * TheMuso` checks latest daily images.
[21:18] <TheMuso`> ok not there yet
[21:18] <persia> No, tomorrow.
[21:18] <persia> Or rather, later today :)
[21:18] <persia> Or ~11 hours from now, however one counts.
[21:18] <TheMuso`> yeah
[21:19] <TheMuso`> In which case I'll tend to those two bugs shortly.
[21:35] <ScottL_> did anyone ever tell you guys that you rock?  they should.  you do!  :)
[21:37] <TheMuso`> Thanks
[22:27] <TheMuso`> Right, portaudio debdiff uploaded, thanks stochastic.
[22:46] <TheMuso`> Yay can't build xine atm due to package installability breakage. :)
[22:49] <persia> heh
[22:54]  * TheMuso` refreshes his local mirror in case the problem is transient and fixed in the archive.
[22:54] <TheMuso`> Otherwise, time to go digging.
[23:08] <TheMuso`> Yay ocaml breaks installability. :S
[23:18] <TheMuso`> Ah ok graphviz is affected by the ocaml transition.
[23:48]  * TheMuso` sighs. I really don't enjoy these wild goose chaces sometimes.
[23:55] <TheMuso`> Oh yay. A launchpad/soyuz bug (i think) regarding not handling provides properly for package metadata.
[23:56] <persia> How so?
[23:56] <persia> Because virtual provides don't work by design.
[23:56] <TheMuso`> libgraphviz-dev in debian depends on ocaml-base-nox-3.11.2 but due to provides, ocaml-base-nox ets installed.
[23:56] <TheMuso`> ocaml-base-nox provides ocaml-base-nox-3.11.2
[23:56] <persia> Which breaks the transition?
[23:56] <TheMuso`> which break libgraphviz-dev installability
[23:57] <TheMuso`> s/break/breaks/
[23:57] <TheMuso`> so we need to carry another change ingraphviz to depend on a versioned ocaml-base-nox
[23:57] <TheMuso`> instead of a ocaml-base-nox-$bla dependency
[23:58] <TheMuso`> I think thats the best approach anyway.
[23:58] <TheMuso`> and all to rebuild xine...
[23:59] <persia> Oh, it's a versioned depends on ocaml-base-nox-3.11.2 ?
[23:59] <persia> Yeah, that's annoying.


[10:31]  * LeoNerd is somewhat surprised that 'bzr shelve' in a git checkout /mostly/ works
[12:03] <jelmer> LeoNerd: with bzr-git, presumably?
[12:10] <LeoNerd> Yeah.. admittedly it did crash, but it seems to have crashed after storing the shelf and unpatching it from the workdir.. so it's quite servicable
[12:11] <LeoNerd> I'm currently developing a server using python in git, a client using perl in bzr, and an integration-test script between the two using perl in git. So it's a bit of a mixup in my head sometimes :)
[12:14] <jelmer> LeoNerd: that sounds.. suboptimal?
[13:10] <thrustcore> bzr has been updating for 2 hours, should I break the lock and start again or should I wait for it to finish?
[15:44] <mark06> anyone experimenting with bzr-hg or fastimport?
[15:45] <mark06> I managed to make bzr-hg proceeed after a path to the mercurial lib, but then it takes hours processing the "manifests", up to failing due to some memory error
[15:47] <mark06> as for fastimport, none of the mentioned commands for exporting an hg repo exists
[23:12] <mark06> is there some way to merge a branch with no common ancestor?
[23:13] <mark06> surprisingly it seems to be a common case: http://zakalwe.fi/~shd/articles/why_not_bazaar.html
[23:13] <mark06> "Having a common ancestor is a strong "hint" that a merge is possible, but it should not be a technical requirement for merging. Git and hg both allow merging arbitrary trees together."
[23:22] <mark06> any progress after this? http://fourword.fourkitchens.com/article/creating-common-branch-ancestry-hard-problem
[23:24] <fullermd> I merge unrelated branches all the time.
[23:24] <jelmer> mark06: that article is very ignorant
[23:24] <jelmer> mark06: "bzr merge -r0..-1 <branch-to-merge>"
[23:40] <mark06> fullermd: how do you do?
[23:41] <mark06> full of conflicts, jelmer: http://vpaste.net/IY9Ku
[23:41] <jelmer> mark06: sure, if there are paths that exist in both you'll probably get conflicts
[23:42] <mark06> better formatted, http://vpaste.net/XXdgs
[23:42] <mark06> jelmer: which is exactly what the article says
[23:42] <jelmer> mark06: no, the article says that a merge is not possible
[23:42] <mark06> no it doesn't say that
[23:43] <mark06> let's put the vcs wars aside, I don't care about it, really
[23:43] <jelmer> mark06: " Bazaar version control tool demands that two trees that are merged must have at least one common ancestor, or cherry-picking must be used."
[23:43] <mark06> I just want to merge :)
[23:44] <mark06> jelmer: you mean the first post? ok
[23:44] <jelmer> mark06: merging two branches with different file ids for the same paths is problematic in bzr; you need to pick the file ids of either side
[23:45] <jelmer> mark06: yes, the first post is wrong. The second post gives a reasonable explanation, at a quick glance
[23:45] <jelmer> (and yes, this is an unsolved problem.. it's a fundamental issue with file ids)
[23:45] <mark06> I wish they worked on "I’m currently looking at writing a custom merge handler (subclassed from  the standard merge3 in Bazaar) that would intelligently handle merges  where file paths do represent the same files"
[23:46] <jelmer> mark06: who are you referring to with "they" ?
[23:46] <mark06> I managed to resolve all the conflicts with lost of "just resolve" but then I get no merge at all but a plain commit
[23:47] <mark06> they = whoever was planning to write such custom merger
[23:48]  * mark06 curious how fullermd handles it
[23:49] <mark06> my real case is that if I ever get bzr-hg working, then I could work better with upstream repo for pidgin... currently I have committed 2.10.9 to a new branch supposed to get only upstream changes....
[23:50] <jelmer> mark06: ah, you're taking up bzr-hg development?
[23:50] <jelmer> mark06: there are lots of use cases for merging unrelated branches
[23:51] <jelmer> mark06: one is merging unrelated branches with non-overlapping files; file ids are not an issue there
[23:52] <mark06> not really, I made some progress with a small patch to mercurial's python module but then the manifests step takes too long and eventually fails with memory error (this is windows, the idea was trying it on my ubuntu server)
[23:52] <mark06> yeah my case is definitely overlaping files
[23:53] <jelmer> mark06: yeah, there is no good way of handling those (the name for this problem is "parallel imports")
[23:53] <mark06> since I have an upstream branch with one single commit for 2.10.9, and from which I based all of my work for pidgin++
[23:54] <jelmer> mark06: cool, bzr-hg is in need of some attention :)
[23:54] <fullermd> I merge really-unrelated branches, so there's minimal overlap in file names (and when there is, they usually really are different files, so resolution is renaming)
[23:55] <mark06> so instead of committing next version to the upstream branch (or breaking this into manual commits according to how often I update it)... I would like to merge the mercurial branch on top of that (all changesets after 2.10.9 I mean)
[23:57] <mark06> hopefully these many conflicts would be only for the first time...
[23:57] <mark06> I just don't understand because in my test, after solving all conflicts I got no merge at all, the commit was plain
[23:59] <jelmer> mark06: resolving conflicts should not remove pending merge parents


[11:27] <oSoMoN> sil2100, hey, thunderbird 60.9.1 is FTBFS in {xenial,disco}-proposed because of a cargo bug (bug #1841191), I'm wondering if there's a way to do an express SRU for cargo with https://github.com/ehuss/cargo/commit/e46e185e4d007daa1a73f3e99e051d9ad039f5a6 ?
[15:11] <Odd_Bloke> mwhudson: https://bugs.launchpad.net/ubuntu/+source/distro-info/+bug/1727751
[16:54] <kanashiro> hi didrocks, I've been working on runc MIR and I'd like to do a similar thing you did in zsys MIR to identify a small set of deps embedded in the generated binary: https://bugs.launchpad.net/ubuntu/+source/zsys/+bug/1839271/comments/11
[16:54] <kanashiro> however, I am not able to reproduce what you did with zsys, to run 'go version -m zsysd' and get that output do I need to build it differently? or just use the binary shipped inside the .deb package should work?
[16:55] <kanashiro> I am using golang from focal-proposed (1.13)
[16:55] <didrocks> kanashiro: I didn't look yet with the package produced binary, but yeah, I know that the module versions are stripped out (probably some linker's flag). The result I'm showing is just running "go build" to build the binary directly
[17:02] <sil2100> oSoMoN: so, those thunderbird uploads - those are to go to -security as the others?
[17:08] <kanashiro> didrocks, sorry for the lack of golang knowledge but what is the exact command you use to build it? just "go build" from the root of the project directory is not generating the binary for me here
[17:09] <ahasenack> rbasak: haproxy is a sync, and we don't want to go beyond the 2.0.x line we are in now, as that is upstream's LTS line
[17:09] <ahasenack> rbasak: do you know how to put a block in place, if that's possible?
[17:11] <didrocks> kanashiro: go build in the binary directory you want to build should be enough. You can try to build all binaries in your project by go build ./... (if ofc, the project can be built directly, without a makefile doing magic)
[17:15] <kanashiro> didrocks, thanks, after entering the zsysd directory worked now :)
[17:15] <kanashiro> I got the same output you reported
[17:18] <didrocks> ;)
[17:22] <ddstreet> connor_k yep i opened lp #1850267 for that
[17:24] <oSoMoN> sil2100, no, those are normal SRUs, there's nothing qualifying them as a security update
[17:26] <connor_k> ddstreet, thank you!
[17:32] <ddstreet> connor_k do you have a n-m upload in progess you can attach the nm test fix to?  if not i can upload just the fix and add the 'block-proposed-bionic' tag to the bug
[17:33] <connor_k> ddstreet, no, I'm just interested in tracking that fix in particular for kernel autopkgtests since we try running n-m
[17:33] <ddstreet> ack, i'll go ahead and put it in the bionic upload queue then, thnx
[17:33] <infinity> oSoMoN, sil2100: Seems like a bit of a moot point when they don't build anyway?
[17:50] <rbasak> ahasenack: you mean in case Debian upload 2.1 to unstable?
[17:50] <rbasak> I'm not sure of a good mechanism :-/
[17:51] <ahasenack> rbasak: exactly
[17:51] <ahasenack> rbasak: because 2.1 is "stable" upstream, but is not an lts stable
[17:51] <rbasak> There is an autosync blacklist
[17:51] <rbasak> Or you could use "ubuntu" in the version number of an upload that is a fakesync
[17:51] <rbasak> Maybe fakesync is the wrong term
[17:52] <rbasak> I mean an upload that is identical to Debian but with an ubuntu1 changelog entry. That would stop an autosync and would have it appear in our merge report etc.
[17:52] <ahasenack> is that the usual? And who would know about the autosync blacklist mechanism?
[17:52] <ahasenack> the usual suspects? :)
[17:53] <rbasak> https://bazaar.launchpad.net/~ubuntu-archive/+junk/sync-blacklist/view/head:/sync-blacklist.txt is the sync blacklist
[17:53] <rbasak> I'm not sure there is a "usual"
[17:53] <rbasak> It's a reasonable enough thing to want though
[17:53] <rbasak> (freezing a specific package in advance of DebianImportFreeze)
[17:54] <rbasak> Given that we already do a merge report with analysis, maybe the sync blacklist is appropriate. We can always manually sync, and we won't miss new versions since our report will tell us.
[17:57] <ahasenack> I would want a new update of the 2.0.x series if it comes from debian, though
[17:58] <ahasenack> let me email ubuntu-devel
[17:59] <rbasak> We'd stop that in the merge report and manually sync it
[17:59] <rbasak> spot
[17:59] <sil2100> oSoMoN: I would say it should be possible to do that, i.e. the cargo SRU, but only of that small change and it would have to be linked in  the bug - and possibly with a separate cargo test-case if possible
[18:44] <oSoMoN> sil2100, that sounds good, I'll prepare the cargo SRUs first thing tomorrow morning then
[18:54] <sil2100> oSoMoN: thanks! Give me a ping once those are uploaded, I might find the cycles to get them in