[06:59] <ara> morning all :)
[07:24] <ara> buenos días jcollado
[07:24] <jcollado> Buenos días ara
[10:15] <davmor2> Morning all
[10:16] <ara> morning davmor2 :)
[12:39]  * ara -> lunch
[14:17] <davmor2> cgregan: how's sunny, sunny boston?
[14:18] <cgregan> davmor2: nice! A little cold still, but we are getting there. Plan to work from the garden today
[14:19] <davmor2> I thought you worked at the lex office or is this just an excuse to skive off
[14:20] <fader> davmor2: I think he's lying to you -- everyone knows you can't have a garden in Boston.  Plants are those things we see in books and in supermarkets.
[14:21] <fader> Supposedly they grow in some sort of mythical layer of material you find if you dig under the snow enough. :)
[14:21] <cgregan> davmor2: hehe....Lex office is closed for renovation so we are all home
[14:21] <davmor2> fader: No they's the things on TV on the gardening shows surely
[14:22] <cgregan> fader: you've got me....I have a plastic plant in the window of my home office which overlooks a railway depot! ;-)
[14:22] <davmor2> Hmm Nice.....
[14:22] <fader> cgregan: Ah, must be nice to live close to the T :)
[14:23] <davmor2> From my window I see steam trains, trains, tops of trees, birds etc etc etc etc etc
[14:25]  * fader tries to figure out if this is 'birds' in the British slang sense or not.
[14:26] <davmor2> No, things with wings (look to the sky and not the gutter)
[14:26] <cgregan> hehe
[14:51] <ara> eeejay: hey hey
[14:51] <eeejay> ara: yo yo
[14:52] <ara> eeejay: don't worry, I answered the question myself :D
[14:52] <eeejay> ara: i will stop holding my breath :)
[14:52] <ara> eeejay: hehehehe
[16:06] <charlie-tca> Can we get xubuntu images turned on in the qa tracker?
[16:08] <davmor2> charlie-tca: that's down to pitti or cjwatson_ if they are incharge of the builds
[16:16] <cjwatson> I'll have a look in a moment
[17:11] <valya> Hello, i'm having trouble with ubuntu 9.04 desktop install. My laptop overheats and reboots during installation. There was no such problem with previous release (8.??). I'm tried to find module "thermal" and remove it but there is no such module. Can someone suggest solution?
[17:19] <davmor2> valya: ubuntu will probably be better for this
[17:19] <valya> thanks
[17:19] <davmor2> sorry #ubuntu
[18:05] <cjwatson> charlie-tca: done
[18:05] <charlie-tca> Thanks again


[11:44] <airurando> my raring ringtail racoon arrived this morning :-)
[11:44] <czajkowski> airurando: yay
[11:44] <czajkowski> hows things?
[11:45] <airurando> not too bad czajkowski
[11:45] <airurando> leg still frustrating
[11:45] <airurando> how are things with you?
[11:47] <czajkowski> looking forward to the weeken
[11:47] <czajkowski> and updates fromhome,
[11:47] <czajkowski> cousin got taken into hospital on sunday
[11:48] <czajkowski> after a funny episode and fuzzy memory trying to rule out mild stroke, she's 16
[11:48] <czajkowski> so just working and keeping busy tbh
[11:49] <airurando> yeah i saw your tweets yesterday.  That is very strange. I hope she is ok
[11:53] <czajkowski> cheers


