[21:27]  * micr0spell Discounts!! Our Special Limited Time Offers Up To May,22!!! Notebooks,Plasma and LCD TV's.Buy your electronic needs at our unique prices. Laptop Sony VAIO® VGN-FW590FFD-575,57$!!!Apple MacBook® Air MC234LL/A-695,27$!!! http://www.elplace.com/


[00:00] <nacc> mdeslaur: i've responded asking for clarification on that
[00:00] <mdeslaur> they didn't bump the other one, as you said
[00:00] <nacc> mdeslaur: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846385
[00:00] <nacc> mdeslaur: yep
[00:00] <nacc> mdeslaur: looking at the history of both php-imagick and ruby-rmagick in debian, it's clear this broke in the update there to 6.9.*
[00:01] <mdeslaur> ah, thanks for the bug link
[00:01] <nacc> mdeslaur: and just been broken in autopkgtests for a long time now (afaict)
[00:02] <nacc> mdeslaur: i also have a handle on the remaining php-imagick bug; it might be an imagemagick regression (off by one somewhere) or it might just be a testcase error; I'm communicating with the php-imagick upstream on that one. So I think we have a handle on everything related to imagemagick, at least
[00:03] <mdeslaur> nacc: cool!
[00:04] <nacc> smoser: so i guess what one *could* do is see if there is a DSC file with the same upstream in the dsc branch? and if so, use the files entries there to know what to pull down, using pristine-tar first, and falling back to pull() if it failes?
[00:05] <nacc> mdeslaur: this seems to not be an uncommon issue, unfortunately, with imagemagick. And nobody has come up with a good solution (in debian or upstream, afaict)
[00:05] <mdeslaur> nacc: it's unfortunately a common problem with a bunch of libraries...the ABI tracking website I linked to earlier is quite depressing to browse
[00:05]  * sarnold hands nacc a jerry can of gasoline and some road flares
[00:06] <nacc> mdeslaur: sad :/
[00:06] <nacc> sarnold: appreciate it!
[01:10] <smoser> nacc, well, maybe i miss something.
[01:11] <smoser> but i'd have thought most of the time if you took this entry (top entry) and there was not something
[01:11] <smoser> but the next entry was same upstream, and there *was* a dsc you could probably use that.
[01:12] <smoser> i think that would work for all cases that asking launchpad would (in the event of an up to date dsc and pristine tar data in the git repo)
[01:27] <nacc> smoser: hrm, that's a good idea
[01:28] <nacc> smoser: i'll see if i can code that up tmrw
[03:07] <sarnold> nedbat in #ubuntu-server points out duplicated text on http://releases.ubuntu.com/xenial/ -- "Desktop image" is in there twice, and "Server install image" three times
[03:09] <sarnold> can anyone recall which project to report bugs against for the releases.ubuntu.com texts? I can't remember any more :(
[03:45] <krytarik> sarnold: 'ubuntu-cdimage' - and there is definitely something off there, yep.
[03:51] <sarnold> thanks krytarik, https://bugs.launchpad.net/ubuntu-cdimage/+bug/1646335  :)
[04:07] <krytarik> sarnold: There is also .img vs .iso on the server images there, btw - but then the 16.04.1 one is missing at the top, which is also indicated by the generic description on it in the directory tree - so yeah.. :P
[04:56] <masber> hi
[04:56] <masber> not sure if this is the right place to ask this
[04:56] <masber> the host key on 2 of my ubuntu servers have changed
[04:57] <masber> I saw that python-cryptography (1.2.3-1ubuntu0.1) has been updated by the unatended updates
[04:57] <masber> would that be the reason of the key changes?
[05:05] <krytarik> masber: Try #ubuntu-server and/or #ubuntu.
[05:13] <masber> I asked them too #ubuntu-server nobody replies and no one has any idea in #ubuntu
[05:13] <masber> krytarik, I was hoping that the devel channel may have an idea
[05:14] <masber> I also asked in the #canonical-sysadmin
[05:14] <masber> anyway let see if I am lucky
[06:53] <cpaelzer> good morning
[07:55] <pitti> Good morning
[07:55] <cpaelzer> hi pitti
[07:56] <pitti> hey cpaelzer, wie gehts?
[07:56] <cpaelzer> still fine, the day hasn't unleashed anything unexpected yet
[07:57] <pitti> haha
[07:57] <cpaelzer> pitti: you might have a qick answer for me, last week we discussed on rerolling a libvirt SRU to use an apparmor abtraction instead
[07:58] <cpaelzer> pitti: that all is done in zesty, ready for re-upload SRU into Xenial
[07:58] <cpaelzer> pitti: since the old was rejected in the queue - can I reuse the version number I had?
[07:58] <cpaelzer> I think yes
[07:58] <cpaelzer> and I asked the same a while ago for a different case - but --force always makes me feel uncomfortable :-)
[07:59] <pitti> cpaelzer: yes, you can
[07:59] <cpaelzer> thanks for the confirmation
[07:59] <pitti> cpaelzer: the version number only gets committed/taken once a package gets accepted
[07:59] <pitti> rejecting from the queue == it never happened
[07:59] <cpaelzer> yet dput complains except you --force it
[07:59] <pitti> you can even have multiple different uploads of the same versino number in a queue at the same time
[08:00] <pitti> which is utterly confusing (archive admins then usually take the youngest one and reject the older ones)
[08:00] <pitti> cpaelzer: complains how? dput can't  even read queues
[08:00] <cpaelzer> pitti: "Package has already been uploaded to ubuntu on upload.ubuntu.com"
[08:00] <cpaelzer> is that just a local file then
[08:00] <pitti> cpaelzer: oh -- delete your .upload stamp file
[08:02] <cpaelzer> nice, now I understand where this came from
[08:07] <cpaelzer> dholbach: good to see you, on the pilot'ing I got your mail but haven't received any "invitation" and can#t find myself in the calendar you linked
[08:07] <cpaelzer> dholbach: am I supposed to enter myself in there?
[08:08] <cpaelzer> dholbach: the other entries I see always have the pilot as guest in the event, so I'd have expected to also see a calendar invite
[08:08] <cpaelzer> dholbach: at least I found myself now (in Decmember 19th)
[08:08] <cpaelzer> 20
[08:09] <cpaelzer> dholbach: I can surely copy to my calendat or so, but did I miss an invite or would there conceptually be no invite the way the schedule is set up?
[08:29] <dholbach> cpaelzer, that's strange - you should have it in your calendar
[08:29] <dholbach> let me check
[08:30] <cpaelzer> dholbach: I copied it for now, but I wondered why it didn't show up on its own
[08:30] <dholbach> it should
[08:30] <dholbach> cpaelzer, I added your canonical.com address as guest to the event
[08:36] <cpaelzer> dholbach: maybe a typo somewhere?
[08:36] <dholbach> did you receive an email?
[08:36] <cpaelzer> dholbach: not one related to the invite
[08:36] <dholbach> bizarre
[08:37] <cpaelzer> but I got your invitation mail, so did the email you used for both come from the same source?
[08:59] <Saviq> seb128, can I do anything to speed http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity8 up? the current unity8 version in zesty now fails autopkgtests because part of the silo migrated already (and apparently we don't have enough Breaks: in our packages...)
[09:11] <pitti> Saviq: I think the correct reason would be "fails because it does not run its tests against other proposed packages", FTR; robru just discovered that the lockstep migration does not seem to work, but that comes after tests
[09:12] <pitti> Saviq: so I figure re-running the tests against all of -proposed should work
[09:12] <pitti> oh, it didn't even get that far
[09:12] <Saviq> pitti, well, yes, that's correct
[09:12] <pitti> it's uninstallable -- well, that needs to be fixed first, obviously
[09:13] <pitti> qml-module-qtqml-statemachine | 5.6.1-7ubuntu2~1 | zesty/universe   | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
[09:13] <Saviq> pitti, yup, there's a new Depends that's not in main
[09:13] <pitti> ^ needs to be moved to main
[09:14] <pitti> which is trivial, as the source is already in main
[09:14] <Saviq> yup :)
[09:40] <Laney> did anyone notice / look into sbuild becoming slow on zesty lately?
[09:41] <Laney> It's taking on the order of 1 minute to even start installing build deps for me
[09:43] <pitti> Laney: for me it's bug 1626436, and I've heard from at least two other people that it was the same for them
[09:44] <pitti> Laney: that bug has a test kernel, it's worth trying that
[09:44] <pitti> Laney: is booting and shutdown  also painfully slow for you?
[09:44] <pitti> but that got introduced around yakkety beta already
[09:44] <Laney> pitti: booting is always slow for me because I have a drive that fails to initialise the first 3-4 times, so hard to tell :-)
[09:45] <Laney> and as for shutting down, I'm out of the room already :P
[09:45]  * Laney will try the kernel though --- could have been slower in yakkety already
[09:45] <Laney> thanks for the tip
[09:47] <pitti> Laney: ah, I always wait so that I can flip the switch box off
[09:47] <pitti> nothing like an actual physical "power off" switch :)
[09:49] <Laney> I should probably replace that drive
[09:49] <Laney> "Startup finished in 1min 21.824s (kernel)"
[09:49] <Laney> /o\
[09:50] <pitti> ugh
[09:50] <pitti> Laney: when I disable lightdm and NM (which are fairly unpredictable), the 4.4 kernel boots in 6s, the 4.8 kernel boots in 25
[09:51] <Laney> pitti: trying the latest one from that bug
[09:53] <Laney> stupid wget respecting robots.txt :-)
[09:55] <jtaylor> :( virtualbox does not build its module with the 16.04 hwe-edge (4.8)
[10:02] <ginggs> Laney: not sure if this related to slowness, but i found https://launchpad.net/ubuntu/+source/blockdiag/1.5.3+dfsg-1 seems to start building and thendies without leaving a log
[10:04] <Laney> hey ginggs
[10:05] <Laney> I think the builders are on 4.4 kernels, and this is apparently a 4.8 regression
[10:05] <Laney> if it happens again after a retry then maybe go ask in #launchpad
[10:05]  * Laney reboots to shiny new kernel
[10:09] <Laney> pitti: certainly *seems* better
[10:09] <Laney> thanks for the tip!
[10:10] <pitti> Laney: yay
[10:11] <pitti> Laney: it's good to know that we don't have multiple different regressions in that regard
[10:13] <ginggs> thanks Laney I'll do that
[10:45] <pitti> Laney: oh btw, there's one thing which you might not yet be aware of and which we need to sort out
[10:46] <pitti> Laney: our CI infra doesn't run autopkgtest and autodep8 out of their anonscm.debian.org git branches, as there is no <censored> way to get to this from a Prodstack instance (you know the pain)
[10:46] <pitti> Laney: so I have some LP mirrors of these repos (https://code.launchpad.net/~pitti/+git)
[10:47] <pitti> Laney: right now I push to these manually, but as nobody else can, we should fix this
[10:47] <pitti> cjwatson: is it possible to have an automatic git branch import from a remote git branch in LP, similar to how we make automatic bzr imports of remote gits?
[10:47] <Laney> isn't this the thing that just got launched recently?
[10:48] <pitti> automatically mirroring https://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git on something like ~ubuntu-release/git/autopkgtest.git would be useful
[10:48] <Laney> http://blog.launchpad.net/code/git-to-git-imports
[10:48] <pitti> !
[10:48]  * pitti loves retroactively fulfilling our needs, you guys rock
[10:49] <pitti> when I wrote that stuff I checked for that and it didn't exist yet, so I resorted to this ugly manual method
[10:49] <pitti> meh, I don't have any control over https://launchpad.net/autopkgtest
[10:51] <Laney> pitti: you can do it under any team (https://code.launchpad.net/+code-imports/+new)
[10:51] <Laney> https://code.launchpad.net/~ubuntu-release/autopkgtest/+git/autopkgtest
[10:51] <pitti> cjwatson, wgrant: could we change the owner of https://launchpad.net/autopkgtest to ~ubuntu-release or ~ubuntu-core-dev? or at least make Laney and me an admin?
[10:52] <pitti> Laney: yay, thanks; want to flip that in the deployment scripts and on the actual deployments too, or want me to?
[10:52] <pitti> Laney: (I have time, just wondering about the hand-over aspect)
[10:54] <Laney> pitti: I can probably do it
[10:54] <pitti> Laney: https://code.launchpad.net/~ubuntu-release/autopkgtest/+git/autodep8
[10:54] <pitti> cjwatson: unping, and thanks for adding this feature!
[11:02] <Laney> pitti: just git remote set-url?
[11:02] <Laney> are these automatically pulled somehow?
[11:02] <pitti> Laney: yes, should work; no, so far I pull them on demand
[11:03] <pitti> Laney: but I wouldn't mind a cron job to pull that and the autopkgtest-cloud branch automatically
[11:03] <pitti> Laney: this is assuming that master never breaks :) (but that shouldn't happen that often)
[11:03] <pitti> Laney: thanks, now "git grep pitti" looks sane ;)
[11:04] <pitti> (in autopkgtest-cloud)
[11:05] <Laney> and if you hax0r into the VPN you can still SSH to things ;-)
[11:06] <pitti> /msg #nsa hey guys, how do I hack openvpn again?
[11:07] <pitti> Laney: I deleted the ~pitti branches
[11:07] <Laney> need to do the lxds and s390xs
[11:12] <Laney> & done
[11:12]  * Laney coffee &
[11:41] <jgdx> hey, could anyone take a look at these failures [1]? They seem unrelated, pass locally with silo 2194 (which is in proposed). [1] http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-themes
[11:42] <jgdx> okay, and those tests are apparantly fixed in https://bileto.ubuntu.com/#/ticket/2244
[12:34] <jgdx> seb128, hey, could you take a look^? unity8 is stuck in proposed, which causes the unity8 test failures for u-themes and uss
[12:34] <seb128> wasn't pitti looking at it?
[12:34] <seb128> he discussed earlier with Saviq
[12:35] <Saviq> he said it was "trivial", kinda what you said yesterday, but not sure anybody actually acted on it :)
[12:36] <seb128> I'm still on xenial and trying to avoid looking at zesty atm
[12:36] <seb128> I though doko or somebody who usually watch component mismatch would pick it up
[12:38] <pitti> no, I didn't run the change-override; I'm trying to slowly wean myself off of archive admin
[12:38] <doko> seb128: sorry, this is not that easy anymore. previously these thing would show up as dep-wait. we don't have good information about component mismatches in update_excudes
[12:39] <seb128> doko, is that due to the citrain workflow?
[12:39] <doko> no, archive reorg, having universe b-d's
[12:39] <Laney> it's because component-mismatches-proposed doesn't mail
[12:43] <seb128> doko, can you try to help Saviq and jgdx to unblock unity8? I don't have the auth keys on the machine I'm currently hacking from to run the commands
[12:44] <doko> seb128: well, if you tell me about what is the problem?
[12:45] <seb128> some new qt binary needs to be promoted but I forgot the name
[12:45] <seb128> Saviq, jgdx, ^ can you tell doko what needs to be moved out of universe?
[12:46] <Saviq> doko, qml-module-qtqml-statemachine
[12:46] <Saviq> it's a binary from qtdeclarative5-opensource-src, which is already in main, so there should be no controversy
[12:47] <jgdx> seb128, thanks for picking it up! But i'm not sure what you're asking? I'm trying to land 2194.
[12:47] <seb128> jgdx, Savig just gave the info needed it's ok
[12:48] <jgdx> ok, thanks
[12:50] <doko> seb128, Saviq: done
[12:50] <seb128> doko, thanks
[12:50] <Saviq> doko, thanks!
[12:50] <doko> seb128: is there a plan to fix the qt* related build failures on i386? qtsvg-opensource-src and qtxmlpatterns-opensource-src
[12:52] <seb128> doko, no idea but maybe Saviq knows
[12:53] <Saviq> first I heard, we can have a look, doko, what do we look at?
[12:53] <doko> Saviq: as always: http://qa.ubuntuwire.com/ftbfs/  that shouldn't be news, or is it?
[12:54] <seb128> it's a pull thing
[12:54] <Saviq> doko, we're not as close to the archive as we should be ;)
[12:54] <seb128> you can't expect devs to regularly open random reports to see what issues might be listed
[12:57] <doko> and even if issues are opened as for location-service ...
[12:58] <Saviq> doko, AFAIU it's the same issue as everywhere else, it's a dependency wait on qtbase 5.7.1 - not sure why it's interpreted as build failure here, but depwaits on other arches
[13:01] <Saviq> basically none of it will move until we publish 5.7 of qtbase, qtdeclarative etc. - which Timo was preparing in https://bileto.ubuntu.com/#/ticket/1985
[13:43] <Laney> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gdal what's it talking about there?
[13:44] <Laney> oh, just copied, maybe it was still in the wormhole
[13:49] <xnox> barry, ubiquity/misc.py:152:5: E741 ambiguous variable name 'l' -> it really isn't, because mark spent $$$ on ubuntu-monospace font that renders iI1l without albigiouties.
[13:57] <cjwatson> pitti: it's been a popular feature already :)
[14:38] <barry> xnox: yeah, that's a new one that's bitten at least one other person recently
[16:27] <nacc> mdeslaur: not sure what to do about imagemagick given debian's response?
[16:28] <mdeslaur> nacc: I'm not sure either...bumping the so just in ubuntu doesn't seem sane. The other thing we could do is manually add a versioned depends to the ruby-rmagick package
[16:28] <nacc> mdeslaur: but I guess this is why php-imagick and ruby-rmagick do all the (sort of odd) at runtime checking of imagemagick versions
[16:28] <mdeslaur> infinity: your infinite wisdom would be valuable ^
[16:39] <nacc> mdeslaur: ha! was it all a timing thing? that is, it passed on amd64 with the rebuild...
[16:39] <nacc> mdeslaur: i wonder if the backlog actually helped here?
[16:40] <mdeslaur> nacc: oh, how curious
[16:40] <mdeslaur> nacc: perhaps
[16:40] <mdeslaur> nacc: did you mash the retry buttons for the other archs?
[16:40] <nacc> mdeslaur: i'm trying one now
[16:42] <nacc> mdeslaur: so i think php-imagick would also need a rebuild / needs to be fixed up for that one testcase still.
[16:43] <mdeslaur> I guess so, yeah
[17:16] <nacc> mdeslaur: this is really strange: http://autopkgtest.ubuntu.com/packages/r/ruby-rmagick/zesty/amd64 there's no entry for build1?
[17:16] <nacc> mdeslaur: but excuses has a link to a passing test using build1?
[17:17] <nacc> mdeslaur<EMAIL_ADDRESS>[17:17] <attente> would it be possible to backport the bubblewrap package to xenial?
[17:20] <nacc> mdeslaur: and if i retrigger, e.g. ruby-rmagick on armhf, it seems to succeed (although I don't see the request show up in the main autopkgtest page for the pkg, maybe expected; but then I don't have anyways to see the logs to verify?
[17:38] <mdeslaur> nacc: weird...maybe it takes a while to refresh
[17:43] <nacc> mdeslaur: yeah, could be
[17:44] <nacc> mdeslaur: i'll be more patient and see :)
[17:50] <nacc> mdeslaur: ok, i just verified manually that using -proposed, ruby-rmagick does pass on ppc64el at least
[17:50] <nacc> mdeslaur: will see if i can get autopkgtest to reflect that :)
[17:51] <mdeslaur> cool
[17:55] <doko> apw, ogasawara: is linux 4.9 ready to migrate, or will that still take some time? asking because I'd like to start a test rebuild tomorrow
[17:56] <ogasawara> doko: I will hand you to rtg and sforshee for that
[17:56] <coreycb> bdmurray, rbasak, hi could one of you do me a favor and reject the ironic-inspector upload to the yakkety queue from ~31 minutes ago?
[17:56] <ogasawara> doko: they are fixing build issue with our tools directory at the moment, but then should be ready to hopefully promote after that
[17:56] <rbasak> Sure
[17:57] <ogasawara> doko: but I don't now if that will be ready by tomorrow
[17:57] <rbasak> Done.
[17:57] <doko> ok, maybe I just copy it to a ppa, I'm only interested in linux-libc-dev
[17:57] <coreycb> rbasak, thanks
[18:21] <nacc> infinity: so i'm really confused by this: rubyrmagick 2.15.4+dfsg-2build1 succeeded on amd64 but not on any other archs. On amd64 it used the imagemagick in z-p to satisfy the deps (hence it passed). On all other archs it failed. But if I retrigger the run on the other archs, it still shows up as failed (and I'm not sure where to go for the logs for the rerun -- they don't show up in e.g.
[18:21] <nacc> http://autopkgtest.ubuntu.com/packages/r/ruby-rmagick/zesty/armhf)
[18:24] <infinity> nacc: That might mean someone manually retried it with proposed enabled for am64.
[18:24] <infinity> nacc: Except I don't see it succeeding?
[18:24] <infinity> http://autopkgtest.ubuntu.com/packages/ruby-rmagick/zesty/amd64
[18:24] <nacc> infinity: yes, it's very strange!
[18:24] <nacc> infinity: but look at excuses
[18:25] <nacc> infinity: it feels like some state is missing or lost<EMAIL_ADDRESS>is the successful run (per excuses' link)
[18:25] <nacc> or maybe simply delayed, i'm not sure
[18:26] <infinity> Could be a delayed UI thing, yeah.
[18:26] <infinity> nacc: Anyhow, if the concensus is that we handwave past this, I can retry all the arches with all-proposed, ick.
[18:27] <nacc> infinity: if amd64 had been run with -proposed, would i be able to see that in the log? what i see is "'--env=ADT_TEST_TRIGGERS=ruby-rmagick/2.15.4+dfsg-2build1 imagemagick/8:<IP_ADDRESS>+dfsg-1ubuntu2'"
[18:27] <nacc> infinity: but nothing else (and that specific trigger combination seems to be what is missing on all the other archs?)
[18:28] <infinity> Ahh.
[18:28] <infinity> Yes, someone ran it with a double-trigger.
[18:28] <infinity> That would "fix" it.
[18:29] <nacc> infinity: i'm also happy to change the deps manually in both php-imagick and ruby-rmagick to depend on a more recent imagemagick, given debian's pushback on the ABI argument
[18:29] <nacc> infinity: i'm just not sure on the 'right' solution
[18:29] <infinity> nacc: Changing the deps manually in the rdeps is not right.
[18:30] <infinity> Where was the Debian discussion?
[18:30] <nacc> infinity: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846385
[18:31] <nacc> infinity: so the double-trigger had to be run manually by someone? anyway to figure out who? as it wasn't me, given i don't know how :)
[18:33] <infinity> I think the queue probably logs somewhere, I'm not sure where. :P
[18:33] <nacc> infinity: ok :)
[18:33] <mdeslaur> oh, there's a new comment on the debian bug
[18:34]  * mdeslaur investigates
[18:34] <nacc> mdeslaur: afaict, debian saying there is no ABI breakage, except for interpreted languages, which should do more checking
[18:34] <mdeslaur> yeah, I'm looking now
[18:35] <nacc> coreycb: thanks for the feedback on python-django
[18:35] <nacc> jgrimm: --^ so i think we just need maas to provide input in that bug?
[18:36] <infinity> The problem with declaring it not an ABI break is that you can't really express it in dependencies.
[18:36] <infinity> So we're stuck with just telling people to upgrade wholesale or be broken.
[18:36] <jgrimm> nacc, agreed
[18:37] <nacc> infinity: right, it feels like these 3 packages now have to upgrade together or not at all
[18:37] <infinity> (Yes, we can say new ruby-rmagick depends on libimagickcore (>= foo), but preventing the old ruby-rmagick from using the new lib means adding Breaks to the new libimagickcore... Doable, but gross)
[18:37] <infinity> Anyhow, we also aren't hugely invested in partial upgrades being perfect (unlike, ironically, Debian), so we can probably handwave past this after I re-run the tests against proposed.
[18:38] <infinity> At least, for leafy packages like this.
[18:38] <infinity> Partial upgrades MUST work well enough to not blow up a machine *during* upgrade, but ruby/php-imagick probably don't count in that set.
[18:39] <nacc> infinity: that makes sense to me
[18:39] <nacc> infinity: so that can be run, if you're comfortable, for ruby-rmagick; I'll see if I can get a betterhandle on php-imagick
[18:39] <infinity> nacc: Yeah, tests retriggered for ruby-rmagick and ruby-gruff.
[18:39] <nacc> infinity: the -proposed run is needed there too, but also a fix is needed (working with upstream hopefully today on that)
[18:39] <nacc> infinity: thanks!
[18:41] <infinity> nacc: I'm not super happy with Debian's response here, but the exposure (a webapp might have a mild hissy fit during the upgrade window) also doesn't seem worth us violently diverging for.
[18:41] <nacc> infinity: agreed, I was surprised at the pushback
[18:51] <nacc> infinity: it does mean, I think, this kind of intervention should be expected going forward too, though :/ Is there a place to document cases like this?
[18:52] <infinity> nacc: In the uploader's head, I suspect. :P
[18:53] <nacc> infinity: heh, ok :)
[18:53] <nacc> infinity: would this be the sort of thing (let's say in a future merge?) to document in the changelog itself so it's known to all developers?
[18:53] <infinity> nacc: You could also fudge the deps, which would "document" it.
[18:53] <nacc> infinity: right
[18:53] <infinity> nacc: But only if you can manage to push that back to Debian, IMO.  Not worth a delta for.
[18:54] <infinity> ie: you could just make ruby-rmagick always depend on libmagickcore >= built-using-version, overriding the shlibs version.
[18:55] <infinity> Doesn't actually fix anything, but at least would sort the testing.
[18:55] <nacc> infinity: yep, I think that's what should be done -- i'll submit a patch to debian for both packages
[18:55] <infinity> Or, rather, doesn't actually fix the upgrade issues.
[18:56] <infinity> But I feel like asking the imagemagick maintainers to track these breaks and add "Breaks: php-imagick (<< foo), ruby-rmagick (<< foo)" to new imagemagick uploads is a thing that's not going to happen.
[18:56] <infinity> So meh.
[18:56] <nacc> right
[18:59] <nacc> infinity: is 'built-using-version' an actual thing? or would that be a hardcoded value for that specific build?
[18:59] <infinity> nacc: It's not an actual thing.  You'd have to divine it via dpkg at build time.
[18:59] <nacc> infinity: right
[19:00] <nacc> infinity: i think this is actually debian bug 591419
[19:01] <nacc> the last comment, sadly, from 6 years ago
[19:02] <infinity> nacc: Keeping it very strict, as suggested, might be a plan.
[19:03] <infinity> Doesn't help the past, but would improve the future.
[19:03] <infinity> For super funzies, to do this without any hardcoding, you'll need to emulate bits of dpkg-shlibdeps
[19:03] <nacc> infinity: ack
[19:04] <nacc> infinity: yeah, i was going to look at what it does under the cover :)
[19:04] <nacc> infinity: thanks again for all your help!
[19:04] <infinity> ie: "ldd path/to/new/plugin.so | grep magickcore | dpkg -S"
[19:04] <infinity> nacc: Well, it's much more clever than what I typed above, but that would get the job done.
[19:05] <nacc> infinity: yeah, makes sense
[19:05] <infinity> nacc: The key here being that you don't want to hardcode the package that contains the library because SONAME bumps will drive you batty.
[19:05] <nacc> infinity: right :)
[19:06] <bdmurray> Laney: Oh did your second upload of glib2.0 actually have Launchpad-Bugs-Fixed in it?
[19:07] <bdmurray> Laney: If so I rejected the wrong one. :-(
[19:08] <infinity> nacc: And if you care about cross-building, use 'readelf -d path/to.so | grep NEEDED' instead of ldd, but then you get to resolve the path by hand (or hope there's only one libfoo.so.N on the system).
[19:09] <nacc> infinity: thanks! jotting this all down
[19:09] <infinity> nacc: (ldd and just skipping the dep if the result is empty is probably the easier route, since neither we nor Debian build the official archive cross, and the dep being slightly wrong for home-built cross setups doesn't really matter)
[19:15] <infinity> nacc: For example: $ ldd /bin/mv | grep '/libc\.' | awk '{print $3}' | xargs dpkg -S | awk '{print $1}' | sed 's/:$//' | xargs dpkg -l | awk '/^.i/ {print $2 " (>= " $3 ")"}'
[19:15] <infinity> nacc: Ish.
[19:16] <infinity> nacc: Some of that can be squished into shorter awks without the greps and seds. :P
[19:17] <infinity> (Also, I'm a terrible person, no need to confirm)
[19:17] <infinity> Well, longer awks, shorter overall code.  You know what I mean.
[19:25] <mdeslaur> infinity: wouldn't it be better to just do a dpkg -l libmagickcore-dev, since it's those header files that it's actually using?
[19:25] <nacc> infinity: understood :) (sorry, was otp)
[19:26] <bdmurray> coreycb: aodh 3.0.1 isn't in Zesty yet .. bug 1645772
[19:26] <infinity> mdeslaur: You're assuming that package will always exist.
[19:27] <coreycb> bdmurray, ok thanks we'll get that in
[19:27] <infinity> mdeslaur: (given it's marked as a "transitional" right now, I'm skeptical)
[19:27] <infinity> mdeslaur: Well, also, the *dep* needs to be on the binary library package. :P
[19:27] <mdeslaur> I meant just to get the version string
[19:27] <infinity> mdeslaur: But the version string of what, exactly?
[19:27] <mdeslaur> yeah, if you're generating the package name too, I see what you mean
[19:27] <infinity> mdeslaur: We still need to know the binary package name.
[19:27] <mdeslaur> right
[19:28] <infinity>  ldd /bin/mv | awk '/\/libc\./ {print $3}' | xargs dpkg -S | awk '{print $1}' | sed 's/:$//' | xargs dpkg-query -W -f='${Package} (>= ${Version})\n'
[19:28] <infinity> nacc: ^-- There, cause I can't leave well enough alone once I start playing with a shell pipe.
[19:28] <infinity> I feel like that sed could turn into a gsub, but awk and I don't agree on how to find the end of a line.
[19:28] <infinity> Or, rather, I don't seem to recall how.
[19:28] <attente> is there a reason why 'apt-file search intltoolize' no longer works? i'm pretty sure this used to work up until very recently
[19:29] <infinity> attente: apt-file update?
[19:29] <attente> infinity: did that
[19:30] <infinity> It's possible we don't ship intltoolize. :P
[19:30] <infinity> It works for, say, libtoolize.
[19:31] <dobey> we ship intltoolize
[19:31] <dobey> it'well, we ship intltool
[19:31] <attente> infinity: if i do 'apt-file search libtoolize', it doesn't show /usr/bin/libtoolize either
[19:31] <attente> even though it shows a few other results
[19:32] <infinity> dobey: Yeah, we sure do.  I have it installed even.
[19:32] <infinity> attente: Curious.
[19:32] <attente> infinity: it's just me though? is apt-file working for you?
[19:32] <infinity> attente: Nope, same results here.
[19:33] <attente> infinity: i thought i was going mad for a while there :)
[19:33] <infinity> Our apt-file is also wildly out of date.
[19:33] <infinity> Perhaps it could use a kick.
[19:54] <coreycb> bdmurray, can you reject aodh 3.0.1 please?
[19:54] <bdmurray> coreycb: done
[19:54] <coreycb> bdmurray thanks
[20:00] <coreycb> bdmurray, sorry can you reject aodh 3.0.1 again?  i meant to use zesty.
[20:01] <bdmurray> coreycb: hmm, misclicked there.
[20:01] <coreycb> bdmurray, np
[20:14] <dobey> hmm
[20:14] <dobey> seems something in new glibc is causing stuff to crash? :(
[20:15] <infinity> dobey: There's a reason it's still in proposed.
[20:16] <infinity> dobey: Do you have specific stuff crashing?
[20:16] <infinity> dobey: I'm investigating, but more testcases won't hurt.
[20:16] <dobey> infinity: indicator-keyboard tests are crashing during build in PPA. i see segfaults in the gtk+3.0 autopkgtests on update_excuses too
[20:17] <dobey> (PPA that has proposed enabled)
[20:17] <doko> dobey: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1646064 is used for tracking
[20:17] <infinity> I'm pretty sure I know the cause of most of them, and have test packages here that I'm about to kick the tires on.
[20:19]  * infinity gets to tire-kicking.
[20:20] <coreycb> bdmurray, ok aodh should be all set now, uploaded 3.0.1 to zesty and a new one to the yakkety queue
[20:35] <dobey> infinity: well i can't seem to get indicator-keyboard to crash locally. no idea why :-/
[20:36] <infinity> dobey: With a chroot updated to proposed?
[20:36] <infinity> dobey: Oh, try running in C.UTF-8 too, since I'm betting that's what's buggy. :P
[20:37] <dobey> hmm
[20:55] <dobey> infinity: hrmm, ok, managed to get it to crash now (though not 100% sure how) and it's dying in a g_variant_get_uint32() call
[20:56] <dobey> infinity: http://pastebin.ubuntu.com/23564864/
[20:56] <dobey> (and that's inside vala-generated C)
[20:59] <dobey> so yeah, this crash makes no sense to me
[21:34] <infinity> dobey: If you can figure out how you reproduced, that would be nice.  I'm having a hard time reproducing some other regressions here too.
[21:35] <dobey> infinity: well, pulling lp:indicator-keyboard and running ./autogen.sh && make -j8 && make check results in a crash. but i'm not sure what would be possibly causing it. the last things i installed from proposed before it started crashing, were the systemd and sqlite3 updates
[21:35] <dobey> before that the tests would run just fine :-/
[21:36] <infinity> Huh.
[21:37] <dobey> hmm, oh actually i guess that trace is wrong. as it's the trace for a SIGTRAP on the client side of the dbus connection, and the server side crashed with a SEGV
[21:37] <dobey> grr
[21:38] <dobey> not sure how to gdb that side of it :-/
[21:44] <dobey> oh fun, so i need to tweak the service file to run it under gdb
[21:50] <dobey> how does one actually get a core file these days?
[21:54] <jtaylor> dobey: if apport does not spit one out (in /var/crash) you can change /proc/sys/kernel/core_pattern
[21:57] <dobey> jtaylor: how do i make apport work inside an lxc container, though?
[21:57] <jtaylor> dobey: no idea, I just turn of the apport indirection on containers hosts
[21:57] <jtaylor> you probably need apport installed in the container than it might work as usual
[21:57] <jtaylor> s/on/off/
[21:58] <dobey> i installed apport in the container, and ran /etc/init.d/apport start, and it didn't collect a core
[22:01] <jtaylor> do you have core files limited via e.g. ulimit?
[22:01] <dobey> i have whatever the defaults in ubuntu are
[22:01] <jtaylor> why do you need apport?
[22:01] <dobey> i don't. i need a core file from a dbus server process
[22:02] <jtaylor> and you can't change the core_pattern?
[22:02] <dobey> change it to what?
[22:02] <dobey> |/usr/share/apport/apport %p %s %c %P
[22:02] <dobey> that is the current value
[22:03] <jtaylor> e.g. core.%e.%u.%P
[22:03] <jtaylor> see man core
[22:03] <jtaylor> that just dumps a core in the cwd
[22:04] <jtaylor> also make sure its not limited, e.g. via ulimit -c unlimited, there is probably a systemd setting for that somewhere if its a service
[22:05] <dobey> i guess i have to do that on the host
[22:05] <jtaylor> changing the core pattern probably, the guest sees the same value but might not be able to change it
[22:06] <jtaylor> I don't think that is a thing that is namespaced
[22:06] <dobey> but no, that doesn't seem to help
[22:44] <dobey> infinity: ok, looks like it's glx causing a crash inside gdk: http://pastebin.ubuntu.com/23565173/
[22:44] <dobey> whee mesa
[22:46] <dobey> sscanf on a NULL, fun
[23:47] <nacc> mdeslaur: infinity: so this works, but isn't fully correct yet: http://paste.ubuntu.com/23565429/. I'm wondering if that's better than just calling dh_shlibdeps and appending to the file manually? (I tested that by hand earlier and it worked). For some reason (still debugging), even though dpkg-shlibdeps documents it, the debian/ruby-rmagick/DEBIAN/shlibs version just doesn't do anything.
[23:48] <nacc> infinity: your version is more generic, as it isn't tied to the soname and soversion itself (although I couldn't think of a better way to find the .so file to use than find itself, which ties us to a rmagick soversion)


[05:07] <aksh1> hi all ,which Ubuntu version has full support for multitouch
[05:07] <aksh1> is it 10.10 or 11.04
[05:08] <aksh1> for arm board
[05:20] <aksh1> hi all, i am refering http://elinux.org/BeagleBoardUbuntu to create a ubuntu 11.04 image for beagle using rootstock.can anyone tell me how to enable cache mechanism so that  for next build i can refer local packages
[13:18] <selcukj> hey
[13:19] <selcukj> i need to install vnc server
[13:19] <selcukj> it is giving me E: Unable to locate package x11vnc
[13:20] <selcukj> when i run sudo apt-get install x11vnc
[14:01] <selcukj> i need to install vnc server
[14:01] <selcukj> it is giving me E: Unable to locate package x11vnc
[14:01] <selcukj> when i run sudo apt-get install x11vnc
[14:02] <selcukj> need help here?
[17:04] <aksh1> hi all, after i am getting error for dpkg-reconfigure -a as dpkg-maintscript-helper: error: couldn't identify the package
[17:56] <aksh1> i have installed plymouth in ubuntu 10.10 with beagleboard but getting error omap init: plymouth-stop pre-start process (447) terminated with status 1
[18:59] <armin76> ubuntu support is nice :P


 https://matterbridge.lubuntu.me/340befbd/file_8937.jpg
 Is this supposed to happen after adding ppa?
 Also after maximizing qterminal sentences didnt restructure itself according to new window size
[00:55] <kc2bez[m]> lubot: The backports PPA is only for Jammy or 22.04
 I feel like shooting myself in the leg. I just did a fresh install an hour ago
 Thank you.
[00:58] <kc2bez[m]> Of course.
 Is there an way to downgrade back to jammy?
[01:02] <arraybolt3[m]> No, sadly. Technically it might be possible, but it would be unimaginably tricky, and so time consuming it would be easier to just fresh install Jammy.
 I will just move to the next version. Lesson learnt
[01:04] <guiverc> this isn't a support channel; but the 'install using existing partition' install method allows you to change releases; ie. install jammy without losing data files & have manually installed packages (where from Ubuntu repositories) re-installed automatically; may not cover any 3rd party packages you've added
[01:46] <guiverc> I've added some fallback photos here ( https://docs.google.com/spreadsheets/d/1TKPjpxR5swdC7Mt-66TarjnoH5GXv9ay81DK-xYkQ8M/edit?usp=sharing ) but NOTE none are great.  blue lobster (https://unsplash.com/photos/VCevAFKFyVY blue being Lubuntu color & lobser) probably the best; was another view of I suspect same lobster there.. also added some 'lunar' shots but they'd be only suitable as interim in my opinion
[01:47] <guiverc> maybe I'll find more
 Blue lobster, Is awesome!
 "I've added some fallback..." <- Definitely agree on the blue lobster. A bit of my own digging revealed nothing better, and that one is pretty good (I had no idea lobsters even were blue until just now :P).
 European lobster or common lobster, is a species of clawed lobster from the eastern Atlantic Ocean, Mediterranean Sea and parts of the Black Sea.In life the lobsters are blue, only becoming "lobster red" on cooking (re @lubuntu_bot: (irc) <arraybolt3[m]> <guiverc> "I've added some fallback..." <- Definitely agree on the blue lobster. A bit of my own digging revealed nothing better, and that one is pretty good (I had no idea lobste
[15:33] <arraybolt3[m]> Cool!
[15:33]  * arraybolt3[m] was going to type something more than that and then hit Enter too soon...
 Blue meaning the distro is alive!! (re @lubuntu_bot: (irc) <arraybolt3[m]> Cool!)
[15:36] <arraybolt3> Nice +1
 If we are keeping count I really like the blue one too.
 +1 for blue
 Speaking of blue ..any news on the "bluetooth file transfer" bug ..https://bugs.launchpad.net/ubuntu/+source/bluedevil/+bug/1945217
[16:11] -ubot93:#lubuntu-devel- Launchpad bug 1945217 in bluedevil (Ubuntu) "org.kde.bluedevilsendfile.desktop in Lubuntu does not launch" [Undecided, Confirmed]
[16:28] <arraybolt3[m]> @Leokolb: Looks like we may have just forgotten about it (I most certainly did).
 Would be great to get that fixed if possible.. (re @lubuntu_bot: (irc) <arraybolt3[m]> @Leokolb: Looks like we may have just forgotten about it (I most certainly did).)
[17:51] <arraybolt3[m]> Simon Quigley: Found the source of the wrong-name-for-upstream-changelog thing in qtxdg-tools. There was a debian/docs file causing the file to be installed uncompressed. Deleting that file resolved the issue. It also left the changelog out of the packaging, but Debian policy states "If there is an upstream changelog available, it may be made available as /usr/share/doc/package/changelog.gz." Not must, not should, just may, which
[17:51] <arraybolt3[m]> Debian policy clarifies as meaning "truly optional and at the maintainer’s discretion." In this instance, it would be more work to figure out how to get the changelog compressed and installed (might require a repack of the archive?), and at least one other package I checked of ours doesn't include the upstream changelog either, so I say omit it.
[17:51] <arraybolt3[m]> Does that seem like a good way to do things?
[18:20] <arraybolt3[m]> Just noticed that qtxdg-tools is not installed by default on Lubuntu 23.04, possible a bug in the seed?
[18:20] <arraybolt3[m]> s/possible/possibly/
[18:25] <arraybolt3[m]> And one last thing, qtxdg-tools is currently in the "libs" section even though it doesn't appear to be a library. It looks like it fits better in "admin", or maybe "utils". Thoughts?
[19:11]  * Eickmeyer[m] uploaded an image: (131KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/wFKbjVkHDwqgYcbHWxrUzLpg/kubuntu-focus-4k-external-display-weird-monitors.jpg >
[19:11] <Eickmeyer[m]> Has anybody seen this show up with multiple screens in SDDM?
[19:12] <Eickmeyer[m]> Just wondering, because I have a patch to upload and I want to make sure it's not theme-specific.
[19:12] <arraybolt3[m]> I've never seen that so far.
[19:12] <arraybolt3[m]> Then again I don't own any 4K panels, nor do I have a monitor stacked on top of another one in my configs.
[19:12] <tsimonq2> Eickmeyer[m]: How many screens does the display manager think it's working with?
[19:12] <Eickmeyer[m]> This was from a Kubuntu Focus customer, though, we have a downstream fix with Kubuntu Focus.
[19:13] <Eickmeyer[m]> arraybolt3: You won't see it with your Focus. I'm wondering specifically if it's been seen in Lubuntu stock.
[19:13] <tsimonq2> I could probably tell you what the bug is off the top of my head, if the display manager is not detecting monitors being unplugged and plugged back in correctly, or it does so in a way where there's an off by one error, you're going to have issues with how many screens it actually wants to display
[19:13] <tsimonq2> If I had to take a best guess, that's what it is. And with the display managensure not being updated for a couple of releases now, bit rot could be a slight factor
[19:14] <Eickmeyer[m]> Simon Quigley: Right, we have a fix.
[19:14] <tsimonq2> Excuse my talk to texans, I will be at a keyboard pretty soon here to respond to Aaron's other questions, but that's my gut reaction to above like that
[19:14] <tsimonq2> Eickmeyer[m]: I see the fix? :)
[19:14] <arraybolt3[m]> Eickmeyer[m]: I've never seen it in Kubuntu stock, I've not used Lubuntu stock with multiple monitors yet.
[19:15] <Eickmeyer[m]> tsimonq2: Sure, but I have yet to formulate the patch. Right now it exists as a postinst script, so it's rather hacky.
[19:15]  * arraybolt3[m] goes afk
[19:15] <Eickmeyer[m]> It relies on xrandr.
[19:16] <Eickmeyer[m]> Simon Quigley: I guess it takes some notes from Dr. Hacky himself. ;)
[19:16] <tsimonq2> LMAO
[19:16] <tsimonq2> I still wanna see it :)
[19:23]  * Eickmeyer[m] sent a code block: https://libera.ems.host/_matrix/media/v3/download/libera.chat/f01a7e86ef1c821648e07079de8de6ea6f06b04c
[19:24] <Eickmeyer[m]> Runs as an independent script now, but should probably be embedded in /usr/share/sddm/scripts/Xsetup
[19:31] <arraybolt3[m]> > <@eickmeyer:matrix.org> ```... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/2833e03450df44016d02763e9f012310905e5a9e>)
 "Does that seem like a good way..." <- For the sake of being decisive here, while I think long-term we should have the upstream changelog available as part of the package, if Debian Policy does not strictly enforce it, we're okay to admit it. Less overall Lintian errors are good, but we should also consider the use case of limited internet access, especially for our set of users
 "Just noticed that qtxdg-tools is..." <- Yes, that's a bug
 "And one last thing, qtxdg-..." <- Go ahead :)
[19:31] <arraybolt3[m]> 👍
 "Has anybody seen this show up..." <- To clearly answer this question, yes. I also have a multi monitor setup. It's worth asking whether the bug is in one of sddm's build dependencies or sddm itself, but I guess you guys are working that out
[19:34] <Eickmeyer[m]> tsimonq2: Sadly, we've found it's SDDM itself, and you just confirmed for me that it's not theme-related, which is one reason why I asked in here.
[19:36] <Eickmeyer[m]> Fact of the matter is we have to patch what we already have.
[19:38] <tsimonq2> Eickmeyer[m]: I would love to peer-review an SDDM patch and help push it as an SRU. Let me know how I can help
[19:40] <Eickmeyer[m]> tsimonq2: Sure, I'll keep you in the loop on it.
[19:42] <tsimonq2> arraybolt3 @arraybolt3:matrix.org: How do you programmatically compare package versions? :)
[19:42] <tsimonq2> (Hint: solve this problem now while you can :P)
[19:42] <arraybolt3[m]> Simon Quigley: dpkg --compare-versions (or something like that)
[19:42] <arraybolt3[m]> Yep, dpkg --compare-version was right.
[19:43] <arraybolt3[m]> s/version/versions/
[19:43] <arraybolt3[m]> `dpkg --compare-versions 0.12.0-0ubuntu1 lt 0.12.0-1 && echo $?`
[19:43] <arraybolt3[m]> returns 0 (true)
[19:44] <tsimonq2> Perfect :)
[20:18]  * Eickmeyer[m] posted a file: organize-screens-avoid-inset.patch (3KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/tHBacjuKSFkckhdRYthGMqCx >
[20:18] <Eickmeyer[m]> Simon Quigley: ^
[20:19] <Eickmeyer[m]> I can do the upload to lunar on this pretty easily.
[20:19] <Eickmeyer[m]> However, I'll get the bug report done/SRU written-up.
[20:33] <tsimonq2> Have you tried your hand talking to upstream about this quite yet?
[20:36] <Eickmeyer[m]> Not yet, but that still wouldn't fix what already exists in Jammy and Kinetic, and only might fix Lunar. If looking at one or any number of those patches in debian/patches is any clue (especially the comments on some of them), they don't exactly seem to be too keen on this kind of item. Also, appears to be a known issue.
[20:37] <Eickmeyer[m]> https://github.com/sddm/sddm/issues/1399
[20:37] -ubot93:#lubuntu-devel- Issue 1399 in sddm/sddm "Is multimonitor support ever going to be thing?" [Open]
[20:44] <arraybolt3[m]> Simon Quigley: Going afk for a bit, just finished qtxdg-tools.
[20:45] <tsimonq2> arraybolt3[m]: Sweet. No worries
[20:59] <Eickmeyer[m]> bug 1998254
[20:59] -ubot93:#lubuntu-devel- Bug 1998254 in sddm (Ubuntu Lunar) "[SRU] sddm with multiple monitors can result in screen overlays and insets" [High, New] https://launchpad.net/bugs/1998254
[21:00] <Eickmeyer[m]> Simon Quigley: ^
[21:26] <tsimonq2> Added to my list. Still quite a long one today. May need to sacrifice sleep tonight...
[21:42] <Eickmeyer[m]> Simon Quigley: Now for the debdiff:
[21:42]  * Eickmeyer[m] posted a file: sddm_0.19.0-3ubuntu1-2.debdiff (5KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/JbDGeMCJnyiBYtyVEwhKWoCl >
[21:43] <Eickmeyer[m]> And as you know, I can JFDI.
[21:45] <tsimonq2> If you could give me a few hours, I want to take the chance to review this and do a little testing on my end as well. It's not that I don't trust you're capable, I would just much rather see you get a thorough second set of eyes now rather than get rejected by the SRU team, or even worse, have it cause a bug for users
[21:45] <Eickmeyer[m]> ok
[21:46] <Eickmeyer[m]> FWIW, I didn't write it, that was my boss, and it's been in the wild for 6 months.
[21:48] <Eickmeyer[m]> But yeah, I can wait.
[21:48] <tsimonq2> Thanks. Again, not saying I don't trust the patch, but I'll try my hand at it :)