[06:56] <nhaines> Good morning everyone!
[06:57] <nhaines> I need more Amazon reviews for my book.  Who's interested?
[06:58] <svij> gimme an review sample and I'll do it ;)
[06:58] <nhaines> \o/
[06:59] <nhaines> Sent!
[07:14] <dholbach> good morning
[07:16] <nhaines> Good morning!
[07:16] <svij> morning dholbach
[07:16] <nhaines> dholbach, I'm looking for Amazon reviews and am wondering if you'd consider taking a look at my book!
[07:16] <dholbach> hey svij
[07:17] <dholbach> I'm not sure when I would next have the time to thoroughly read it and everything.... :-/
[07:18] <nhaines> dholbach: It's okay.  That's what pleia2 said too, but I'm pinning her down to mid-November like she said.  ;)
[07:18] <dholbach> haha
[07:19] <svij> I couldn't say no to nhaines :D
[07:21]  * svij will see if his book is a good bedtime-story.
[07:23] <nhaines> Well, it certainly got its first review today.  5 stars!  http://www.amazon.com/review/R3M23WF3QLWQNV/ref=cm_cr_dp_title?ie=UTF8&ASIN=1484206096&channel=detail-glance&nodeID=283155&store=books
[07:24] <svij> congrats :)
[07:25] <nhaines> Thanks!  It's a start.  And I'm ranked #75 in Unix!  That makes me an Amazon bestseller, I think, haha.
[07:25] <svij> lol
[07:25] <nhaines> Now to go after that lucrative MINIX crowd.