[07:00] <smalls1> I'm having an issue with ipv6 as far as it not being able to bind to eth0 and filling log files to the tune of GB's. I have mitigated the disk usage by editing
[07:00] <smalls1> /etc/systemd/journald.conf
[07:00] <smalls1> to limit the size of the files.
[07:00] <smalls1> upon login, I see this seemingly Relevant section
[07:00] <smalls1>  https://pastebin.com/H8BUPGSR
[07:00] <smalls1> Also dmesg seems to provide:
[07:00] <smalls1> audit: type=1400 audit(1674610638.420:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=495 comm="apparmor_parser"
[07:00] <smalls1> I'm wondering if apparmor is preventing the successful binding to eth0.
[07:00] <smalls1> I don't currently use ipv6 for anything, but I would like to resolve the issue/error.
[07:00] <smalls1> Any insights or suggestions are welcome. This is my first time with this issue.
[07:00] <smalls1> The system is currently hosted as a VPS if that provides any additional information.
[07:23] <frickler> smalls1: seems your network config is broken, for autoconfig you need a /64, but the log shows /96
[07:53] <smalls1> frickler: thank you for responding.  is this something I can change on my end? any reading material I can access to wrap my head around this?
[08:02] <smalls1> perhaps netplan configuration adjustment?
[08:38] <frickler> smalls1: depends on where this is coming from. if your netplan config doesn't contain anything about IPv6 currently, adding "dhcp6: true" may help. otherwise you need to check with your VPS provider
[14:11] <teward> athos: i see a server triage discuss on a wontfix nginx bug from well over a year ago.  note Debian hasnt made the change either suggested by the bug regardless of Fedora or not (I would know, I'm a comaintainer in Debian)
[14:12] <teward> anything i should know?  (see bug #1666368)
[14:12] -ubottu:#ubuntu-server- Bug 1666368 in nginx (Ubuntu) "[Ubuntu 16.04] nginx won't start on boot while network does not up yet" [Undecided, Won't Fix] https://launchpad.net/bugs/1666368
[14:33] <athos> hey teward! Thanks for pinging on this one :)
[14:36] <athos> I just did not want to reply to that comment saying that "our position have not changed on this one" without discussing with the team and confirming the position did not change. I will remove the tag if you want to reply to that comment. Otherwise, I will reply after discussing it with the team later today
[14:48] <teward> athos: any chance we can get the 'team' discussion on that one to include me?  I know the Server Team has their own internal meetings, etc. but I'd like to put my two cents in
[14:48] <teward> teeeeechnically i'm not officially part of the paid server team but still keep nginx in my radar *heavily* xD
[14:50] <teward> my opinion is "stay with the systemd docs, unless Debian changes this" but I swear I've seen this request in Debian and it was won'tfixed
[14:51] <athos> easiest way would be to start a thread in<EMAIL_ADDRESS>and remove the tag, having the discussion in the mailing list. I can start the thread now if that works for you :)
[14:51] <teward> go right ahead
[14:51] <teward> also update your LP profile - freenode is now lIbera chat for ubuntu ;)
[14:51] <teward> *is nitpicky today*
[14:52] <athos> haha thx :)
[14:53] <teward> i saw your email about triage and why you put it on the list again
[14:54] <teward> i should point out though that this is one of those things where divergence from Debian just *adds* to the delta, it's a small delta but still
[14:56] <rbasak> FWIW, I don't want to make these changes as piecemeal delta. Either we do it across the distribution as a policy, or not at all.
[14:56] <athos> yeah... I wouldn't even call it a small delta, if applied, considering how this would change package behavior/service start process
[14:56] <teward> here's a key question: what're the other httpd packages doing
[14:56] <teward> apache2, lighttpd, etc.
[14:56] <teward> i think they're doing what we're doing now
[14:57] <teward> if we choose to change this for nginx then we would have to apply this in other httpds as well to match functionality, so that 'delta' is larger because it requires a distro wide change there
[14:57] <teward> and if Debian isn't doing it it makes me question whether we should
[14:57] <teward> not that it should be the only decider, but it's still a valid q
[14:58] <rbasak> I suggest that the point made at the bottom of https://devguide.python.org/documentation/style-guide/#audience is relevant here.
[14:59] <rbasak> "vocal category of reader who is looking for vindication for one of their programming errors"
[14:59] <teward> rbasak: so, treat this as a case of "this user is being obstinate with their opinions, so stay our ground hard and reiterate our decision from circa-2020"?
[15:00] <rbasak> IMHO, this has already been extensively discussed, and a random person hitting the issue is something we already knew would happen, and so doesn't really change anything.
[15:00] <teward> (I'm uncaffeinated, assume i'm saying things 'harder' than i mean)
[15:00] <rbasak> (nor does their vote)
[15:01] <teward> ack
[15:01] <rbasak> OTOH, I'm open to reconsideration if there's widespread consensus that something needs to change, but I don't see that here.
[15:01] <teward> agreed
[15:01] <teward> two or three people != wide consensus
[15:02] <teward> also i'd support this if nginx upstream had this in their systemd service in the tarball but they don't so.
[15:02] <teward> :P
[15:02] <rbasak> Some upstreams do, and it's still wrong. The distribution should have a consistent policy across all packages and stick to it.
[15:02] <rbasak> That way users know what they need to do if they want to customize.
[15:02] <teward> agreed
[15:03] <rbasak> Also see: https://discourse.ubuntu.com/t/spec-definition-of-an-online-system/27838/5
[15:03] <teward> then i think we're going to stick to our guns, and I'm happy to remove the tag and reiterate that the general consensus of the *distribution* is to follow SystemD recommendations as was stated in 2020, and that we will not change this just because of a few people having the request
[15:03] <teward> and then point at that spec
[15:04] <teward> rbasak: who has vote powers on that spec proposal btw since it's "pending review"
[15:04] <teward> (i'd like to put my opinion on heh)
[15:04] <teward> oh foundations
[15:04] <teward> i answered my own question
[15:04] <teward> *goes to obtain coffee*
[15:05] <rbasak> teward: no "vote powers". It's Ubuntu development so done by consensus, or escalated to the TB for a decision if that doesn't work :)
[15:05] <teward> so, opinions/questions should end up on the thread then.
[15:05] <teward> i'll read it once i'm awake and see if i have anything i should voice in (a-la httpd)
[15:06] <teward> but i see you already did half my work for me (lighttpd etc.) in your last reply in April
[15:07] <rbasak> athos: there's also vorlon's opinion here: https://discourse.ubuntu.com/t/spec-definition-of-an-online-system/27838/4?u=rbasak
[15:07] <teward> but going back to the nginx bug, should I just reiterate that we're sticking to our decision and defining that network-online.target should *only* be used when it's needed?
[15:08] <teward> and that's a customization doable by sysadmins and not by default?
[15:08] <rbasak> That was the prior decision.
[15:08] <teward> unrelated: kerberoasting sucks and is a legit problem in AD environments >.<  *goes to secure a client's environment with insane firewall lockdowns*
[15:09] <rbasak> If server team people want to revisit that, then sure we can look at it again, but any conclusion should cover all the points raised in that Discourse thread and the other bugs.
[15:10] <teward> then, should this even be loaded as a discussion thread via server team email, or should we just stick to the decision we made?  I don't see a reason esp. with that spec in mind now to change our decision, and I'm happy to reiterate it
[15:12] <rbasak> I don't expect the decision to change, but will see what my colleagues think when it's raised.
[15:12] <teward> ACK
[15:12] <teward> if the decision is "we'll leave it the same as it currently is" then i'll happily reply i have a reply ready to go :p
[15:12] <teward> and i should stab debian-devel and see if they have a spec/definition for network-online.target and what defines "network online" :P
[15:12] <teward> (because curiosity)
[15:24] <teward> rbasak: i assume you guys have a meeting where you discuss this, or is this going to be an<EMAIL_ADDRESS>thread that I can chime in on?
[15:24] <teward> (though you already know my opinion)
[15:27] <teward> so if you or athos want to be my voice in your discussion feel free :)
[15:27] <teward> now if only the lists didn't get shoved into my junk mail >.>
[15:28] <rbasak> teward: we have an internal daily meeting, but if there's actually somehting to discuss we can do it on the ML or here.
[15:29] <teward> ack just let me know how it goes, i don't think there's going to be any objection to keeping status quo for nginx :P
[15:29] <teward> just keep me in the loop if possible :)
[15:29] <rbasak> Yep
[15:29] <teward> pretty sure the decision from 2020 will stand given the current state of that spec too
[15:29] <teward> and vorlon even stating directly that netowrk-online.target should be very limited in use
[15:30] <teward> and your discussion of httpd stuff (case in point: a friend of mine uses a local Apache2 and phpmyadmin on an airgapped (aka "no internet") dev server so network-online.target would not be desired there heh
[15:32] <athos> I will gather all the urls and points here and start the discussion in the ML. It seems there won't even have a discussion at all, but at least we will have a reference for the issue in the future :)
[16:31] <athos> teward: nobody seems inclined to hop into the discussion to change the current behavior we have across the distro. So, on a second thought, I don't even think we need a ML thread for that (given the discourse discussion already exists). You said you have a reply ready for that bug, is this right? do you want to go ahead and push the button? :)
[16:35] <jedininjarob> hey how small is a server install, smaller then Alpine?
[16:35] <teward> yeah i'll push the button and reply that the Server Team upholds the original decision circa-2020
[16:35] <teward> athos: ^
[16:36] <teward> i may not be part of the Canonical server team but I'm still around so :P
[16:37] <jedininjarob> imlooking to build a slim system and have tiling widow manager, for an AI build work stastion, looking for opions
[16:37] <ogra> jedininjarob, you cant really compare the two ... one is a server installation for actual machines, the other is a cloud container OS ...
[16:38] <jedininjarob> really ok,
[16:38] <ogra> jedininjarob, if you want to compare something you'd better compare alpine to the ubuntu cloud images
[16:39] <jedininjarob> nah,lol  any sudjestion then on a bare min system would a server do it?
[16:39] <jedininjarob> alpine on baremetal dumb idea them?
[16:41] <teward> athos: done.
[16:44] <jedininjarob> did i just get kicked?
[16:44] <patdk-lap> by yourself? yes, yes you did
[16:44] <jedininjarob> lol
[16:44] <patdk-lap> jedininjarob has quit (Remote host closed the connection)
[16:44] <jedininjarob> dang me
[16:46] <jedininjarob> howslim is a server install "ill put it on a laptop" to run AI stuff and tiling window manager, bad use case?
[16:46] <patdk-lap> I always install jeos/minimal for servers
[16:46] <patdk-lap> those are under a gig of diskspace
[16:46] <patdk-lap> but it removed a lot of things people normally expect
[16:46] <patdk-lap> server installs dont have window managers
[16:47] <patdk-lap> those are called desktops :)
[16:47] <jedininjarob> i need realy access to python,internet forupdate "wifi" drivers and tilingmanager othertoolsetc..
[16:47] <jedininjarob> :)
[16:58] <athos> thanks, teward!!!
[18:12] <jedininjarob> that isnt nessicarily the exactdefininstion of a markov decision processing,, markov chains are just numbered sequences USED ina certain way,  but specificaly your talkingabout input processing i think your asking is indeed validbut misguided in inplementastion....
[18:12] <jedininjarob> markov chains need a specific implementastion befor they are MARKOV chains other wise...itsjust stringsofniumbers with somemaths


