[02:54] <hallyn> apw: sforshee: so "recently" eric did the patches so that if you mount something over part of /proc, an unpriv user (in userns) can't uncover the mounted part.  can't umount the cover, can't mount a new instance
[02:56] <hallyn> i didn't really think it was something people did...  more importantly it causes trouble for nested unprivileged containers.  since lxcfs files are mounted over procfiles, unpriv user can't then create a container
[02:56] <hallyn> how would you feel about a sysctl to turn that off?
[02:56] <hallyn> (it's done only for proc and sysfs near as i can tell)
[02:57] <hallyn> maybe i'll see how eric feels about that upstream
[03:00] <hallyn> hm, though what i'm seeingdoesn't *really* make sense...
[03:06] <hallyn> hm, maybe there should be an added check for sb equivalence
[03:07] <hallyn> probably doesn't make him feel as cozy...
[03:11] <hallyn> heh, can't do that.  no sb yet
[03:22] <hallyn> well let's instrument for one more debug kernel
[04:25] <stgraber> hallyn: one thing that worries me there is that those fixes are in stable, so that effectively broke or will break all of our users... admitedly I'm probably the biggest user of userns nesting, but still, I can't be the only one.
[04:26] <stgraber> adding a sysctl may be fine, but we'd have to SRU a lxc packaging change to all supported releases to turn said sysctl on (and do so conditionally depending on kernel version as some won't have it)
[04:26] <stgraber> anyway, going to bed now
[11:19] <Tehdastehdas_> I'm trying to report a kernel bug using "ubuntu-bug linux" as instructed in https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies . The first instruction after that is "The submitter should provide as much information as possible in the bug description". Where do I write this bug description? The first thing Apport asks me after launching it is "Send the report? | Cancel / Send"
[11:21] <jpds> Tehdastehdas_: That's after you send it
[11:21] <Tehdastehdas_> Oh
[11:23] <Tehdastehdas_> I wonder how many other users stopped there...
[11:23] <teward> you'd be surprised how many people run `ubuntu-bug` for other packages and just don't put information in either
[11:24] <Tehdastehdas_> maybe they have browser trouble
[11:35] <Tehdastehdas_> Success: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1491797
[11:37] <jpds> Tehdastehdas_: Did you configure the system to suspend on overheat?
[11:38] <apw> we have a configuration option for that
[11:38] <apw> from what i can see the kernel is seeing the machine hit a critical temperature milestone and bailing to avoid dammage, that seems appropriate
[11:39] <jpds> Yeah, it doesn't sound like it's being "foolish"
[11:39] <Tehdastehdas_> But why not suspend as default?
[11:40] <jpds> Tehdastehdas_: I can't actually think of a situation where any of my machines have overheated
[11:40] <Tehdastehdas_> Sure, but just google "laptop overheating"
[11:40] <jpds> And if it was a server room where the aircon failed... I'd rather the machines turned completely off really
[11:41] <Tehdastehdas_> How do I configure the system to suspend on overheat?
[11:42] <Tehdastehdas_> Also, how do I change the temperature limit, because sometimes bios crashes the machine first
[11:42] <jpds> Tehdastehdas_: Only reason I can think of where a laptop would overheat is a blocked fan?
[11:43] <jpds> At that point... you should clean the fan
[11:43] <Tehdastehdas_> Nope, the hardware has been disassembled, and everything was fine. Then I drilled extra holes to the bottom.
[11:44] <apw> Tehdastehdas_, the temperature limits come from the bios tables iirc
[11:44] <apw> and normally the bios is in charge of the fans and the kernel just finds out about alerts from the bios
[11:44] <Tehdastehdas_> Using xsensors I can see that the fan runs 3500 rpm right before the crash, while maximum rpm is 5000
[11:45] <apw> yep and the lenovo bios fan control has been criticised often in the older machines particularly for not spinning up quick enough
[11:46] <Tehdastehdas_> Another slow fan Lenovo bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/751689
[11:46] <apw> indeed cking (not here atm) did a very good write up of the issue, how the huristics in the bios fail to react fast enough
[11:47] <Tehdastehdas_> In my case the temperature can stay at 90 C for an hour, and the fan won't go faster than 3500 rpm
[11:48] <Tehdastehdas_> It's quiet though, that's nice
[11:51] <Tehdastehdas_> Soo, how about making the kernel throttle instead of overheat, and suspend at 97 C instead of shut down at 100 C?
[11:53] <Tehdastehdas_> by throttling I meant pausing processes to reduce heat production
[11:58] <jpds> Tehdastehdas_: Have you tried installing cpufrequtils and changing the governor of the CPUs?
[11:59] <jpds> (Not suggesting that that would solve the problem)
[12:00] <apw> Tehdastehdas_, really it should not sit at that temp for a long time, ugg, those bios' are broke
[12:00] <apw> anyhow, i'll ask someone to have a peek later when they are on
[12:02] <Tehdastehdas_> yes, the bios is broken, but the kernel has many opportunities to remedy the situation, and it wastes them
[12:07] <Tehdastehdas_> I don't have the skills to trigger cpufrequtils at a certain temperature
[12:07] <Tehdastehdas_> Besides, that's the kernel's job in my opinion
[12:10] <jpds> Tehdastehdas_: It doesn't trigger, it runs the whole time
[12:10] <Tehdastehdas_> so it runs slowly all the time
[12:11] <apw> Tehdastehdas_, the problem is the bios says to the kernel "do not do this i have it in hand", so the kernel goes about its business and later the bios says "OI YOU ITS TOO HOT STOP NOW" so it does
[12:13] <Tehdastehdas_> so the kernel should detect the faulty bios from the temperature/rpm -mismatch, and take control?
[12:14] <apw> i am not sure i can know in advance trivially, and once we get the "alert stop" i am not sure we can take control and switch to suspend
[12:14] <apw> that said i thought that on these broken lenovos there was a lenovo specific fan control thing you could use
[12:14] <apw> which would take it out of auto, switching from bios to userspace control of the fans
[12:17] <Tehdastehdas_> I tried it a couple of years ago, but couldn't make it work, don't remember why
[12:18] <Tehdastehdas_> Surely it is the kernel's decision to shut down (and not suspend), as it logs the decision
[12:19] <apw> Tehdastehdas_, not necessarily, that just means it got told it had to shutdown, that the bios said we are about to explode may mean we have no right to then ask the bios to suspend
[12:20] <Tehdastehdas_> hibernate then, that's not the bios's business?
[12:21] <apw> except that is a multi-second event we may not be give that long, i would think the contract with the bios is "stop, and make it quick else i will turn off under you"
[12:22] <apw> not getting into this situation is better, and likely user control of fans is appropriate give this is patently a broken bios
[12:22] <apw> but, anyhow, we had someone do a lot of work on this in the day, on an x201 iirc which that bug claims, and he ought to have the background on whats what
[12:23] <Tehdastehdas_> many seconds yes, as is shutting down
[12:25] <apw> Tehdastehdas_, so ... i see in the bug you mentioned there is a suggestion to run thinkfan with a specific config, have you tried that at all?
[12:26] <apw> comment #141
[12:26] <Tehdastehdas_> long time ago, didn't work, don't know why
[12:27] <Tehdastehdas_> still, I think it's the kernel's job, because users aren't that skilled
[12:28] <apw> if userspace can fix it, that can be automated such that it is simple for owners of the affected hw in all likleyhood
[12:28] <apw> the kernel is not really the right place to handle such complex heuristics as they differ for each and every broken bios
[12:28] <ogra_> didnt the thermal handling switch to userspace with themald recently ?
[12:28] <apw> and it would have a heap of junk that most people have
[12:28] <apw> ogra_, a point indeed
[12:28] <apw> Tehdastehdas_, what series are you running
[12:28] <ogra_> (at least for intel CPUs)
[12:29] <apw> ogra_, it _is_ possible that that might be able to stave off doom in this case
[12:29] <ogra_> yeah
[12:29] <ogra_> or that thermald didnt get installed by update-manager
[12:29] <Tehdastehdas_> series? is it not in the bug report?
[12:30] <ogra_> (which would be a serious update.manager bug indeed)
[12:31] <Tehdastehdas_> synaptic says thermald is not installed
[12:31] <ogra_> on what release are you ?
[12:31] <Tehdastehdas_> 14.04
[12:31] <apw> Tehdastehdas_, it might be in the bug report, but it would have been easier to tell me than tell me its in the bug report
[12:31] <ogra_> iirc it is required from vivid on
[12:31] <ogra_> ah
[12:32] <apw> ok then the latest is available in vivid, as the linx-lts-vivid backport is there
[12:32] <Tehdastehdas_> but I don't recognize the word "series" in this context
[12:32] <apw> so ... i would suggest you try switching to the lts-vivid hwe kernel which will pull in and use thermald as well
[12:32] <ogra_> right, something in the hwe stack needs to pull it in apparently
[12:32] <apw> sorry my bad, that is what launchpad calls a release
[12:33] <apw> Tehdastehdas_, so like install linux-generic-lts-vivid and and then reboot, and see if things are any better
[12:34] <apw> Tehdastehdas_, and if you do, regardless of whether it works, mention we suggested and your tried it, and what the result was
[12:38] <Tehdastehdas_> got it, rebooting
[12:58] <Tehdastehdas_> apw, installed it and rebooted - still max. 3500 rpm after several minutes at 95 C
[12:59] <Tehdastehdas_> am I supposed to add this information to the bug report?
[12:59] <apw> and cat /proc/version_signature says you have a 3.19 kernel and is thermald running
[12:59] <apw> and yes if you are running the new version and its there, writing that in the bug helps
[13:00] <Tehdastehdas_> it says Ubuntu 3.19.0-26.28~14.04.1-generic 3.19.8-ckt4
[13:00] <apw> ok thats good, so it is the new version
[13:00] <apw> ps -ef | grep thermal
[13:00] <apw> does that say thermald is running
[13:01] <Tehdastehdas_> thermald --no-daemon --dbus-enable
[13:08] <apw> Tehdastehdas_, ok record all that in the bug, and i'll ask someone to have a look when they are in
[13:14] <Tehdastehdas_> commented the bug report accordingly
[13:29] <apw> Tehdastehdas_, thanks
[19:29] <MikeCamel> terrible newb qu: anyone got a good way to add a patched file to a source (dkms) deb file?  file-roller fail...
[19:33] <FrauHase> Hi
[19:33] <MikeCamel> HI
[19:34] <FrauHase> Is there a chance to disable IPv4-support (for a IPv6-only network)?
[19:35] <apw> FrauHase, i'd say i normally just configure without ipv4 addresses
[19:35] <apw> we have a coulpe of people who run ipv6 only networks, and things work modulo the internet not being very accessible v6 only
[19:36] <stgraber> you can totally fix that by having your gateway do DNS64 and NAT64 for you
[19:36] <apw> stgraber, right but you need to be you to have the patience for all that
[19:36] <FrauHase> actually, its for a test environment with no access to internet ...
[19:36] <apw> but it does work pretty well i think i heard you say
[19:36] <stgraber> though then you'll still find a few random software (mostly perl) who don't even know what INET6 are and that will break (sent a dozen or so patches to various upstreams for that)
[19:37] <stgraber> and some things like google hangouts and my chromecast who are broken for different reasons (the first being some weird server-side bug on their end, the latter being because they don't bother to do IPv6 multicast)
[19:38]  * apw watches stgraber take on the ipv6 world single handed :)
[19:41] <FrauHase> guess I'll do as apw suggests ... just hoped for a more safe way to only have IPv6 talking on the net ...