[01:50] <blizzkid> lo all. I saw there is python-twitter but couldn't find one for identi.ca, so I hacked python-twitter for identi.ca. Would this be something interesting to include in Ubuntu?
[05:32] <micahg> can someone verify that I did this sync request bug properly before I subscribe ubuntu-main-sponsors? bug 400410
[05:38] <StevenK> The Debian maintainer just requested one ...
[05:38] <micahg> ah, didn't see the bug, sorry, I filed this as a wishlist a month ago
[05:39] <micahg> wait, was it this bug 415730
[05:40] <micahg> no, I didn't see it
[05:40] <micahg> StevenK: so, should I do anything with the bug I filed?
[05:44] <StevenK> micahg: I'll sort it out, hold on
[05:44] <micahg> ok
[05:44]  * micahg was hoping to get a sync bug right after messing up so many times :)
[05:46] <micahg> ah
[05:46] <micahg> now I see it
[05:46] <StevenK> micahg: Fixed
[05:47] <micahg> thanks
[05:49] <micahg> good thing I asked
[05:49] <micahg> would've screwed up another sync request
[06:12] <qiyong> is there spanish ubutnu channel?
[06:14] <Flannel> qiyong: #ubuntu-es
[06:15] <qiyong> Flannel: thanks
[07:58] <dholbach> good morning
[08:22] <stochastic> what does it mean to 'ack' a bug?
[08:23] <dholbach> acknowledge, approve
[08:23] <stochastic> i.e. upload a fix?
[08:32] <directhex> stochastic, depends on the type of bug
[08:33] <stochastic> directhex, can you explain, or is there a page definition somewhere?
[08:35] <directhex> stochastic, usually acks are used in ubuntu for bugs requiring sponsorship - i.e. the bug gets ack'd to say "yes, this should happen"
[08:35] <\sh> moins
[08:36]  * stochastic thinks he understands now
[08:38] <stochastic> so it would be kosher to ask if a motu could ack Bug #325004 and Bug #415680  ??
[08:42] <directhex> stochastic, the second one, i'd say yes. the first one it looks like there's still ongoing discussion with dholbach
[08:42] <stochastic> directhex, okay thanks for clarification
[08:43] <directhex> i'll test-build tap-plugins
[08:43] <dholbach> I didn't assign denemo to myself, so if you want to go ahead and grab it, just do it
[08:46] <juanje> dholbach: Hi :-)
[08:46] <juanje> dholbach: Do you mind to check the changes to the package we are reviewing the other day? http://revu.ubuntuwire.com/p/nautilus-md5sum ;-)
[08:47] <directhex> dholbach, nah, still needs looking over. i'll take care of tap-plugins since it looks like a simple upload
[08:51] <directhex>   Uploading tap-plugins_0.7.1-0ubuntu1.dsc: done.
[08:51] <stochastic> thanks directhex
[08:51] <directhex> stochastic, ^^
[08:51] <stochastic> directhex, ^^ ;P
[08:54] <directhex> that's my good deed for the month. i think i need a lie down
[08:58] <stochastic> dholbach I'd love to sort out any issues still left on the denemo bug, should you have the time.
[08:58] <frandieguez> Hi to all, I have a question regarding the creation of deb packages. I'm making a virtual package for 32 and 64 bits platforms, but for 64 bits doesn't exist one package. Does exist a standarized method for solve this issue at debian/control file?
[08:59] <directhex> frandieguez, is it a missing build-dep or a missing binary package?
[08:59] <frandieguez> @directhex the main problem is that I have made a package for easy-installing of Chipmunk program
[09:00] <frandieguez> The problem is that at 64 bits platforms the program doesn't work
[09:01] <frandieguez> So, I can't do a package for chipmunk for 64 bits platform and the virtual package that has to include the chipmunk package isn't consistent
[09:04] <directhex> if the app doesn't work on amd64, why make a package for it for amd64?
[09:08] <frandieguez> @directhex let me explain. I have made a package that collects programs for my pupils like (gcc, gdb, netbeans.... and others), this packge is a virtual package that depends over the rest
[09:09] <directhex> metapackage. a virtual package is something else
[09:09] <directhex> probably your easiest option is to Recommend: the package which isn't on all arches
[09:10] <directhex> recommends are pulled in when they can be
[09:10] <frandieguez> @directhex additionally I have made a package for chipmunk program http://www.dcc.uchile.cl/~lmateu/CC41C/chipmunk.html
[09:10] <frandieguez> @dorectjex good point!
[09:12] <frandieguez> @directhex that works perfectly!
[09:17] <directhex> stochastic, ftbfs on itanium
[09:18] <stochastic> directhex, yes I see, but previous versions also ftbfs on itanium
[09:18] <stochastic> so I assume it's an issue with the code, I will forward the log upstream
[09:18] <directhex> please do
[09:22] <slytherin> frandieguez: when defining dependencies you can specify architectures like this ' gcc [!amd64], netbeans [!sparc]'
[09:27] <frandieguez> @slytherin with [!amd64] parameter you mean "install gcc package unless you are on amd64 platform", isn't it?
[09:28] <slytherin> frandieguez: right.
[09:28] <slytherin> in simply words, no dependency on gcc on amd64 platform
[09:28] <frandieguez> thanks, this solution is more elegant
[09:31] <slytherin> frandieguez: you can also specify multiple arch like this - [amd64 sparc] (only on amd64 or sparc) or [!amd64 !sparc] (all platforms other than amd64 or sparc).
[09:49] <stochastic> can any motu with a spare minute take a look at http://revu.ubuntuwire.com/p/a2jmidid ?
[11:33] <dholbach> juanje: done
[11:36] <dholbach> stochastic: replied
[11:48] <juanje> dholbach: :-)
[11:48] <juanje> dholbach: Thanks :-)
[11:49] <j^> anything that can/needs to be done to get oggvideotools accepted? http://revu.ubuntuwire.com/p/oggvideotools
[12:24] <juanje> dholbach: I agree with your comments. I've already changed the package and I did the upload again. There is something else we need to do to have the package accepted?
[12:25] <dholbach> I'll take another look
[12:26] <juanje> dholbach: thanks :-)
[12:38] <dholbach> juanje: approved it, now you need a 2nd ACK
[12:40] <stefanlsd> juanje: whats the url?
[12:40] <juanje> dholbach: Thanks :-)
[12:40] <juanje> stefanlsd: http://revu.ubuntuwire.com/p/nautilus-md5sum
[12:41] <logari81> what is the normal process for removing a part of an upstream tarball, just manually removing it from the orig.tar.gz? should the exclusion also be considered in a get-orig target or in the watch file?
[12:42] <juanje> dholbach: thank you so much. I've learned a lot of datails to have a look with this package. I'll check the others I have in queue :-)
[12:42] <dholbach> super :)
[12:44] <slytherin> logari81: What do you mean by manually? It is preferred that get-orig-source will give you the correct .orig.tar.gz as it is supposed to go in distro. So yes you should handle removal there.
[12:47] <juanje> dholbach: one question about your last comment
[12:47] <dholbach> fire away
[12:48] <juanje> dholbach: the Standards-Version is not the debian-policy version?
[12:48] <juanje> the package's version I mead
[12:48] <dholbach> it is
[12:48] <juanje> I mean
[12:48] <logari81> slytherin: ok, I am trying to find an example package corresponding to such a case, just to be sure
[12:48] <dholbach> seems we have debian-policy and lintian out of sync :)
[12:49] <juanje> dholbach:  I just checked with rmadison and told me there is <IP_ADDRESS>
[12:49] <slytherin> I believe there is already 3.8.3 of policy
[12:49] <juanje> in karmic
[12:49] <juanje> ops
[12:50] <juanje> dholbach: so then I should put 3.8.2 or 3.8.3 for karmic?
[12:50] <dholbach> just leave it
[12:50] <dholbach> like it is
[12:50] <juanje> ok
[12:51] <juanje> dholbach: but for the other packages? just to know the good one
[12:52] <dholbach> I hope somebody will sync/merge debian-policy
[12:52] <dholbach> then we should be good again
[12:54] <juanje> me too :-P
[12:54] <juanje> :-)
[13:14] <juanje> Could anyone review this package http://revu.ubuntuwire.com/p/mount-systray ?
[13:14] <juanje> thanks
[13:14] <juanje> :-)
[13:15] <slytherin> juanje: usually Friday is the day when you can go announcing about your packages on REVU.
[13:23] <juanje> slytherin: ohhh... I didn't know. I'm sorry. I've announced my packages here sometimes but nobody say nothing, I guess that was because I did the worng day... I didn't know it was a special day for that. I'm sorry
[13:24] <stochastic> dholbach, replied/fixed issues on Bug #325004
[13:24] <dholbach> stochastic: I'll take a look when I get back from lunch
[13:24] <dholbach> maybe somebody else has the time to check it beforehand?
[13:25] <stochastic> dholbach, I'm not in that big of rush, I'm off to bed now (but I'm worried about feature freeze so don't forget about it please :)
[13:25] <dholbach> alright :)
[13:25] <dholbach> sleep tight
[13:32] <iulian> Oh look, it's dholbach!
[13:50] <slytherin> juanje: no need to be sorry for that. :-)
[13:55] <jbernard__> iulian: thanks for the lua-iconv upload, I really apprecite it
[14:04] <iulian> jbernard__: Don't mention it. :)
[14:46] <dholbach> nxvl, nhandler, james_w: do we need to reschedule tomorrow's Packaging Training session too?
[14:46] <james_w> reschedule?
[14:47] <dholbach> https://wiki.ubuntu.com/Packaging/Training
[14:47] <james_w> I don't see one scheduled?
[14:47] <dholbach> there was one
[14:47] <dholbach> DktrKranz'
[14:49] <DktrKranz> yes, but I can't host it, I'll travel tomorrow
[14:50] <dholbach> ok
[14:50] <DktrKranz> sorry for the short notice, but it has been a surprise for myself too
[14:51] <dholbach> no worries Luca
[14:51] <dholbach> who of any of the release teams would like to talk a bit about freezes, release schedule and stuff?
[14:51] <dholbach> 18:00 UTC
[14:52] <dholbach> I can't because I'll be in the ubuntu global jam meeting at the same time
[14:53] <dholbach> any other packaging related topic will do too
[15:05] <Sam-I-Am> howdy
[15:06] <Sam-I-Am> wandered over here from #ubuntu-server with some packaging questions...
[15:06] <Sam-I-Am> when building a package from source, what determines which files get copied from the original source tree into debian/build ?
[15:06] <bddebian> Heya gang
[15:07] <maxb> Sam-I-Am: Fundamentally, it's whatever files get copied by the execution of debian/rules targets
[15:08] <maxb> Often debian/rules will delegate to debhelper dh_* commands for most of that
[15:08] <Sam-I-Am> yeah...
[15:08] <Sam-I-Am> so openldap copies most of its tree into debian/build... except 'contrib'
[15:08] <Sam-I-Am> stuff is getting built in contrib... just back in the main source tree which is a problem
[15:09] <Sam-I-Am> trying to move that into debian/build
[15:11] <maxb> Hrm... "debian/build" ? What is that?
[15:11] <maxb> The usual directories are debian/tmp and debian/$(BINARY_PACKAGE_NAME)
[15:11] <Sam-I-Am> the directory which gets the openldap source for building
[15:11] <Sam-I-Am> at least with openldap
[15:11] <maxb> Hrm. Quirky buildsystem
[15:12] <Sam-I-Am> y.. yeah
[15:12] <Sam-I-Am> i dont think i'm about to change that part :)
[15:23] <Sam-I-Am> maxb: i'm still not sure how its copying those files
[15:23] <Sam-I-Am> its not obvious to me
[15:35] <logari81> how should I interpret the two licenses contained in the following header:
[15:35] <logari81> http://pastebin.ubuntu.com/255767/
[15:35] <logari81> are they combined with an OR or with an AND condition?
[17:09] <jtimberman> Can a second MOTU advocate take a look at CodeRay, trying to get it in for Karmic. http://revu.ubuntuwire.com/p/coderay
[17:12] <Ampelbein> jtimberman: i'll have a look
[17:12] <jtimberman> Thanks!
[17:18] <Ampelbein> jtimberman: uploaded.
[17:18] <jtimberman> Awesome!
[17:24] <pochu>                                They both like KDE, they both work
[17:24] <pochu> for Canonical, they both like Karaoke and they just started
[17:24] <pochu> a Country band.
[17:24] <pochu> One of the above is not true.
[17:24] <pochu> heh
[17:36] <logari81> I am packaging a library (getfem) which in its orig.tar.gz contains the sources of another library (superlu) in a separate directory. I ve realized though, that superlu exists in ubuntu as a standalone package. I am wondering if I can/should delete the superlu folder from the original tarball. Since the superlu version provided with getfem partly suffers from missing copyright headers it would be nice if I could get rid of it.
[17:37] <logari81> I ve tried to find a similar case looking for *-dfsg source packages but I couldn't find a similar example
[18:28] <fabrice_sp> bddebian, in case you didn't noticed: I'v just uploaded again aptoncd. It should be ok this time :-)
[19:26] <bddebian> fabrice_sp: Uploaded, thanks!
[19:27] <fabrice_sp> really?
[19:27] <fabrice_sp> thanks a lot bddebian !
[19:27] <fabrice_sp> you're my hero! :-)
[19:27] <bddebian> No, thank YOU :)
[19:29] <fabrice_sp> by the way, how can I take over the actual maintainer? Asking him to orphan the package, or through Debian Bug #484637 ?
[19:34] <bddebian> fabrice_sp: If he is OK with you taking it over, it's just a matter of changing yourself to the maintainer and noting it in debian/changelog.  You could probably close #484637 with that changelog entry too if you wanted.
[19:34] <geser> fabrice_sp: ask in #debian-devel on OFTC, they should know better their processes than us :)
[19:35] <fabrice_sp> geser, you're right. Sorry about that 'debian' noise :-)
[19:40]  * DktrKranz cheers bddebian, our brave ftp-assistant!
[19:41] <jtimberman> mathiaz: ping
[19:44] <bddebian> heh
[19:56] <mathiaz> jtimberman: hey
[19:57] <jtimberman> mathiaz: saw your comments on merb.. for the rules file, can those items be handled in the next release? as is the rules bundles the packages just fine. I can add the readme.source of course.
[19:59] <mathiaz> jtimberman: did you try to remove all the rules from the file?
[19:59] <mathiaz> jtimberman: to me it seems that all the code in the rules file is pretty much a cut'n paste from the pkg-ruby-rb cdbs class
[20:02] <jtimberman> mathiaz: per suggestion from one of the debian-ruby-extras folks i copied an existing package (couldn't say off hand at this point which one :))
[20:13] <mathiaz> jtimberman: right - it doesn't seem trivial
[20:14] <mathiaz> jtimberman: so we can defer it to a later release
[20:14] <jtimberman> great
[20:14] <jtimberman> I'll upload w/ the README.source added
[20:14] <mathiaz> jtimberman: great. thanks
[20:20] <jtimberman> mathiaz: should be uploaded in a moment
[20:47] <mathiaz> jtimberman: is it normal that merb requires rails?
[20:48] <jtimberman> No.
[20:48] <mathiaz> jtimberman: when installing one of merb package rails gets pulled in
[20:48] <jtimberman> Really??
[20:48] <mathiaz> jtimberman: yop
[20:48] <mathiaz> jtimberman: http://paste.ubuntu.com/255899/
[20:49] <mathiaz> jtimberman: but it's not  problem with the merb packaging
[20:49] <jtimberman> Hmm.
[20:49] <mathiaz> jtimberman: it's probably one of its dependency that recommends rails
[20:49] <jtimberman> Yeah.
[20:49] <mathiaz> jtimberman: and recommends are installed by default
[20:49] <mathiaz> jtimberman: this can be fixed post-FeatureFreeze
[20:49] <jtimberman> what packages did you specify to install?
[20:50] <jtimberman> 'merb'?
[20:50] <mathiaz> jtimberman: http://paste.ubuntu.com/255900/
[20:50] <mathiaz> jtimberman: ^^ one of this package is probably recommending rails
[20:50] <mathiaz> jtimberman: merb-core and merb-slices
[20:50] <jtimberman> ok
[20:53] <jtimberman> http://paste.ubuntu.com/255903/
[20:54] <jtimberman> mathiaz: and http://paste.ubuntu.com/255904/
[20:54] <mathiaz> jtimberman: hm - interesting
[20:54] <jtimberman> yeah what is a 'ruby 4.2' ?!
[20:56] <jtimberman> thats bizarre, that looks like a binary program package, but its a completely different version than 'ruby'
[20:56] <mathiaz> jtimberman: http://paste.ubuntu.com/255906/
[20:57] <mathiaz> jtimberman: http://packages.ubuntu.com/karmic/ruby
[20:57] <mathiaz> jtimberman: This package is a dependency package, which depends on Debian's default Ruby version (currently 1.8.x).
[20:57] <jtimberman> Indeed. Weird that the version is 4.2.
[20:59] <mathiaz> jtimberman: yeah - it's just that the numbering scheme isn't related to the actual version of ruby it depends on
[20:59] <mathiaz> jtimberman: it basically is a meta-package
[21:00] <jtimberman> yeah. So this rails...
[21:01] <mathiaz> jtimberman: so what's left now is stompserver and chef
[21:02] <mathiaz> jtimberman: we'll look at the rails depency later - first focus on getting all the package in the archive in time for FeatureFreeze
[21:03] <jtimberman> Yes.
[21:03] <jtimberman> mathiaz: sounds good to me :)
[21:28] <fabrice_sp> ScottK, I'm fixing openturns for bug #411189. Should I subscribe u-u-s, or you will take care of my debdiff?
[21:32] <fabrice_sp> i've subscribed u-u-s. Have to go now. Bye
[22:48] <ScottK> Good.
[22:48]  * ScottK is on vacation right now.
[23:45] <stochastic> if a script is licensed under http://creativecommons.org/licenses/by/3.0/ would that be able to be included in the repositories?
[23:50] <jtimberman> mathiaz: got stompserver updated
[23:51] <james_w> stochastic: yes, though it's not a great code license
[23:52] <mathiaz> jtimberman: great - I went through a first review of chef
[23:52] <jtimberman> mathiaz: going through it now, thanks :)
[23:55] <mathiaz> jtimberman: stompserver looks much better now
[23:55] <jtimberman> mathiaz: :)
[23:55] <mathiaz> jtimberman: thanks for sorting out the options with absolute path
[23:55] <mathiaz> jtimberman: one last important bit is to use the upstream tarball
[23:55] <jtimberman> Yeah, only trouble was determining the most elegant consistent way to do that.
[23:55] <jtimberman> it should be in there?
[23:55] <mathiaz> jtimberman: there isn't any diff.gz file
[23:56] <mathiaz> jtimberman: http://revu.ubuntuwire.com/p/stompserver
[23:56] <mathiaz> jtimberman: the only files are stompserver_0.9.9-0ubuntu1.tar.gz and the .dsc
[23:57] <mathiaz> jtimberman: what should be available is a .orig.tar.gz, .diff.gz and .dsc
[23:58] <jtimberman> ooh... orig.tar.gz, not orig.tgz?
[23:59] <mathiaz> jtimberman: what you need is stompserver_0.9.9.orig.tar.gz (which is the upstream tarball)
[23:59] <mathiaz> jtimberman: http://rubyforge.org/frs/download.php/31579/stompserver-0.9.9.tgz.
[23:59] <jtimberman> yeah, i have stompserver_0.9.9.orig.tgz (not .tar.gz)