[00:08] <pleia2> and reviewed+sent out mail to summary writers
[00:12] <pleia2> ooh, airplane #3 might take me home
[00:12] <pleia2> (they've gone through 2 others with "equipment problems"
[00:12] <pleia2> )
[00:15] <imnichol> pleia2, sounds like fun.  Which airline?
[00:16] <imnichol> I once got stuck at my local rural  airport while the only mechanic within an hour interrupted their dinner to drive to the airport and repair an overhead luggage rack
[00:35] <ahoneybun> pleia2, it is past the point of adding articles right?
[00:36] <ahoneybun> because the porting guide got released
[00:37] <ahoneybun> https://developer.ubuntu.com/en/start/ubuntu-for-devices/porting-new-device/
[01:08] <imnichol> Does anyone else have a very difficult time writing summaries for 90% of the i.u.c stories?
[01:55] <silverlion> good morning everybody. I'd like to drop current news from the lubuntu team in here ;) https://wiki.ubuntu.com/Lubuntu/Marketing/Press%20Releases#Lubuntu_14.04.2_available
[07:07] <PaulW2U> ahoneybun: we can add articles up to 2359 GMT on Sunday, i.e. the week's not over yet
[07:08] <PaulW2U> but that link is to the porting guide. do you have a link to a news article that says it's released?
[07:09] <PaulW2U> imnichol: yes! that's why they normally get left to last :)
[07:16] <PaulW2U> ahoneybun: Found one - http://news.softpedia.com/news/Official-Ubuntu-Phone-Porting-Guide-Published-473836.shtml
[15:41] <imnichol> Glad I'm not the only one then!
[16:58] <dcwilliams_VA> Just finished up a few summaries
[16:58] <dcwilliams_VA> Paul - are you in the UK?
[16:59] <PaulW2U> Sure am
[17:26] <PaulW2U> Summaries nearly finished and it's only Saturday - that doesn't happen too often  :)
[17:39] <imnichol> Woo!
[17:40] <imnichol> This next  week my goal is to write one summary a day for the i.u.c stories, rather than trying to sit down and hammer them all out before I hit the bars on Friday evening
[17:41] <imnichol> Anyone in here should feel free to ping me and hold me to it! ;)
[17:46] <imnichol> Looks like the only remaining summary is the cut-the-rope one
[17:49] <PaulW2U> ..for now. We still have 30 hours of the week left (GMT-wise). Links can still be added ;)
[17:53] <imnichol> PaulW2U, speak of the devil
[17:53] <imnichol> How do I add a link?
[17:54] <imnichol> i.e. is there a process or do I just throw it in the doc?
[17:55] <PaulW2U> Just copy and paste exactly as you see the existing links. Pressing return or space after the URL changes the text into a link.
[17:57] <PaulW2U> \o/
[17:59] <imnichol> Wasn't really sure where to put the story
[17:59] <imnichol> Moved it down to the "In the Blogosphere" sectin
[17:59] <imnichol> Might even belong in "Other Articles of Interest"
[18:00] <imnichol> I just think it's cool that the dev team is supporting current standards
[18:00] <PaulW2U> Blogosphere is where we put on Phoronix articles
[18:01] <PaulW2U> I'll just add a couple of space to adhere to wiki syntax
[18:01] <imnichol> Awesome
[20:41] <pleia2> imnichol: flew with Qatar Airways, very nice :)


