[01:23] <crimsun> JFo: do you happen to have access to an identical model ThinkPad as the reporter's in #548661?
[01:24] <crimsun> (I'm not convinced that it's a kernel issue)
[03:43] <JFo> crimsun, I don't, but I can find out if someone else does
[03:55] <crimsun> JFo: much obliged
[03:57] <JFo> my pleasure
[03:57] <crimsun> I'm attempting to shift my work schedule to accomodate her responses, but it's difficult
[03:58] <JFo> yeah, :-/ UK time...
[08:22] <JohnFlux> smb: hey :)
[08:23] <smb> JohnFlux, Not here right now. I haven't had my first coffee. :-P
[08:23] <JohnFlux> smb: :-)
[08:23] <JohnFlux> smb: we added support for my driver to the kernel...  do you know roughly when that means I can use that kernel and be able to have the nvidia drivers?
[08:24] <JohnFlux> smb: I'm just being spoilt now :-)
[08:24] <JohnFlux> smb: getting the nvidia drivers isn't a high priority, just a niceity
[08:25] <smb> JohnFlux, your id quirk should have been in since around this Monday. "The" nvidia drivers I fail to make a connection to right now
[08:28] <JohnFlux> smb: yes, quite possibly my question is nonsense.  At the moment I have a "custom" kernel.  Can I install the proprietary nvidia drivers?
[08:29] <JohnFlux> smb: actually I should just stop bothering you and go google
[08:29] <smb> JohnFlux, I think I saw Alberto tell people they are "safe" now.
[08:29] <JohnFlux> cool
[08:57] <JohnFlux> smb: the nvidia drivers gave an error when installing, but worked anyway
[08:57] <JohnFlux> smb: thanks for the help
[08:58] <smb> JohnFlux, Sounds good. Welcome.
[09:04] <smb> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/539655
[09:04] <ubot3> Malone bug 539655 in linux "nouveau hard lockup in nouveau_gem_ioctl_cpu_fini" [Medium,Triaged]
[10:14] <apw> http://patchwork.ozlabs.org/patch/48906/
[10:19] <Kevin`> hi, cjwatson says this should be handled here, so: simple fix to this bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/160366
[10:19] <ubot3> Malone bug 160366 in linux "Add xen netboot support" [Wishlist,Triaged]
[10:20] <Kevin`> 03:30 < cjwatson> xen-blkfront should go in scsi-modules, and xen-netfront  should go in nic-modules
[10:20] <Kevin`> 03:31 < cjwatson> (feel free to copy and paste that)
[10:23] <Kevin`> to be clear, a seperate version of the installer isn't needed, like the original author suggested
[10:27] <smb> Kevin`, Ok, yeah. So just those two. Should be doable. Thanks
[10:28] <Kevin`> np :)
[10:32] <Kevin`> might be proper to include the framebuffer/keyboard interface, assuming it isn't already included. I don't know if there's a way to do a graphical netboot install anyway though?
[10:32] <Kevin`> I certainly never do
[13:38] <apw>  *      <xres>x<yres>[M][R][-<bpp>][@<refresh>][i][m][eDd]
[13:39] <apw> video=VGA1:stuff
[14:42] <tseliot> mjg59: I'm getting this with the open radeon driver "ACPI: ACPI brightness control misses _BQC function" with a Mobility Radeon HD 4200 (1002:9712). No backlight for me?
[14:42] <tseliot> well, backlight management
[14:46] <mjg59> tseliot: Lacking _BQC won't inherently result in missing ACPI backlight
[14:46] <mjg59> Do you have anything in /sys/class/backlight?
[14:47] <tseliot> mjg59: yes, I have /sys/class/backlight/acpi_video0/ but my problem is that dimming the backlight freezes X
[14:47] <mjg59> tseliot: Unrelated to the kernel message, then
[14:48] <mjg59> Probably implemented via some SMI that interacts badly with the native driver. What machine is this?
[14:48] <tseliot> mjg59: it's an Inspiron
[14:48] <tseliot> dell inspiron
[14:49] <mjg59> What model?
[14:49] <tseliot> mjg59: fglrx gets this right
[14:50] <mjg59> Still via the acpi_video backlight?
[14:50] <tseliot> mjg59: it's from series 11, I can't say more
[14:51] <tseliot> mjg59: ah, that's a good question but I don't how fglrx works
[14:52] <mjg59> That makes fixing things difficult
[14:52] <mjg59> You're best going via Dell, then. They'll be able to work out what the BIOS is doing
[14:52] <tseliot> mjg59: can it be a BIOS issue?
[14:53] <mjg59> Given that it works with fglrx, it's clearly a radeon bug
[14:53] <tseliot> ok, thanks for your help
[14:53] <mjg59> But if it's via an SMI call, there's no way to work out what the BIOS is doing
[14:54] <mjg59> It's probably writing to some chip register directly
[14:54] <mjg59> And failing for one reason or another
[14:54] <tseliot> oh
[14:55] <mjg59> Due to a difference in chip setup between radeon and fglrx
[14:55] <mjg59> But without knowing what it's doing, fixing this is difficult
[14:55] <mjg59> You presumably can't send me the acpidump
[14:55] <mjg59> And even if you could, it'd probably just show an SMI trigger
[14:55] <mjg59> So you'll need to ask Dell what the backlight setting is doing, and then work out why that conflicts with radeon
[14:57] <tseliot> ok, I'll definitely ask Dell, thanks
[14:59] <mjg59> tseliot: Note that the correct fix for this is *not* a bios update
[14:59] <mjg59> The bug is definitely in radeon, and that's where the fix should be
[14:59] <tseliot> mjg59: yes, we should fix radeon after seeing what's going on
[14:59] <tseliot> got it
[16:04] <cnd> is there a place where bugs that weren't picked up for lucid are monitored for M?
[16:05] <cnd> There's bug 333990, which should be a simple config option in the kernel, and I don't want it to forget about it for M like seems to have happened since jaunty
[16:05] <ubot3> Malone bug 333990 in linux "[Karmic]Please enable PCI express ASPM (powersave)" [Medium,Won't fix] https://launchpad.net/bugs/333990
[16:06] <cnd> Is the Ubuntu later milestone used for such purposes?
[23:11] <crimsun> bjf: my inbox exploded thanks to the tagging. Had to add another filter. :-)
[23:12] <bjf> :-)
[23:13] <crimsun> so, we could probably halve these mic bugs by doing these two things:
[23:13] <crimsun> 1) making sure *Mic Boosts are raised to max
[23:14] <crimsun> 2) grepping the HDA codec dumps to make sure the correct init is made
[23:14] <crimsun> (and of course the underlying init keeps changing from under me...)
[23:14] <bjf> ack