[20:00] <pleia2> jose: feel free to add more people to the quotes list ;) I am so detatched... community members would be good too
[20:16] <jose> pleia2: yep! I need to update it with the replies I've already gotten. Have a couple more in mind :)
[20:20] <pleia2> thanks :)
[20:20] <pleia2> finishing blog post now that will collect more from the community via fridge/planet, and have our quiz...
[20:31] <pleia2> \o/
[20:31]  * pleia2 seeks lunch
[20:40] <jose> Mark and Jane got back to us already
[20:40] <jose> Marius from Softpedia is thinking on what to write
[20:40] <pleia2> great


[10:12] -GitHub[m]:#mir-server- **[MirServer/mir]** bors[bot] merged [pull request #2844](https://github.com/MirServer/mir/pull/2844): Migrate BasicIdleHub to use Synchronised<T>
[10:24]  * Saviq uploaded an image: (463KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/FqkJnziovJkhpeDbulqRPmKX/image.png >
[10:24] <Saviq> alan_g is this the breakage you were experiencing? NB this is 22.10
[10:25] <alan_g[m]> No, that's "just" SDL2 not respecting fullscreen (which has been forever
[10:25] <Saviq> ACK
[10:26] <alan_g[m]> )
[10:41] <Saviq> RAOF (he/they) there's another reason why wlcs won't migrate:
[10:41] <Saviq> https://launchpad.net/ubuntu/+source/wlcs/1.5.0-1/+build/25533553
[10:42] <Saviq> Did you not bring https://github.com/MirServer/wlcs/pull/263/files over?
[10:59] <Saviq> alan_g I got a live Lunar desktop + stable ubuntu-frame and neverputt from the archive. Both nested on X11 and on a VT, `frame-it neverputt --fullscreen` #WFM¿?
[11:00] <Saviq> (on VirtualBox, but doubt that matters at all)
[11:02] <Saviq> I do have older libsdl built for 23.04 if you want a try
 "Did you not bring https://github..." <- Oh wlcs is already a sync from Debian?