[00:13] <Eickmeyer> OvenWerks: teward is reviewing your code for ubuntustudio-menu-add.
[00:13] <teward> cursory review
[00:14] <teward> nothing in-depth ;)
[00:14] <teward> Eickmeyer: OvenWerks: BUGS == ROADMAP, is this intentional?
[00:15] <teward> (same file twice)
[00:15] <teward> just curious
[00:15] <Eickmeyer> teward: I believe the file was supposed to be renamed ROADMAP, but the BUGS file didn't get deleted? Might've been a git collision, for lack of a better term.
[00:15] <teward> nope still present there
[00:15] <Eickmeyer> smh
[00:15] <Eickmeyer> I can fix unless you want to just kill it with fire.
[00:16] <teward> Eickmeyer: i don't have upload to this code branch
[00:16] <teward> if you can update it in the git that'd be great
[00:16] <Eickmeyer> I can. standby...
[00:16] <teward> your changelog also is UNRELEASED
[00:16] <teward> which is not a valid target
[00:16] <teward> I assume you want me to just alter that
[00:16] <Eickmeyer> Ugh... also will fix.
[00:17] <teward> eesh, native package.
[00:17] <teward> Not complaining MUCH but...
[00:17] <teward> I prefer quilts ;)
[00:17] <teward> not an impact on the review though just me shivering because Debianisms
[00:17] <teward> and some chaos i've had to deal with there
[00:17] <Eickmeyer> Yeah, it's a native package. No reason to not be native since it's for Ubuntu only.
[00:17] <teward> yep
[00:17] <teward> Eickmeyer: other than those issues I pointed at
[00:18] <teward> everything LOOKS OK
[00:18] <teward> it'll need AA review of course, but fix the things I indicated
[00:18] <Eickmeyer> Ok. Fixing now.
[00:18] <teward> for ubuntustudio-menu-add anyways
[00:23] <Eickmeyer> teward: Fixed.
[00:30] <teward> Eickmeyer: ack.  Going to run this through local sbuild with LIntian calls, as well
[00:30] <teward> give me a bit
[00:30] <teward> gotta spin an eoan chroot ;)
[00:30] <Eickmeyer> No worries.
[00:33] <teward> hmmmmmmmmmmmmm
[00:37] <teward> Eickmeyer: there's a few things in the built binaries that throw some lintian pedantic warnings
[00:37] <teward> W: ubuntustudio-menu-add: binary-without-manpage usr/bin/ubuntustudio-menu-add
[00:38] <teward> if this shouldn't have a manpage you might want an override...
[00:38] <teward> and this is when `lintian --pedantic` is run on the built binaries inside the sbuild schroot
[00:39] <teward> it passes but not sure how pedantic you want me to be with warnings
[00:40] <Eickmeyer> teward: In the past, vorlon, infinity, and sil2100 have just let that one go.
[00:40] <teward> ack
[00:40] <teward> i'll make a note of it but i'll consider it 'passing'
[00:40] <teward> since it didnt lintian-fail
[00:40] <teward> just something i noticed
[00:40] <Eickmeyer> Ok.
[00:40] <Eickmeyer> ack
[00:40] <teward> and i'm overly pedantic ;)
[00:40] <teward> and in Debian they whine more when that triggers
[00:41] <Eickmeyer> Yeah.
[00:41] <teward> builds clean, looks lintian clean except for that
[00:42] <Eickmeyer> Cool.
[00:43] <Eickmeyer> teward: When (if) you get to dpf-plugins, don't expect manpages for that either. Those plugins are something that you would only run if you already knew how to run them.
[00:43] <Eickmeyer> Live/Recording Audio Engineers, for example.
[00:45] <teward> yeah i'm just overly pedantic from the Debianisms I've had to handle :P
[00:45] <Eickmeyer> No worries.
[00:52] <teward> Eickmeyer: uploaded to NEW queue
[00:53]  * teward needs food
[00:53] <Eickmeyer> teward: Saw that, thanks!
[01:01] <teward> Eickmeyer: eoan-proposed next time though the system redirects it
[01:02] <Eickmeyer> teward: I was always told to target the release directly, letting the system redirect it.
[01:02] <teward> *shrugs*
[01:02] <teward> i'm picky ;)
[01:02] <teward> but all's good
[01:02] <teward> the system'll redirect it regardless :)
[01:02]  * Eickmeyer *thumbsup*
[01:04] <teward> OvenWerks: what Eickmeyer is NOT telling you is I want to school you in how PEP8 works :P
[01:04] <teward> and how triple-apostrophe strings are NOT comments.
[01:04] <teward> flake threw all sorts of "WTH" info level warns there :|
[01:06] <teward> Eickmeyer: OvenWerks: you do NOT want to know the complaints sarnold has
[01:08] <sarnold> ahoy pals, could I beg someone to replace all the calls to rm and cp with native python calls instead, in https://git.launchpad.net/ubuntustudio-menu-add/tree/usr/bin/ubuntustudio-menu-add ?
[01:08] <teward> sarnold: you should NACK it
[01:09] <sarnold> it'd also be a huge favour to me to rexplace the exoedit thing with an array-based execution, see https://docs.python.org/3/library/subprocess.html#subprocess.run for an example
[01:10] <Eickmeyer> Oh boy...
[01:10] <sarnold> https://docs.python.org/3/library/os.html#os.unlink
[01:10] <sarnold> the file *copy* is annoying, but this may be a suitable replacement: https://docs.python.org/3/library/shutil.html#shutil.copyfile
[01:11] <teward> sarnold: https://bugs.launchpad.net/ubuntustudio-menu-add/+bug/1831154 also please
[01:11] <teward> i would suggest you also offload your comments there
[01:11] <teward> Eickmeyer: OvenWerks: I also ran a "dig" into here with my own knowledge and though I don't see an obvious exploit mechanism, I *HATE* subprocess wrappers where not needed
[01:11] <teward> esp. in latest Python in Eoan
[01:12] <teward> so I asked AA / release team to REJECT the package as-is
[01:12] <teward> as well, all the things sarnold indicated
[01:12] <Eickmeyer> ack
[01:13] <teward> i didn't do a full code dig and though I've DONE these kinds of subprocess wraps before...
[01:13] <teward> there's inbuilt os calls for lots of these things
[01:13] <teward> and those're preferred to these subprocess wraps
[01:13] <teward> ALTERNATIVELY
[01:13] <teward> give me direct upload rights to your code base
[01:13] <teward> i'll rewrite it myself ;)
[01:13] <teward> *shot*
[01:15] <teward> oh wait
[01:15] <teward> i forgot
[01:15] <teward> my membership gives me upload :|
[01:15] <Eickmeyer> teward: Haha
[01:15] <sarnold> it's still polite to ask :)
[01:15] <Eickmeyer> teward: Go ahead. I trust you.
[01:15] <teward> i'll provide a patch for it that they can apply :p
[01:15] <teward> sarnold: and let you review it too xD
[01:19] <teward> UNRELATED also use spaces not tabs
[01:19] <teward> because tabs suck
[01:23] <teward> this... is messy :|
[01:24] <teward> sarnold: we're in Py 3.7+ in Eoan right?
[01:25] <sarnold> teward: I think so; at the moment umt search reports python 3.7 in main, 3.8 in universe in eoan
[01:25] <teward> 3.7+ is fine
[01:26] <teward> because formatstrings
[01:26] <teward> saves doing string arithmetic
[01:27] <Eickmeyer> teward, sarnold: OvenWerks does most of his development in bionic, I believe.
[01:28] <teward> Eickmeyer: they can still use formatstrings :P
[01:28] <teward> the point is that i hate this string arithmetic
[01:28] <teward> "string data1:{} data2:{}".format(value1, value2)
[01:28] <Eickmeyer> I know, I was just referring to the 3.7 vs 3.8.
[01:28] <teward> ^ condensed to: f'string data1:{value1} data2:{value2}'
[01:29]  * Eickmeyer couldn't code his way out of a paper bag, so he sticks to packaging
[01:29] <teward> but as long as it's 3.7+ it's fine
[01:29] <teward> note to self: don't code review without food
[01:36] <teward> Eickmeyer: you and OvenWerks are going to hate me
[01:36] <teward> because of this patch
[01:36] <Eickmeyer> teward: I'm not, and I hope OvenWerks doesn't.
[01:37] <Eickmeyer> I am just grateful for the contribution!
[01:38] <teward> oh this is a LARGE patch
[01:39] <teward> sarnold: oh fun fact
[01:39] <teward> your subprocess array approach?
[01:39] <teward> for the one remaining SP call?
[01:39] <teward> sp.run(shlex.split("the full command string"), ...)  <-- shortcut
[01:40] <teward> i know a few tricks LOL
[01:40] <sarnold> teward: btw I hate that approach
[01:41] <sarnold> the whole point of using the array based approach is that the programmer actually knows what the arguments are, and asking the shell, or shlex, or whatever, to split them apart, is likely to break something, or let some smartasss name a file $(id) or whatever
[01:43] <teward> sarnold: true.
 Look who's in the Ubuntu Studio chat :D