[07:54] <tjaalton> sweet, only eight packages non-synced/merged with debian
[07:54] <tjaalton> I'll merge a couple later today
[08:52] <Sarvatt> tjaalton: dont suppose xorg-server is in there huh? :D
[10:02] <Sarvatt> wow nice, I just applied this to xorg-server 2:1.6.0-0ubuntu15 and its amazing how fast VT>X switch is in KMS now. http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=commit;h=fdbb6fd3d3c0ce7078f8faaf089af51cc36cbcb3
[11:03] <tjaalton> Sarvatt: sure. I'll add that commit, since there is a noticeable lag when switching back to X
[11:07] <tjaalton> oh right, it's included in <IP_ADDRESS>1
[12:23] <tjaalton> bryce: there are a bunch of patches against xorg-server by you. plans to send them upstream?
[13:42] <Sarvatt> xvmc-vld branch of xf86-video-intel is looking good, xvmc's working in UXA now
[17:13] <Sarvatt> your xorg-server 1.6.2rc1 works great here tjaalton - http://sarvatt.com/downloads/Xorg.0.log.txt
[20:24] <Sarvatt> nice, UXA hangs in firefox are fixed now, just finished compiling a new kernel/drm/intel driver to test the patches. bad news is it needs updates to all of those to be fixed.. https://bugs.freedesktop.org/show_bug.cgi?id=20152
[20:36] <albert23> Last exa migration before the 965 freeze occurs: -> 0x5750ec0 (0xffe0a00) (1280x25) (c)
[20:36] <albert23> assuming size of the pixmap is 4 bpp x 1280 x 25, the pixmap ends at FFFFE00
[20:37] <albert23> Yesterday I found pushing back exa offscreen from the end of aperture prevented the freeze
[20:37] <albert23> So that seems to match quite nicely
[20:38] <albert23> Could there be any reason the gpu reads more then the pixmap size, for example due to tiling?
[20:39] <albert23> jbarnes maybe^?
[20:42] <tjaalton> better ask on #intel-gfx
[20:42] <tjaalton> Sarvatt: ok, good to know
[20:46] <jbarnes> albert23: yes, that's one reason... it also prefetches data past the end of objects
[20:47] <albert23> jbarnes: how large would the prefetch be? Pushing back exa offscreen 4 KB didn't help. 1MB seems to be enough
[20:47] <jbarnes> generally shouldn't got past a page of prefetch
[20:48] <jbarnes> but tiling can increase the object's size to the next power of two
[20:48] <jbarnes> or at the very least its width will be increased to the next multiple of the tile size
[20:48] <jbarnes> which can add a lot
[20:49] <albert23> jbarnes: note we had the 32MB classic texture buffer until beginning of April
[20:49] <jbarnes> yeah I saw that add... interesting
[20:49] <albert23> so this matches also with the beginning of the freeze bug
[20:49] <albert23> Now we only need a safe value for the push back...
[20:50] <albert23> The 32 MB classic was causing problems on some older 8xx cards
[20:52] <albert23> Assuming maximum display height of 4096 lines, 8MB should be safe
[21:06] <albert23> Well, we can always calculate the required unused memory dynamically, and possibly only if IS_I965G(pI830)
[21:58] <albert23> This is what I am testing now. Maybe someone else who has the freeze can test this as well? http://paste.ubuntu.com/175953/