[11:05] <Saviq> sunweaver hey, would you please apply this to wlcs in Debian? Otherwise it won't build on ppc64el on gcc-12:
[11:05] <Saviq> https://github.com/MirServer/wlcs/pull/263/files
[11:46] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths closed [pull request #2839](https://github.com/MirServer/mir/pull/2839): Reimplement idle_inhibit_unstable_v1
[11:48] <alan_g[m]> Saviq, if you've the headspace: https://github.com/MirServer/mir/pull/2842 looks good
 "alan_g I got a live Lunar..." <- alan_g any pointers on how to reproduce?
[12:55] <alan_g[m]> Which problem are you trying to reproduce?
[12:55] <Saviq> The SDL2 on 23.04, works for me
[12:57] <alan_g[m]> Mouse input? Enabling ible_inhibit not crashing server? Closing window not killing client?
[12:57] <alan_g[m]> FWIW I've simply been running Miriway
[12:57] <Saviq> That may be half of my problem - I thought SDL2 is broken completely on 23.04?
[12:58] <alan_g[m]> Well, try using the mouse to reconfigure the window size
[12:59] <alan_g[m]> (Lunchtime here - BBIAB)
[13:00] <Saviq> I'll report back on https://github.com/MirServer/mir/issues/2841
[13:13] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq added question to [issue #2841](https://github.com/MirServer/mir/issues/2841): On 23.04, SDL2 mouse input doesn't work
[15:02] <alan_g[m]> neverputt --fullscreen works fullscreen for you?
[15:02] <Saviq> Under Frame, I believe so - but not under Miriway…
[15:03] <Saviq> Well… it… sometimes… changes behaviour…
[15:05] <Saviq> Can confirm Meta+Space making it work in Miriway
[15:06] <Saviq> But since it's the same behaviour in 22.10 (and more importantly, not in Frame), I think it's not a regression we need to stress about
[15:06] -GitHub[m]:#mir-server- **[MirServer/mir]** bors[bot] merged [pull request #2842](https://github.com/MirServer/mir/pull/2842): (Sophie's) reimplementation of idle_inhibit_unstable_v1
[15:06] -GitHub[m]:#mir-server- **[MirServer/mir]** bors[bot] closed [issue #2838](https://github.com/MirServer/mir/issues/2838): [Wayland] idle_inhibit_unstable_v1 is badly broken
[15:06] -GitHub[m]:#mir-server- **[MirServer/mir]** bors[bot] closed [issue #2836](https://github.com/MirServer/mir/issues/2836): Enabling zwp_idle_inhibit_manager_v1 causes Mir to crash with some applications
[15:06] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq removed question from [issue #2841](https://github.com/MirServer/mir/issues/2841): On 23.04, SDL2 mouse input doesn't work
[15:08] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq edited [issue #2841](https://github.com/MirServer/mir/issues/2841): SDL2 mouse input doesn't work reliably
[15:09] <alan_g[m]> I don't have 22.10 around to check. You see the same behaviour there? (But not on 22.04 & 20.04)
[15:10] <Saviq> I'll check <22.10 soon
[15:12] <alan_g[m]> Well, I don't see it on 20.04 or 22.04 so it was 22.10 I was wondering about
[15:12] <Saviq> Yes, I can see it on 22.10
[15:12] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths edited [issue #2841](https://github.com/MirServer/mir/issues/2841): [22.10, 23.04] SDL2 mouse input doesn't work reliably
[15:13] <alan_g[m]> Does the team think we want a 2.12.1 with #2824?
[15:14] <Saviq> You mean so we get it into Lunar?
[15:15] <alan_g[m]> And into Frame/stable
[15:15] <Saviq> IMO 24.04 is a more important target, 23.10 can wait for a 2.13
[15:15] <Saviq> Same, IMO Frame can wait for 2.13
[15:15] <alan_g[m]> Also Debian
[15:16] <Saviq> Haven't seen anyone complaining about it
[15:17] <alan_g[m]> The complaint was #2824 - AFAIK the first time anyone tried to use idle-inhibit
[15:17] <alan_g[m]> (With a real world client that is)
[15:18] <Saviq> Ah :) https://github.com/MirServer/mir/pull/2824
[15:18] <Saviq> Wrong #
[15:20] <Saviq> https://github.com/MirServer/mir/pull/2842 might be a more plausible candidate for a point release
[15:20] <alan_g[m]> #2836
[15:20] <alan_g[m]> C&P did something weird
[15:20] <alan_g[m]> So problem: #2824
[15:20] <alan_g[m]> Bugfix: #2824
[15:21] <Saviq> #2824 is output names :) #2842 is bugfix, #2836 is problem
[15:21] <alan_g[m]> Dammit what is C&P doing?!
[15:22] <alan_g[m]> Yes, Something got screwed in my pasting.
[15:25] <alan_g[m]> So: does the team think we want a 2.12.1 with #2842, #2836 is problem report
[15:25] <Saviq> I'm +1 on getting that out there sooner than later
[15:26] <alan_g[m]> This might also be considered: https://github.com/MirServer/mir/pull/2840
[15:30] <Saviq> I reproduced the neverputt mouse issue on live 22.04.1
[15:34] <alan_g[m]> A good job we're leaving that snap on core20 then. Weird
[15:41] <Saviq> But yeah, didn't reproduce on 20.04.5
[15:44] <alan_g[m]> Other possible candidates for a bugfix release: #2791, #2802, 2804, #2817, #2821
[16:38] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq edited [issue #2841](https://github.com/MirServer/mir/issues/2841): 22.04+ SDL2 mouse input doesn't work reliably
[16:57] <Saviq> Talk tomorrow o/