[01:43] <teward> sarnold: but in this case these args don't seem fixed that way.  We could do that though
[01:43] <teward> @tsimonq2 there's a nuke with your name on it waiting in the Lubuntu infra
[01:43] <teward> go fix it
 @teward [<teward> @tsimonq2 there's a nuke with your name on it waiting in the Lubuntu in …], Oh?
[01:46] <teward> whoopsies i forgot to attach that patch
[01:46] <teward> Eickmeyer: sarnold: patch attached to the bug
[01:46] <teward> sarnold: i think you'll be happy with it
[01:46] <teward> but the patch is HUGE because tabs -> 4-spaces
[01:46] <teward> because the other thing I found was ***mixed punctuation***
[01:46] <teward> s/punctuation/indentations/
[01:46] <teward> which throws INdentationErrors
[01:47] <teward> sarnold: this patch is not a small one, but it pulls all the subprocess wrapped rm/cp and replaces them with os.unlink/shutil.copyfile accordingly
[01:49] <teward> tsimonq2: and no there's no nuke in the infra for you to deal with
[01:49] <teward> i just wanted to drive you insane :P
[01:49] <teward> Eickmeyer has an annoying habit they picked up from me
[01:49] <teward> being insistent on asking for things
[01:49] <teward> like sponsoring
[01:49] <teward> ... or in this case NOT tearing OvenWerks a new one
[01:51] <teward> Eickmeyer: wrt developing in Bionic...
[01:51] <Eickmeyer> teward: I appreciate it.
[01:51] <teward> i dev for 3.7/3.8 in Bionic too
[01:51] <teward> pyenv is my friend
[01:51] <teward> also lets me have 3.5 for the ancient infra I have to support for some older boxes
[01:52] <teward> Eickmeyer: this'll need a run test of course
[01:52] <teward> not just a build test
[01:52] <Eickmeyer> teward: ack
[01:52] <teward> because I had to remove some of the logic that WAS in place because subprocess is gone for some calls
[01:52] <teward> the logic *SHOULD* still function as is
[01:52] <teward> but it's... eh
[01:53] <sarnold> teward: it's usually better to stuff whitespace patches into their own thing, so the substantive fixes are easier to review
[01:53] <teward> good point
[01:53] <teward> sarnold: i can split that out but in this case my IDE did the autochanging
[01:54] <teward> sarnold: still, i think you'll like this.  https://paste.ubuntu.com/p/JX8gBK6fM4/ has the code after my revisions
[01:55] <sarnold> ahhhh that's the stuff :)
[02:26]  * OvenWerks actually has his tabs set to 2 spaces width
[02:28] <OvenWerks> teward: thank you for your work. I am relatively new to python, coming from c,c++,have done perl and tcl/tk in the past as well
[02:29] <OvenWerks> my main reason for working in python at all it that it seems to be favoured and is less likey to require adding more libs (though tcl/tk is used by enough other stuff it is always there for the studio iso)
[02:32] <Eickmeyer> OvenWerks: There's a patch in the bug report if you want to apply it and play with it.
[02:33] <OvenWerks> I was looking for that... thanks.
[02:34] <OvenWerks> I can create a man page if needed, but it would just be a rehash of the included help in the GUI :)
[02:34] <OvenWerks> sorry I forgot.
[02:34] <Eickmeyer> bug 1831154
[02:35] <Eickmeyer> OvenWerks: A man page is always welcome and would get rid of that lintian warning.
[02:35] <Eickmeyer> teward: ^
[02:36] <OvenWerks> with all the tab to space fixes I can't see what he did...
[02:38] <Eickmeyer> OvenWerks: It's mostly whitespaces. I'd look at the diff if you can.
[02:39] <OvenWerks> unlink is fine though. At some point I should change the var cmd to something more descriptive
[02:48] <OvenWerks> teward: I will try to remember that for python I should for some insane reason use spaces instead of tabs. :P
[02:49] <OvenWerks> I am actually surprised there were any spaces
[02:49] <OvenWerks> must have been cut and paste
[02:52] <OvenWerks> teward: I have tried using array based execution in the past and after loosing some hair went to the define comandline, run. Leftovers from bash no doubt and much easier to read from my POV.
[02:52] <OvenWerks> anyway. I will run the patch.
[03:10] <OvenWerks> Ga!, now it doesn't work...
[03:40] <OvenWerks> Ya, 0k...
[03:52] <OvenWerks> teward: same problem... array based execution doesn't work.
[05:02] <OvenWerks> teward: I have put back in the string based command line and uploaded. I have yet to be able to get array based commands to work (I have also tried in the past) and in fact I have had problems using a joined string within the command as well... which is why a define the command line first as a string and use it. That is all that has ever actually worked
[05:03] <OvenWerks> Eickmeyer: ^^
[05:05] <Eickmeyer[m]> teward and sarnold are more worried about the security implications for this. AFAIK, they’re both east-coasters, so they’ll see this in the morning.
[06:05] <OvenWerks> Eickmeyer: maybe they can figure out why the array based execution doesn't work.
 Probably a subproccess headache
 which I run into myself
 sarnold: ^ this is usually why I hate subprocess calls.
 OvenWerks: I can fix that as well - but for some reason there was mixed indentation.  Reverting the array based call is an easy you can do yourself but the main problem was the unsafe calls to cp/rm via subprocess
 because that can easily be exploited with the right few code stabs
 though exploitability on that is LOW it's still a headache
 let me poke at this after I get to work
