[14:35] <gamerchick02> cmaloney, i tried Jit.si and it didn't work for my mom so we switched to Zoom. i'm not happy about that but whatever
[14:45] <jrwren> why not skype, or google hangouts or google duo or facetime?
[14:45] <cmaloney> gamerchick02: Firefox?
[14:45] <gamerchick02> yes firefox
[14:45] <cmaloney> I tried it with my parents and they had to use Chrome
[14:46] <cmaloney> it was slightly frustrating to my dad to log into Chrome, but eventually they managed
[14:46] <cmaloney> and you could see the light dawn for them on why this was useful
[14:47] <gamerchick02> jwren, i'm the only apple user in the family (ipad and i don't facetime with it), no to skype, no to hangouts, no to duo. it's too much to deal with right now, i do not have the bandwidth to help remotely right now.
[14:47] <cmaloney> jrwren: I have reasons for each, but not sure if you care to hear them
[14:48] <gamerchick02> i can't leave to drive the hour and a half-ish to her house without risking a jail sentence and a $1000 fine so i'm not taking chances and i'm not happy about it. i know WHY (to keep the richies from going to their summer homes) but dang if it's killing me
[14:49] <cmaloney> Well, it's also to contain the spread of COVID-19
[14:49] <cmaloney> But yeah, if zoom works then cool
[14:50] <cmaloney> THat's one thing I like about Zoom: they've made it really simple to onboard folks
[14:50] <cmaloney> Jitsi is working on the Firefox issues, though so hopefully it'll get better
[14:50] <cmaloney> But yeah, remote diagnostics is no fun
[14:52] <gamerchick02> nice! i'll keep that in mind. it worked for my brother in firefox but he also has a beefy PC (as do i) and she's working from a laptop
[14:53] <gamerchick02> no remote diagnostics is absolutely no fun. i cannot see what she's doing and she's afraid to touch ANYTHING so i say "click on this" and she'll question me. or i'll say what do you see? "nothing." well that's a grand old help.
[14:54] <gamerchick02> when i'm on remote help calls being helped i tell the tech EXACTLY what i see and EXACTLY what i've clicked or typed in.
[14:54] <gamerchick02> with the exception of passwords or passcodes, then i say "i'm entering my password/code"
[14:55] <jrwren> I'd LOVE to hear reasons why zoom is better than skype or hangouts.
[14:56] <jrwren> I guess if it is your typical MSFT is evil stuff, I'd rather not both you with writing it out.
[14:59] <gamerchick02> zoom is not the best. i do not care what the best is but zoom works at this point in time so i'm not going to question it. i do not have bandwidth to argue with anyone about semantics about which video call software is best when I CANNOT SEE MY MOM to troubleshoot or even just see her in person.
[15:00] <jrwren> that isn't what I mean. i'm not judging.
[15:01] <cmaloney> jrwren: Zoom doesn't require an account to use it, just the client
[15:02] <jrwren> interesting!
[15:02] <cmaloney> jrwren: Also Hangouts used to (not currently) have an upper limit of 10 people for a call
[15:02] <cmaloney> And Skype had a spam problem
[15:03] <gamerchick02> oh yes the whole account thing is one of the reasons why we're using it
[15:03] <cmaloney> Not sure if that is still true with MSFT's transition for Skype from the old client, but leaving up your skype client was bound to attract horny russian girls
[15:04] <gamerchick02> i'd rather her use some open source client on linux but getting her to use linux at this point is a lost cause that i don't have the bandwidth to get her to use either
[15:04] <gamerchick02> EW
[15:04] <cmaloney> Only one person needs a zoom account
[15:04] <jrwren> now that you mention it. that is why i closed the skype client and never used it again many years ago... until a month ago.
[15:04] <gamerchick02> i knew there was a reason why i abandoned skype
[15:04] <jrwren> thanks, that all makes sense.
[15:04] <gamerchick02> now i use skype for business every day for work but mostly screenshare and IM.
[15:04] <cmaloney> So yeah, that's why Zoom is eating MSFT and Google's lunch
[15:05] <cmaloney> Also Google kinda screwed up with their mixed messaging on the state of Hangouts and Google Meet
[15:05] <cmaloney> It's part of the reason I checked out Jami and Signal
[15:06] <cmaloney> And Google Duo feels like one of those Google Projects that gets started and has a half-life of 2 1/2 years before they kill it
[15:06] <cmaloney> see also: Allo
[15:07] <gamerchick02> see also Stadia. i predict that to be gone before 2025
[15:07] <cmaloney> And Facetime is Apple only so Zoom has the advantage there
[15:07] <cmaloney> gamerchick02: problem with Stadia is they should have kept Google Fiber to supplement it
[15:07] <gamerchick02> plus 1 to facetime. i realize that facetime is so EASY (i have used it in the past) but it's apple only and will never get ported to another system
[15:08] <gamerchick02> cmaloney, yes i agree. "every google fiber customer gets Stadia for $X extra if they want it."
[15:08] <gamerchick02> or they get a free trial for X months
[15:08] <cmaloney> This is why I'm so hot on Jitsi, because it's actual competition to Zoom from the OSS side
[15:08] <gamerchick02> i prefer PS4 and switch for gaming :)
[15:08] <cmaloney> Well, it also takes care of the crappy bandwidth issues
[15:09] <gamerchick02> oh and PC. one of the reasons why i've not bopped into the xbox arena... because almost all xbox games are on windows
[15:09] <gamerchick02> plus i'm not a halo fan. *shrug*
[15:09] <cmaloney> But alas, I'm not Google, and even sometimes I wonder if GOogle is either
[15:09] <gamerchick02> lol true. their messaging services are just a hot mess right now
[15:10] <cmaloney> I will admit that since the closure of G+ I'm not about to put in any effort into exploring Google products
[15:10] <gamerchick02> i still use hangouts but want to kill it in favor of telegram. just need one person to move over to telegram. hangouts doesn't even work on my watch
[15:11] <gamerchick02> i actually liked G+. why do they kill the good stuff... RSS, G+, hangouts (almost)
[15:12] <cmaloney> I'm really hesitant about telegram, honestly. They've done a few things that really irritate me, not the least of which is their ICO for their BS whatever-coin.
[15:12] <cmaloney> gamerchick02: There's more corporate whuffie to be had in decommissioning and creating new products than maintaining them.
[15:12] <gamerchick02> i just want fewer chat apps on my phone
[15:12] <gamerchick02> true
[15:16] <jrwren> i find it is pretty easy... don't use products by the really evil companies. IMO GOOG and FB are REALLY evil. that cuts out over 50% of the chat app market ;)
[15:17] <cmaloney> jrwren: indeed
[15:27] <gamerchick02> jrwren, that's great but then i'm vastly limiting my pool of friends (people i actually know in meatspace) that can contact me online. it's a double edged sword.
[15:29] <gamerchick02> not everyone knows that these companies are terrible (or they know and don't care). i know and care but in the interest of keeping in contact with people, i use them. *sigh*. yes i've given out my number (please do text me. please!) they insist on contacting me on facebook.
[15:30] <gamerchick02> oh and honestly there are people i only want to contact me on facebook (cue people that i'm connected to because reasons but don't want to have my mobile # also for reasons. those reasons being every dang meme and conservative thought that passes through their head)
[15:32] <jrwren> yup.
[15:32] <jrwren> its a choice.
[15:32] <jrwren> i'm ok with limiting my pool of friends.
[15:32] <jrwren> i say, "I don't use that"
[15:33] <jrwren> always hilarious when i login to FB once every 6mo or so and see old messenger messages I missed.
[15:33] <jrwren> just a week or so ago I learned how to see the cold messages on there... saw something from years ago... cuz FB can't write software for shit.
[15:38] <cmaloney> I much prefer the "I'm not on Facebook" response, but I know that's a choice. :)
[15:38] <cmaloney> My email is public if someone wants to get a hold of me
[15:44] <jrwren> i just got cold emailed by someone after answering their stackoverflow question. am i wrong to find that inappropriate?
[16:11] <gamerchick02> i'm not ok with limiting my pool of friends. many are non-technical (like through OES and Nile) and i'm not going to snub them because "i don't do facebook". what i do is LIMIT my facebook use to every other day-ish and make sure i have notifications on for events and that's it.
[17:14] <jrwren> sure. life is about choices.
[20:33] <Scary_Guy> I used Jitsi with Firefox and had no issues, but that was before the most recent major update.
[21:15] <cmaloney> I think it's mostly to do with camera / microphone access
[21:15] <cmaloney> My dad had a hell of a time getting it to work with Firefox


[00:11] <gizmobay> nevermind I figured it out
[10:14] <DaveMorris1> ok, I was having some problems with metadata been produced for mythvideo.  I have Life on Mars recorded and transcoded, however metadata been pulled down for it is for the US version.  I've created an nfo file in the directory containing the videos, which has <thetvdb seriesid="79177" /> in it (as per http://www.mythtv.org/wiki/FillMythMetadata.pl#NFO_Files) however it doesn't seem to be used
[10:14] <Zinn> [www.mythtv.org] FillMythMetadata.pl - MythTV
[10:47] <DaveMorris1> discovered the problem and filled a bug for it. #707903
[10:47] <DaveMorris1> bug #707903
[10:47] <Zinn> Bug 707903 in mythplugins (Ubuntu) "Example series name overrides enabled by default in jamu.conf" [Undecided, New] http://www.launchpad.net/bugs/707903
[17:30] <uW> hey folks i'm trying find a video card that has s-video out to connect to a regular old tv...that hopefully it won't require too much tweaking
[17:39] <mrand> uW: I'd search with google using "s-video OR svideo", or on ebay.  Also, Newegg has a power search that you can use:  http://www.newegg.com/Product/PowerSearch.aspx?N=100007709&IsNodeId=1&SubCategory=48&GASearch=3
[17:39] <Zinn> [www.newegg.com] Newegg.com - Computer Parts, PC Components, Laptop Computers, LED LCD TV, Digital Cameras and more!
[17:41] <uW> thanks mrand!!! ..i was wondering because i remember ati drivers had issues in linux..
[17:43] <uW> and i was searching the forums for working hardware configs, but the last mention of svideo in that thread was from 2009 so i was wondering if newer cards would be easier to setup
[17:48] <mrand> uW: Despite AMD promising last year (or was it the year before?) about better drivers, I've not heard anyone bragging on them, so yeah, I'd lean towards the newest Nvidia you can find.  I saw a few that had DVI output, which can be used witha  converter cable to drive an HDMI tv, so it could be somewhat future proof.  But I wouldn't spend extra for that.
[17:51] <uW> nice..
[17:51] <mrand> uW: looks like there are some s-video cards that even support VDPAU (hardware offload/decode).  You can find the VDPAU list on the mythtv wiki.
[17:53] <uW> i didn't even know about VDPAU
[18:45] <rhpot1991> s-video thats crazyness
[18:46] <rhpot1991> could prob find some vdpau capable pci card to use
[19:06] <mrand> rhpot1991: there are 20 moderately recent Nvidia cards, and a few quite new ones (including a GTS 250 and a 260) with PCIe and s-video.  If they'd been available back when I built my system, that's what I would have gotten (since I had standard def).
[19:40] <uW> yeah..i knw s-video is nutz but i haven't been really compelled to upgrade my tv..


[00:01] <xevious> nacc: Do I have to do anything to clean the source repo before running debdiff?
[00:01] <xevious> All I've done in it was run `dpkg-buildpackage -S -us -uc -d`
[00:02] <nacc> xevious: that would clean it (-nc would not)
[00:02] <nacc> xevious: that should generate your new dsc
[00:02] <xevious> Thanks... just making sure there wasn't anything extra. Filing the bug now.
[00:03] <nacc> xevious: i'd let you know in the bug if there is :)
[00:09] <nacc> xevious: i'm doing php-horde-{argv,auth,autoloader}
[00:09] <nacc> xevious: i have a feeling it's not going to make sense to retrigger much more for php-defaults until we get all the new uploads in
[00:10] <xevious> I agree.
[00:11] <xevious> I can churn through several of these PHPUnit ones now that I've got the workflow down.
[00:11] <nacc> xevious: yeah, it's pretty repetitive
[00:11] <nacc> things to grep for PHPUnit_, setExpectedExpectation, getMoc
[00:11] <nacc> *getMock
[00:12] <nacc> and then for php7.2 itself, count( and i'm just finding create_function
[00:12] <xevious> nacc: https://bugs.launchpad.net/ubuntu/+source/php-guzzlehttp-promises/+bug/1749850
[00:21] <xevious> nacc: Also, I let the PHP_CodeSniffer lead dev know that we've currently got a version with known issues packaged: https://github.com/squizlabs/PHP_CodeSniffer/pull/1899#issuecomment-366100156
[00:21] <nacc> xevious: thanks
[00:22] <nacc> yeah, and if it's not a feature thing, but a bugfix changes, we aren't bound to Feature Freeze
[00:22] <nacc> worst-case, we can backport the fixes back
[00:22] <nacc> xevious: but i expect we'll get lots of bug rreports (or none as people are using composer directly) for these packages in the next few months
[00:22] <xevious> nacc: If those php-guzzlehttp-promises changes look good, I'll move on to the next package with the "Class 'PHPUnit_Framework_TestCase' not found" issue.
[00:24] <xevious> (I'll skip over any Horde packages...)
[00:24] <nacc> xevious: it looked ok, except i think your debdiff's chagne to bootstrap.php may have had some local context? i'm not sure
[00:24] <nacc> xevious: it didn't apply cleanly here
[00:26] <nacc> xevious: tbh, for cases like this, i should have said, it's eaiser to give me a debdiff (really just a patch) to apply from the uupdated repo to the version you want me to build
[00:26] <nacc> so that i can avoid the uupdate itself as part of the patch
[00:27] <xevious> Isn't that what I gave you?
[00:27] <nacc> xevious: what you gave me appears to be the full debdiff (incl. the uupdate itself)
[00:27] <nacc> if that makes sense
[00:27] <nacc> hrm, uscan for me is not reporting a new upstrea version
[00:27] <nacc> did you have to modify the watch file?
[00:27] <xevious> I didn't
[00:28] <nacc> i'm admittely on bionic
[00:29] <xevious> About the full debdiff: when I ran debdiff, it complained about not having a directory for the 1.1.0 version to generate the diff from. So, I pulled another copy of 1.1.0 and made a debdiff that includes the uupdate. How would I generate it against the already uupdated version?
[00:30] <xevious> I built/tested it on a xenial system, using pull-lp-source to do the initial download.
[00:33] <nacc> xevious: i meant you can just give me a patch (something like): cd <old srcpkg>; uscan; uupdate ../new tarball; cd ..; cp -aR <new srcpkg> <new srcpgk>.bak; cd <new srcpkg>; <make changes>; cd ..; diff -urpN <new srcpkg>.bak <new srcpkg> > debdiff; lp-attach debdiff
[00:33] <nacc> xevious: since the first bits of that i have to do locally anyways, as i need th eorig tarball to build it to sponsor it :)
[00:34] <xevious> Want me to do that for you on this one or just the ones going forward?
[00:34] <nacc> going forward, i think; i'm working on this one now
[00:37] <nacc> xevious: those php-horde ones i just entioned all uploaded, btw
[00:37] <nacc> *mentioned
[00:38] <xevious> Looks like you need to bump php-mockery on i386.
[00:40] <xevious> (It's still showing regressions and is the only arch listed for the old version on the 'excuses...' page.)
[00:41] <nacc> xevious: thanks
[00:42] <nacc> xevious: did you make changes to the upstream Makefile?
[00:43] <xevious> I did not
[00:43] <xevious> Intead of removing their 'test' target, I added an empty 'override_dh_auto_test' target to debian/rules.
[00:43] <nacc> xevious: oh i see what's going on
[00:43] <xevious> I removed a patch to the Makefile
[00:43] <nacc> xevious: you were in a patches applied state
[00:43] <xevious> Uhoh
[00:44] <nacc> so i think it got a bit confused
[00:44] <nacc> so the patch is dropped in your debdiff
[00:44] <nacc> or maybe i am
[00:44] <xevious> Which patch?
[00:44] <nacc> let me do this by hand :)
[00:44] <xevious> The one that changes vendor/bin/phpunit to phpunit?
[00:44] <xevious> I removed that patch.
[00:44] <nacc> right, but sponsor-patch is claiming that it is still happening, and im' not sure why
[00:45] <xevious> The changes were simple. Want me to redo it with your suggested workflow?
[00:45] <nacc> it's ok, i can fix it up locally
[00:45] <nacc> so the problem is your debdiff is totally correct
[00:46] <nacc> except if you're already in a patches applied state (e.g., after just extracting the source package normally)
[00:46] <nacc> xevious: ah you're missing a changelog entry and a update-maintainer run
[00:46] <nacc> hrm, no you're not
[00:46] <nacc> well the latter yes, but for some reason patch didn't see your change to changelog
[00:46] <nacc> PEBKAC, nm
[00:47] <xevious> update-maintainer?
[00:47] <nacc> xevious: marks the package as being matinained by ubuntu
[00:47] <nacc> so that debian is not contacted for issues in it
[00:48] <nacc> also fixed yoru version (i thought uupdate did this correctly) it should have been 1.3.1-0ubuntu1
[00:48] <nacc> because we are going ahead of debian
[00:49] <xevious> Yeah, I set the version when I wrote the changelog with dch. I'll stick to what uupdate recommends.
[00:49] <nacc> yep
[00:49] <nacc> also, i'm inserting a bug reference in the changelog
[00:50] <nacc> this way LP will close the bug for us when the package migrates
[00:50] <xevious> Cool
[00:50] <xevious> Yay automation
[00:52] <rbasak> nacc: mysql-5.7 migrated. Thanks!
[00:53] <rbasak> (I assume it was something you did, judging from your activity here)
[00:53] <xevious> nacc: So, I hate to be a PITA, but should we update to PHPUnit 7? Support for PHPUnit 6 ends a little less than a year into 18.04's life. PHPUnit 7 is at least supported until a couple months before 20.04 comes out.
[00:54] <xevious> I'm imagining the look of rage on nacc's face.
[00:56] <nacc> rbasak: yeah i finally got the right set of triggers
[00:56] <nacc> rbasak: and well, fixed that package too :)
[00:57] <nacc> xevious: heh, how bad is the backwards compat
[00:57] <nacc> xevious: the issue is this mess is already pretty bad
[00:57] <nacc> and, tbh, we've done no updates to phpunit 5.1.3
[00:58] <nacc> in xenial
[00:59] <xevious> It's hard to tell how bad it'd be: https://phpunit.de/announcements/phpunit-7.html
[01:00] <xevious> Looks like it could be a pain.
[01:01] <nacc> xevious: tbh, my vested interest is pretty minimal
[01:01] <nacc> while i agree fully with what you are saying, phpunit itself is in universe
[01:01] <xevious> Ok, let's not do it.
[01:01] <nacc> and it would a ton (more) delta to ubuntu packages :)
[01:02] <xevious> I'm sold. PHPUnit 6 it is.
[01:02] <xevious> Guzzle dev does not want to add the tests back into the archive and asked if we can use `git clone` instead: https://github.com/guzzle/promises/pull/87#issuecomment-366109645
[01:04] <nacc> xevious: this may be worth an email to the debian devs
[01:04] <nacc> xevious: i'm not entirely sure what the best practice is from a packaging perspective
[01:04] <xevious> Yeah, it kind of blows up the whole process, since `uscan` can't do its thing without a web page to parse.
[01:05] <xevious> Well, really it's because `uscan` only does HTTP downloads.
[01:06] <xevious> Oh wait
[01:06] <xevious> It does do git?
[01:07] <nacc> xevious: so it does, but only for tar.xz
[01:07] <nacc> which is fine
[01:07] <nacc> it does say 'last resort' :)
[01:07] <xevious> Yeah, well this is the last resort.
[01:08] <nacc> yeah i suppose so :)
[01:08] <xevious> From the man page...
[01:08] <xevious> > If the upstream publishes the released tarball via its web interface, please use it instead of using this mode.
[01:08] <xevious> ...however, if they've removed the files you need from the released tarball available via the web interface...
[01:09] <xevious> Alright, let me read up on uscan and see if I can make a new version that retains the tests.
[01:10] <nacc> new php-mail-mime is in bionic-proposed, i'm retriggering now
[01:14] <nacc> slangasek: i'vetried to reproduce the current failure with php-defaults & php-horde-core in bionic-proposed with: `autopkgtest -U -s --apt-pocket=proposed=src:php-defaults,src:php-horde-core php-horde-core -- autopkgtest-virt-lxd autopkgtest/ubuntu/bionic/amd64` but it passes here
[01:14] <nacc> slangasek: do you have any idea what i'm missing?
[01:15] <nacc> xevious: i need to eod/afk soon, but i'll check back in later and be back online/active tmrw morning after kid dropoff
[01:16] <slangasek> nacc: the passage of time?  is the failure still reproducible if you retry it on autopkgtest.u.c?
[01:16] <xevious> nacc: Which TZ are you in? When's morning for you?
[01:16] <xevious> I'm Eastern US...
[01:16] <nacc> xevious: PST US
[01:17] <nacc> slangasek: i thougth so becuase i'm pretty sure i retriggered it
[01:17] <nacc> slangasek: but let me try again and see
[01:18] <xevious> Cool. I'll get all my non-PHP-packagin things out of the way in the morning tomorrow, that way I can be totally focused on this once you're online.
[01:18] <nacc> xevious: sounds good, thanks!
[01:18] <xevious> nacc: I'm going to rework this to try to add the tests back in before calling it a day.
[01:19] <nacc> xevious: sounds good, feel free to add the debdiff tat results in the bug (based upon the version now in b-p)
[01:19] <xevious> Will do
[01:19] <nacc> xevious: and waiting on php-guzzlehttp-promises to publish then i can retrigger those
[01:23] <xevious> nacc: Can you retrigger all the guzzle packages to run their tests with this new php-guzzlehttp-promises package, assuming its tests complete?
[01:42] <xevious> nacc: I got it to detect the new version using git, but it's failing to download it.
[01:43] <xevious> it=uscan with an updated debian/watch
[01:43] <xevious> > uscan: Newest version of php-guzzlehttp-promises on remote site is 1.3.1, local version is 1.1.0
[01:43] <xevious> > uscan:    => Newer package available from
[01:43] <xevious> >       https://github.com/guzzle/promises.git refs/tags/v1.3.1
[01:43] <xevious> > Undefined subroutine &main::getcwd called at /usr/bin/uscan line 3370, <REFS> line 72.
[01:44] <xevious> ?!
[01:44] <xevious> That line is: my $curdir = getcwd();
[01:44] <roaksoax> xevious: uscan will downalod to ../
[01:45] <xevious> Yeah
[01:45] <roaksoax> so you would be able to cd ../<package>-<version>
[01:46] <xevious> I'm trying to update the watch file to download based on a git tag instead of parsing a web page.
[01:46] <Unit193> That's not entirely accurate.
[01:46] <xevious> It's correctly parsing the git repository, but failing immediately upon entering the git-specific section of the `uscan` code.
[01:46] <tsimonq2> I hate doing that with GitHub *so* much.
[01:46] <tsimonq2> I just copy/paste from other packages I maintain.
[01:46]  * tsimonq2 finds an example
[01:47] <tsimonq2> This is for src:vc:
[01:47] <tsimonq2> version=4
[01:47] <tsimonq2> opts=filenamemangle=s/Vc-(\d\S+)\.tar\.gz/vc_$1\.orig\.tar\.gz/ \
[01:47] <tsimonq2>   https://github.com/VcDevel/Vc/releases .*/Vc-@ANY_VERSION@@ARCHIVE_EXT@
[01:49] <xevious> tsimonq2: For this one, I need to clone via git instead of downloading the latest release via HTTP. They added a .gitattributes file that prevents all the tests from being included in any archives.
[01:51] <xevious> Ok I found the bug.
[01:51] <tsimonq2> Ok cool
[01:51] <xevious> `/usr/bin/uscan` doesn't have `use POSIX;` any where in it.
[01:51] <xevious> *anywhere
[02:06] <xevious> nacc: Ok my plan was foiled anyway: uscan's git mode uses `git archive` behind the scenes, so the resulting tarball won't include the test files.
[02:24] <xevious> That lack of `use POSIX;` has been fixed in a newer version of `uscan`.
[02:25] <xevious> They switched to `cwd()` instead of `getcwd()`: https://anonscm.debian.org/cgit/collab-maint/devscripts.git/tree/scripts/uscan.pl#n4435
[02:27] <xevious> So, that's currently broken in 16.04.
[02:29] <nacc> xevious: ack re: guzzle
[02:31] <nacc> slangasek: fwiw, retrigger didn't help ... should i retry with all-proposed=1? i can't reproduce this error<EMAIL_ADDRESS>[02:32] <xevious> nacc: I'm done. Have a good night. See you on the onlines tomorry.
[02:46] <xevious> nacc: Looks like php-parser needs to be prodded for ppc64el.
[04:27] <tsimonq2> tjaalton: Looking more at this patch that fixes Qt with the new mesa, there's some problems upstream with it getting approved. Solus and openSUSE have the patch now but I think generally in Ubuntu and Debian we're in agreement that we shouldn't follow suit until it's ready for review upstream. I'll keep you posted, but that's where it's at right now.
[04:54] <nacc> xevious: thanks, retrigged
[04:54] <tjaalton> tsimonq2: ok, good to know
[04:57] <tsimonq2> tjaalton: Did you get a chance to look at that xorg script that doesn't follow the XDG spec?
[04:57] <tsimonq2> (for lack of a better reference... heh)
[04:57] <tjaalton> not yet
[04:57] <tsimonq2> Alright.
[08:27]  * mvo hugs rbalint for automatic kernel cleanup in unattended-upgrades
[08:36] <rbalint> mvo: :-)
[08:45] <Unit193> juliank: Pokepoke?  Did you happen to see my ping the other day?
[10:03] <doko> jamespage, fyi: <zigo> doko: FYI, I'm currently flipping the switch to Py3 for all OpenStack stuff.
[10:53] <jamespage> doko: yeah that's quite optimistic
[10:55] <doko> jamespage: debian imports are still on ...
[10:55]  * jamespage shrugs
[10:56] <jamespage> doko: debian and ubuntu don't merge/sync on openstack packages anyway
[10:56] <jamespage> doko: and zigo is putting all of that work into experimental first
[11:04] <doko> ahh, ok
[11:25] <ahasenack> hi, could an AA please take a look at the new queue for this libzstd sru please?
[11:25] <ahasenack> https://launchpad.net/ubuntu/xenial/+queue?queue_state=0&queue_text=
[11:25] <ahasenack> xenial, artful
[11:28] <jamespage> doko: and his freeze is alot further away than ours :-)
[11:29] <jamespage> based on my exp of the single openstack package we have migrated, there are lots of paper cuts and its not fully backed into the upstream testing
[13:02] <pitti> cjwatson: hello Colin, how are you?
[13:02] <pitti> cjwatson: I'm trying to change https://code.launchpad.net/~pitti/systemd/+git/debian to the new location at salsa.d.o.
[13:02] <pitti> I can't seem to find that - easier to delete and recreate the branch? or does that need some admin review too?
[13:06]  * pitti deletes and recreates it
[13:14] <jbicha> doko: ring FTBFS in Ubuntu and has no rdepends. Would you be interested in kicking it out of bionic when I do the evolution-data-server transition?
[15:35] <dgadomski> hello, could anyone please take a look at bug #1644662? there's a trivial patch to be sponsored there, thanks
[15:46] <jbicha> dgadomski: the bionic part of that is fixed in https://ftp-master.debian.org/new/gnome-themes-extra_<IP_ADDRESS>-1.html
[15:46] <jbicha> upstream changed the source package name so it'll need to go through the new queues
[15:47] <jbicha> unless you were in a hurry and wanted it in bionic faster so that you could do a SRU?
[15:48] <dgadomski> jbicha: exactly, the fact it's missing in bionic is blocking our users waiting for SRU in xenial
[15:49] <slashd> jbicha, if you sponsor bionic (which is a SRU requirement). I'll sponsor dgadomski for the stable release with my SRU uploader right.
[15:51] <jbicha> slashd: ok, I'll upload it to bionic now
[15:52] <slashd> jbicha, tks
[15:52] <slashd> dgadomski, ^
[15:52] <slashd> ddstreet, fyi ^
[15:52] <dgadomski> thanks jbicha
[15:53] <ddstreet> thnx
[15:56] <jbicha> dgadomski: done: https://launchpad.net/ubuntu/+source/gnome-themes-standard/3.22.3-3ubuntu2
[18:16] <xevious> nacc: Good morning. How are things looking on your end? I updated the gist this morning: https://gist.github.com/iammattcoleman/88013cb5f92105b15a66ee2ada442a16#file-2018-02-15_181233_php-defaults_issues-md
[18:29] <nacc> xevious: uploaded a few horde fixes already
[18:29] <nacc> xevious: otherwise same old same old )
[19:03] <xevious> nacc: What about just removing unused packages? The Sabre libraries are unmaintained and only two packages are showing any reverse-dependencies: php-sabre-dav, which uses php-sabre-vobject. Can we remove the other Sabre packages?
[19:04] <xevious> php-sabre-dav is only used by php-horde-dav
[19:04] <nacc> xevious: can you see if they are removed in debian testing (rmadison -u debian <srcpkg>) and if there are bugs filed there
[19:08] <xevious> nacc: They're all showing "source, all" in both stable and unstable when I run rmadison on them.
[19:09] <nacc> xevious: ah that emans removed from testing
[19:10] <xevious> Ah, yeah. php-sabre-dav shows a lot more than just stable and unstable.
[19:10] <nacc> https://bugs.launchpad.net/bugs/1749783
[19:10] <nacc> xevious: feel free to add srcpkg task there
[19:10] <nacc> (also affects distribution/package)
[19:12] <nacc> xevious: also, i would appreciate a sanity check if you can. Can you run the autopkgtest for php-horde-core locally with just php-defaults from proposed (or all proposed) and see if it passes?
[19:21] <xevious> nacc: Running it with all of proposed, since I haven't learned how to enable a single package from proposed yet.
[19:22] <nacc> xevious: something like --apt-pocket=proposed=src:<srcpkg>, or =proposed=<binpkg>
[19:22] <xevious> Oh, that's pretty simple.
[19:23] <nacc> yeah it's handy
[19:23] <nacc> and that's basiclaly what the retry triggers end up translating too
[19:23] <nacc> *to
[19:25] <xevious> The Zeta components are another thing I'd like to see phased out, since they're also very old and unmaintained. However, they're used by `phpab` (only, nothing else uses them), but that's a build dependency of a ton of PHP packages.
[19:26] <nacc> xevious: does phpab depend on it upstrea too?
[19:27] <xevious> Yes
[19:27] <nacc> xevious: yeah hard for us to diverge there
[19:27] <xevious> Although, if we switch to having the packages contain their full Composer dependency stack, then it wouldn't matter.
[19:28] <nacc> xevious: yeah i'm drafting that up soon
[19:28] <nacc> although i'm going the other direction
[19:28] <nacc> let's drop php* in universe :)
[19:28] <nacc> with your suggestion hopefully being a middle ground if there is pushback
[19:29] <xevious> There are several PHP applications that sysadmins probably want to be able to install via packages.
[19:29] <xevious> Zabbix, etc.
[19:29] <nacc> imo, i think they should be snaps
[19:29] <nacc> not debian packages
[19:29] <nacc> the packages get out of date too quick
[19:30] <nacc> and if they are snpas, we might be able to get the upstream to maintain them :)
[19:30] <nacc> we can provide the infrastructure to use for building the snap using the right dependencies (basically the php runtie)
[19:30] <nacc> but it doesn't really make sense for, e.g., me to try and maintain zabbix in ubuntu
[19:30] <xevious> The thing slowing down the packages is just the fact that we can't have two different versions of the same PHP library installed via APT.
[19:30] <nacc> i never have used it :)
[19:31] <nacc> well, there is that and there is backwards-incompatible changes
[19:31] <nacc> we are in between both now
[19:32] <xevious> So, since those sabre packages aren't in testing, does that mean we can remove them from bionic?
[19:32] <nacc> xevious: should be ok, yeah
[19:32] <nacc> xevious: they can then come back in via unstable and get wedged in proposed separately, if they gt fixed
[19:42] <nacc> xevious: making good progress on horde
[19:42] <nacc> it's just all knotted together
[19:42] <nacc> so it's not worth me retrying too much until i get them all fixed
[19:47] <nacc> xevious: any luck getting php-horde-core to fail? i'm stumped no it
[19:47] <nacc> *on*
[19:49] <ahasenack> is it ok, in general, to call apt-cache policy in a maintainer script like postinst?
[19:50] <ahasenack> I'm wondering about locks and such
[19:50] <nacc> ahasenack: is this to see if a package is isntalled?
[19:50] <ahasenack> sort of, it's to see if a repository is available
[19:50] <ahasenack> like a ppa
[19:50] <xevious> nacc: No, it passed. Lots of tests that "need some love"
[19:51] <nacc> xevious: yeah, that's what i see too
[19:51] <ddstreet> jbicha re: gnome-themes-standard, it seems the pkg does a fancy dance to update the debian/control file 'Uploaders:', based on content of the currently-installed /usr/share/gnome-pkg-tools/1/rules/uploaders.mk file, you aware of that?  should i just let that field get upated and sponsor/upload the sru with a changed Uploaders: entry?
[19:51] <nacc> xevious: but consistently fails on launchpad :/
[19:51] <nacc> xevious: i'll come back to it last
[19:52] <nacc> ahasenack: hrm
[19:52] <ddstreet> jbicha e.g. for artful sru, it changed the control file Uploaders as:
[19:52] <ddstreet> -Uploaders: Dmitry Shachnev<EMAIL_ADDRESS>Jeremy Bicha<EMAIL_ADDRESS>Laurent Bigonville<EMAIL_ADDRESS>Michael Biebl<EMAIL_ADDRESS>[19:52] <ddstreet> +Uploaders: Dmitry Shachnev<EMAIL_ADDRESS>Emilio Pozuelo Monfort<EMAIL_ADDRESS>Laurent Bigonville<EMAIL_ADDRESS>Michael Biebl<EMAIL_ADDRESS>[19:52] <ahasenack> I could grep /etc/apt/sources.list.d/*, also maybe /etc/apt/sources.list
[19:53] <ahasenack> but apt-cache policy would also tell me if the repo I'm looking for has pinning
[19:53] <ahasenack> the use case is that a new version of ua-tools will enable pinning for the fips repository, but only for new installs
[19:53] <nacc> ahasenack: yeah, it just seems ... not great, to parse that output
[19:53] <ahasenack> and I'm wondering how to check a) that fips is in use already (the tool itself uses apt-cache policy + uname -r);
[19:54] <ahasenack> and b) if pinning is configured already or not
[19:54] <ahasenack> it looked more resilient to use apt-cache policy than to look for the specific config files we create
[19:55] <ahasenack> but I might as well call the case of the user having renamed the files a corner case
[19:55] <nacc> ahasenack: yeah, i'm just not sure either is great :)
[19:56] <ahasenack> right
[19:56] <xevious> nacc: I'm going to do the Zeta packages, since they have to be updated for phpab.
[19:56] <nacc> xevious: thanks
[19:56] <nacc> xevious: did you look at php-numbers-words alrady?
[19:56] <nacc> xevious: beause afaict, we just have horde and zeta and sabre right now?
[19:57] <xevious> php-numbers-words is another old, unmaintained project.
[19:57] <xevious> It's only *recommended* by php-text-captcha, not a hard requirement.
[19:57] <nacc> does it pass with the sed?
[19:57] <nacc> i'll check
[20:06] <nacc> xevious: yea looks like it will, needs a count replacement too
[20:06] <nacc> will do it after kid pickup
[20:30] <xevious> nacc: Should I run `quilt pop -a` before generating the debdiff?
[21:01] <xevious> nacc: Can you check out the patch on this ticket? https://bugs.launchpad.net/ubuntu/+source/php-zeta-unit-test/+bug/1750041
[21:02] <xevious> nacc: If it looks good, can you merge it and rerun the tests for php-zeta-base and php-zeta-console-tools with it?
[21:03] <xevious> nacc: I'm doing a non-marathon day today, so I'll be calling it quits soon (going to the G3 concert in NYC!)
[21:11] <jbicha> ddstreet: all the Debian GNOME pacakges do that debian/control.in thing. I wouldn't worry about it :)
[21:12] <jbicha> the SRU Team doesn't worry about that field so either change it or don't change it is fine
[21:33] <ddstreet> jbicha awesome, i figured as much, thnx
[21:36] <nacc> xevious: reviewing it now
[21:41] <nacc> xevious: thanks! enjoy the show!
[22:28] <cjwatson> pitti: I could've done it, but was on leave today.  I see you deleted and recreated it, so fine.
[22:30] <nacc> why would request.cgi complain about a non-existent package only for certain archs (e.g., i386) when it's a all binary package? and it works for some of the arches
[22:31] <nacc> is it just a matter of things being copied to the rigth spot?


[02:02] <xerebz> is there some timeout to the console? i'm leaving an apt-get installing and after a couple minutes of being idle, the monitor turns off and it seems like the install is halted until you move the mouse..
[04:58] <xerebz> the ubuntu demo image has a timeout of the screen and it seems like the system too.. is there a way to disable this?
[04:58] <xerebz> like an idle timer until the screen goes blank
[08:05] <sveinse> (How) can I download an ubuntu source package for natty armel from my maverick amd64 host?
[08:08] <amitk> the source package should be the same regardless of arch
[08:09] <amitk> so if you have the right deb-src lines 'apt-get source <package>' should work
[08:15] <cooloney> sebjan: hi sebjan, are you around?
[08:30] <sebjan> cooloney: hi, yes!
[08:36] <cooloney> sebjan: i just updated the status of bug 633227
[08:36] <ubot2> Launchpad bug 633227 in linux-ti-omap4 "instabilities with highmem activated" [High,Confirmed] https://launchpad.net/bugs/633227
[08:38] <sebjan> cooloney: yes, I saw that. I cant' remember if I tested with an old panda prototype or with a official one
[08:38] <sebjan> cooloney: but I know that I tested also on Blaze with an E2.1 chip and I reproduced the issue there
[08:39] <sebjan> I can make a test with a recent panda, but I don't expect any surprise here
[08:39] <hrw> cooloney: I have mem=1G problems on EA1 and on A1
[08:39] <hrw> es2.0 and es2.1
[08:44] <cooloney> yeah, but Ming Lei can't reproduce that.
[08:45] <cooloney> and with mainline kernel and Angstrom file system, system is unstable when building kernel
[08:45] <cooloney> i'll ask him to provide some information about his board
[08:46] <hrw> cooloney: let he fill tmpfs with 512MB of data first
[08:46] <hrw> it helped for me to get it fail faster
[08:48] <cooloney> hrw: hmmm. ok, i will let him know
[08:51] <persia> sveinse, Note that if you need a *natty* package from a maverick system, you'll need to put a natty deb-src line in sources.list (or apt-get source in a natty chroot)
[08:51] <sveinse> persia, so I discovered. thanks
[14:01] <XorA|gone> grrrrrrrrrrrrrrrrrrrrrrrrrrrr
[14:09] <ogra> grrrrr ?
[14:18] <XorA|gone> just grrrrr
[19:01] <janimo> rsalveti, so rootstock needsa chaging?
[19:01] <rsalveti> janimo: yup, just to get the omap3 kernel
[19:01] <rsalveti> easy change
[19:02] <rsalveti> was planning to work on this soon
[19:02] <rsalveti> together with other rootstock changes
[19:02] <ogra> its a trivial change
[19:02] <rsalveti> yup, but need testing
[19:02] <ogra> grrr .... still no trace of unity-2d at http://ports.ubuntu.com/ubuntu-ports/pool/main/u/
[19:02] <janimo> ah ok, I did not know rootstock did something hardcoded with kernel name
[19:03] <ogra> it pulls from the netinstall dir
[19:03] <rsalveti> janimo: yup, getting the versatile one
[19:03] <ogra> since we have a plain vmlinuz there
[19:03] <rsalveti> only when using the full emulation mode
[19:03] <ogra> yep
[19:05] <topfs2> rsalveti, not sure if you saw it but I have xbmc + gstreamer with h264, the other codecs are being a little pain (mostly because I'm not sure what the demuxer should output as caps, talking with gstreamer crew about this)
[19:06] <topfs2> this is with our player and all our post-processing stuff
[19:06] <rsalveti> topfs2: cool, that helps with most of the cases already
[19:06] <rsalveti> good to know
[19:07] <rsalveti> once you have it working with gst it shouldn't be that hard to support other formats
[19:07] <rsalveti> but I don't know the code
[19:07] <topfs2> its a successful poc, have quite a lot in school atm so not sure when I will be finishing it. I have no doubt that we can add more formats as time progress
[19:07] <topfs2> have a vaccation comming up but will try to clean it up after that and push to a branch so the code is available for the world :)
[19:08] <rsalveti> topfs2: awesome
[19:08] <topfs2> off to school again now though :)
[19:08] <topfs2> ttyl
[19:09] <rsalveti> later
[21:34] <ogra>  netbook-meta (2.040) natty; urgency=low
[21:34] <ogra>  .
[21:34] <ogra>    * Refreshed dependencies
[21:34] <ogra>    * Added transmission-gtk to netbook-recommends
[21:34] <ogra>    * Added unity-2d to netbook
[21:34] <ogra> \o/
[21:34] <ogra> curious if the images will build with that :)
[21:50] <rsalveti> cool
[22:02] <ctyler> davidm: prpplague in #pandaboard said we're building similar things. PandaStack being built to supplement our build farm: http://twitgoo.com/1z7sxh
[22:03] <davidm> Indeed you are
[22:04] <davidm> ctyler, http://dmtechtalk.wordpress.com/
[22:04] <davidm> I'm planning on 20 pandas in a single 3U box
[22:04] <davidm> all remote controlable and with a secure booting method
[22:05] <ctyler> we're adding 15 Pandas to the Fedora-ARM build farm in stack form
[22:05] <davidm> Also see: https://blueprints.launchpad.net/ubuntu/+spec/other-arm-n-public-panda-ppa-build-cluster
[22:06] <davidm> I'm going to provide part numbers and directions so anyone can build 3U 20 device stacks
[22:07] <davidm> ctyler, we are designing a daughter card that will allow a secure boot method, as panda has no secure booting
[22:07] <davidm> anyone can overwrite the SD card, the daughter card stops that
[22:08] <davidm> I'm just waiting on my pandas to free up
[22:09] <ctyler> cool :-)  wish these things were shipping faster!
[22:09] <davidm> ctyler, you and me both :- you and me both......
[22:10] <ctyler> we just got our last 3 of 15 ordered in November, so they're starting to move, but man.
[22:11] <davidm> Yep
[22:11] <davidm> ctyler, Do you need remote control of the units and does secure booting matter to you?
[22:15] <ctyler> no, they're builders in a koji system, which uses a mock (chroot) build environment
[22:16] <ogra_> ctyler, any what prevents me from uploading a package with scripts that break out of that chroot and gain me access ?
[22:19] <ctyler> ogra_: we'll know you you are :-)
[22:19] <ogra_> ah
[22:19] <persia> ogra_, Difference between distro builders and PPA builders.
[22:19] <ogra_> so only signed up people can upload
[22:19] <ctyler> the chroot isn't so much for containment as a clena buildroot
[22:19] <ctyler> clean*
[22:19] <ogra_> persia, yeah
[22:23] <persia> Mind you, if the cluster servers were in general availability, the koji admin might be happier, but it's a balance of effort vs. trust.