[00:25] can the d-i partman handle setting block sizes for the lvm? [00:26] hehehe_off: just that php makes programming safe tools almost impossible [06:36] Good morning [06:36] hi lordievader [06:38] Hey cpaelzer, how are you? [07:12] lordievader: I'm good and feel close to EOW [07:12] lordievader: everything ine for you as well today? [07:12] +f [07:12] Doing good here, just found out q35 is a lot faster in qemu :D [07:13] more modern = better most of the time [07:13] True, but newer can also mean less stable. [07:13] lordievader: what was your workload? [07:14] Oh very low, just some benchmarking. Was checking nfs performance. It was doing 14MB/s while direct to disk was around 130MB/s. [07:14] In iperf there was a difference of 10 times the bandwith between two similar vms, one had the old stuff the other one q35 turned out. [07:19] I've seen the same when people change from the old default e1000 net to virtio [07:20] Did not expect that much from q35, but maybe it implied some device changes that triggered your improvement [07:21] I think it is the change pci to pci-e. There is a huge difference between e1000 and virtio. === danpawlik_ is now known as danpawlik [08:00] hehehe_off you said 755. if the user is www-data, apache can modify the file [08:49] on a auto security update of my openvpn package, it seems that the openvpn is not coming up corectly aynmore [08:50] only a manual restart solves it /etc/init.d/openvpn restart === lordievader[m] is now known as lordievader === lordievader is now known as Guest88772 === Guest88772 is now known as lordievader [08:57] This happend on all my machines. is there a bug in upgrading? [08:57] I've skipped the process of setting up an account when installing ubuntu-server, I suppose there's no default password for root, right? [08:58] adac: perhaps. Can you try downgrading to see if it starts working again? If so, please report a security regression with details. [08:58] cbauer: correct [08:59] rbasak, how can I downgrade it to previous version? [08:59] when booting the ubuntu-server livecd, switching tty and trying to chroot to set a password for root of the installed ubuntu-server, but not having much luck even mounting the disk [08:59] the shell there seems _very_ limited [09:01] is it normal that I can't name my account "admin"? [09:01] seems reserved [09:01] adac: click through the versions on https://launchpad.net/ubuntu/+source/openvpn to find the appropriate debs. [09:03] rbasak, ok thanks I'll try [09:05] rbasak, yes that worked. tun interface is there and all is up and running [09:05] shoudl I try upgrading again? [09:06] upgrading also worked [09:06] hmm [09:06] maybe there is a prblem then wit auto security upgdates? [09:06] *updates [09:42] my livecd doesn't appear to be booting in uefi mode, is this normal? [09:43] UEFI is of-course enabled on the machine [09:43] http://imgur.com/l7rmg7L [09:44] writing error but still, there's no efivars mounted [09:45] manually mounting it worked though, so not sure if it actually installed in uefi mode [10:01] adac: hard to say. Thank you for checking. I guess we'll have to see if others report the same problem. [10:12] rbasak, ok. You're welcome [12:14] cbauer: check your bios settings, you may need to enable "UEFI CDROM" instead of "CDROM" in your boot device list [12:15] 'enable'? you mean select? [12:16] cbauer: depends on your bios, but yes. took me some time to find that out when trying to install UEFI via network boot [12:17] installed it now, as /sys/firmware/efi/ exist I presume UEFI setup was successfull [12:18] issue isn't the UEFI at least [12:18] the livecd/ubuntu is just weird to me, that's all, like missing UEFI tools I'm used to on other distros [12:20] for some reason lspci doesn't return [12:21] ^C is ignored as well [12:57] rbasak: adac: we are seeing the same issue now, unattended upgrades updating openvpn and vpn broken after that [12:57] frickler, ok thanks for the info! [12:58] rbasak, ^^ [13:00] frickler, adac: thanks. To confirm, are you both seeing this server side or desktop side? [13:01] And could it be that your openvpn clients aren't reconnecting automatically somehow? [13:01] Or is it something more than that? [13:02] rbasak, they actually do but only after ah manual /etc/init.d/openvpn restart [13:02] *a manual [13:06] rbasak: I tried manually reconnecting, got no response from the server. restarting fixes it for me like for adac. nothing obvious in the logs though [13:09] frickler, ok so we have totally the same issues. And int happened on every single serer of mine [13:09] not only one [13:12] adac: right, four servers here, broken after automatic upgrade. cannot reproduce with manual downgrade/upgrade [13:13] frickler, exactly not reproducable whith manual downgrade/upgrade here as well [13:13] rbasak, ^^ [13:14] mdeslaur: ^ [13:14] I'd like to help but the non-reproducibility of this makes it really difficult :-/ [13:14] frickler, ubuntu 16.04 right? [13:14] rbasak, yes I understand of course [13:17] adac, frickler: could you try downgrading and then upgrading using the unattended-upgrades command? I'm not sure if that suppresses things if it's run recently though. [13:18] And it'd be useful if you could file a bug against openvpn to start tracking this please. Tag it "regression-update". [13:19] I don't see how the unattended-upgrades command would change things, but at least that's closer. [13:20] http://launchpadlibrarian.net/325110671/openvpn_2.3.10-1ubuntu2_2.3.10-1ubuntu2.1.diff.gz is the diff that was applied as the security update. I don't see anything in there that could be causing this, so perhaps it's a latent bug in the packaging rather than something actually introduced by the security update (rather the security upgrade triggered the latent bug). [13:34] rbasak: adac: https://bugs.launchpad.net/ubuntu/+source/openvpn/+bug/1700079 , unattended-upgrades run manually also does not reproduce this [13:34] Launchpad bug 1700079 in openvpn (Ubuntu) "openvpn broken after unattended security upgrade" [Undecided,New] [13:36] frickler, ok thanks for the info [13:39] frickler, out of curiosity, what did all break for with that? For me of course the communication to the (web) services that are behind the the VPN and can only be access trough the VPN. Second my logging was interrupted, sending everything to to a log server [13:40] trough VPN [13:40] Im also thinking about turning of auto security updates. Maybe have a monitoring when there are security updates and then run them manually [13:41] trough ansible or so [14:01] rbasak: hi, question about the git workflow [14:01] Sure [14:01] rbasak: following Deconstruct current Ubuntu delta into logical commits. [14:01] rbasak: let's see if I can point you precise where I am at [14:02] rbasak: I did the big step "2. Deconstruct current Ubuntu delta into logical commits." [14:02] my question is about, at the very end, [14:02] "Interactively rebase the deconstructed Ubuntu delta and drop 'changelog' and 'update-metadata' changes, by simply dropping those lines from the rebase todo file." [14:02] what I have now, is each change in a single commit, as we wanted [14:02] and an out-of-date debian/changelog, because of those drops [14:03] and also out-of-date d/control (no maintainer change, it's still debian) [14:03] That's expected for logical [14:03] the next big step is [14:03] We're reducing it to git commits only - no changelog changes, only commit messages. And no update-maintainer. [14:03] 3. Rebase delta onto latest Debian release. [14:03] but let's say there was no new debian release [14:04] this was just to bring the repo up-to-date with what was uploaded manually, without the git workflow [14:04] then we would have to reconstruct the changelog here, right? [14:04] and d/control [14:04] Yes, though I'm a little confused as to why you need that. [14:05] I don't think I do, I was just verifying each step [14:05] But yes, it should be fine to add a commit with the full changelog change, and another commit for the full update-maintainer change. [14:05] and understanding where I was [14:05] Then you should have an identical tree to the non-git upload. [14:05] right [14:05] rbasak: ok, the other question I have, [14:05] But I'm not sure what you'd do with that tree/commit when you have it. We don't really have a process/use case for that. [14:06] rbasak: when picking each change from debian/changelog, and figuring out the commit that does that, [14:06] rbasak: this delta is old [14:06] rbasak: the d/changelog usually lists something like "Remaining changes" and then a list [14:06] You could certainly tag logical (without doing the changelog and update-maintainer commits) and leave that for future merges. [14:07] rbasak: my question is, this section doesn't have the original bug numbers anymore for each one of those old delta changes [14:07] do we care? [14:07] rbasak: http://pastebin.ubuntu.com/24932986/ is what I deconstructed into individual commits [14:08] my git log --oneline: http://pastebin.ubuntu.com/24932993/ [14:16] I usually drop the bug numbers, so that matches what I would do. I do this because leaving a full LP references leaves a Launchpad-Bugs-Closed against that version, which would technically be wrong. And the bug numbers can be found in previous changelog entries if needed anyway. [14:17] ahasenack: on the next merge, feel free to refactor the changelog entry. But you can't change it until then of course. [14:17] s/the changelog entry/the remaining changes section/ [14:18] ok [15:03] what does this [linux-any] mean in d/control? [15:03] libaio-dev [linux-any], [15:04] in a Build-Depends line [15:08] ahasenack: it is an architecture wildcard if I recall. [15:09] kernel-cpu is the format, so you could say any-i386 for only i386, or in your case only linux kernels and any cpu === danpawlik is now known as danpawlik_ [15:17] ahasenack: https://www.debian.org/doc/debian-policy/ch-relationships.html#s-depsyntax === Epx998_ is now known as Epx998 [17:00] 2 [17:17] nacc: when you have a moment, we can talk about the samba merge [17:22] Hi all. Could I get some assistance setting up a test OpenStack deployment using Ubuntu Autopilot? I seem to be running into an issue. [17:22] ahasenack: give me a few minutes to context switch out of my current stuff [17:22] nacc: yep [17:41] ahasenack: want to use a HO? [17:43] nacc: yes please [17:43] nacc: let's use the standup one [17:43] ahasenack: ok [18:08] *beeps* [18:09] finally got IPv6 1:1 NAT working... which is... odd... [18:16] ipv6 nat? [18:17] ahasenack: LXD containers and on-link IPv6 only [18:17] ahasenack: the only 'nat' that exists was the snat/dnat >.> [18:32] nacc: is there a way to insert those empty commits now after all this? Pick one commit in the middle of the rebase somewhere to edit, commit, and rebase --continue? [18:33] I don't mind starting over, btw [18:34] ahasenack: right, so the easiest way is to edit just before you want to insert [18:34] ok [18:34] ahasenack: in the rebase -i editor [18:34] ahasenack: that will drop you to the shell just after commiting the entry you edited [18:35] ahasenack: so then you can freely do a `git commit --allow-empty -m 'message...' [18:35] great [18:35] thx [18:35] ahasenack: what's fun is you can actually do that directly in the rebase -i editor [18:35] with [18:35] x git commit --allow-empty -m 'message..' [18:35] but I have no commit hash there [18:35] ah, x [18:35] ahasenack: advanced usage :) [18:35] I'll get there someday :) [18:36] hm, that krb patch isn't upstream yet [18:37] I definitely miss a dep3 header [18:37] * ahasenack puts on the Indiana Jones hat [18:38] heh, found it [18:38] https://bugzilla.samba.org/show_bug.cgi?id=10490 [18:38] bugzilla.samba.org bug 10490 in Winbind "pam_winbind fails with kerberos method = secrets and keytab" [Normal,New] [18:38] from 2014 [18:38] ahasenack: :) [18:39] ahasenack: i especially like that last comment from last april [18:39] still scrolling down [18:40] heh [18:42] debian bug is not mentioned in d/changelog or git log [18:42] * ahasenack keeps digging [18:42] found [18:42] https://launchpad.net/bugs/1310919 [18:42] Launchpad bug 1310919 in samba "pam_winbind krb5_ccache_type=FILE stopped working after 14.04 upgrade" [Medium,Confirmed] [18:44] is 17.04 in beta or? [18:44] Epx998: 17.04 ... came out in april 2017 [18:44] Epx998: as per the name [18:44] ah word [18:44] is not listed as LTS which is why i asked [18:44] Epx998: it's not an LTS. [18:45] Epx998: even year'd april releases are currently LTS [18:46] someone usually updates this page when releases are released or retired https://wiki.ubuntu.com/Releases [18:46] thanks - saved the link [18:47] hmm maybe i should do 16.04.2 [18:48] do you need the newer kernel? [18:48] oh wait you've got crazy hardware issues. you might benefit frmo the newer kernel. :) [18:49] no, I am just tinkering with my linux desktop, drive is failing - so giving something new a go [19:28] Hi all. I have a 14.04 server with md raid. one drive failed miserably and won't spin up. I have replaced the drive and added the new partitions to the arrays, but it adds them as spares and won't promote them to an active drive. [19:29] is there a way to force the spare to be used? === wwalker_ is now known as wwalker [19:30] I see a lot of threads online regarding this, but no solutions. [19:33] fullstop: how did you remove old and add new drive to the array? what mdadm commands did you use? [19:34] I couldn't remove the old one since it was no longer in the device table -- it won't spin up. [19:35] so I added a new one with mdadm --manage /dev/md0 --add /dev/sdb3 [19:35] and it resynced [19:35] but now it shows a degraded array with one drive and one spare. [19:35] pastebin it? [19:37] https://pastebin.com/raw/zRFtJAnZ [19:37] I have all of the data backed up, so rebuilding everything isn't the end of the world [19:37] but it would have been nice to pop a new drive in and rebuild. [19:38] fullstop: can you pastebin /proc/mdstat ? [19:41] https://pastebin.com/raw/czawGj7f [19:42] I won't know if the larger volume will work or not for a few hours. [19:45] I think that I'll wait for the resync to finish and start fresh with two new drives. [19:46] nacc: hi, one more question [19:47] nacc: let me divide up this work in two phases: a) rebase old/debian; b) rebase new/debian [19:47] in (a) I split all the changes into individual commits and so on [19:47] I just found a keysense error in the log, fallentree, and I suspect that the "good" drive isn't so good. [19:48] in (b), I apply that to the new debian package, resolving conflicts, dropping patches that are upstream already, etc [19:48] nacc: good so far? [19:48] nacc: oh, hm. Now that I explained it like that, I don't think I have a question anymore :) [19:48] fullstop: yeah. --add should've added and activated the drive. see what happens when the sync is done, my guess is it'll promote the drive to active and move to UU status [19:48] nacc: but I can humor you with what it was [19:49] fullstop: well, it's been a few years since I used mdadm last. nowadays it's all ZFS for me [19:49] yes, we've switched to zfs for new stuff as well. [19:50] it took me a few minutes to remember how to do the mdadm stuff. [19:51] fullstop: this cheatsheet always helped me back then http://www.ducea.com/2009/03/08/mdadm-cheat-sheet/ [19:52] I have a feeling that it works better if you still have the target disk in place and are able to remove it. [19:56] perhaps, yeah [19:57] fallentree: that's handy, thanks [19:57] I had to replace a drive maybe two or three times and each time they were still visible to the OS so I'd fail it and remove manually, before replacing [19:57] sarnold: yw [19:58] fallentree: I haven't tried the root on zfs yet but mdadm is so much less fun I really don't know how to drive the root on mdadm that I've got :) [20:00] sarnold: grub recognizes it automatically, and you could even reboot into rescue mode / installer USB, recreate partial array (1 disk mirror, with the other "missing" (valid value to mdadm)), rsync files, rinse and repeat on the old drive, sync them up, chroot, update-grub, win [20:01] did that a few times. in production. over ssh. :) [20:01] no need to separate out /boot, if it's simple RAID1 mirror, for any other level you need separate /boot [20:02] I'm spinning up an OpenStack cloud using Ubuntu Autopilot. I'm setting up MAAS. When I commission machines, should I check "Allow SSH access and prevent machine from powering off"? [20:02] I'd think I'd want to be able to SSH into it, but I don't know why that's linked with "prevent powering off". [20:03] fallentree: ohhhhh my. you mean I can probably live migrate to zfs on root? :) [20:04] Or, if that checkbox is unchecked, can I still log in as ubuntu using the SSH key I put into MAAS? [20:04] darinavbt: if you don't have sccess in here you can also try in #maas [20:04] sarnold: no, you said mdadm, you and yeah you could live migrate to mdadm RAID 1. As for ZFS, thing is you can't create partial mirrors, so live migration is off [20:04] Thanks! [20:05] fallentree: you can add a new drive to a mirror vdev any time you want :) [20:05] sarnold: yeah but it doesn't auto-rebalance like btrfs [20:05] you'd still have to (re)copy data [20:06] unless that changed recently [20:06] fallentree: that's adding a new vdev entirely; you can add more disks to a mirror vdev, or turn a single disk vdev into a mirror vdev, any time you want [20:07] sarnold: I see. in which case it would be possible to live migrate to ZFS root yeah [20:07] "live"... you would need a short period of downtime when you assemble the chroot with root mounted from the zpool so grub and initramfs pick it up [20:07] fallentree: the mdadm steps seem more complicated than I expected; I'm surprised about the rsync.. are those instructions for going frmo nothing to mdadm root? [20:09] sarnold: yeah, I had single drive, plain ext4 partitions, added another, partitioned, created partial mdadm devices (with "missing" in place of original disk), copied data and then from rescue mode assembled the full array and set up grub/initramfs [20:10] ahasenack: sorry, was afk -- i'm here now [20:10] of course ran one final rsync from rescue mode before cleaning up old single drive and adding to the mirror [20:11] nacc: np === rory is now known as guest [20:12] nacc: I found out that one of the patches that still applies is wrong now with this new upstream version, and for a moment wondered in which "phase" it should be dropped: (a) or (b). It's (b), of course, since that's when our changes are being applied on top of the new debian version [20:13] fallentree: that's so cool. :D [20:14] yeah it was pat-on-the-back-worthy once done :) of course, that was after numerous test attemps with VMs and lotsa failures :) [20:15] haha [20:16] yeah I can imagine [20:35] anyone experience with pxe / tftp testing? [20:35] I am setting up a clonedeploy server and I am having issues with TFTP [20:36] I would like to test if my TFTP server on Ubuntu is properply working, but I don't know how too. My router seems to properply handle PXE, based on Wireshark packets, and the server IP [20:36] but not sure on the tftp server on the pxe/tftp server. [20:39] nacc: I'm getting a traceback now when I run merge finish: http://pastebin.ubuntu.com/24935370/ [20:39] could it be related to the fact I'm no more in detached head state, since I created that branch to push do LP? === CodeMouse92 is now known as CodeMouse92__ [20:47] SupaYoshi_: can you tftp to the server? :) [20:54] ahasenack: hrm, it *shouldn't* matter [20:54] ahasenack: you ran `git ubuntu merge start` with the same args? [20:55] close, I ran with -f [20:55] git ubuntu merge start ubuntu/devel -f [20:55] ahasenack: ok, that should be ok still for finish (the -f is mosty for the tag overwriting0 [20:55] yeah [20:56] ahasenack: bah, it's my recent change -- one sec [20:56] :) [21:01] ahasenack: can you push your branch somewhere? i'll see if i can reproduce it locally [21:01] ahasenack: also i think this will fix it: http://paste.ubuntu.com/24935500/ [21:02] nacc: pushed, it's that samba-merge-4.6.5 one from here: https://code.launchpad.net/~ahasenack/ubuntu/+source/samba/+git/samba/+ref/samba-merge-4.6.5 [21:03] nacc: too bad it's a snap and I can't patch it on-the-fly :) [21:03] r/o filesystem [21:04] ahasenack: ok, reproduced [21:07] ahasenack: and fixing [21:13] ahasenack: pushing, it should refresh in a few minutes [21:13] ok [21:13] thx [21:20] ahasenack: should be available now [21:20] refreshing [21:20] got r65 [21:20] ahasenack: yeah that should have the fix [21:21] $ git ubuntu merge finish ubuntu/devel [21:21] 06/23/2017 18:20:44 - INFO:Using git repository at /home/andreas/git/merges/samba [21:21] no crash [21:21] and I have a new changelog [21:21] I think [21:21] ahasenack: cool :) [21:22] some chunks are repeated from previous changelog entries [21:22] ahasenack: can you show me in a paste? [21:22] it added the changelog from 4.5.8+dfsg-2ubuntu2 [21:22] yep [21:22] chrome doesn't like big pastes to pastebin :/ [21:23] ahasenack: to be clear, the tooling doesn't actually look in d/changelog. What it did was use the git commits you ahve in your branch [21:23] which include the entries (correctly) from 4.5.8+dfsg-2ubuntu2, afaict [21:23] nacc: http://paste.ubuntu.com/24935632/ [21:24] ahasenack: right, so lines 28-30, e.g., come from 03d512aff0e477b9d2094ac128f1f4b349631231 [21:24] yes [21:24] ahasenack: it's looking at every git commit since 'debian/sid' and extracting each message into debian/changelog (basically running `git reconstruct-changelog debian/sid`) [21:25] ahasenack: which is correct? I mean it's doing what you told it to do [21:25] ahasenack: you need to push those commit messages in (indentation wise) [21:25] ahasenack: as they are now carried forward delta [21:25] I thought I had [21:25] no, wait [21:25] ahasenack: at least in my view of your repo, you haven't yet [21:25] the dep8 one, for example [21:25] that I didn't indent [21:26] because it wasn't old delta [21:26] but I think I see your point [21:26] it *is* old delta now [21:26] it's about being a delta [21:26] yeah [21:26] yep [21:26] I purposedly skipped those [21:26] ok [21:26] so it's correct to list all that again, because it's delta from now on [21:26] correct [21:26] ok [21:26] and you want to nest it under "remaining chagnes" [21:26] because it is remaining changes that were previously reviewed/uploaded [21:27] right [21:27] ahasenack: you can also see the difference between the old changelog and this one, we drop LP: to LP automatically [21:27] how do I do this again? I tagged before running merge finish [21:27] ahasenack: git checkout [21:27] ahasenack: git rebase -i new/debian [21:27] ahasenack: 'r' the ones you want to chagne the commit message for [21:27] that's ok [21:28] ahasenack: and then run 'finish' command again [21:31] ahasenack: does that make sense? [21:31] nacc: http://pastebin.ubuntu.com/24935676/ [21:32] nacc: what about * d/p/krb_zero_cursor.patch: add DEP3 header [21:32] ahasenack: i think lines 35-39 are part of the old delta too? [21:32] it's a delta, but a change I made while doing the merge [21:32] and when we remove a patch, is that delta? [21:33] ahasenack: i would keep that dep3 change at the top-level, because it's 'new' delta relative to what was uploaded prior [21:33] removing the patch removed the delta [21:33] ahasenack: let me look in the branch [21:33] I have to push again, after the commit messages changes [21:33] but the content is untouched [21:34] ahasenack: that's fine [21:34] ahasenack: ok, so i think this is a case of delta being added and dropped prior [21:34] ahasenack: so it shouldn't even be in the new changelog [21:35] which one? [21:35] ahasenack: e.g., 88c04472396882cc60ea81a57ca6902e20cb77cb and e341bb56cbd3d28907e40b4eeb0ec3e550bfe888 negate each other [21:35] that guy was added and dropped several times [21:35] ahasenack: or i guess not dropped, but clarified [21:35] ahasenack: as you didn't undo the debian/rules change (afaict)? [21:36] oh, I might have forgotten that bit [21:36] yep, need to remove it [21:36] ahasenack: do you want to do another HO? might be easier to clarify this case [21:36] and have to check artful [21:36] hi my tftp gives a timeout [21:37] let's forget fix-1584485.patch for a moment [21:37] I did indeed forget about the debian/rules associated change for that one [21:38] nacc: what about "refresh patches", "add DEP3" and "Remove d/p/winbind_trusted_domains.patch" [21:38] last one is me removing a delta [21:38] ahasenack: i think refresh patches can be nested, as you're not contentfully changing the delta [21:38] ahasenack: even the d/p/krb_zero_cursor.patch change, could be nested under the commit corresponding to line 7 [21:39] ahasenack: as just a [..] comment [21:39] http://prntscr.com/fng069 my tftp server times out [21:39] ahasenack: if you're explicitly dropping delta, it should be in a * Drop: section with a reasoning [21:40] ok, will do [21:41] ahasenack: and in git, it should end up being an empty commit (as it can't have any content relative to Debian, as the delta didn't exist in Debian) [21:41] hm [21:42] I think that goes back to my reasoning before about (a) and (b) phases [21:42] the patch can only be dropped when applied to the new samba version [21:42] so (b) [21:42] I don't understand how that would be an empty commit [21:42] ahasenack: sure, a commit can *become* empty [21:42] ahasenack: ok, so you have some commit X in old/ubuntu [21:43] ahasenack: it added some functionality relative to old/debian [21:43] ahasenack: that change is no longer needed in new/debian [21:43] which channel on freenode is for discussing girls? [21:43] nacc: hold a bit [21:43] nacc: "so you have some commit X in old/ubuntu" [21:43] not really: I have a huge change, not individual commits yet [21:43] its kinda amusing with so many guys here girls are not a topic [21:43] ahasenack: well, that should be logical [21:44] hehehe_off: please stop. [21:44] nacc why [21:44] hehehe_off: you can read the topic, you know you're being offtopic. [21:44] I like girls [21:44] I asked where is such channel [21:44] hehehe_off: and that is a ubuntu server discussion, how? [21:44] !alis | hehehe_off [21:44] hehehe_off: Alis is an IRC service to help you find channels. For help on using it, see "/msg Alis help list" or ask in #freenode. Example usage: "/msg Alis list http" [21:44] I did not find any using alis [21:44] :) [21:45] hehehe_off: i don't care. [21:45] maybe there are none [21:45] nacc then why talk to me? [21:45] so u do care :D [21:45] anyhow I am off :) [21:45] hehehe_off: because you're leading to noise when i'm trying to actually get something done. [21:45] you wont use /ignore why? [21:46] :))) [21:46] if 1 question about girls provokes u so much [21:46] hehehe_off: it's not cute or funny. you are being intentionally disrespectful of a channel's rules. [21:46] :) [21:46] nacc: ur just feeding trolls. notify the ops and don't waste your time ;) [21:46] fallentree: true [21:47] and coding requires libido :) [21:47] including ubuntu server [21:51] i open #ubuntu-server after hours of doing other stuff and i see hehehe_off saying that coding requires libido. well... sorry for evasdropping on this discussion :D [21:52] :) [21:52] hi gheorghe_ [22:02] is there any weird different for dns from 14 to 16? [22:03]