[13:46] <teward> sarnold: call/run don't seem to accept things properly, so i'm going to go with their initial approach which I think works.
[13:46] <teward> there's some oddness in subprocess with how commands are passed and I REGULARLY have this headache.
[13:52] <teward> OvenWerks: I condensed the 'old way' you were doing into a single line - https://git.launchpad.net/ubuntustudio-menu-add/commit/?id=f395294eb0dc1efd24be846e27974b453c5e80ff
[13:52] <teward> that's the ONLY time i'm pushing to the code
[13:53] <teward> if you and Eickmeyer / Eickmeyer[m] would like to test this that'd be great.
[13:53] <teward> i'll make a note in the bug
[13:53] <teward> if it works with that in line then that should take care of the major issues
[13:53] <teward> and i'll do another last-minute review
[13:54] <studiobot> * teward001 pours some salt on @Eickmeyer just to make sure they're pinged accordingly.
[14:37] <Eickmeyer> teward: Did you commit it to master?
[14:38] <Eickmeyer> Nm, I see that you did.
[14:56] <teward> Eickmeyer: yes?
[14:56] <Eickmeyer> I SAID nevermind. ;)
[14:56] <teward> :P
[14:56] <teward> *salts Eickmeyer anyways*
[14:57]  * Eickmeyer throws a full coffee mug at teward
[14:57]  * teward already has had 4 coffees, does not need another
[15:04] <OvenWerks> teward: cp/rm was just me not learning python well enough. The subprocess.call string formating is different and so probably works. I have always tried putting the string together with + and that did not work for me.
[15:05] <OvenWerks> I struggled with the subprocess calls for a long time before I came up with the way I finally used
[15:05] <teward> OvenWerks: i actually tested both run AND call
[15:05] <teward> with an 'echo' command
[15:05] <teward> only worked with strings
[15:05] <teward> which means I'll go digging on that later
[15:05] <teward> I COULD HAVE SWORN I got it to work
[15:05] <teward> but i'll have to go poking at my other scripts
[15:06] <teward> OvenWerks: and I have no provlem with the subprocess calls :)
[15:06] <teward> the only difference is
[15:06] <teward> instead of var = somestr; sp.call(var, ...)
[15:06] <teward> just define the string inside the call ;)
[15:06] <teward> that's the only one-line condensing I did :)
 HOLY HANNA I'm spamming myself on AndroIRC xD