[17:35] <OvenWerks> zequence, knome: http://cdimage.ubuntu.com/ubuntustudio/dvd/current/ still has old saucy images in it. Who do we ask to have it cleaned?
[17:35]  * OvenWerks is downloading a trusty iso so he can test changes against it
[19:27] <knome> OvenWerks, would first check if people in -release know what's going on, then maybe ask #canonical-sysadmin
[22:58] <OvenWerks> knome: Thanks
[22:58] <knome> no problem
[22:59] <knome> tell me if you need more help with it
[23:01] <OvenWerks> I don't think you have the access :)
[23:12] <knome> i don't, but if poking those places do not seem to help...


[00:48] <pingu> kubuntu is just loading the desktop wallpaper and nothing else when I boot the ISO
[00:48] <pingu> and please only 1 person help me because im not getting bombarded with bash commands as a complete newbie
[00:48] <pingu> (unless you want me to go back to windows of course :P)
[00:49] <pingu> i gave the VM 4gb ram and 21gb VDI
[00:52] <pingu> kubuntu-23.04-desktop-amd64.iso
[00:58] <pingu> oh wait it finally loaded the logon screen
[01:10] <pingu> wow really ? 'If your user account doesn't have a password set, you won't be able to switch to another user or perform administrative tasks using the su or sudo commands. In this case, you can follow these steps to set a password for your user account:'
[01:10] <pingu> its a damn VM
[01:10] <pingu> I only want to learn bash
[01:21] <pingu> k  I was advised it would be much easier to just delete this user and make a new user so I did that
[02:19] <dabbler> What's the most recent version of kubuntu for which the old installer is still available?
[02:47] <dabbler> I need LUKS+Btrfs support
[09:30] <guruprasad> dabbler, the 23.04 installer looked the same as the installers from the previous releases and it allowed me to set up Btrfs+LUKS by following the instructions in https://mutschler.dev/linux/ubuntu-btrfs-20-04/
[09:31] <guruprasad> The only thing that I had to change was to use `space_cache=v2` instead of `space_cache` in the mount options.
 Hi all
 Kubuntu shows busybox initramfs error when SATA in bios is set to RIDE ON
 RAID*
[11:48] <oerheks> Omar good, as expected.
[11:48] <oerheks> do not set it to raid, as the manual gives.
[12:13] <BluesKaj> Hi all
 What should i set it to? (re @IrcsomeBot: <oerheks> do not set it to raid, as the manual gives.)
[12:35] <oerheks> ?
[12:35] <oerheks> set it back
 + my other laptop is sat to RAID and it is working
[12:35] <oerheks> oh? working with ubuntu?
 Yeah (re @IrcsomeBot: <oerheks> oh? working with ubuntu?)
[12:36] <oerheks> most of those raid devices onboard are soft raids
 It was on RAID before i install linux (re @IrcsomeBot: <oerheks> set it back)
[12:36] <oerheks> and such raid option should be set before install.
 It work when i set it to ACHI
[12:37] <oerheks> i guess that raid is not suitable.
[12:37] <oerheks> good luck!
 It was (re @IrcsomeBot: <oerheks> and such raid option should be set before install.)
 Thank you (re @IrcsomeBot: <oerheks> good luck!)
 I tested it via Bluetooth and it lagging
[13:24] <oerheks> IrcsomeBot, nobody knows what you are testing, telegram is a lagging service
[17:32] <user|17> come si installa su pendrive usb
[17:33] <oerheks> !usb
 Thanks man


