[02:41] <idnar> -r ancestor::submit..
[02:41] <idnar> there's something visually fun about that
[02:43] <lifeless> :)
[02:43] <lifeless> almost perl in its elegance :P
[02:44] <idnar> although I think I actually just want bzr missing
[02:44] <fullermd> It really needs a pair of top-aligned dots at the beginning though.  Isn't that in Unicode somewhere?
[02:45] <idnar> haha
[02:46] <idnar> ¨::..
[02:46] <idnar> hmm, no
[02:46] <idnar> ··::..
[02:47] <idnar> someone else can write the patch to add it to the revisionspec syntax :P
[02:47] <fullermd> Alternate interpretation: "ancestor::submit.." would be a good title for a prog metal album.
[02:51] <bairui> hey, guys... on evaluating my repository layout needs for website development, a question arose regarding releases. We have a staging area (called XPT) from which successfully (accepted) builds become releases. What is a better strategy (repository-wise) with dealing with these releases? Should I have a single XPT branch from the trunk (created either way back when or at the first release) and as new
[02:51] <bairui> releases come, just merge them into XPT and tag the successful ones?   Or...   Create a new branch for each release?
[02:51] <mwhudson> fullermd: i like "Alternate interpretation: ancestor::submit.." actually
[02:54] <lifeless> bairui: both are fine
[02:54] <bairui> cool
[02:54] <fullermd> mwhudson: Could be a totally genre crossover.  Tracks include "Criss-cross merging the streams" and "-rdate:All Our Yesterdays".
[02:54] <bairui> tagging it is then, methinks
[02:54] <bairui> thanks, lifeless
[02:55] <mwhudson> fullermd: i like "Alternate interpretation: ancestor::submit.." actually
[02:55] <mwhudson> bah!
[02:55] <mwhudson> fullermd: :-p
[02:55] <fullermd> Maybe I should take that back.  It almost makes me look like some kinda nerd.
[05:15] <james_w> poolie, hi, did you change the crontab on jubany to send to canonical-bazaar?
[05:21] <james_w> poolie, if you did, it's bouncing
[05:21] <james_w> in fact, that's not conditional :-)
[05:21] <james_w> it is bouncing
[05:22] <james_w> "Relay access denied" from smtp.external
[06:07] <poolie> hi james_w; i did
[06:07] <poolie> shall i set it back to you?
[06:17] <poolie> i've donethat
[07:06] <vila> hi all !
[07:06] <vila> good evening poolie
[07:07] <vila> compiz: I don't what you're doing but t 2.5GB (3.7GB virtual), you're overdoing it
[07:07] <vila> I almost rebooted...
[07:09] <blackarchon> this wouldn't happen with KDE!
[07:10] <vila> :)
[07:10] <vila> famous last words ?
[07:11] <blackarchon> I call it the eternal truth!
[07:13] <AfC> KDE or GNOME3, works for me!
[07:13] <AfC> [I can't believe I just wrote that]
[07:15]  * gour stays with xfce
[07:16] <bairui> i just switched to xfce about a week or so ago
[07:16] <bairui> from awesome. I *liked* awesome... I just wanted to play with something shiny for a while.
[07:16] <jam> vila: unity --replace &;  Should fix it, I think.
[07:17] <jam> There are some memory leaks in compiz wrt app indicators
[07:17] <jam> bug #779717
[07:18] <gour> i'm just not sure i will be able to stay on freebsd seeing that DEs are becoming more & more linux-only
[07:18] <vila> jam: yeah, thanks, I've seen some earlier bugs and thought the issue was fixed...
[07:19] <vila> fullermd: ^ Imminent death of FreeBSD predicted ;)
[07:20] <vila> vila: stop it ! Enough noise already !
[07:20] <AfC> Replace Unity. Yes, that's an excellent idea.
[07:29] <zzz> Hi, is there any possibility to see the actual branches? Like git branch -a in git?
[07:30] <blackarchon> 'bzr branches' has just made it into trunk
[07:34] <vila> zzz: a bit more context may help answer your question
[07:34] <vila> zzz: branches map to directories by default
[07:36] <AfC> zzz: ie http://research.operationaldynamics.com/bzr/quill/ ; lots of Branches there; 'mainline' only one with a Working Tree in it.
[07:37] <gour> i like that hg doen't have 'main' line...but, well
[07:38] <gour> for me, greater problem is lp' lack of wiki & private repos (in comparison with bb)
[07:42] <vila> jelmer_: what's the status of bzr-svn with respect to bzr-2.4.0 ?
[07:42] <vila> jelmer_: no pressure intended et al, but, you know.. ;)
[07:50] <vila> jam: regarding bug #614713, you said 'reasonable to backport', how far should I target ? 2.0 ?
[08:27] <poolie> hi there vila, all
[08:28] <vila> jml: I've got a magic guesser but you won't be able to use it :) Good one ! (Joke aside, kudos for the neat pkgme-binary, that's the kind of magic I *love* !)
[08:28] <vila> hey poolie !
[08:30] <vila> poolie: I've run selftest -Econfig_stats | subunit-sum on bzr.dev.revnos[5982:6082] and your fdatasync raise interesting numbers
[08:30] <vila> s/sync/& stuff/
[08:30] <poolie> oh?
[08:31] <vila> since you cache the config we get a preview of what read/write once will achieve
[08:48] <vila> https://launchpad.net/bzr/+milestones
[08:48] <vila> list all the planned dates for the releases
[09:06] <jml> vila: thanks :)
[09:50] <poolie> jam, hi?
[09:50] <poolie> jml, hi
[09:52] <vila> Riddell: hey PP, can I ask for some reviews ? :D
[10:53] <vila> jam, jelmer, Riddell : ping
[10:53] <jelmer> vila!
[10:54] <vila> ha ! Someone ! :D
[10:54] <jelmer> uhoh, what did I volunteer for ? ;-)
[10:54] <vila> jelmer: how's going :)
[10:54] <vila> oh, nothing, just wanted to know are you were going on with bzr-svn and if you needed help there
[10:56] <jelmer> vila: alright so far, still working on tests
[10:56] <vila> \\o o// rock&roll !
[11:05] <jelmer> vila: :)
[11:07] <vila> If our beloved PP can shime in now... that would be so great ;)
[11:57] <vila> wow, almost felt into the 'pqm-is-broken' trap :) The progress does *not* work for 2.0 ...
[11:57] <vila> ohhh, and we run the test suite twice with [ascii] :)
[13:02] <vila> Riddell: Ping
[13:32] <briandealwis> jelmer: I have a local git repo.  With latest bzr.dev and bzr-git at tip, should I be able to use file:.../git-repo,branch=XXX to reference a particular git branch?
[13:32] <jelmer> briandealwis, yep
[13:33] <briandealwis> jelmer: I'm getting an error: "Not a branch: "/Users/bsd/Manumitting/Projects/e4/platform-ui-git": location is a repository.
[13:34] <briandealwis> jelmer: but branching without ",branch=XXX" works fine
[13:34] <jelmer> briandealwis, what does "BZR_DISABLE_PLUGINS=bzrtools bzr branches ../git-repo" say?
[13:36] <briandealwis> jelmer: no change
[13:37] <briandealwis> jelmer: sorry — I didn't fully read your message
[13:37] <briandealwis> jelmer: it just spits out 'master'
[13:38] <jelmer> briandealwis: does that match the output of "git branch" in that repo?
[13:38] <briandealwis> jelmer: yes — good catch.  Sorry for the confusion.
[13:39] <briandealwis> jelmer: do you think specifying 'origin/XXX' will work?  (There's a pile of origin/ branches listed with 'git branch -a'
[13:40] <jelmer> briandealwis, that should work, but you have to urlescape the / to prevent it from being interpreted as a path separator
[13:40] <jelmer> ,branch=origin%2Ffoo
[13:40] <jelmer> I realize that's not a very nice syntax, but it's a start
[13:40] <briandealwis> it makes complete sense
[13:41] <briandealwis> …though unfortunately origin%2Fxxx doesn't work — same location-is-a-repository
[13:42] <jelmer> actually, it needs to be
[13:42] <jelmer> ,ref=refs%2Fremotes%2Forigin%2Ffoo
[13:44] <briandealwis> nifty — but now I get a "ValueError: unable to map ref refs/remotes/origin/R4_development back to branch name".  Strangely there's only HEAD under .git/refs/remotes/origin/
[13:44] <briandealwis> I wodner where 'git branch -a' gets its info from then?
[13:45] <jelmer> briandealwis: ah, argh
[13:45] <jelmer> briandealwis: yeah, remotes are still problematic - can you file a bug?
[13:45] <briandealwis> ok
[13:46] <jelmer> briandealwis, git branch -a gets them from the packed refs file, which bzr-git will also be looking in
[13:47] <briandealwis> This is all great stuff, jelmer.
[13:47] <jelmer> briandealwis: now if only it actually worked.. :)
[13:53] <briandealwis> jelmer:  filed as bug 829481
[13:53] <jelmer> briandealwis, thanks!
[13:54] <briandealwis> jelmer: it's working great once I establish a local tracking branch
[14:03] <briandealwis> jelmer: the fix to bzr-git for avoiding rebuilding the git-map cache no longer triggers a rebuild.  thanks for that too!
[14:09] <vila> jelmer: thanks for the review !
[14:09] <vila> everybody: just thanks jelmer will you, it's just this time of day ;)
[14:12] <jelmer> briandealwis: great, thanks for confirming :)
[14:12] <jelmer> vila: hehe :)
[14:16] <vila> jelmer: any news from Riddell ?
[14:24] <jelmer> vila, haven't heard from him
[14:49] <vila> la la la, finally a trick to use pdb for blackbox tests \o/
[14:52] <jelmer> vila: ooh?
[14:52] <vila> http://paste.ubuntu.com/670131/
[14:53] <vila> I thought it was possible for... a long time, never tried. Stupid vila
[15:04] <vila> jelmer: and now https://code.launchpad.net/~vila/bzr/debug-blackbox-tests/+merge/72195
[15:07] <vila> great, merge proposals and bug numbers overlap... endless fun
[15:17] <jelmer> vila: it'd be great if BZR_TEST_PDB could support that too
[15:17] <fullermd> vila: Onoes!  BSD is dying again??   :(
[15:18] <vila> fullermd: hehe, wow, you've been away for long ;)
[15:19]  * vila just can't remember about BZR_TEST_PDB... time for some grepping
[15:19] <jelmer> fullermd, it's true, netcraft confirms it!
[15:20] <fullermd> Oh, I was worried for a second.  It's not REALLY official 'till it's on Wikipedia.
[15:21] <vila> jelmer: doesn't it work already ?
[15:21]  * vila tests
[15:22] <jelmer> vila: I'm not sure actually.. I just figured it wouldn't
[15:22] <vila> it seems to work but I'm not that familiar with post-mortem debug
[15:23] <vila> and before fullermd jumps his gun, yes, I prefer live debug ;)
[15:23] <fullermd> Ew.  Live bugs are creepy.
[15:24] <jelmer> fullermd: You have entomophobia and still manage to be a programmer?
[15:24] <vila> jelmer: right, looking at the implementation it's called far after stdin/stdout have been restored so N/A ?
[15:24] <fullermd> Well, it would be a problem if I were a _bad_ programmer.  Just gives me another reason to maintain my wonted perfection, see.
[15:25] <vila> fullermd: it's an acquired taste, I love bugs at breakfast
[15:25] <jelmer> heh, fair enough
[15:26] <jelmer> vila: that's a good point; so this means I should be using "from bzrlib import debug; debug.set_trace()" rather than importing from pdb?
[15:26] <vila> jelmer: yes
[15:26] <vila> well, at least with the proposed patch
[15:27] <vila> there may be a way to override the pdb.Pdb class directly, but I went with the simplest dirst
[15:27] <vila> first
[15:28] <jelmer> vila: this seems reasonable too
[15:29] <vila> thinking about it, may be I should just define set_trace in bzrlib including the pdb import... so we can just say bzrlib.debug()
[15:29] <vila> errr
[15:29] <vila> bzrlib.set_trace()
[15:30] <vila> jelmer: love/hate ?
[15:30] <jelmer> vila: in debug makes more sense to me
[15:30] <jelmer> and easier to find
[15:30] <jelmer> if we really care about not having to type that many characters, we should have ./bzr override pdb.Pdb
[15:31] <jelmer> IMO
[15:31] <vila> k
[15:32] <vila> on the other hand overiiding pdb.Pdb may be seen dev-hostile in same cases, bah, let's see what reviewers think, thanks for your feedback
[15:33] <lamalex> hi bzr, i'm trying to set up daily builds for the unity team. working on nux and when i run my recipe i get an error i dont understand, bzr: ERROR: No such tag: upstream-1.2.0t hooks - Stage 5/5
[15:33] <jelmer> lamalex, hi
[15:33] <vila> I like the existing ability to do self.debug() in tests (which triggered my typo above: bzrlib.debug())
[15:33] <lamalex> hello jelmer
[15:33] <jelmer> lamalex, it sounds like you're trying to build a non-native package but do not have a tag for the upstream tarball
[15:34] <jelmer> lamalex, since launchpad itself does not (yet) support non-native packages in recipes, I would recommend building with --allow-fallback-to-native
[15:34] <fullermd> Sounds like a double error actually, with it not clearing the line before giving the error.
[15:34] <lamalex> jelmer, what's a native vs non-native package? (i'm not a packager..)
[15:34] <lamalex> it's all C++ code..
[15:35] <jelmer> lamalex: http://wiki.debian.org/DebianMentorsFaq#What_is_the_difference_between_a_native_Debian_package_and_a_non-native_package.3F
[15:35] <lamalex> :)
[15:36] <jelmer> lamalex, in contrast to the answer on that FAQ, native packages often make more sense for daily builds
[15:36] <jelmer> lamalex: as upstream is going to change for each new upload, so there isn't much benefit in trying to reuse tarballs
[15:37] <lamalex> makes sense
[15:37]  * lamalex tries that flag
[19:03] <jml> mgz: I'm probably going to have some time for testtools hacking on the weekend. Am looking forward to seeing your stuff on assertThat.
[19:03] <jml> mgz: I don't want to nag. I very, very much appreciate your contributions. But I also want to release.
[19:04]  * jml goes
[19:05] <jelmer> maxb, btw, I did a subvertpy release
[19:05] <jelmer> jml: have a good weekend :)
[19:13] <etenil> Hi there
[19:14] <jelmer> hi
[19:15] <etenil> I'm working with the bzrlib, and I'm trying to make a formatter that turns a log into HTML, but the formatters seem to only be able to output to files (from the API anyway) and I'd need the output into a variable. Could someone help me?
[20:09] <mgz> blast, missed jml
[20:26] <Riddell> good evening
[20:27] <Riddell> sorry vila, I had a day off today
[20:27] <Riddell> are reviews still needed?
[20:28] <jelmer> 'evening Riddell
[20:28] <jelmer> I think there's still two open MPs
[20:35] <GRiD> hi Riddell  and/or jelmer, i'm waiting for proposal 70691. here if you want to talk about it.
[20:35] <Riddell> GRiD: got the full URL?
[20:36] <GRiD> https://code.launchpad.net/~weyrick/bzr/54624-warn-on-large-files/+merge/70691
[20:36] <GRiD> actually, i'm here as long as the approaching thunderstorm doesn't take out my power.
[20:36] <jelmer> g'evening GRiD
[20:37] <GRiD> howdy :)
[20:38] <GRiD> re: this proposal, i was thinking that if my final comment makes sense, i should probably make that functionality more explicit in the docs, and add a test for it
[20:39] <Riddell> GRiD: yes, I was just going to say that
[20:39] <GRiD> ok i'll add that, shouldn't take long.
[20:39] <Riddell> "add.maximum_file_size" why the dot in there?  bzr config options mostly don't use dots but some do and I'm not sure why
[20:41] <GRiD> if you look up in the comments a bit, that was one of the original suggestions from martin
[20:41] <GRiD> it seems that's a convention that's trying to be adopted
[20:44] <jelmer> yeah
[20:46] <jelmer> GRiD: I think this all looks ready to land
[20:47] <GRiD> awesome. let me just push these final doc changes and test
[20:48] <jelmer> GRiD, can you also add another newline above AddWithSkipLargeAction ?
[20:50] <GRiD> well now you're asking for a lot
[20:51] <jelmer> :D
[21:02] <GRiD> :) ok just pushed
[21:03] <jelmer> cool
[21:11] <Riddell> GRiD: lovely, approved, shall I sent it to PQM?
[21:12] <GRiD> very cool. uh, i don't know the next step, this is my first patch :)
[21:17] <Riddell> a good first patch :)
[21:17] <Riddell> next step is to ask the patch pilot (moi) to send it to PQM which is the programme that runs the test suite then merges it if it all works
[21:17] <Riddell> unfortunately pqm doesn't seem to want to work tonight "httplib2.ServerNotFoundError: Unable to find the server at api.launchpad.net"
[21:18] <Riddell> ah here we go
[21:19] <Riddell> GRiD: actually, could you add a release note too?
[21:19] <Riddell> needs an entry in doc/en/release-notes/bzr-2.5.txt
[21:19] <teratorn> hi, I'm trying to 'bzr merge', but bzr is failing to work because it complains about outstanding changes in the working directory. Which there are none, only the mistaken perception of changes; a bunch of files that have modes +x instead of -x presumably because this is on a Windows file system... how can I get unstuck?
[21:20] <Riddell> teratorn: does running bzr commit help ?
[21:20] <jelmer> teratorn: bzr revert should reset the entire tree, including the permission bits
[21:20] <Riddell> that's a better idea
[21:21] <teratorn> lets see
[21:21] <teratorn> I guess that works.... but how would it have gotten screwed up in the first place?
[21:22] <jelmer> teratorn: was there perhaps another branch you pulled in (and then reverted?) that touched the permissions bits?
[21:27] <teratorn> jelmer: I don't think so *shrug*
[21:28] <teratorn> btw, is there a fast-export/fast-import tool for bzr?
[21:30] <jelmer> teratorn, yep, there is a fastimport plugin
[21:31] <teratorn> yeah - I'm just checking it out now
[21:31] <jelmer> teratorn, I'm not sure what else could have caused the permission bits, I don't have a lot of experience using bzr on windows
[21:31] <GRiD> Riddell, ok thanks. I'll add the note
[21:45] <GRiD> Riddell, pushed, please take a look. tried to follow the existing format.
[21:54] <Riddell> GRiD: lovely, sent, it's in the queue at http://pqm.bazaar-vcs.org/
[21:54] <GRiD> great thanks :)
[21:55] <GRiD> i guess i should close the associated bug
[22:14] <GRiD> Riddell, shows a conflict in the release notes. do I have to do something?
[22:15] <Riddell> uh oh
[22:16] <Riddell> GRiD: merge in trunk and I'll send it again
[22:18] <elmo> does no one else find the bzr completions in zsh slow to the point of unusability ?
[22:19] <Riddell> they're slow to the point of unusability on bash too
[22:19] <elmo> Riddell: really?  bash works ok for me
[22:20] <elmo> I finally got annoyed enough to try bash
[22:20] <elmo> and was horrified to find it works there
[22:24] <mgz> elmo: have you seen contrib/zsh/README ?
[22:24] <mgz> my understanding is the new bash-completion plugin uses a more sensible method
[22:25] <mgz> it's certainly fast on my ancient laptop
[22:26] <GRiD> Riddell, ok i think i've merged ok
[22:26] <elmo> mgz: hmm, I hadn't thanks
[22:28] <mgz> GRiD: about your earlier question, unexpected merge conflicts are one reason I superstitiously wait for the pqm run to complete successfully before marking the bug fixed :)
[22:29] <mgz> so, elmo, I think `bzr shell-complete` is just slow, and zsh uses it while bash-completion doesn't.
[22:30] <GRiD> mgz, agreed, i actually did wait ... :)
[23:08] <bairui> elmo: did you find the problem? I think my bzr zsh setup is woeful too. :-(
[23:09] <elmo> bairui: I'm sure what mgz said is likely the problem - unfortunately I don't know enough zsh to be able to use the information to fix it
[23:10] <bairui> ok, but I don't even understand what he said - where is contrib/zsh/README ? whose contrib is that? bzr's? where is that? I did a locate and came up dry... :-?
[23:13] <bairui> oops... I didn't read his final word on the matter. :)
[23:15] <fullermd> Yes, it's right in the bzr tree.
[23:15] <bairui> you guys *have* a bzr tree :)
[23:16] <fullermd> We what?  Of course not.  What kind of nerds do you take us for?
[23:16] <bairui> heh - it's just that at this party... I'm a lesser nerd :-/
[23:16] <fullermd> In my youth, I tried that once.  It was an embarassing failure.
[23:16] <bairui> lol
[23:17] <fullermd> Now I just strive instead to be _massively_ more nerdy than anyone else.  That way, any references or jokes I make are so far out nobody even notices that I tried, so the end result is that I seem more normal.
[23:17] <fullermd> ...  that's my theory, anyway.
[23:19] <bairui> good blending strategy - at nerd parties
[23:21] <fullermd> There's...  some other kind?
[23:22] <bairui> heh - no. not fun ones, anyway.
[23:22] <bairui> so, without being able to read said README, what are my zsh bzr completion options? suck it up and wait? or is there a super-magic fix? or... use bash? :-(
[23:23] <fullermd> You can just read the README online y'know   ;p
[23:24] <fullermd> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/view/head:/contrib/zsh/README
[23:24] <bairui> thanks, fullermd :D
[23:24] <fullermd> It's even more fun that way too, 'cuz it looks like loggerhead is trying to syntax highlight the README as if it were python...
[23:25] <bairui> yes... a bit unfortunate.
[23:25] <fullermd> Of course, the Right Answer is obviously to just use tcsh, like all smart attractive people do.
[23:25] <bairui> so, fullermd, you're on zsh too, eh?
[23:26]  * fullermd looks around for a stick.
[23:26] <bairui> heh :D
[23:26] <fullermd> I had a professor once who kept a 2x4 by his desk, with "Board Of Education" stenciled on it.
[23:26] <fullermd> He threatened to use it with some regularity.
[23:27] <bairui> the Clue Stick!
[23:27] <bairui> we had a senior at uni with a wiffle (sp?) bat that he'd wield in the labs. It was his Clue Stick
[23:58] <idnar> hmm
[23:58] <idnar> is there an easy way to reorder pipes?


[07:01] <hyperair> smspillaz: is unity supposed to use the command name, or the name from the desktop file for its tooltips?
[07:02] <hyperair> https://bugs.launchpad.net/bugs/694280 this seems to show unity using the name of the bianry
[07:02] <ubot5`> Ubuntu bug 694280 in banshee (Ubuntu) "in unity sidebar banshee name is banshee-1" [Undecided,New]
[07:02] <hyperair> binary*
[07:51] <smspillaz> hyperair: I don't know
[08:19] <hyperair> hmm oh well
[15:03] <seiflotfy> hey guys
[15:03] <seiflotfy> gord, or kenvandine_ ?
[15:03] <seiflotfy> u guys there?
[15:15] <OmegaYear> Anyone going to 27c3?
[16:45] <OmegaYear> http://www.newscientist.com/blogs/nstv/2010/12/best-videos-of-2010-progress-bar-illusion.html
[16:45] <OmegaYear> Interesting.
[16:48] <coz_> OmegaYear,  yep any graphics  progress bar or otherwise  ..has a major impact  on the eye and perception  for sure
[18:07] <lamlex> Is there a utouch itc?
[18:07] <lamlex> irc
[19:24] <lamalex> unity keeps losing my decorations
[19:26] <vish> lamalex: well, Christmas is over.. so not a huge issue i guess ;)
[19:46] <seiflotfy> lamalex, do u have an idea if there are wncksync or bamf python bindings
[19:46] <seiflotfy> or are there dbus bindings for it
[19:47] <lamalex> wncksync is dead afaik
[19:47] <lamalex> I think there are bamf bindings but I don't really know
[23:14] <lamalex> DBO, my man what up
[23:14] <DBO> eatin turkey
[23:15] <lamalex> nice
[23:15] <lamalex> have a good christmas?
[23:17] <lamalex> DBO, have you ever tried doing dualhead on your macbook?
[23:17] <DBO> yes I have tried that
[23:17] <DBO> it works
[23:17] <lamalex> nice
[23:18] <lamalex> with compiz/unity?


[01:09] <Cohort> hi :) where do i edit my qtcurve theme kin kubuntu 22.04
[01:14] <Cohort> under application style there should be an option for qtcurve but there is not
[01:19] <Cohort> used to be able to super customize that
[01:25] <Cohort> yeah, i don't see it anyplace x.x
[03:21] <RobinHood23> I don't have HDMI as an option in my list of audio devices -- how do I fix this?
[03:39] <sildara> Yowww I just reinstalled with a disk encryption
[03:40] <sildara> How do I search for channels?
[03:40] <sildara> #linux
[08:03] <hateball> Hello, I have an annoying Wayland / XWayland issue, would this be the correct place to ask about such a thing ?
[08:06] <hateball> Anyways, the issue is that I run plasma on Wayland with AMD GPU. I have both an iGPU (ryzen 7700x) and dGPU (7900 XTX). I only have a monitor connected to the dGPU. Whenever the monitor goes into powersave and I wake it up again, it is like anything running under xwayland eg Steam starts using the iGPU for rendering, so the performance goes out the window. Anything running under native wayland keeps working as it should. I have to reboot to get xwayland
[08:06] <hateball> / Steam to behave.
[08:07] <hateball> So I am just trying to find out if there is a way to force xwayland to always use the dGPU, but I am not having much luck
[08:10] <hateball> ... if that's the actual issue. I just know there is an issue :D
 KDE XWayland Video Bridge Aims To Improve Linux Desktop Screen Sharing - Phoronix
 https://www.phoronix.com/news/KDE-XWaylandVideoBridge
[08:54] <fairyfloss> Hi!
[08:56] <hateball> Hello fairyfloss
[08:57] <fairyfloss> haya
[08:57] <fairyfloss> Any kubuntu master around?
[08:59] <fairyfloss> was looking for a solution to Appearance > Applications Styles issue from a stock kubuntu install
[09:05] <fairyfloss> :/
[09:21] <hateball> :(
[09:30] <hateball> fairyfloss: What is the issue ?
[09:36] <fairyfloss> @hateball, https://askubuntu.com/questions/1445251/kubuntu-plasma-global-theme-doesnt-change-the-application-style
[09:37] <fairyfloss> so the Plasma Global Theme does not add any Applications Styles to the selection panel.
[09:38] <fairyfloss> https://i.imgur.com/XGw1gmB.png
[09:41] <fairyfloss> ive tested the plasma on Mint and it run like a charm. So i presume the plasma wants to interact only with GNOME native Styles only? and does not want to take any other styles on list?
[09:44] <hateball> This seems to work as expected for me, if I am understanding you correctly. I go into settings for the global theme, and in my case I choose Breeze Dark. But I can then also go into Application Styles and choose something different and hit apply
[09:45] <hateball> Ah you download a new theme, gotcha
[09:46] <fairyfloss> yea.
[09:47] <hateball> I mean... perhaps the new themes do not include new Application Styles?
[09:47] <fairyfloss> yup
[09:47] <fairyfloss> they dont appear on the Applications style selection
[09:48] <hateball> Yes I understand, but are you sure that Application Styles are actually included with the selected theme?
[09:51] <fairyfloss> i believe yes,. because when i hit the Configure GNOME/GTK Applications Style button i can see the GTK theme selections has a quite a list of my downloaded styles.
[09:51] <hateball> Yes but Qt and GTK styles are different so maybe Qt style is not included
[09:51] <fairyfloss> or thats something entirely different ?
[09:52] <hateball> Anyway I do not know enough about this, I just set it to Breeze Dark and that's enough for me :D
[09:52] <hateball> Someone else may know better
[09:52] <fairyfloss> hmm... ok so for kubuntu i have to search specifically qt Application styles?
[09:52] <fairyfloss> thats pretty fcuked up then
[09:53] <hateball> Well Plasma is Qt based
[09:53] <fairyfloss> right
[09:53] <hateball> GTK themes would only apply to GTK apps such as GIMP
[09:53] <hateball> Whereas Qt theme would apply to say... Kate, Quassel etc
[09:53] <fairyfloss> and so by the general search there are only 8 styles
[09:53] <fairyfloss> lol
[09:54] <fairyfloss> that still gives errors to users
[09:55] <fairyfloss> but how come the styles appear on linux mint or other distros o0
[09:55] <fairyfloss> that are gnome ? o0
[09:56] <hateball> iirc Linux Mint uses Cinnamon which is GTK
[09:59] <fairyfloss> so whats the problem with kubuntu - plasma accepting the application styles on the list? o0
[10:00] <fairyfloss> https://i.imgur.com/sHgHXwB.png
[10:03] <fairyfloss> only one thing that can be selected but i think thats not an general theme style ?
[10:04] <hateball> fairyfloss: no that is just for GTK apps like I said, so eg GIMP
[10:04] <fairyfloss> yeah
[10:04] <fairyfloss> thought so.
[10:19] <Sildara> Hey, my global themes don't seem to work
[10:19] <fairyfloss> i mean yea,. so usually the application styles comes with them. but i dont have any general styles at all.
[10:20] <fairyfloss> aha! @Sildara !
[10:20] <fairyfloss> The same story here!
[10:20] <Sildara> Same issue? ahaha
[10:20] <Sildara> No transparency or blur, nada
[10:20] <fairyfloss> yup ^^ already have tested with two stock kubuntu installations
[10:20] <Sildara> Try to configure which parts to customise, I choose al, application styles unchecks itself and it makes barely any alterations
[10:21] <Sildara> Maybe a bug?
[10:21] <fairyfloss> even not appearing on the Application Styles  list
[10:22] <Sildara> You running KDE plasma?
[10:22] <fairyfloss> yes
[10:22] <Sildara> Yeah same
[10:23] <Sildara> I wonder if it's a distro issue or a desktop environment issue
[10:23] <fairyfloss> id say thats in distro to accept the plasma application style
[10:32] <fairyfloss> this is truly an disturbing bug in the core plasma kde
[12:48] <BluesKaj> Hi all
[12:53] <hateball> Hello hello
 hey , i m removing lots of things from kubuntu like whole snapd ,few packages like wine ,
 but i m scared to reboot , because if somthing important i removed by mistake ,it wont boot up
 anyway , going to reboot
[18:40] <kamil441> Так
 ??
[18:40] <kamil441> Hello?
[18:40] <kamil441> Who knows what is i'm open right now?
[18:42] <kamil441> Well goodby then
[22:01] <Guest60> hello
[22:26] <r_m_m> Hi


[08:53] <xnox> luna:  is everything ok?
[08:53] <xnox> luna:  do you need to talk to someone?
[09:09] <luna> not really and not really
[09:22] <sil2100> xnox: hm, do you know if vorlon had any other concerns about the slow-phasing of grub and shim?
[09:23] <sil2100> Since his earlier comments confused me and now I don't know if I really should merge it or not
[09:59] <xnox> sil2100:  hm, yeah, that.
[09:59] <xnox> vorlon:  are we wrong, or are we wrong?
[10:25] <juliank> We need to implement phasing groups to get sensible phasing of signed artefacts and their related packages
[10:27] <juliank> Oh that is hard, it needs to be - for shim-signed - Phased-Update-Group: shim (= ${shim:Source-Version})
[10:27] <juliank> because we phase both on name and version
[13:24] -queuebot:#ubuntu-release- Unapproved: ovn-octavia-provider (hirsute-proposed/main) [0.3.1+git2020121115.b882a7f-0ubuntu1 => 1.0.0-0ubuntu1] (openstack)
[13:30] -queuebot:#ubuntu-release- Unapproved: cinder (focal-proposed/main) [2:16.2.1-0ubuntu2 => 2:16.3.0-0ubuntu1] (openstack, ubuntu-server)
[13:30] -queuebot:#ubuntu-release- Unapproved: neutron (focal-proposed/main) [2:16.3.0-0ubuntu3 => 2:16.3.1-0ubuntu1] (openstack, ubuntu-server)
[13:30] -queuebot:#ubuntu-release- Unapproved: horizon (focal-proposed/main) [3:18.3.2-0ubuntu<IP_ADDRESS> => 3:18.3.3-0ubuntu1] (openstack, ubuntu-server)
[13:30] -queuebot:#ubuntu-release- Unapproved: nova (focal-proposed/main) [2:21.1.2-0ubuntu2 => 2:21.2.0-0ubuntu1] (openstack, ubuntu-server)
[13:49] -queuebot:#ubuntu-release- Unapproved: pyyaml (hirsute-proposed/main) [5.3.1-3build1 => 5.3.1-3ubuntu1] (core, i386-whitelist)
[14:07] -queuebot:#ubuntu-release- Unapproved: accepted ovn-octavia-provider [source] (hirsute-proposed) [1.0.0-0ubuntu1]
[14:08] -queuebot:#ubuntu-release- Unapproved: accepted pyyaml [source] (hirsute-proposed) [5.3.1-3ubuntu1]
[14:53] -queuebot:#ubuntu-release- Unapproved: u-boot-menu (hirsute-proposed/main) [4.0.2ubuntu3 => 4.0.2ubuntu4] (core)
[14:55] <xnox> bdmurray: ^^^ should fix booting riscv64 images in qemu
[14:55] <xnox> kernel in proposed should fix booting unmatched
[14:56] <xnox> not sure what we still need to fix unleashed.
[14:59] <jamespage> please could the earlier of the two uploads for ceph to bionic UNAPPROVED be rejected please
[14:59] <jamespage> .orig got into the mix somehow
[15:00] -queuebot:#ubuntu-release- Unapproved: ceph (bionic-proposed/main) [12.2.13-0ubuntu<IP_ADDRESS> => 12.2.13-0ubuntu<IP_ADDRESS>] (desktop-core, ubuntu-server)
[15:01] -queuebot:#ubuntu-release- Unapproved: neutron (hirsute-proposed/main) [2:18.0.0~rc2-0ubuntu1 => 2:18.0.0~rc2-0ubuntu2] (openstack)
[15:06] <vorlon> xnox, sil2100: I have no problem with merging the slow-phasing change but I don't feel strongly either way
[15:19] <xnox> tah
[15:19] <xnox> sil2100:  vorlon: accepting u-boot-menu would be nice.
[15:21] <sil2100> o/
[15:23] <sil2100> xnox: ok, I don't know this piece of code so just asking for clarification: this code path is not depended on and used by non-riscv u-boot targets?
[15:32] <sil2100> I'll assume that's the case
[15:33] -queuebot:#ubuntu-release- Unapproved: accepted network-manager [source] (hirsute-proposed) [1.30.0-1ubuntu3]
[15:33] -queuebot:#ubuntu-release- Unapproved: accepted u-boot-menu [source] (hirsute-proposed) [4.0.2ubuntu4]
[15:38] <xnox> sil2100:  nobody in ubuntu uses u-boot-menu =) and fdtdir was introduced in hirsute only; and now removed => it has never worked on Ubuntu before.
[15:39] <xnox> (because the debian's paths are used, which are not the ones ubuntu's kernel ship) So i'm reverting to how things were in groovy & focal.
[16:07]  * Laney tries running an autopkgtest from prod-proposed-migration *eek*
[16:08] <sil2100> o/
[16:08] <sil2100> xnox: that's what I wanted to hear!
[16:15] <sil2100> vorlon, xnox: confirmed that the phasing is smart and auto-updates before phasing
[16:15] <sil2100> Releasing grubz for groovy
[16:17] <xnox> sil2100:  all three of them =) and hopefully launchpad copy will work this time around....
[16:23] <sil2100> Ok, got 3 messages so I guess the copies worked!
[16:26] <xnox> sil2100:  looking good!
[16:44] <cjwatson> Switching the Ubuntu publisher over to Python 3 (in a short while once the deployment finishes).  Hopefully this will be a non-event but mentioning it here just in case ...
[16:45] <juliank> nice
[16:46] <Laney> ooh, what an exciting event!
[16:48] <cjwatson> Somebody should port lp:ubuntu-archive-publishing at some point too
[16:49] <cjwatson> Hm, deployment failed at the push stage, so maybe not so exciting ;-)
[16:56] <sil2100> :(
[16:58] <cjwatson> Back to the drawing board I suppose
[17:08] <Laney><EMAIL_ADDRESS>[17:08] <Laney> couple of bumps but there, that's the first run in the new environment
[17:08] <Laney> requires you to add "<IP_ADDRESS>  autopkgtest.ubuntu.com" to /etc/hosts :-)
[17:09] <Laney> (obviously don't keep that there)
[17:13] -queuebot:#ubuntu-release- Unapproved: pikepdf (hirsute-proposed/universe) [1.17.3+dfsg-4ubuntu1 => 1.17.3+dfsg-5ubuntu1] (ubuntustudio)
[17:16] -queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (hirsute-proposed) [2:18.0.0~rc2-0ubuntu2]
[17:16] -queuebot:#ubuntu-release- Unapproved: rejected pikepdf [source] (hirsute-proposed) [1.17.3+dfsg-5ubuntu1]
[17:17] -queuebot:#ubuntu-release- Unapproved: pikepdf (hirsute-proposed/universe) [1.17.3+dfsg-4ubuntu1 => 1.17.3+dfsg-5ubuntu1] (ubuntustudio)
[17:30] -queuebot:#ubuntu-release- New: rejected libegl-mali-xlnx [sync] (hirsute-proposed) [9p0.01rel0-0ubuntu4]
[17:30] -queuebot:#ubuntu-release- New: rejected linux-firmware-xilinx-vcu [sync] (hirsute-proposed) [2020.2-0ubuntu0xlnx2]
[17:33] -queuebot:#ubuntu-release- New sync: libegl-mali-xlnx (hirsute-proposed/primary) [9p0.01rel0-0ubuntu5]
[17:34] -queuebot:#ubuntu-release- New sync: linux-firmware-xilinx-vcu (hirsute-proposed/primary) [2020.2-0ubuntu1]
[17:34] -queuebot:#ubuntu-release- New: accepted libegl-mali-xlnx [sync] (hirsute-proposed) [9p0.01rel0-0ubuntu5]
[17:34] -queuebot:#ubuntu-release- New: accepted linux-firmware-xilinx-vcu [sync] (hirsute-proposed) [2020.2-0ubuntu1]
[17:40] <doko> Laney, juliank: why does "suddently" (today) gimp-plugin-registry show up as a failing autopkg test triggered by python3-defaults? it didn't show up for the past five days ...
[17:40] <juliank> Did somebody retry it?
[17:41] -queuebot:#ubuntu-release- Unapproved: apport (hirsute-proposed/main) [2.20.11-0ubuntu62 => 2.20.11-0ubuntu63] (core, i386-whitelist)
[17:42] <bdmurray> ^- sil2100 that's just disabling crash reporting
[17:43] <doko> it was triggered by the imagemagick upload, but not for python3-defaults
[17:46] <sil2100> Looking
[17:49] <juliank> doko: ADT_TEST_TRIGGERS=python3-defaults/3.9.4-1 gnome-gmail/2.7-2 jupyterlab-pygments/0.1.2-5 keras/2.3.1+dfsg-3 lazygal/0.10.2-1 libflame/5.2.0-3ubuntu2 link-grammar/5.8.1-1 mpi4py/3.0.3-8 nodejs/12.21.0~dfsg-3ubuntu1 numpy/1:1.19.5-1ubuntu2 python-djvulibre/0.8.4-3build3 python3-proselint/0.10.2-2 python3-stdlib-extensions/3.9.4-0ubuntu1 python3.9/3.9.4-1 resfinder/3.2-2
[17:49] <juliank> restrictedpython/4.0~b3-2 sabnzbdplus/3.1.1+dfsg-2 systemfixtures/0.6.4-2 udisks2/2.9.2-1 ufw/0.36-7.1 virulencefinder/2.0.3+git20190809.dde157a-2'
[17:49] -queuebot:#ubuntu-release- New binary: libegl-mali-xlnx [arm64] (hirsute-proposed/none) [9p0.01rel0-0ubuntu5] (no packageset)
[17:49] -queuebot:#ubuntu-release- New binary: linux-firmware-xilinx-vcu [amd64] (hirsute-proposed/none) [2020.2-0ubuntu1] (no packageset)
[17:49] <juliank> doko: The trigger expansion added a python3-defaults trigger to it
[17:49] <juliank> presumably
[17:49] -queuebot:#ubuntu-release- Unapproved: accepted apport [source] (hirsute-proposed) [2.20.11-0ubuntu63]
[17:49] <sil2100> hm, ok, gnome-sudoku seems
[17:50] <sil2100> seems not-really-featurish indeed
[17:50] -queuebot:#ubuntu-release- Unapproved: accepted pikepdf [source] (hirsute-proposed) [1.17.3+dfsg-5ubuntu1]
[17:50] <sil2100> Though there were some modal dialogs added, but hm hm
[17:50] <juliank> doko: hmm but that test failed 5 days ago
[17:50] -queuebot:#ubuntu-release- Unapproved: accepted gnome-sudoku [sync] (hirsute-proposed) [1:40.0-1]
[17:51] <juliank> doko: are you sure britney did not report issues before?
[17:51] <juliank> did it forget to fetch results and got them now that it got triggered again?
[17:51] <juliank> I don't know how it fetches
[17:52] <juliank> In any case, the failure seems to be correct :D
[17:52] <doko> juliank: pretty sure, because we assigned the issues last Thu in Foundations meeting, and it didn't show up there, and I remember that r-cran-irkernel was the only one remaining this morning
[17:53] <juliank> do we have output from previous britney runs around?
[17:53] <doko> yeah, tried to find that, but apparently not
[17:54] -queuebot:#ubuntu-release- New: accepted libegl-mali-xlnx [arm64] (hirsute-proposed) [9p0.01rel0-0ubuntu5]
[17:54] -queuebot:#ubuntu-release- New: accepted linux-firmware-xilinx-vcu [amd64] (hirsute-proposed) [2020.2-0ubuntu1]
[17:56] <juliank> doko: It certainly saw that gimp-plugin-registry failed yesterday: https://people.canonical.com/~ubuntu-archive/proposed-migration/log/hirsute/2021-04-11/19:58:18.log
[17:56] <juliank> Checking for new results for failed gimp-plugin-registry/ppc64el for trigger python3-defaults/3.9.4-1
[17:56] <juliank> but that's at I: [2021-04-11T21:01:55+0000] - Checking for new results for failed gimp-plugin-registry/ppc64el for trigger python3-defaults/3.9.4-1
[17:57] <juliank> but earlier too: I: [2021-04-11T02:03:48+0000] - Checking for new results for failed gimp-plugin-registry/amd64 for trigger python3-defaults/3.9.4-1
[17:57] <doko> anyway, I'll retry
[18:00] -queuebot:#ubuntu-release- Unapproved: lightdm (groovy-proposed/universe) [1.30.0-0ubuntu3.1 => 1.30.0-0ubuntu4~20.10.1] (ubuntu-budgie, ubuntu-mate, ubuntukylin, xubuntu)
[18:01] -queuebot:#ubuntu-release- Unapproved: lightdm (focal-proposed/universe) [1.30.0-0ubuntu3.1 => 1.30.0-0ubuntu4~20.04.1] (edubuntu, ubuntu-budgie, ubuntu-mate, ubuntukylin, ubuntustudio, xubuntu)
[18:06] -queuebot:#ubuntu-release- Unapproved: python-os-brick (hirsute-proposed/main) [4.3.1-0ubuntu1 => 4.3.1-0ubuntu2] (openstack)
[18:17] -queuebot:#ubuntu-release- Unapproved: file-roller (hirsute-proposed/main) [3.38.0-1 => 3.38.1-1] (ubuntu-desktop) (sync)
[18:18] -queuebot:#ubuntu-release- Unapproved: seahorse (hirsute-proposed/main) [40~alpha-1 => 40.0-1] (ubuntu-desktop) (sync)
[18:20] -queuebot:#ubuntu-release- Unapproved: accepted python-os-brick [source] (hirsute-proposed) [4.3.1-0ubuntu2]
[18:31] -queuebot:#ubuntu-release- Packageset: Added lg-gpio to raspi in hirsute
[18:31] -queuebot:#ubuntu-release- Packageset: Added linux-firmware-raspi2 to raspi in hirsute
[18:31] -queuebot:#ubuntu-release- Packageset: Added pi-bluetooth to raspi in hirsute
[18:31] -queuebot:#ubuntu-release- Packageset: Added raspberrypi-userland to raspi in hirsute
[18:31] -queuebot:#ubuntu-release- Packageset: Added rpi-eeprom to raspi in hirsute
[19:34] -queuebot:#ubuntu-release- Unapproved: python-manilaclient (hirsute-proposed/main) [2.5.0-0ubuntu1 => 2.6.0-0ubuntu1] (openstack)
[19:37] -queuebot:#ubuntu-release- Unapproved: python-monascaclient (hirsute-proposed/main) [2.2.1-0ubuntu1 => 2.3.0-0ubuntu1] (openstack)
[19:41] -queuebot:#ubuntu-release- Unapproved: python-novaclient (hirsute-proposed/main) [2:17.2.1-0ubuntu1 => 2:17.4.0-0ubuntu1] (openstack)
[19:43] -queuebot:#ubuntu-release- Unapproved: python-octaviaclient (hirsute-proposed/main) [2.2.0-0ubuntu1 => 2.3.0-0ubuntu1] (openstack)
[20:05] -queuebot:#ubuntu-release- Unapproved: python-openstackclient (hirsute-proposed/main) [5.4.0-0ubuntu1 => 5.5.0-0ubuntu1] (openstack)
[20:16] -queuebot:#ubuntu-release- Unapproved: rejected openvswitch [source] (groovy-proposed) [2.13.3-0ubuntu<IP_ADDRESS>]
[21:17] -queuebot:#ubuntu-release- Unapproved: python-ovsdbapp (groovy-proposed/main) [1.5.0-0ubuntu1 => 1.5.0-0ubuntu2] (openstack)
[21:21] -queuebot:#ubuntu-release- Unapproved: python-ovsdbapp (focal-proposed/main) [1.1.0-0ubuntu1 => 1.1.0-0ubuntu2] (ubuntu-server)
[22:39] -queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (hirsute-proposed/main) [1:21.04.7 => 1:21.04.8] (core)
[23:43] <vorlon> bdmurray: your hirsute upload of ubuntu-release-upgrader includes changes to DistUpgrade/apt_btrfs_snapshot.py not mentioned in the changelog?
[23:45] <vorlon> bdmurray: ah, is DistUpgrade/ from a different source and vendorized? that rings a bell


[01:02] <Fudge> no themuso AlanBell?
[11:04] <AlanBell> hi Fudge
[11:05] <AlanBell> I expect themuso is off for the holidays
[23:06] <Fudge> I am looking forward to trying mythspeech


[17:52] <mup> Bug # changed: 1815084, 1923867, 1923871, 1925784
[20:37] <mup> Bug #1926510 opened: dhcp subnet snippets are NOT inside the pool block <MAAS:New> <https://launchpad.net/bugs/1926510>
[22:32] <maratg> Hello. I'm trying to find out if there is a way to "manually" set a node as "Deployed". I had a node released accidentally - our maas is not setup to erase on release, so i was able to set the power state back to "On" and all the services on the node were intact. But I would like to get it back into deployed state and "lock" it.


[00:03] <tsimonq2> guiverc: Hey, so for bug 1922342 I saw your note in the QA tracker. Have you tested with this machine before? (Is this a recent bug/does it show on Jammy?)
[00:03] -ubottu:#lubuntu-devel- Bug 1922342 in casper (Ubuntu Kinetic) "Impish live session takes ages to boot on BIOS systems" [High, Fix Released] https://launchpad.net/bugs/1922342
[00:04] <tsimonq2> !standuo
[00:04] <tsimonq2> !standup
[00:04] <tsimonq2> This is my one hour "last call" for any RC bugs or *anything* someone has noticed that's off. I'm all ears.
[00:04] <tsimonq2> At 1:00 UTC I'm marking us as ready.
[00:05] <guiverc> I have no concerns about us being ready; so ack to ready
[00:06] <guiverc> the 1922342 has occurred since mid-groovy cycle on a unmodified ISO; its expected...
[00:06] <guiverc> it's not Lubuntu ISOs specific; but all flavor & Ubuntu Desktop too
[01:45] -queuebot:#lubuntu-devel- Builds: Lubuntu Desktop amd64 [Mantic Final] has been marked as ready
 That's just a running joke at this point
[08:16] -queuebot:#lubuntu-devel- Builds: Upgrade Lubuntu amd64 [Mantic Final] has been marked as ready
[08:17] -queuebot:#lubuntu-devel- Builds: Upgrade Lubuntu amd64 [Mantic Final] has been updated (20231009)
[08:41] <guiverc> it's getting dark outside, not much day left (for me anyway) :)
[08:45] <guiverc> most days anyway yeah ; overcast & loads of rain today locally (& I got drenched)
 Welcome Michael !
 @utkarsh2102 Hey! I'm on the road today, if you have anything for me feel free to relay it here :)

 Also, when we have a codename, let me know immediately please (here or PM if still embargoed) so I can do my usual debootstrap / lintian / vim / devscripts / cala uploads immediately :)
 Hello! Yes, absolutely, will do! (re @tsimonq2: @utkarsh2102 Hey! I'm on the road today, if you have anything for me feel free to relay it here :)

 Also, when we have a codename, let me know immediately please (here or PM if still embargoed) so I can do my usual debootstrap / lintian / vim / devscripts / cala uploads immediately :))
 Thanks! Happy Release Day!! (re @utkarsh2102: Hello! Yes, absolutely, will do!)
 You, too! ^.^ (re @tsimonq2: Thanks! Happy Release Day!!)
[13:28] <tsimonq2> Updated the release announcement.
[13:29] <tsimonq2> I see ISOs, so pushing to social media.
[14:48] <Eickmeyer> tsimonq2: You don't wait for the OK from the release team?
[14:48] <Eickmeyer> (consisting of the official release email)
[14:51] <Eickmeyer> Reason being: just because the isos are there, doesn't mean the mirrors have all synced yet.
 FYI: email server that is handling our Discourse mail and other stuff is being fubar right now for Microsoft-destined recipients (tsimonq2 and myself included) because MIcrosoft has blocked the VPS provider's networks.  I opened a high priority ticket with the provider to get them in touch with Microsoft.
 This explains our discourse email crap we've observed in the past year
 I also have the same problem :( (re @teward001: FYI: email server that is handling our Discourse mail and other stuff is being fubar right now for Microsoft-destined recipients (tsimonq2 and myself included) because MIcrosoft has blocked the VPS provider's networks.  I opened a high priority ticket with the provider to get them in touch with Microsoft.)
 remind me what your address is again (re @Roberalz: I also have the same problem :()
 because if it's yahoo or a free mail provider i can't do shit about it
 and yeah apologies about swears
 i'm grumpy
 Is a Outlook address
 that's a Microsoft destined recipient
 hotmail, msn, outlook, etc. are included in the same notice
 I know :)
 Thanks @teward001
 so are the other complainers.  However, Microsoft until *recently* just silently dropped without errors
 so that's been changed in the recent timeframe so
 I just hate email, does that count for complaining. :P
 VPS provider indicated they have zero luck getting their entire range unblocked, but have had luck with specific IPs so.
 welcome to IT Security 101 - Email Sucks (re @kc2bez: I just hate email, does that count for complaining. :P)
 Indeed.
 i'm going to be yoinking data out anyways, and replacing some mail server stuffs.
 I usually get the discourse stuff though.
 ye unless you're on a Microsoft provider (MS365 tenant, etc.) it breaks
 because blocklists.  Which hopefully we'll be able to get *these* systems i use for the SMTP off that chaos
[17:45] <tomreyn> hey, just a quick note - you probably got this on your list, though: https://manual.lubuntu.me/stable/1/1.1/retrieving_the_image.html currently points to 23.04
 tomreyn yes I am working on updating that for 23.10 right now release annoucment came kinda early in the morning for me as I am on the west coast of usa
[17:47] <tomreyn> great (the first part) :)
 @kc2bez and others: https://discourse.lubuntu.me/t/notice-known-issue-with-emails-used-for-account-sign-ups-on-this-discourse - globally pinned for now until this email issue is resolved
 Also should be done now. The checksum part means I need to know what the final version is with all changes and usually means I have to add that on release day
[21:11] <tsimonq2> Eickmeyer: I mean, yeah, you're 100% right.
[21:11] <tsimonq2> Eickmeyer: My "release day" checklist from memory is obviously outdated. :P
[21:12] <tsimonq2> Eickmeyer: Also, nice, if Ubuntu Studio gets to outline Calamares' flaws in its release announcement, I accept it as a personal challenge to respond in our next release announcement with "we did all that, and better" ;)
[21:13] <Eickmeyer> tsimonq2: Those were literal bug reports we got.
[21:13] <tsimonq2> Eickmeyer: I know, I know. Doesn't mean I won't take the bait XD
[21:14] <tsimonq2> (To be clear to any backlog readers, I consider Eickmeyer a friend and 100% know it's not a dig, I just enjoy giving him crap. ;) )
[21:14] <Eickmeyer> ^ A little too much. :P
[21:15] <Eickmeyer> XD
[21:15] <tsimonq2> I know it's going to come up again at the summit. I don't plan on budging unless the TB forces my hand.
[21:15] <tsimonq2> (Or some large event happens.)
[21:17] <Eickmeyer> BTW, utkarsh still hasn't sent out the release announcement email due to issues with the emailer, and official release "go-ahead" was given via #ubuntu-release at 9:38am my time (11:38 CDT).
[21:18] <tsimonq2> My IRC client is still set to UTC XD
[21:18] <Eickmeyer> ...
[21:18] <Eickmeyer> you get the idea.
[21:18] <tsimonq2> That's why I was oddly specific yesterday ;)
[21:18] <tsimonq2> But yeah, I get it
[21:18] <Eickmeyer> HAHAHAA (oddly specific)
[21:20] <Eickmeyer> RE: Large event: last flavor sync we were discussing moving as many away from ubiquity as possible due to the amount of technical debt in ubiquity. Nobody wants to have ubiquity in their LTS as then they'd be beholden to maintain it for that amount of time.
[21:20] <tsimonq2> I agree, and to be honest, when it comes to timing, I don't... blame you?
[21:21] <Eickmeyer> I shudder at the thought. I had to fix *two* bugs in Ubiquity and it took me hours to hunt down how and where.
[21:21] <Eickmeyer> And each one was a single line.
[21:21] <Eickmeyer> It shouldn't take hours to fix a single line.
[21:22] <tsimonq2> I mean, we have a related issue. Take a peek at our (meaning, the Qt/KDE frontend) for release upgrading. It still has KDE *4* conditionals in it.
[21:22] <Eickmeyer> Oh, you mean in ubuntu-release-upgrader?
[21:22] <tsimonq2> yeah :)
[21:23] <Eickmeyer> Well, that one isn't going away and is still supported by Foundations, so I think we can all work together there.
[21:23] <tsimonq2> So, I think Riddell originally wrote that. We just never got around to doing more than bugfixes.
[21:23] <tsimonq2> I agree.
[21:23] <tsimonq2> I don't plan on rewriting that in Lubuntu, to be clear :)
[21:23] <Eickmeyer> As we shouldn't. That's a can of worms nobody should be opening.
[21:24] <tsimonq2> (In fact, I'd like to be *more* dependent on update-notifier/release-upgrader, just its libraries, if possible.)
[21:24] <Eickmeyer> Kubuntu and Ubuntu Studio are using a version of KDE Neon's update notifier that I forked.
[21:25] <tsimonq2> Is that a standalone package? Why was I under the impression Discover handled this?
[21:25] <Eickmeyer> Discover never handled the upgrade notification, just update notifications.
[21:25] <Eickmeyer> (I should've been clear)
[21:25] <tsimonq2> Cool, so it no longer does that, at least in the Ubuntu flavors?
[21:26] <tsimonq2> (I'd be curious to see what you're working with.)
[21:26] <Eickmeyer> So, Discover handles the package update notifications, but plasma-disto-release-notifier handles the upgrade notifications for distro upgrades.
[21:28] <tsimonq2> Got it, that makes sense.
[21:28]  * tsimonq2 wonders about the UX on Lubuntu, but meh...
[21:29] <tsimonq2> Eickmeyer: So, it's just a notifier that calls the existing program, much like lubuntu-update-notifier now does, right?
[21:29] <Eickmeyer> tsimonq2: well, it's a KDE Plasmoid that calls the update-manager common backend.
[21:31] <Eickmeyer> https://launchpad.net/plasma-distro-release-notifier
[21:31] <tsimonq2> <3
[21:33] <Eickmeyer> tsimonq2: It has to get the EOL date frm the raw git output of the .json in the eol branch.
[21:33] <tsimonq2> I mean, kinda makes sense.
[21:34] <tsimonq2> Could use distro-info-tools or whatever it's called?
[21:34] <Eickmeyer> Doesn't have the EOL date.
[21:34] <tsimonq2> orly?
[21:34] <tsimonq2> base-files doesn't either?
[21:34] <Eickmeyer> Nope.
[21:34] <tsimonq2> That seems... unintended? Or at least, not what it could be.
[21:35] <Eickmeyer> Well, I think because EOL is simply announced, and then everything is moved to old.u.c months later.
[21:35] <Eickmeyer> er, oldreleases.u.c
[21:35] <tsimonq2> Oh, well, that's another thing.
[21:36] <Eickmeyer> But yes, it would be nice if there was an exact date instead of arbitrary "9 months/3 years/5 years" from release.
[21:36] <tsimonq2> I really think *something* should be smarter to say "hey bud, looks like what 'yer running here is EOL, can we just sed sources.list, or do you want to upgrade?"
[21:36] <tsimonq2> Instead of the Many errors
[21:37] <Eickmeyer> plasma-disto-release-notifier actually says, "Your release goes EOL in x days/weeks/etc.".
[21:37] <tsimonq2> Hey dude, ubuntu.csv has EOL dates :)
[21:37] <tsimonq2> e.g. http://launchpadlibrarian.net/631684138/distro-info-data_0.54_0.56.diff.gz
[21:37] <tsimonq2> 23.04,Lunar Lobster,lunar,2022-10-20,2023-04-20,2024-01-25
[21:37] <tsimonq2> That last CSV key is it, no?
[21:38]  * Eickmeyer doesn't dare translate that into the required .json format the neon team made
[21:38] <tsimonq2> That sounds like a bet XD
[21:39] <Eickmeyer> I mean, one could curl the hell out of it.
[21:43] <tsimonq2> Eickmeyer: This would be sooooooooooooooooooooooooooooooo easy.
[21:43]  * tsimonq2 starts on patches
[21:43] <Eickmeyer> HAHAHAHAHAHA
[21:44] <Eickmeyer> Would be nice to have something where I wasn't having to actively maintain a git branch every 6 months. :)
[21:44] <tsimonq2> ;)
[21:47]  * tsimonq2 grabs a fresh ISO
[21:48] <tsimonq2> Eickmeyer: How is this called? (As in, what's the *best* way to manually call it?)
[21:48] <Eickmeyer> `/usr/share/distro-info/ubuntu.csv` :eyes:
[21:48] <Eickmeyer> plasma-distro-release-notifier
[21:49] <tsimonq2> Cool. I'll run a quick baseline while my patch compiles.
[21:49]  * tsimonq2 is the machine 😎
[21:49] <Eickmeyer> 😂
[21:50] <Eickmeyer> Mantic EOLs on slurpee day.
[21:52] <Eickmeyer> tsimonq2: Flaw in your plan: the LTS dates don't use the 3-year date in the csv.
[21:54] <tsimonq2> Eickmeyer: Nah, that's not a flaw, that's a conditional. XD
[21:54] <Eickmeyer> Heh
[22:23] <tsimonq2> QDate("2025-06-01")
[22:23] <tsimonq2> That looks right.
[22:25] <tsimonq2> Eickmeyer: I hate this patch: 0004-set-ubuntu-version.patch ;)
[22:26] <tsimonq2> BOOOOOOOOOO uscan doesn't work :P
[22:35] <kc2bez> Time for some regex-watch-file-fu
[23:01] <tsimonq2> kc2bez: I don't envy anyone who has to modify watch files by hand without docs.
[23:01] <kc2bez> Nor do I.
[23:37] <Eickmeyer> Yeah, there's a reason why I just said, "screw it" to the watch file with that one.
[23:38] <Eickmeyer> I mean, it's not truly forked in the sense of a fork, but if I have to I will.
[23:39] <Eickmeyer> (native packages don't need watch files, if you know what I mean)
[23:43] <Eickmeyer> tsimonq2: I hate that you hate it, but can't wait to see it so I can see it and barf at it. 🤮 😂
[23:47] <tsimonq2> Eickmeyer: How do you want your patch? :)
[23:47] <tsimonq2> Some people hate Launchpad MPs, I don't blame them.
[23:47] <tsimonq2> And to be fair, the patch will be pretty unreadable. It's better to use a non-unified diff on this one to review, I'd say.
[23:48] <tsimonq2> Anyway, I'm testing now, but it builds. Have I mentioned I hate string quoting?
[23:48] <tsimonq2> XD
[23:48] <tsimonq2> "On a platter"
[23:48] <kc2bez> Email or it doesn't count.
[23:48] <tsimonq2> ^^^^^^^^
[23:48] <Eickmeyer> Damnit, arraybolt3 took the words out of my fingers. Though, pancakes sound amazing.
[23:48] <tsimonq2> kc2bez: has the only real answer XD
[23:48] <Eickmeyer> tsimonq2: You know my email.
[23:48] <tsimonq2> Or, fax machine. No printer.
[23:48] <tsimonq2> Eickmeyer: Sweet.
[23:49]  * tsimonq2 slides Aaron and Erich some pancakes
[23:49] <kc2bez> It is the greybeard coming out. XD
[23:49] <kc2bez> \o/
[23:49] <tsimonq2> \o/
[23:50] <kc2bez> jinx
[23:50] <tsimonq2> XD
[23:50] <kc2bez> :D
[23:51] <kc2bez> Take the time you need, contribute where you can.
[23:51] <tsimonq2> Do you remember what happened recently with wxl's status? :)
[23:51] <kc2bez> Yeah, we can fast track some of that given past history I'd say.
[23:52] <tsimonq2> Prove you don't have bad amnesia, and I think we'd be happy to restore your status. ;)
[23:52] <guiverc> We'd love to have you around @arraybolt3, you've been available on request (when needed) anyway! so you'll sure not be starting again..
[23:52]  * Eickmeyer rubberstamps arraybolt3 cuz reasonz
[23:52] <tsimonq2> Yeah @arraybolt3, your work with the XDG desktop portals really saved our bacon :)
[23:52] <tsimonq2> (Ha. Ha. Ha.)
[23:53] <Eickmeyer> 🤦
[23:53] <kc2bez> Maybe prove you had temporary amnesia could work...
[23:54] <tsimonq2> XD
[23:54] <tsimonq2> I mean, I don't judge. Everyone has something going on. My point is, if you remember how to package as well as you did, you'll be green stamped pretty easily.
[23:55] <kc2bez> +1
[23:55] <Eickmeyer> Having a hand in that mentoring, I can +1 that.
[23:56] <tsimonq2> We all do ;)
[23:56] <kc2bez> That is never ending
[23:56] <Eickmeyer> I even forgot stuff that bit me this past cycle.
[23:57] <kc2bez> Everything is iterative, just do better than last time every time and you are all set.
[23:57] <tsimonq2> It's one of those "read once, remember where to find stuff, bookmark it, use Lintian" type things
[23:57] <tsimonq2> +1
[23:58] <tsimonq2> 1% improvement is improvement ;)
[23:58] <Eickmeyer> Lintian is your friend except when it considers x.x-xubuntux.23.10 a debian nmu update and vorlon himself tells lintan to "go home, you're bitrotted."
[23:59] <tsimonq2> HAHAHAHA I was just thinking about that
[23:59] <kc2bez> On the Wayland front upstream had some comments today, let me dig it up.
[23:59] <tsimonq2> @arraybolt3: I told someone on Twitter today "whenever I'm ready for the mountain of bug reports" XD
[23:59] <tsimonq2> kc2bez: oh? :)
[23:59] <tsimonq2> Ref: https://twitter.com/GhigoTrieste/status/1712465673107243188


 @mitya57 I intend to try to upload the plasma 5.25 beta that is out on Thursday, so you may wish to wait until that to do plasma rebuilds on the 5.15.4 ticket?
 If all builds go fine then maybe we can publish Qt even earlier. Like tomorrow or on Wednesday. Or you want Plasma first?
 I would quite like the plasma beta to not get stuck behind Qt. Qt will not migrate until the libzstd migration happens, blocked by a regression currently (re @mitya57: If all builds go fine then maybe we can publish Qt even earlier. Like tomorrow or on Wednesday. Or you want Plasma first?)
 However, lets keep in touch and see where we both get to on these things in the next couple of days :)
 Ok
 I want Qt 5.15.4 in Ubuntu before we have it in Debian. Because otherwise it will be auto-synced and gets stuck because docs are not bootstrapped.
 But in Debian the Release team wants openssl transition to finish first, so we have a few days at least.
 Understood. If Qt goes 1st it will not be the end of the world. I will be also be building plasma beta for jammy in a beta PPA, which is like what most testers will use anyway
 By the way, for Qt 5.15.4 I included KDE's patches for Wayland.
 I saw that. 🎉 (re @mitya57: By the way, for Qt 5.15.4 I included KDE's patches for Wayland.)
 Thank you