[15:07] <OvenWerks> Yes that works just fine.
[15:07] <teward> yep.  And saves some memory space, albeit only a little bit :)
[15:08] <OvenWerks> I also removed some excess comments last night.
[15:09] <OvenWerks> teward: I had never seen that method of creating strings before. Is there a quick link I can use to read up on it?
[15:09] <OvenWerks> (and does it work inside of a print() as well?)
[15:10] <teward> https://realpython.com/python-f-strings/
[15:10] <OvenWerks> does it work on the right side of an =
[15:10] <teward> OvenWerks: yes, it works wherever a string would be defined
[15:10] <teward> it's actually born from "".format
[15:10] <teward> which https://www.geeksforgeeks.org/python-format-function/ is decent at explaining
[15:11] <teward> OvenWerks: but the f"foo {blah}" where blah is a variable format is 'new' enough I don't trust it on < py3.7
[15:11] <OvenWerks> cool, it may make things better in -controls too then. (no there are no cp/rm in there)
[15:11] <teward> it's supported in 3.6 but :)
[15:11] <teward> OvenWerks: indeed, there's a ton of ways to condense
[15:11] <teward> to quote sarnold, I could probably if I put my mind to it make things a lot shorter
[15:11] <teward> but :P
[15:11] <teward> I tend to backwards-compat my code for 16.04's py3.5 so I use "{}".format(var) instead
[15:12] <OvenWerks> teward: I learn by doing.
[15:12] <teward> but i've been falling in LOVE with the in-line strings :)
[15:12] <teward> yep
[15:12] <teward> well that's how you learn :)
[15:12] <teward> I learn by doing as well
[15:12] <teward> but i don't have any RECENT code examples on it :)
[15:12] <teward> keep in mind also i only JUST got coredev so my bootprints are not yet everywhere :p
[15:12] <teward> they're starting to show up though, with this package :P
[15:13] <teward> mmmmm, dark-chocolate covered peanuts... *snacks*
[15:13] <OvenWerks> coffee
[15:13] <teward> had that
[15:13] <teward> 4 cups already :)
[15:13] <teward> but caffeine doesn't negate hunger so
[15:13] <OvenWerks> I just got up and made breakfast for my son.
[15:13] <teward> indeed :)
[15:14] <OvenWerks> my eating will wait till my Yf gets up.
[15:14] <teward> 11:14 here so by now i should probably switch into 'lunch' mode soon enough heh
[15:15] <OvenWerks> Food is food, I still call meat cow and pig rather than beef and pork.
[15:19] <OvenWerks> f-strings "new"? actually it is kinds like the old school (bash, perl) ${var}
[15:21] <Eickmeyer> Holy crap, the build far is either stuck or extremely busy. 17050 jobs in the queue, 23 hour wait.
[15:21] <Eickmeyer> *farm
 OvenWerks: new for Python ;)
 Eickmeyer: yikes, there was build issues earlier
