[02:53] <dany197666666> hlp
[02:53] <dany197666666> help
[02:53] <dany197666666> pls~
[02:56] <sladen> dany197666666: we would need to know the question first
[02:57] <dany197666666> i have RTL8187SE
[02:57] <dany197666666>  em wind its ok
[02:57] <dany197666666>  but here im weak segnal
[03:10] <sladen> dany197666666: is there a problem with the wifi connection?
[03:11] <dany197666666> signal
[03:15] <sladen> dany197666666: try moving slightly, or moving the machine closer to the access point
[03:15] <sladen> dany197666666: or adjusting the antenna direction
[03:15] <dany197666666> lol
[03:16] <dany197666666> in wind e ok
[03:16] <dany197666666> but here its weak
[03:22] <sladen> dany197666666: wind doesn't normally affect wifi signals, just moisture in the air can, and so can other sources of interference ... like microwave ovens
[03:35] <dany197666666> its de same place
[12:11] <jamespage> pitti: scratching and itch - http://paste.ubuntu.com/26169731/ - does that look reasonable?
[12:11] <jamespage> and what's the best way of getting that into the autopkgtest infra?
[12:11] <jamespage> and/an
[12:11] <jamespage> fingers ran away from me...
[12:19] <pitti> jamespage: not sure any more, but I think we just run autodep8 from git; so best to file it as a Debian bug, Antonio is pretty quick in applying them
[12:19] <pitti> then ask Laney to pull and re-deploy
[12:19] <jamespage> pitti: ok will do
[12:22] <jamespage> cjwatson: thanks for doing those allocations so quickly :)
[12:23] <cjwatson> np
[12:29] <TJ-> cjwatson: could you possibly provide some feedback (assuming you're still involved with the Debian package) at some point for my proposed patch for Bug #1737604
[12:41] <cjwatson> TJ-: wow, that's profoundly unpleasant, but perhaps it's required.  Could you also please handle escaping inside double quotes correctly?  The syntax docs are https://www.gnu.org/software/grub/manual/grub/grub.html#Quoting
[12:41] <cjwatson> (we probably can't handle expansions there, but could at least manage escaping)
[12:42] <cjwatson> TJ-: also it might be worth using   printf %s "$title_raw"   rather than   echo "$title_raw", for a bit more safety against e.g. titles that start with a "-" inside the delimiters
[12:43] <juliank> Ugh: /var/lib/docker/nuke-graph-directory.sh: 64: /var/lib/docker/nuke-graph-directory.sh: shopt: not found
[12:45] <juliank> ah bug 1724353
[12:46] <cjwatson> TJ-: and ... I'm a bit confused by $1 being used in some places and $line in others, and it makes me wonder: I know that menuentry is documented such that the title is always the first arg, but is that actually required?  the old code seems to tolerate it coming later
[12:50] <juliank> So, can I use sbuild with lxd via the autopkgtest stuff?
[13:00] <TJ-> cjwatson: thanks, I'll look at that. I got slightly lost inside those sed expressions and focused on the single-quote one.  I used 'echo' because the original code did. I used $1 since the parent code had already shifted the arguments but it can use $line without issues too, I think.
[13:10] <TJ-> cjwatson: re: menuentry 'title' order... I assumed from looking at both forms of the sed expressions that the unwritten assumption is that there will only be one pair of quote marks so it's OK to capture anything between first and last quote
[13:11] <cjwatson> TJ-: Right, but you're using $1 and thus assuming that the title will come first.
[13:15] <TJ-> cjwatson: Yes, based on the docs which show 'title' as a non-option first arg of menuentry.
[13:15] <cjwatson> TJ-: Right.  As I said above, I know that the docs say that but it is not entirely clear to me that that's enforced; if it's not, then there may be config files in the wild with a different ordering.  Needs checking.
[13:16] <TJ-> cjwatson: right, so it might be safer to locate the first ' or " ?
[13:17] <cjwatson> TJ-: Yeah
[13:17] <TJ-> cjwatson: but if it's out of order that wouldn't help either :s
[13:17] <cjwatson> It'd be no worse than what's there now, at least?
[13:17] <TJ-> cjwatson: currently " beats ' anyhow
[13:18] <cjwatson> s/.*\(['"]\).*/\1/  or some such
[13:18] <cjwatson> with the usual unpleasant quoting
[13:18] <TJ-> cjwatson: I was trying to ensure both have an equal chance of being used first :)
[13:18] <cjwatson> er except that first .* will be greedy
[13:18] <cjwatson> s/[^'"]*\(['"]\).*/\1/
[13:19] <TJ-> yes, the lack of a non-greedy operator for sed is often frustrating
[13:19] <cjwatson> I don't think it's possible to do much better than that without a full parser
[13:20] <TJ-> cjwatson: What I'll do is create some test-cases with all the permutations I can think of and modify it so it can deal with them all, hopefully without complicating it too much more!
[13:21] <cjwatson> sounds good.  maybe at some point I'll have time to get further with my rewrite of os-prober
[13:24] <TJ-> cjwatson: I think title has to be first: grub-core/commands/menuentry.c::grub_normal_add_menu_entry() => menu_title = grub_strdup (args[0]);
[13:30] <cjwatson> TJ-: But that is after option parsing, which may rearrange things.
[13:31] <TJ-> cjwatson: Glad you're the grub master, not me!
[13:32] <cjwatson> Not really any more, but I remember a few things :-)
[13:34] <TJ-> cjwatson: although I can't think of a way in which the title could be elsewhere and still get passed as the first arg to that function :) title has to come before {command;...}, and the --options are separated into their own pointers/arrays
[13:35] <TJ-> cjwatson: thanks for the feedback; I'll get those tests created and then modify the code as required
[13:37] <cjwatson> TJ-: I'm pretty sure that title could come after the options and still work.  The arg parser will parse out the options and remove them from the resulting args array.
[13:37] <cjwatson> But you can try it.
[13:38] <TJ-> cjwatson: I will :)
[16:13] <tsimonq2> xnox: I'm currently prepping Qt 5.9.3 in Bileto, would you like me to grab Fedora's OpenSSL 1.1 support patch and include it with the transition?
[16:14] <tsimonq2> xnox: I'd just need help with testing it works, as I'm not familiar with OpenSSL.
[16:48] <juliank> I don't entirely understand why I should add root:1000:1 to /etc/subuid when I want to remap my uid to the same in an lxd container as https://insights.ubuntu.com/2016/12/08/mounting-your-home-directory-in-lxd/ says - it works fine without?
[17:10] <xnox> tsimonq2, no, please don't.
[17:10] <xnox> tsimonq2, we do not have openssl1.1 in the archive, and probably will not have it soon. Compared with others, we can consider qt done already, despite it being unpatched in the archive.
[17:22] <teward> hmm... I think Quilt is fubar... somehow.  The system says that there's new unhandled changes in the source code... but it's as a result of Quilt patching.... not sure how to fix the issue.
[17:36] <rbasak> jbicha: OOI, any particular reason you're syncing mongodb 3.4 from experimental? I'm looking at the mongodb package from a Juju perspective, so wanted to understand the current needs for that package before making any recommendations.
[17:37] <jbicha> rbasak: I synced it from experimental for LP: #1595242, maybe you should ask the Debian maintainer what's keeping it from unstable
[17:38] <rbasak> Ah. THanks!
[17:38] <rbasak> balloons: ^
[17:44] <rbasak> jbicha: also, just to be clear, you have no other specific use case apart from general archive maintenance?
[17:44] <jbicha> right, I don't use mongodb
[17:44] <rbasak> Eg. there's a request for mongodb 3.6, which is released upstream but not in Debian.
[17:45] <rbasak> OK, thanks. So I don't need to involve you in that conversation then?
[17:45] <rbasak> I'll file in Debian BTS.
[17:45] <jbicha> yeah, 3.6 looks like it would be good for 18.04 LTS: https://www.mongodb.com/support-policy
[17:49] <balloons> rbasak, gotcha
[17:50] <balloons> rbasak, note the upstream arch support is present in 3.4, so that version does work, assuming we can support it, etc
[17:51] <rbasak> balloons: OK. So we don't actually need 3.6?
[17:53] <balloons> rbasak, no, it's not a hard requirement; as John noted 3.4 actually had the arch support that was a driver. 3.6 is still a nice to have and may be easier to support, but not required
[17:53] <balloons> it has more implications for juju as well; more changes
[17:55] <rbasak> OK thanks
[18:09] <balloons> rbasak, we spoke about having the js engine be enabled / disabled as part of the package, as well as having the service start or not. Do you have a handle on the work required to tweak the existing 3.4 package to do this?
[18:30] <rbasak> balloons: JS engine tweak should be relatively easy, but I think that's unacceptable for the generic mongodb package.
[18:32] <rbasak> balloons: not having the service start: ideally you'd split the package like we did in MySQL. Not much effort but it is a pain to maintain a delta. I don't know if the Debian maintainers would take it.
[18:33] <rbasak> You could use policy-rc.d to override, but if Juju doesn't "own" the system and has other tenants, that might break some user expectations. But the policy-rc.d mechanism, assuming the package isn't buggy, should be quite straightforward to implement in Juju.
[20:13] <mwhudson> morning
[20:56] <tsimonq2> xnox: ack
[20:56] <tsimonq2> Morning mwhudson :)
[22:48] <dax> jbicha: i happened to be talking about xchat-gnome elsewhere and noticed your bug report from 10 minutes ago
[22:49] <dax> jbicha: as someone without any dev insight at all... i don't know why ubuntu still has that package at all
[22:49] <dax> afaict its main accomplishment seems to be confusing users into using an irc client with no bugfixes since 2014 instead of, say, hexchat
[22:50] <jbicha> well, seb128 uses xchat-gnome 🤷
[22:50] <dax> oh is that who's keeping it alive
[22:50] <jbicha> I don't think I would go that far…
[22:51] <jbicha> xchat-gnome at least uses gtk3 https://github.com/hexchat/hexchat/issues/2047
[22:53] <dax> oh, i lie, it's getting bugfixes, the date part of the version string just isn't being changed
[22:54] <dax> (i assume because changes are getting picked and backported)
[22:55] <mdeslaur> I've been fixing it also, until it got removed and forcing me to switch to hexchat
[22:55] <mdeslaur> but I'll probably be switching back since it's gtk3
[22:55] <dax> does it have sasl or any of the other various important changes from hexchat?
[22:55] <dax> 'cause it didn't last time i looked, and this was saddening
[22:57] <mdeslaur> the codebase is pretty similar, so it should be relatively trivial to fix that if it doesn't
[22:57] <RAOF> jbicha: If you would very kindly upload colord-gtk to Debian that would be a kindness.
[22:57] <mdeslaur> I'd rather hexchat switch to gtk3 though
[22:57] <dax> same
[23:05] <jbicha> RAOF: can I bump its debhelper compat to 10 first?
[23:05] <RAOF> jbicha: Sure. I was going to do that myself, but then decided that I didn't need any of the changes.
[23:07] <RAOF> I guess with compat level 10 we could drop the autoreconf sequence from the `dh` invocation.
[23:07] <jbicha> RAOF: all done
[23:07] <RAOF> Rad.
[23:08] <RAOF> I might see if I can trouble you to upload a new colord later, as well, but colord-gtk ended up taking longer than I thought :)