[02:02] <lotuspsychje> good morning
[04:38] <lotuspsychje> leftyfb: its been weeks registered trolls come mock us with random unsolvable issues
[04:38] <lotuspsychje> they know how they work, and slip tru the system
[04:38] <leftyfb> oh, I'm not sure it's unsolvable. But I'm pretty damn sure it's unsupported
[04:39] <lotuspsychje> they sort of join in gangs, like 5 questions in 5min
[04:39] <leftyfb> who in their right mind (that doesn't already know how to ) is running LILO on ubuntu regardless if you "can"
[04:39] <lotuspsychje> lol
[04:40] <lotuspsychje> i wonder if that wouldnt give mass problems with todays ubuntu
[04:40] <lotuspsychje> replace grub with lilo hehe
[06:04] <guiverc> i saw a question earlier today on askubu about lilo..  it's still used on mainframes (s390) I think...
[06:07] <lotuspsychje> !info lilo
[06:07] <lotuspsychje> been ages since i saw one guiverc :p
[06:11] <guiverc> lilo?  or mainframe??  or both?? :)
[06:11] <lotuspsychje> lilo
[06:13] <guiverc> really old debian for me (pre 2004/ubuntu... not sure I've ever seen lilo on ubuntu though. switched to grub before I tried ubuntu)
[06:13] <lotuspsychje> its too long ago for me.. perhaps some early redhat?
[07:01] <Katnip> redhat 6 and debian...
[07:01] <Katnip> about 1998
[07:04] <lotuspsychje> yeah that must have been it
[07:20] <lordievader> Good morning
[07:27] <ducasse> good morning
[11:53] <oerheks> yay, netgear ... https://gist.github.com/nstarke/a611a19aab433555e91c656fe1f030a9
[11:54] <lotuspsychje> iot & routers =zombieland2
[11:54] <oerheks> Idiots of Technology
[11:54] <lotuspsychje> lol
[11:55] <oerheks> like the 737-max, designed by hoompa loompas
[11:55] <lotuspsychje> admin:1234 also helps very much
[11:55] <oerheks> admin:admin, standard by ziggo
[11:55] <lotuspsychje> good idea to default passwords on connected devices
[12:00] <pizzaiolo> morning
[12:00] <lotuspsychje> morning pizzaiolo
[12:01] <pizzaiolo> have an optional holiday today, should be pretty quiet in the office :)
[12:01] <daftykins> daft question then... but just having a private key to one of their helper domains for reaching a home router, what's the best anyone can really do?
[12:07] <lordievader> I suppose that routerlogin.com address redirects to the login page of your router. Suppose you divert the traffic to something which captures the credentials. If the admin webinterface is exposed to the internet, you can then login to their router.
[12:08] <lordievader> From the perspective of the user everything is "fine" (correct keys used, etc.).
[12:09] <daftykins> yeah i was thinking that might be the extent of it too, so not terribly exciting
[12:13] <lordievader> You'd think they don't share the privkey among certificates... right?
[12:17] <daftykins> oh yeah it's still a big fail :D
[12:17] <daftykins> i'm always disappointed how these router companies only fix things when dragged along by the hand and forced
[12:19] <pragmaticenigma> why fix the old, when there is the new shiny to produce?
[12:19] <daftykins> let me relink you to oerheks share from just earlier - https://gist.github.com/nstarke/a611a19aab433555e91c656fe1f030a9
[12:20] <oerheks> :-D
[12:20] <oerheks> i have some twitters stored, that give these posts
[12:21] <oerheks> more fun than Garfield comics
[13:48] <oerheks> i need chrome on my server
[13:49] <pragmaticenigma> how come?
[13:51] <lordievader> I was about to say that is is strange to run a webbrowser on a server, and then I thought that I am running w3m quite frequently on my server XD
[13:52] <lordievader> If only the email world would ditch html.
[14:03] <pragmaticenigma> lordievader: ditch? they're trying to get it to be more compliant with HTML5
[14:06] <lordievader> Or... we could just go back to plain text \o/
[14:08] <pragmaticenigma> I suspect it's an uphill battle there lordievader ... ask your friendly local marketing guy
[14:09] <lordievader> I know.
[14:13] <lotuspsychje> bug #1841718
[14:15] <lotuspsychje> a big one :p
[14:15] <lordievader> Sounds like fun -.-
[14:16] <lotuspsychje> we had a few user complaints about that
[14:16] <oerheks> njummie
[14:38] <pizzaiolo> what's going on in main?
[14:38] <lotuspsychje> a user with a teleport bot
[14:39] <lotuspsychje> teleporting meesages to another chat/server
[14:40] <pizzaiolo> so they're on another network all together and the bot acts as the 'bridge'?
[14:41] <lotuspsychje> it teleports between yeah
[14:42] <oerheks> if this one is accepted, it opens the door to tons of scripts/bots
[14:42] <oerheks> why he, not me?
[14:44] <pragmaticenigma> I don't think it's been accepted... this individual seems to only come out when they're certain the ops aren't paying attention
[16:16] <leftyfb> tomreyn: what came of keyrcbot?
[16:22] <pragmaticenigma> at the moment... nothing... they never joined -ops and pricey is giving up
[16:22]  * oerheks facepalms
[16:23] <pragmaticenigma> last message logged from -ops: Pricey "I think it might be easier to move on with our lives. I expect the users will find it annoying (if there are multiple) and gentle recommendations of alternative clients to them at that point will give the best outcome."
[16:24] <pragmaticenigma> So I guess we're left with asking keyrcbot user to please fix their client to make it more user friendly
[16:24] <pragmaticenigma> change our approach
[16:25] <oerheks> i just don't answer him anymore, done.
[16:25] <pragmaticenigma> oerheks, leftyfb - For now, the compromise was to ask the user running keyrcbot to reconfigure their software so that it doesn't tag the messages with the remote user name, and Ideally if they could authenticate into freenode using the same remote username to reduce confusion
[16:26] <leftyfb> pragmaticenigma: that's not how the client works
[16:28] <pragmaticenigma> I figured as much, but perhaps requesting they find a better method for their "bridge" would prove effective?
[16:29] <leftyfb> 2020 Jan 20 09:34:24 <keyrcbot>	[rudi9719]: This is not a debate.  Although I find most bridges slightly annoying, some users find them useful (for example, from work I cannot connect to IRC, so I might want to use a bridge)
[17:49] <hggdh> if we cannot auto-complete the actual user, this is a problem on the bridge side, not on IRC. (I have no idea how keyrcbot deals with it, but, again, not my problem)
[17:49] <pragmaticenigma> hggdh: Yes, we get that, and that was discussed in the -ops channel as a valid use. However, they should be configured properly to reduce the amount of noise. I see no reason that the person in question can't properly configure or find a more appropriate piece of software to do their bridging without making it difficult for other users to communicate with them
[17:49] <hggdh> so, to call it a bot is just plainly wrong.
[17:51] <oerheks> he said others use it too.. so another potential ircsomebot account that delivers spam?
[17:51] <pragmaticenigma> hggdh: The issue taken is the fact that the user claims to have multiple people behind the bridge, where as multiple people behind the bridge trying to help different people in the #u channel is going to cause great confusion and irritation. We're trying to make the use of Ubuntu as pleasent as possible. Nothing worse than going to the support room, and having no idea who to talk to or who is actually responding to you
[17:51] <hggdh> pragmaticenigma: I see no reason for WHY they MUST "properly configure it". It is working for them. If they cannot distinguish which message is for which of their users, they will soon have a reason to "reconfigure" it.
[17:51] <oerheks> :(
[17:51] <pragmaticenigma> hggdh: you keep missing the point... THERE ARE MULTIPLE USERS BEHIND IT. The operator claimed as much... but ops can just keep cherry picking words from my comments
[17:52] <hggdh> IF they start to be annoying because of lack of proper addressing, then we can consider other actions
[17:52] <pragmaticenigma> I would much rather not see it come to that
[17:52] <pragmaticenigma> being reactive to such an incident is a poor experience for all... especially for a new person just coming into the community
[17:52] <hggdh> pragmaticenigma: yes, I know, this is the idea of a bridge. Their problem, not ours. But you went on attack mode first
[17:53] <pragmaticenigma> I asked as politely as I could
[17:53] <pragmaticenigma> hggdh: my first request to them was far, far from being aggressive or an attach
[17:54] <hggdh> pragmaticenigma: again, the benefit of doubt.
[17:55] <hggdh> if they start spamming, we will deal with them as we deal with any other spammer. Being a bridge, this means that all of their users will be affected (and, again, this is their problem)
[17:55] <pragmaticenigma> oh... so you can go and make it sound like I was the agressor, but completely ignore the behavior of them there after.... quite the double standard... but then again... that seems to be the montra of ops
[17:56] <hggdh> I see it as neing rude. They answered -- and it mostly always happen -- being rude as well. They were NOT being spammers, and they were NOT off-topic.
[17:57] <pragmaticenigma> I was not rude, that was never my intention. I asked them as kindly as I could... but there you go with the double standard... give them the benefit of the doubt, but accuse me of being aggressive in my opening statement
[17:57] <hggdh> the mantra of ops is "try to de-escalate", "give the user the benefit of doubt", "try to understand".  Some of them will be bad. Some of them will be nice. Just like any registered user
[17:58] <hggdh> pragmaticenigma: I did not say it was your intention. But this is how it came thru
[17:59] <pragmaticenigma> your own words said I was aggresive
[18:00] <pragmaticenigma> hggdh: and oerheks is right, we require registration, to help minimize the spam and clutter. This person is allowing other users to use their gateway as a means to bypass the very thing we're trying to prevent in the first place
[18:00] <hggdh> yes. You were. But this does not mean you *intended* to be so. It is just the way they read it (and I as well)
[18:01] <pragmaticenigma> so to me, it really does appear that something needs to be done about it now, before it becomes the problem down the road.
[18:01] <hggdh> so, they one of their users abuse, we /quiet /kick /ban (as needed) the whole bridge.
[18:01] <hggdh> I do not see the problem. This has happened before
[18:02] <pragmaticenigma> I have been in here for the better part of 2 years now... this is the first time I've witnessed this type of behavior. I'm not discounting the benefit of a bridge, not everyone can maintain a constant connection. But you and the rest of -ops just discount the fact that 4 people all have the same opinion about this particular case, and you refuse to do nothing about it
[18:03] <pragmaticenigma> *to do anything about it
[18:06] <pragmaticenigma> hggdh: also to note those 4 people are among the larger contributors in providing assistance in channel
[18:10] <leftyfb> pragmaticenigma: par for the course with the ops. Blame the volunteers and let the abusers go about their business
[18:11] <pragmaticenigma> you forget leftyfb ... also tell the volunteer to back down because "reasons"
[18:11] <pragmaticenigma> citing previous incidence without providing proof
[18:12] <leftyfb> pragmaticenigma: I know all about it. Been dealing with it for a while now.
[18:14] <pragmaticenigma> In recent history, I so seldom raise things to the level of ops... yet I'm made out to be the bad guy... let alone trying to ask a user in #u why they're connected the way they are would result in immediate action by ops to say I was offtopic no less
[18:15] <leftyfb> pragmaticenigma: don't take it personally. This is how the ops operate.
[18:16] <pragmaticenigma> I don't take it personally... i just don't like being shutdown on whims of fancy

[18:52] <pragmaticenigma> hggdh: Let's change the perspective and drop the pretense... What I and others are asking for, is not the ban or removal of that user. We aren't even focused on the usage of the "bot" or whatever is the more appropriate term to call it. What we are asking for is that ops attempt to reach out to this person, and attempt to ask them to make whatever it is that they're using, more transparent to reduce the friction for users
[18:52] <pragmaticenigma> trying to request help. The confrontation comes from the perceived apathy from ops that no effort is made other than to ask the person who raised the issue to step back.
[18:53] <pragmaticenigma> which is why we have these disagreements. if ops wants to do nothing, that is well within their right, but to brush others off serves as a real disservice to everyone trying to make this a better community
[19:28] <hggdh> well
[19:29] <hggdh> first of all, what pretense?
[19:30] <hggdh> secondly, in what ways did the owner of the bot break the rules? Please note that the fact you do not like a bridge does not make is intrinsicly bad, or mean
[19:33] <pragmaticenigma> there you go again, putting words in my mouth... did you read what I said in -ops? I said I don't mind a bridges, but would appreciate them configured to avoid such friction in addressing a user on the other end
[19:33] <pragmaticenigma> hggdh: the guidelines... the guidelines that are published at !guidelines... right there, in the text says NO BOTS
[19:33] <pragmaticenigma> Ubuntu already provides bots for channel logging, for help, and factoid related queries - there really is no need for more bots. If you think another bot would be helpful, contact the channel operators first.
[19:34] <pragmaticenigma> that is right from the guidelines page itself
[19:34] <pragmaticenigma> hggdh: so if you want to keep calling it a bot.. .then by the very definition of the term, it's not allowed per the very guidelines the ops are supposed to be upholding
[19:34] <hggdh> this is a bridge, and it is behaving as a bridge
[19:34] <pragmaticenigma> so now we're going to flip flop on the term
[19:35] <pragmaticenigma> PICK ONE!
[19:35] <pragmaticenigma> What do you want to call it hggdh ?
[19:35] <pragmaticenigma> seriously... ops needs to pick what they're going to define it as... and as such, there are much better implementations of bridges out there that don't echo like this one does
[19:36] <pragmaticenigma> The source for keyrcbot is right here hggdh : https://github.com/Rudi9719/keyrcbot/blob/master/keyrcbot.go
[19:36] <pragmaticenigma> it's defined as a bot
[19:36] <pragmaticenigma> so lets go with that... and since the author is calling it a bot, but the definition in the guidelines, it's not allowed
[19:36] <pragmaticenigma> s/buy/by/
[19:36] <hggdh> I would call it a bridge. I *did* call it a bridge before. But you are fixed on bot, so I thought it would be easier to call it a bot. I apoligise
[19:37] <hggdh> And I do not really care on what they call themselves. It is -- so far -- a bridge. While it behaves like a bridge, no problems.
[19:38] <pragmaticenigma> Except that it is confusing users in chat... they don't know who to reply to
[19:38] <hggdh> I also would like to point out that -- until oerheks and you started questioning it -- their users we behaving nicely.
[19:38] <hggdh> pragmaticenigma: and how is this a problem for you?
[19:38] <pragmaticenigma> We pointed it out because we're were having issues not knowing who they're talking to
[19:39] <hggdh> when THEY send a message, they can add a nick -- and it WILL highlight the nick. When YOU send to them, you can only tab-resolve to the bridge's nick. So I see this as a problem for THEM
[19:40] <oerheks> Indeed, he is polite. but my point is; it opens the door for other services, i don't like to see whatsapp/matrix spam, without knowing what to do
[19:40] <pragmaticenigma> I'm really on the camp with oerheks ... it's that it is opening the door to a point where it will get out of control. better to uphold the rules per the letter of such rules... than give graces to some and not others
[19:42] <pragmaticenigma> it just makes it more difficult down the road... if you were a landlord and had a rule of not allowing residents to plant flowers, but because one asked nicely you let them... then you have everyone planting flowers... then there is the one unit that waters their flowers and dumps water on the passerbys below
[19:42] <oerheks> oke, now we are all up2date about this bridge, i appreciate your comments on this hggdh
[19:42] <pragmaticenigma> now how are you going to tell that person they can't have flowers on their patio, when everyone else can...
[19:44] <hggdh> I understand where you are going (or so I think). But the analogy breaks at a few points. (1) a landlord cannot evict a resident without some due legal process; we can, on the other hand, if we perceive the need
[19:44] <hggdh> (2) they did not behave as a bot EVEN if they named themselves one;
[19:44] <pragmaticenigma> hggdh: the due process wouldn't be a problem if the first person wasn't allowed to do the behavior in the first place
[19:45] <hggdh> (3) everything was going nicely UNTIL you started discussing it
[19:45] <pragmaticenigma> hggdh: and there we're back to blaming me for all this
[19:45] <pragmaticenigma> hggdh: so much help
[19:45] <pragmaticenigma> much luv
[19:45] <hggdh> the due process is ALWAYS needed. And users can misbehave even when they are not behind a bridge
[19:46] <hggdh> pragmaticenigma: please read "you" as a collective
[19:46] <hggdh> all y'all if you prefer
[19:46] <pragmaticenigma> right hggdh but they typically don't misbehave... as they recoginize it's their direct handle at risk of being kicked
[19:47] <hggdh> so, again: what was the problem?
[19:48] <hggdh> again: everything was going nice until all y'all started discussing it
[19:48] <pragmaticenigma> i've explained every avenue to which you just won't read or just outright perfer to shift blame... alll you're doing at this point is trying to wear me down and hope I go away
[19:50] <pragmaticenigma> We asking for the mods to be proactive, rather that reactive when it becomes a problem. All I'm asking is that you reach out... but you can't be bothered... because the ops are too busy to give too rips about the reputation of the community... let's wait till it gets as bad as ##linux... then try to do something... but oops, that'll fail because of the due process that wasn't followed in the firs tplace
[19:50] <hggdh> Oh, I see. *I* am shifting blame to all y'all, but YOU are not shifting blame to the ops :-)
[19:51] <pragmaticenigma> well you're certainly not upholding your pillar of de-escalation either
[19:51] <hggdh> (1) they did not cause problems; (2) if, and when, they became a problem we will deal with them; (3) not liking them is not reason. There.  I am just not agreeing with your reasoning, which is quite different. But I *am* trying
[19:54] <pragmaticenigma> then please, stop the blame shifting and I'll do the same
[19:54] <pragmaticenigma> I'm trying my best to explain what my position is... but I keep getting accused of having it in for the other party. That's what I meant by drop the pretense
[19:55] <oerheks> pragmaticenigma,  breeth in and out, lets wait and see what is going to happen, besides, i do not like to loose you as volunteer
[19:55] <oerheks> people left #u for less troubles
[19:56] <hggdh> oerheks: I do not remember threatening to kick pragmaticenigma
[19:57] <oerheks> no, you didn't, but i feel there is some tension that should not be there, between *us*
[19:57] <hggdh> I agree. And I am sorry I could make myself clear.
[19:57] <oerheks> it is all about people and people, in the end.
[19:59] <pragmaticenigma> hggdh: Here's what I'm asking, and only what I'm asking. I have a concern with a person in #u that appears to be using software that they have defined as a "bot" to provide themselves with a bridge to another chat system. I'm asking that the -ops please reach out to the individual on the basis that the channel prefers a bot not be used. I recommend that -ops ask this individual to consider updating their software to make
[19:59] <pragmaticenigma> it appear that they are a regular user to provide a more consistent user experience for everyone.
[19:59] <pragmaticenigma> that's it
[20:00] <hggdh> pragmaticenigma: OK. I will pass it on.
[20:00] <pragmaticenigma> I always intended this to be an ask, and that's all anyone I feel would like to see
[21:18] <Bashing-om> UWN614 is on the streets: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue614
[23:34] <lotuspsychje> good morning
[23:44] <tomreyn> hey there, lotus
[23:44] <lotuspsychje> hey hey tomreyn
[23:44] <jeremy31> I will not be awake at 12:44 AM
[23:45] <lotuspsychje> blame years of working in shifts
[23:45] <tomreyn> the earöy bird catches ... the first ticket
[23:45] <jeremy31> second mouse gets the cheese
[23:46] <lotuspsychje> lol tomreyn
[23:46] <lotuspsychje> the first ticket is MINE
[23:46] <tomreyn> second mouse gets grumpy tom
[23:47] <lotuspsychje> lol
[23:48] <lotuspsychje> anyone with ati seen updates coming in?
[23:50] <tomreyn> i only got amdgpu, and that's on 18.04, no recent updates
[23:50] <lotuspsychje> kk tnx
[23:51] <lotuspsychje> now bug #1841718 is fixxed
[23:51] <pragmaticenigma> well... fix committed... I say fixed when it's released


[14:39] <alkisg> Hi, I want to include some file called "someconfig.in" in my package, which will contain a line like "my arch is @ARCH@", and the @ARCH@ will be replaced with the compile-time architecture.
[14:40] <alkisg> The rest of the package files are in shell or python, nothing gets compiled so we're not using autotools etc yet
[14:40] <alkisg> Where should I look? What part processes .in files? Is that autotools?
[14:40] <sney> that is
[14:41] <alkisg> Thanks, googling... :)
[14:42] <geser> are you wanting to include this upstream or only in your packaging?
[14:43] <alkisg> I'm both upstream and packager, so I guess it would be better to include it upstream
[14:43] <alkisg> Would a simple makefile be enough, since I only want that one simple thing?
[14:43] <alkisg> With some sed expression inside to replace ARCH?
[14:43] <geser> yes
[15:00] <Rhonda> Laney: uploaded for utopic, not yet for trusty, it's pending for when I don't need the bandwidth. :)
[15:12] <psusi> how do you slap bzr upside the head and get it to stop unapplying quilt patches all the time?  I can find nothing about bzr and quilt in the documentation or web.
[15:35]  * alkisg can't find an $ARCH variable in Makefiles...
[15:35] <alkisg> If I have to find it myself with shell, dpkg --print-architecture etc, then why would I use make instead of a plain #!/bin/sh file?
[15:38] <geser> it's up to you if you use a Makefile for the sed call or use a shell script to do the same
[15:39] <alkisg> geser: not for the sed call, but for detecting the build architecture
[15:40] <alkisg> E.g. amd64 in debian vs x86_64 in other distros
[15:40] <alkisg> I wouldn't want to use distro-specific code there, would I?
[15:41] <alkisg> In some distributions I would see it with `uname -m`, in debian-based distros with `dpkg --print-architecture`, but it sounds like a very common problem, I would assume a more elegant solution would be available...
[16:55] <alkisg> Oh well, if we're going to have distro-specific code anyway to detect the target arch, we can just leave the `sed /s/@ARCH@/$ARCH/` part up to the packaging process...