[15:34] <Eickmeyer> @teward001: cjwatson said they were doing a test rebuild.
 that would explain it
[16:34] <teward> Eickmeyer: if you need me to fast-build I can compile for amd64 for you to test sooner
[16:34] <teward> but you'll of course have to download the .deb and install
[16:35] <Eickmeyer> teward: Yeah, I coul download the .deb now and do it, tbh. It's done building, it just hasn't published to the PPA. Looks like build dispatching is also paused, so publishing is likely not to happen as well.
[16:36] <teward> i'll sbuild it on eoan amd64 local then upload somewhere standby
[16:37] <Eickmeyer> I stand corrected, it just published.
[16:37]  * Eickmeyer is installing the built deb now
[16:38] <teward> heh
[16:38] <teward> well that was a fast build now xD
[16:39] <teward> Eickmeyer: https://people.ubuntu.com/~teward/ubuntustudio-menu-add_0.1_all.deb if the PPA is slow :P
[16:39] <teward> yay for sbuild :)
[16:40] <Eickmeyer> teward: Already have it. Everything works from my tests, but OvenWerks might have some more in-depth testing.
[16:40] <Eickmeyer> OvenWerks: New build in autobuilds, you can probably just apt upgrade.
[16:41] <teward> and if that doesn't work for you I have the built binary in that link above :)
[16:41] <teward> Eickmeyer: I almost totally forgot about 'people.u.c' though as an SFTP upload point xD
[16:41]  * Eickmeyer hasn't used people.u.c, and probably could.
[17:44] <Eickmeyer> OvenWerks: Let us (me & teward) know how testing ubuntustudio-menu-add goes.
[17:44] <studiobot> * teward001 was poked
[17:44] <studiobot> * teward001 goes back to poking redis-server instead
[17:44] <Eickmeyer> hehe
[17:45]  * teward drops a crate of onions on Eickmeyer
[17:45] <teward> oops :)
[17:45] <Eickmeyer> MMmmm... walla walla sweets...
[17:47]  * Eickmeyer starts grilling the onions for burgers
[17:47]  * sarnold spills some kosher salt and slices off a big piece of onion
[17:48] <Eickmeyer> ^this guy onions.
[17:49] <teward> i'm sorry you assume that sarnold is NOT ALREADY an onion :p
[17:49] <teward> *shot*
[17:50] <OvenWerks> Eickmeyer: it may be a fewhours before I can play with it. The machine I am on is still 16.04... (son's laptop)
[17:50] <Eickmeyer> OvenWerks: No worries. teward^
[17:51]  * Eickmeyer wanders off to play a game with his son
[17:54] <teward> ack
[18:17] <teward> OvenWerks: i miiight have a way to make the 'subprocess.run' with an array work
[18:17] <teward> but we need to drop shell=True possibly
[18:17] <teward> (to sate sarnold's concerns)
[18:24] <teward> OvenWerks: Eickmeyer: specifically, http://people.ubuntu.com/~teward/array-based_subprocess_execution_of_exo-desktop-item-edit.patch
[18:24] <teward> which i THINK works proper
[18:24] <teward> but again, needs the tests :)
[18:24] <teward> no rush
[18:27] <teward> Eickmeyer: OvenWerks: http://people.ubuntu.com/~teward/ubuntustudio-menu-add_0.1_all_v2.deb <-- with that last patch
[18:27] <teward> in case you want to test :)
[18:28] <teward> (since the builders are slow)
[18:28] <OvenWerks> teward: I think the terminal was there because it uses the binary name without the path.
[18:28] <teward> possibly, but I don't think hwe have a choice so longa s the binary is in PATH
[18:28] <OvenWerks> again one of those things I tried more than one way
[18:28] <teward> OvenWerks: we could also hardcode the full path
[18:29] <teward> which is probably the even safer approach
[18:29] <teward> i don't know the full path though for that binary
[18:29] <OvenWerks> I don't suppose it is likely to move from one cycle to the next ;)
[18:29] <teward> yeah, in which case hardcode it
[18:29] <teward> i know that hardcoding things like that *tends* to be a bad thing
[18:29] <teward> but we can always patch code later if things cahnge :P
[18:29] <OvenWerks> $ which exo-desktop-item-edit
[18:30] <OvenWerks> /usr/bin/exo-desktop-item-edit
[18:30] <teward> change*
[18:31] <teward> patch updated i'll update that .deb :p
[18:31] <OvenWerks> using the full path is always considered more secure
 yes, it is
[18:32] <OvenWerks> pk won't allow anything else
 http://people.ubuntu.com/~teward/ubuntustudio-menu-add_0.1_all_v3.deb is the 3rd deb version then including the fullpath this time
 again, in case you all want to supersede the speed of the builders ;)
[18:34] <OvenWerks> teward: I won't be able to test for a few hours (prolly 1430 local (-0700))
[18:34] <teward> that's fine
[18:34] <teward> as i said no rush
[18:34] <teward> but the builders are stressed right now
[18:34] <teward> so :P
[18:35] <OvenWerks> Spending time with my Yf before she goes to work.
[18:35] <teward> no problem :)