[05:22] -queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (disco-proposed) [1.178.2]
[05:26] -queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (cosmic-proposed) [1.175.6]
[05:28] -queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (bionic-proposed) [1.173.8]
[08:38] <rbalint> rbasak could you please release cosmic's initramfs-tools today? there is a new one in unapproved and i'd also like to piggyback on it with LP: #1814355
[08:40] -queuebot:#ubuntu-release- Unapproved: initramfs-tools (cosmic-proposed/main) [0.131ubuntu15.2 => 0.131ubuntu15.3] (core)
[08:46] <xnox> https://launchpad.net/ubuntu/cosmic/+queue?queue_state=1&queue_text=initramfs-tools
[08:46] <xnox> the one from 6 minutes ago, superseeds the unapproved upload from 11th of june
[09:02] <rbasak> rbalint: I'm out this morning. I'll try and look this afternoon for you.
[09:10] <rbalint> rbasak, thanks!
[10:25] -queuebot:#ubuntu-release- Unapproved: linux-signed-hwe-edge (bionic-proposed/main) [5.0.0-19.20~18.04.1 => 5.0.0-19.20~18.04.1] (kernel) (sync)
[10:31] -queuebot:#ubuntu-release- Unapproved: linux-signed-hwe-edge (bionic-proposed/main) [5.0.0-19.20~18.04.1 => 5.0.0-19.20~18.04.1] (kernel) (sync)
[10:39] -queuebot:#ubuntu-release- Unapproved: rejected linux-signed-hwe-edge [sync] (bionic-proposed) [5.0.0-19.20~18.04.1]
[10:39] -queuebot:#ubuntu-release- Unapproved: accepted linux-signed-hwe-edge [sync] (bionic-proposed) [5.0.0-19.20~18.04.1]
[11:04] -queuebot:#ubuntu-release- Unapproved: linux-signed-hwe-edge (bionic-proposed/main) [5.0.0-19.20~18.04.1 => 5.0.0-19.20~18.04.1] (kernel) (sync)
[11:05] -queuebot:#ubuntu-release- Unapproved: accepted linux-signed-hwe-edge [sync] (bionic-proposed) [5.0.0-19.20~18.04.1]
[11:17] -queuebot:#ubuntu-release- Unapproved: linux-signed-hwe-edge (bionic-security/main) [5.0.0-19.20~18.04.1 => 5.0.0-19.20~18.04.1] (kernel) (sync)
[11:17] -queuebot:#ubuntu-release- Unapproved: linux-signed-hwe-edge (bionic-updates/main) [5.0.0-19.20~18.04.1 => 5.0.0-19.20~18.04.1] (kernel) (sync)
[11:34] -queuebot:#ubuntu-release- Unapproved: accepted linux-signed-hwe-edge [sync] (bionic-security) [5.0.0-19.20~18.04.1]
[11:34] -queuebot:#ubuntu-release- Unapproved: accepted linux-signed-hwe-edge [sync] (bionic-updates) [5.0.0-19.20~18.04.1]
[11:41] -queuebot:#ubuntu-release- Unapproved: linux-signed (disco-security/main) [5.0.0-20.21 => 5.0.0-19.20] (core, kernel) (sync)
[11:41] -queuebot:#ubuntu-release- Unapproved: linux-signed (disco-updates/main) [5.0.0-20.21 => 5.0.0-19.20] (core, kernel) (sync)
[11:45] -queuebot:#ubuntu-release- Unapproved: accepted linux-signed [sync] (disco-security) [5.0.0-19.20]
[11:45] -queuebot:#ubuntu-release- Unapproved: accepted linux-signed [sync] (disco-updates) [5.0.0-19.20]
[11:47] -queuebot:#ubuntu-release- New binary: jsonnet [s390x] (eoan-proposed/universe) [0.13.0+ds-1ubuntu1] (no packageset)
[11:49] -queuebot:#ubuntu-release- New binary: jsonnet [amd64] (eoan-proposed/universe) [0.13.0+ds-1ubuntu1] (no packageset)
[11:49] -queuebot:#ubuntu-release- New binary: jsonnet [ppc64el] (eoan-proposed/universe) [0.13.0+ds-1ubuntu1] (no packageset)
[11:49] -queuebot:#ubuntu-release- New binary: jsonnet [i386] (eoan-proposed/universe) [0.13.0+ds-1ubuntu1] (no packageset)
[11:52] -queuebot:#ubuntu-release- New binary: jsonnet [armhf] (eoan-proposed/universe) [0.13.0+ds-1ubuntu1] (no packageset)
[11:53] -queuebot:#ubuntu-release- New binary: jsonnet [arm64] (eoan-proposed/universe) [0.13.0+ds-1ubuntu1] (no packageset)
[12:57] -queuebot:#ubuntu-release- Unapproved: gnome-control-center (disco-proposed/main) [1:3.32.2-0ubuntu1 => 1:3.32.2-0ubuntu1.1] (ubuntu-desktop)
[13:04] -queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1012.13] (no packageset)
[13:07] -queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1012.13]
[13:09] -queuebot:#ubuntu-release- Unapproved: systemd (xenial-proposed/main) [229-4ubuntu21.21 => 229-4ubuntu21.22] (core)
[13:10] <ddstreet> ubuntu-sru team, please reject my systemd upload in xenial unapproved queue from 1 month ago, i just re-uploaded with an additional patch from rbalint
[13:15] -queuebot:#ubuntu-release- Packageset: Removed gnome-control-center from desktop-core in disco
[13:15] -queuebot:#ubuntu-release- Packageset: Added gnome-control-center to ubuntu-desktop in disco
[13:44] -queuebot:#ubuntu-release- Unapproved: rejected systemd [source] (xenial-proposed) [229-4ubuntu21.22]
[13:44] <apw> ddstreet, ^
[14:07] <ddstreet> apw thanks, hopefully new uplaod won't be in unapproved for a month :)
[14:09] <apw> changing systemd is always mentally challenging
[14:09] <apw> its unreliable enough as it is
[15:35] -queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.39.2 => 2.39.2ubuntu0.1] (desktop-core, ubuntu-server)
[15:47] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.39.2ubuntu0.1]
[16:42] <tsimonq2> [2019-06-26 16:36:21] lb_chroot_hooks
[16:42] <tsimonq2> P: Begin executing hooks...
[16:42] <tsimonq2> ...
[16:42] <tsimonq2> AttributeError: 'Package' object has no attribute 'section'
[16:43] <tsimonq2> Ooh, fun.
[16:43] <tsimonq2> Who broke the archive? :P
[16:57]  * tsimonq2 wonders if this is an apt issue.
[17:21] -queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1045.50] (kernel)
[17:51] <tsimonq2> It doesn't seem like it's an apt issue; reverting to an older version of apt in a PPA and then doing a test livefs build shows the same error.
[17:51] <tsimonq2> (known good version of apt, that is)
[18:18] <tsimonq2> Aha! https://launchpad.net/ubuntu/+source/python-apt/1.9.0 says "- Remove Package.section attributes" which is relevant because "pkg       is the python-apt Package object for this package"
[18:24] <tsimonq2> vorlon, juliank: The latest update to python-apt broke apt-xapian-index by removing the (admittedly legacy) Package.section attribute. This is a problem because it's included by default on Lubuntu images (and probably more), and is causing the ISO build to fail. I see there being two potential solutions here: 1) Fix the apt-xapian-index build in eoan-proposed and fix apt-xapian-index itself
[18:24] <tsimonq2> (either by doing Ubuntu-specific changes or via Debian in the bug I'm about to file); 2) Revert the commit removing those attributes in python-apt for now until 1) is in place.
[18:25] <tsimonq2> 2) is easy for now, but I don't want to touch python-apt without talking to juliank first.
[18:29] <tsimonq2> I'm absolutely exploring why this wasn't caught during p-m.
[18:30] <tsimonq2> That will be another bug I file in Debian, because this should have been caught earlier.
[18:34] <tsimonq2> Oh, it's orphaned. Coooool.
[19:00] <tsimonq2> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931133 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931132
[19:05] <teward> tsimonq2: > orphaned since 1243 days. < yeah probably not going to get fixed heh
[19:06] <tsimonq2> teward: Become a DD and then adopt it. :P
[19:06] <tsimonq2> Or a DM.
[19:06] <teward> tsimonq2: no thanks I don't want it :P
[19:28] <Eickmeyer> Can anybody shed light on why Studio's build failed? https://launchpadlibrarian.net/430720022/buildlog_ubuntu_eoan_amd64_ubuntustudio_BUILDING.txt.gz
[19:28] <Eickmeyer> I don't know if it's related to tsimonq2's apt-xapian-index bug or not.
[19:29] <tsimonq2> Eickmeyer: Yes it is.
[19:29] <Eickmeyer> tsimonq2: kthx. :)
[19:30] <wxl> ah they are similar with
[19:30] <wxl> AttributeError: 'Package' object has no attribute 'section'
[19:34] -queuebot:#ubuntu-release- New binary: linux-signed-gcp-edge [amd64] (bionic-proposed/main) [4.18.0-1015.16~18.04.1] (kernel)
[19:34] <wxl> https://salsa.debian.org/apt-team/python-apt/commit/fedd51be48be53d00d386c45eab8f63f462db202#faf51da27adfc87e2950af44dc159112540aed75_0_10
[19:34] <wxl> * The `section` attribute has been removed from :class:`apt_pkg.Package`
[19:34] <wxl>   and :class:`apt.package.Package`
[19:36] <tsimonq2> Yeah, it's the same bug.
[19:53] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp-edge [amd64] (bionic-proposed) [4.18.0-1015.16~18.04.1]
[19:53] -queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1045.50]
[20:09] <juliank> tsimonq2: We need to fix reverse depends. The python-apt change cannot be reverted, it is following apt's removal of that field
[20:09] <juliank> Eickmeyer: I fixed that yesterday, but livecd-rootfs got stuck in proposed and pyython-apt migrated
[20:09] <tsimonq2> juliank: ack
[20:11] <juliank> If somebody could hint that ubuntu-image failure that's blocking livecd-rootfs, image building will be back on
[20:12] <juliank> I don't have the repo on this machine, and finding it, branching it, and pushing it back seems like it's a lot of work right now :)
[20:14] <Eickmeyer> juliank: ack, but can't do the hint.
[20:14] <juliank> tsimonq2: I filed the other apt 1.9 migration bugs as normal in Debian, not important, as the move to unstable is still way off; I also attach patches to them all :)
[20:15] <juliank> But maybe I missed some
[20:16] <tsimonq2> juliank: ok, feel free to adjust my bug reports :)
[20:17] <juliank> tsimonq2: If you see other such issues and forward them, it'd be nice if you could User<EMAIL_ADDRESS>apt-1.9.0 :)
[20:18] <juliank> tsimonq2: I'll have a look at apt-xapian-index shortly and see if I can add static typing information, that could cover any future API breaks at least - though not sure when to run them yet, gotta work on a solution for automatic python type testing, as there are regressions due to mypy updates and semantic changes all the time :/
[20:18] <tsimonq2> juliank: ack, thanks
[20:19] <juliank> I added the usertag to your bug btw
[20:19] <juliank> tracking list: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=deity@lists.debian.org;tag=apt-1.9.0
[20:21] <tsimonq2> Sweet
[20:21] <juliank> So, like PEP8 tests we don't want to run mypy tests during autopkgtests or build I think, as it can regress due to changes in mypy
[20:22] <juliank> -> example: 0.710 complains if I re-define a variable with the same type, 0.670 does not
[20:22] <juliank> the question is: if we don't want to do this, how can we ensure to catch type failures?
[20:23] <juliank> OTOH, if the tests depend on mypy, a new mypy will only migrate after all tests are fixed, so maybe we are good?
[20:31] <juliank> oh ffs, ubuntu-image fails in different places in different runs
[20:35] <juliank> here's the hint: https://code.launchpad.net/~juliank/britney/hints-ubuntu--livecd-rootfs-2-598/+merge/369363
[20:36] <juliank> skiptested livecd-rootfs upload as the ubuntu-image failure is super weird and i did not want to badtest it
[20:36] <juliank> please merge!
[20:39]  * juliank also retried it a second time and hopes either thing happens before the next image build


[04:18] <N6REJ> would someone mind clearing up a tiny confusion I have with NFS vs Samba.  Do I need both or is simply NFS enough?
[02:25] <rambo3> wake up
[06:03] <Tigerman> Silly question that might be asked in the wrong chan coming up.. Ive used RedHat with kerio mailserver, is there a similar mailserver program for ubuntu?
[06:21] <mralphabet> kerio is redhat specific?
[06:21] <mralphabet> as in, it only works on redhat?
[06:23] <Tigerman> seems so
[06:23] <mralphabet> I'm not sure I believe that
[06:24] <mralphabet> it works on suse
[06:24] <mralphabet> Supported operating systems
[06:24] <mralphabet> Kerio MailServer runs on Windows 2000/XP/2003, server and desktop editions, Red Hat Linux, SUSE Linux and Mac OS X. Kerio Outlook Connector for Microsoft Outlook runs on Windows 2000/XP/2003.
[06:24] <Tigerman> well, some people suggesting alien the kerio rpm, but well
[06:24] <Tigerman> they want money for kerio now as well :p
[06:25] <mralphabet> those are the OS's that kerio supports out of the box, it does not say "will not work on anything other then these"
[06:25] <mralphabet> ahh, so you are looking for a free option
[06:25] <Tigerman> preferrably
[06:25] <Tigerman> i think kerio was free when i used it, actually
[06:26] <mralphabet> so what you really want is a free option to kerio, regardless of what it runs on
[06:26] <mralphabet> because if it runs on one linux os, it will run on the next
[06:26] <Tigerman> well, if i can get the source and compile it on ubuntu..
[06:27] <mralphabet> binary based distrobutions are fine too, you don't *have* to compile anything
[06:27] <Tigerman> id preferr binary based, yeah
[06:28] <Tigerman> i hate starting to edit things and having to install things manually.. im lazy :p
[06:28] <mralphabet> rpm based distrobutions are slightly more difficult, but still not anything to kill yourself over
[06:29] <mralphabet> anyway, I use sendmail
[06:29] <mralphabet> ;)
[06:29] <Tigerman> mm.. lots of people do.. i dont like sendmail
[06:29] <mralphabet> so i don't have a recommendation for you ;(
[06:30] <Tigerman> communigate pro someone just recommended me
[09:40] <AMSmith42> Is there a defacto webmail server?


[10:33] <lotuspsychje> i found an old upstream thunderbird bug about the system handler; https://bugzilla.mozilla.org/show_bug.cgi?id=953953
[10:33] <lotuspsychje> gonna link it to my bug, and also made a new one, as this one is 9y old
[10:36] <lotuspsychje> there, https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1983144
[10:38] <Fallen> lotuspsychje: 9yo bugs are not uncommon in Thunderbird, as long as that one is confirmed and categorized correctly I don't think you need a new one.
[10:39] <lotuspsychje> you think thats possible they still fix that older bug Fallen ?
[10:39] <ravage> just give it another 9y :)
[10:39] <lotuspsychje> loll
[10:40] <Fallen> Yes :) Bugs to fix aren't prioritized by recency of submission. I'm not saying it is on a roadmap right now, but two bugs won't make it more likely that the issue is fixed.
[10:40] <lotuspsychje> i also tested the thunderbird snap (version 102) wich also dont pickup system handler
[10:41] <Fallen> (saying this with my Thunderbird hat on btw, I am in the Thunderbird Council)
[10:41] <lotuspsychje> cant you push some strings there Fallen :p
[10:41] <lotuspsychje> for an old friend hehe
[19:05] <Britt[m]> Hello Everyone 🙂