IRC chat logs for #ltsp on irc.freenode.net (webchat)


Channel log from 30 January 2020   (all times are UTC)

00:21Ark74 has joined IRC (Ark74!~Luis@177.238.145.140)
04:00
<alkisg>
!forget ltsp-initrd
04:00
<ltspbot>
The operation succeeded.
04:01
<alkisg>
!learn ltsp-initrd as Create the ltsp.img initrd add-on: https://ltsp.org/man/ltsp-initrd/
04:01
<ltspbot>
The operation succeeded.
04:01
<vagrantc>
heh :)
04:03
alkisg: i didn't test some of the newly fixed issues, but it didn't break anything for me as of 8aa2e8de8029d2db722254616f740620ca343c2b Restore live CD netbooting (#43)
04:03
<alkisg>
Great
04:03
If you want, go ahead and release it; or wait for me to fix that partprobe thing today
04:04
<vagrantc>
if you fix it today, i may as well wait till tomorrow to upload ... should have enough time
04:04
<alkisg>
Let's try to make it 20.01 instead of 20.02 though, in case we find something grave and need an 20.02 release :)
04:05
I will fix it today
04:06
<vagrantc>
still will fit the version scheme :)
04:07
ah, i did notice cups failing to load ina way that there might be some more elegant way to fix ... i presume it's disabled in ltsp somehow?
04:07
it spits out obnoxious failures at boot
04:07
<alkisg>
Yes, to save RAM, as by default it's not used
04:08
It didn't for me... what were the failure messages?
04:09
I think that by default I just use `systemctl mask`, the same as MASK_SYSTEM_SERVICES...
04:10* vagrantc boots a client to try and find what it says
04:12
<vagrantc>
Failed to start CUPS Scheduler ... and ... Failed to start CUPS Socket
04:12
<alkisg>
Ah, then we probably just need to mask those too
04:14
<vagrantc>
seems to be cups.path and cups.socket
04:14
but they're not .service files ... does MASK_SYSTEM_SERVICES work with that?
04:15
<alkisg>
If you do the change, please also lower "re systemctl mask" to "rw systemctl mask"; I updated MASK_SYSTEM_SERVICES yesterday to "rw" but forgot to update cups...
04:15
Yes, it should work fine
04:15
client/init/55-various.sh
04:17
<vagrantc>
yup, adding cups.path and cups.socket to MASK_SYSTEM_SERVICES made the noise go away
04:18
in config_cups_server ?
04:22
<alkisg>
Yes, only when it's needed to disable cups
04:22
There's a logic there where if CUPS_SERVER is localhost, cups shouldn't be disabled etc
04:23
vagrantc: but also note that something else might be triggering cups.path etc in your setup, and disabling that something else instead might make more sense
04:23* vagrantc shrugs
04:23* alkisg boots a buster vm to check...
04:23
<vagrantc>
this is on bullseye, so maybe doesn't even exist in buster
04:24
they both claim to be PartOf=cups.service
04:25
<alkisg>
Do you see a red line on boot? Or does it show up on systemctl --status?
04:26
<vagrantc>
alkisg: red line on boot ... "systemctl status" didn't show a problem ... systemctl status cups.path or cups.socket showed an issue
04:26
<alkisg>
systemctl status cups.path => not found
04:26
I don't have a bullseye vm though
04:27
<vagrantc>
do i need to run "ltsp initrd" every time i change lts.conf ?
04:27
hah!
04:27
ltsp.conf
04:27
<alkisg>
Yeah
04:27
<vagrantc>
ok
04:28
<alkisg>
It's possible to fetch and apply ltsp.conf via nfs, but I haven't enabled it by default yet
04:28
<vagrantc>
could also write a hook that re-runs it whenever ltsp.conf is modified
04:28
iwatch or whatever
04:29
<alkisg>
`ltsp initrd` also sends all of /etc/ltsp and /usr/share/ltsp
04:29
So it will need some extra care if we use inotify etc to automate it
04:30
I guess that part might be implemented as an http service instead
04:30
wget server:ltsp.conf => also updates ltsp.img if needed on the server
04:31
<vagrantc>
it's so nice that login on the console works now!
04:32
<alkisg>
We should do a gsoc about implementing passwd changing with PAM too
04:32
I wonder if that can be done with pam_exec, or if .c will be needed
04:33* alkisg tests with debian-live-testing-i386-mate.iso
04:33
<alkisg>
(booting .isos is cool too; otherwise it wouldn't be easy for me to test bullseye :))
04:34
<vagrantc>
yeah, that's amazing :)
04:35
so far, i've tested sddm and lightdm and gdm3 ... although gdm3 is absurdly slow but works ... and lxdm doesn't work at all
04:36
well, lxdm comes up, but it doesn't successfully auth
04:36
<alkisg>
LXDE has moved to lightdm a couple of years ago, right?
04:36
So I didn't write code to handle lxdm.conf at all
04:36
<vagrantc>
could be
04:37
<alkisg>
gdm3 is using wayland, and even when it fails and falls back to xorg, it takes a long time on VMs
04:37
<vagrantc>
i figured the pam stuff should work, but apparently you need additional code?
04:37
<alkisg>
It's a bit faster on real hardware
04:37
No, it should work, sorry I was talking about handling autologins etc
04:37
But DMs do have bugs, some don't work with ldap etc
04:37
Not all of them use pam properly
04:38
E.g. ubuntu unity 16.04 failed to unlock with the new ltsp. I googled it,and it had the same issue with ldap
04:38
Yet ubuntu mate 16.04 etc work fine, it was a unity bug
04:38
<vagrantc>
heh
04:39
that said, supporting lightdm, sddm and gdm3 sounds to cover the most important ones ...
04:39
<alkisg>
debian-live-testing-i386-mate.iso doesn't have cups.service nor cups.path...
04:40
focal does have cups.path, but it doesn't show up in red, just "dead inactive"
04:41
Sorry it does at boot, but not at systemctl status
04:41
<vagrantc>
sysemctl --list-units, maybe
04:41
<alkisg>
So I can reproduce locally
04:41
<vagrantc>
yay
04:41
seems fairly minor
04:41
i've built a patched ltsp that also tries to disable those two ... but i guess it might go badly if those files aren't present
04:42
or, it will shift from one warning to another :)
04:42
<alkisg>
mask isn't intrusive, it should show a "service not foudn but proceeding anyway", and just make a symlink to /dev/null
04:42
But not in red :)
04:43
gdm3 is a pain with epoptes, they refused to allow broadcasting over it as a valid use case, and it pops up one vt for itself and one for the user, so it's confusing
04:43
<vagrantc>
ok, great
04:43
<alkisg>
For now, I'll be recommending gnome users to use lightdm instead
04:45
<vagrantc>
sounds reasonable
04:48gdi2k has left IRC (gdi2k!~gdi2k@host86-185-148-176.range86-185.btcentralplus.com, Quit: Leaving)
04:49
<alkisg>
vagrantc: as far as I can see, yeah disabling cups.path and cups.socket when cups.service is disabled, is fine and won't cause other issues
04:50
I even have those in 18.04, they just didn't show up in red for some reason
04:50
If you want commit it and I'll test that too today along with partprobe
04:50
Or if you don't have time, I can do that too
04:52
<vagrantc>
already have the patches locally, so will push :)
04:52
<alkisg>
Great
04:52
<vagrantc>
seemed to work for me
04:53
alkisg: any objection to moving /usr/sbin/ltsp to /usr/bin/ltsp ?
04:53
<alkisg>
vagrantc: don't we put administrative programs in sbin?
04:53
<vagrantc>
but ltsp info is useful without administrative privledges
04:54
<alkisg>
Just for now :)
04:54
It should use ltsp mount in the future to get info from inside the images
04:54
<vagrantc>
sure, but you could use archivemount for that :)
04:54
<alkisg>
Or to access ltsp.conf
04:55
(which is not readable by users in the recommended setup)
04:55
We'd have to rewrite the ltsp code to use archivemount then, instead of reusing the existing mount code
04:55
<vagrantc>
ah, i see
04:55
if it's really going to soon require root, i guess it's fine
04:55
<alkisg>
The existing mount code runs under busybox too
04:56
<vagrantc>
makes it harder to run ltsp --help but no big deal
04:56
<alkisg>
But don't administrative programs belong in sbin anyway? All those do support --help
04:56
Is there any recommendation about moving things to bin that I'm not aware of?
04:57
<vagrantc>
it's seemed to be a trend, but i'm not aware of any specific recommendations
04:58* alkisg wouldn't even mind if sbin went away completely :)
04:58
<vagrantc>
i think that might happen
04:58
soemday
04:58
<alkisg>
There are so many programs in bin that aren't useful without root rights or pkexec authorization anyway
04:59
vagrantc: so if you think that bin is more appropriate, I have no objections at all
04:59
Maybe we'll need to update the section of man pages, maybe not
05:01
<vagrantc>
the thought came to me when i booted a vm that i *thought* had ltsp installed but then i ran "ltsp info" only to get command not found ...
05:01
<alkisg>
Ah vagrantc one thing only... we're using things like `modprobe`; if ltsp isn't in sbin, and sbin isn't in path, those won't work
05:01
<vagrantc>
true enough
05:03
alkisg: it's a pleasure to be working on ltsp again ... even if i still don't personally have a real-world use at the moment :)
05:03
<alkisg>
It's a fun little beast; challenging but rewarding
05:04
OK off to work; will start coding in an hour
05:04
<vagrantc>
the latest stuff seems so much easier to debug and work with and tweak :)
05:05
still don't know where everything is off the top of my head, but that might come with time :)
05:05
<alkisg>
It was horrible when `ltsp-update-image` was needed to test a one-line changr
05:05
<vagrantc>
yes!
05:05
the LTSP_INIT_* tweaks are astoundingly flexible
05:06
er ... POST_INIT_*
05:06
<alkisg>
Yeah, PRE_* too
05:06
E.g. PRE_INITRD_BOTTOM => gets a shell inside the initramfs
05:46
What would be the "mid" directive? IN_*? E.g. IN_KERNEL_DEBUG_SHELL=debug_shell, to get a shell at the time when the image is mounted, not after the work is done...
05:47
(for the future of course, not now...)
05:48kjackal has joined IRC (kjackal!~quassel@2a02:587:3115:3000:e5a1:8ff8:992d:2899)
06:01statler has joined IRC (statler!~Georg@p5B30E4C3.dip0.t-ipconnect.de)
06:15
<alkisg>
!learn unmkinitramfs as unmkinitramfs extracts an initrd, but it doesn't always work, so: kvm -m 512 -kernel /srv/ltsp/focal/boot/vmlinuz -initrd /srv/ltsp/focal/boot/initrd.img -append "break=top"
06:15
<ltspbot>
The operation succeeded.
06:16
<vagrantc>
can't you just zcat | cpio -i ?
06:16
<alkisg>
Nah, those were the good old days
06:16
<vagrantc>
hah
06:16
well, there are other compression types, sure
06:16
<alkisg>
Now they put the microcode in front and it doesn't work anymore
06:17
Hence unmkinitramfs,
06:17* vagrantc sighs
06:17
<alkisg>
But then Ubuntu does something more weird and breaks concatenated initrd traversal, hence... kvm
06:18
<vagrantc>
eesh
06:18
<alkisg>
I should file a bug for unmkinitramfs in ubuntu, but ... no... time... for all those bugs :D
06:19
<vagrantc>
i tried making an x86_32 chroot ... and it failed until i figured out i needed to get the overlay module added
06:19
and the easiest way to do that was to add the ltsp package
06:19
<alkisg>
Hehe
06:20
O
06:20
<vagrantc>
but mmdebstrap works really nicely to make a chroot ... much faster than debootstrap
06:20
<alkisg>
I'll rewrite the systemctl mask cups in a single line, no need to do 3 invocations there
06:21* alkisg would love to see cross-distro chroot creation tools
06:21
<vagrantc>
it can even make a squashfs image ... can ltsp image read in a squashfs?
06:21
<alkisg>
Sure
06:21
It can even read a squashfs from inside a partitioned image
06:22
mmdebstrap available since buster, not bad for recommending it in https://github.com/ltsp/community/wiki/chroots
06:24
Heh, it even has a chrootless mode; I guess that's a word then :P
06:24
(when we changed ltsp-pnp to chrootless ltsp)
06:25
I wonder if it can create an armhf chroot that way
06:26kjackal has left IRC (kjackal!~quassel@2a02:587:3115:3000:e5a1:8ff8:992d:2899, Ping timeout: 272 seconds)
06:28
<vagrantc>
anything well supported by qemu-user-static should work fine
06:32
<alkisg>
It says chrootless, I imagine it doesn't even use the chroot command at all
06:33
So no qemu either
06:33
So it should work even in architectures that qemu doesn't support, or even to create a x86 chroot while the server is armhf, etc etc
06:41
<vagrantc>
so, most of those modes are quirky
06:41
i've only had any luck with sudo/root and unshare modes
06:43
it would be interesting to try it, though :)
06:44
<alkisg>
There's a trend in fedora to avoid postinst in favor of declarative things
06:44
E.g. to drop a file with the group you want, instead of calling adduser
06:44
That would be awesome, if packages were able to get installed without running any code at postinst
06:44
<vagrantc>
yeah, i've started seeing that in debian too
06:45
<alkisg>
Then we could manage chroots without the chroot command, with just an apt --root=there switch
06:45
<vagrantc>
yes, debian's maintainer scripts are a big strike against debian (and derivatives)
06:45
that's basically what mmdebstrap's chrootless attempts to do...
06:47
<alkisg>
OK I'll assume that `losetup -P` is everywhere available *except* for Ubuntu's initramfs'es
06:47
It's provided by the mount package, and it's there in debian initramfs'es
06:48
(about the partprobe thing)
06:48
So it's even there on a `deboostrap`'ed chroot with no other packages
07:02
This is the diff for partprobe, testing it: https://termbin.com/jkir
07:02
I.e. we try to pass as much of "-rP" as we can to losetup
07:03
And we expect it to work in all cases, even on initramfs/klibc which doesn't support either of them
07:04
<vagrantc>
so ... with mmdebstrap and squashfs-tools-ng ... managed to create a bootable ltsp image:
07:04
sudo mmdebstrap --aptopt='Acquire::http::Proxy "http://192.168.122.1:8000";' --aptopt='Apt::Install-Recommends "true"' --aptopt='Acquire::Languages "none"' --include=ltsp,linux-image-686,systemd-sysv,lxde --arch=i386 bullseye /srv/ltsp/x86_32.squashfs http://deb.debian.org/debian
07:05
the proxy is obviously optional
07:05
<alkisg>
Yey! Wiki time! :)
07:05
<vagrantc>
and the acquire::languages is optional as well ... but it skips downloading some needless cruft
07:05
though package searches won't have full descriptions from apt
07:06
oh, then i had to ln -s /srv/ltsp/x86_32.squashfs /srv/ltsp/images/x86_32
07:06
<alkisg>
VMs go to /srv/ltsp/vm.img, exported images to /srv/ltsp/images/ex.img
07:07
VMs can be symlinked, images shouldn't due to nfs
07:07
(although our nfs root is /srv/ltsp, so it'll work under that)
07:07
<vagrantc>
i guess i could've ln -s x86_32.squashfs x86_32.img and then ltsp image x86_32 ?
07:08
<alkisg>
Why do you want to create a squashfs from the chroot instead of letting ltsp do it?
07:08
Put the chroot in /srv/ltsp/chroot and run ltsp image chroot
07:08
<vagrantc>
there's no chroot
07:08
<alkisg>
mmdebstrap creates a squashfs without a directory?
07:08
<vagrantc>
it produces a usable squashfs image
07:08
<alkisg>
But only if you pass some option, right?
07:09
Can't you just tell it to create a chroot instead?
07:09
i.e. omit that option?
07:09
<vagrantc>
yes, it can also create a chroot ... just wanted to see if it woudl work this way
07:09
<alkisg>
In that case, you'll put it directly inside images/
07:09
As the target dir, with no symlinks etc
07:09
<vagrantc>
mmdebstrap assumes it will be a squashfs if the target ends in .squashfs
07:09
<alkisg>
Ah, no option to make this .img?
07:10
<vagrantc>
would have to rename it
07:10
<alkisg>
Renaming sounds better than ln in this case
07:10
<vagrantc>
sure
07:10
but it's pretty cool
07:10
it does create a chroot directory but then throws it out
07:11
the advantage being, no intermediary uncompressed directory ... the disadvantage being you can't update it as easily ... but it's pretty fast
07:12
mmdebstrap produces a tarball on standard output if you don't give it a target ... which then uses a tar2sqfs to generate the squashfs image
07:12
so i guess i could do the tar2sqfs part myself ... but was just experimenting with the options and ideas
07:13
it'd be nice to be able to add the initramfs-tools module hooks without installing all of ltsp ... not that it's very large :)
07:14
<alkisg>
I think all the ltsp dependencies are already there in a plain deboostrap
07:14
So it just adds a few kb of code under /usr, nothing more
07:14
<vagrantc>
i was more thinking about if you have an old version of ltsp in the booted image, and it has some leftover files that the initramfs copy of the ltsp files doesn't delete
07:15
<alkisg>
The new and old ltsp can coexist without issues, including the initramfs code
07:15
<vagrantc>
or does it not use /usr/share/ltsp ... just from the initramfs directly?
07:15
cool.
07:15
<alkisg>
Some tricks were needed, but it works fine
07:16
<vagrantc>
with --mode=unshare, you can create the ltsp image without root access ... though it requires enabling user namespaces on Debian (not sure if ubuntu has it enabled by default or not)
07:21kjackal has joined IRC (kjackal!~quassel@athedsl-299999.home.otenet.gr)
07:24woernie has joined IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de)
07:49
<alkisg>
vagrantc: I'm ready, you may release now if you like
07:50
<vagrantc>
alkisg: not until i get a good night's sleep :)
07:50
<alkisg>
Sure :)
07:54* vagrantc waves
07:55
<alkisg>
gn vagrantc
07:55vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
09:24kjackal has left IRC (kjackal!~quassel@athedsl-299999.home.otenet.gr, Ping timeout: 268 seconds)
09:24kjackal has joined IRC (kjackal!~quassel@195.97.13.252)
09:46statler has left IRC (statler!~Georg@p5B30E4C3.dip0.t-ipconnect.de, Remote host closed the connection)
10:07kjackal has left IRC (kjackal!~quassel@195.97.13.252, Ping timeout: 268 seconds)
10:21statler has joined IRC (statler!~Georg@gwrz.lohn24.de)
10:38kjackal has joined IRC (kjackal!~quassel@2a02:587:3115:3000:e5a1:8ff8:992d:2899)
11:26woernie has left IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de, Remote host closed the connection)
11:27woernie has joined IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de)
11:31section1 has joined IRC (section1!~section1@178.33.109.106)
11:46enaut[m] has left IRC (enaut[m]!enauttchnc@gateway/shell/matrix.org/x-iwrgghksxacdlaka, Quit: User has been idle for 30+ days.)
12:35Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
15:38statler has left IRC (statler!~Georg@gwrz.lohn24.de, Ping timeout: 260 seconds)
15:51statler has joined IRC (statler!~Georg@gwrz3.lohn24.de)
16:17GodFather has joined IRC (GodFather!~rcc@wsip-66-210-242-210.ph.ph.cox.net)
17:28kjackal has left IRC (kjackal!~quassel@2a02:587:3115:3000:e5a1:8ff8:992d:2899, Ping timeout: 272 seconds)
17:29mnevans has joined IRC (mnevans!8008b09d@zero.geol.umd.edu)
17:30
<mnevans>
Hell LTSP World. I would like to set up internet passthrough for a laptop computer that is on my LTSP LAN. 2 network interfaces, chrootless install.
17:30
Following instructions here, adapted for LTSP19:
17:30
https://help.ubuntu.com/community/UbuntuLTSP/ThinClientHowtoNAT
17:31
so I was thinking to add the line, to /etc/dnsmasq.d/local-dhcp.conf, such as:
17:31
# set router for setting up NAT? dhcp-option=option:routers,192.168.67.254
17:32
But this is the wrong syntax, as reported when I restart dnsmasq.
17:32
Any suggestions - appreciated. I will check back in 28 mins... thanks in advance!
17:32
<alkisg>
mnevans: please don't follow ltsp5 instructions on ltsp20 :)
17:32
Read the man page and set NAT=1, nothing more
17:32
!ltsp.conf
17:32
<ltspbot>
ltsp.conf: Configuration file for LTSP: https://ltsp.org/man/ltsp.conf/
17:32
<mnevans>
Haha! Of course.
17:33
Sorry, I missed that. Which man page, exactly, please?
17:33
<alkisg>
Read 2 lines above
17:33
<mnevans>
got it...
17:33
man ltsp.conf
17:33
<alkisg>
Or the link I pasted, online
17:34
Read the NAT parameter there
17:34
<mnevans>
Is there a template ltsp.conf? I don't see one in /etc/ltsp/ in my installation.
17:47mnevans2 has joined IRC (mnevans2!8102b419@129-2-180-25.wireless.umd.edu)
17:55
<alkisg>
mnevans, again read the man page
17:55
The first line there tells you how to install the template
17:55
Really, man pages are the best source of information
17:55
mnevans2 ^
17:55
<mnevans2>
Got it ... I think the lines in ltsp.conf:
17:55
[server]
17:55
NAT=1
17:55
and restarted dnsmasq seemed not to complain. I can test in 5 mins... Then I will figure out and add the settings for the client displays, based on the examples in the man pages.
17:55
...Thank you!
17:56
<alkisg>
mnevans2, you need to restart the ltsp service, NOT dnsmasq, for NAT=1
17:56
sudo service ltsp restart
17:56
dnsmasq is not related to NAT
17:56
NAT is done by an ltsp script
17:56
<mnevans2>
thank you - reading that... and also ltsp initrd?
17:56
<alkisg>
[server] doesn't need ltsp initrd
17:56
Only clients do
17:57vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
17:57
<mnevans2>
Ah, I missed that too. So you run ltsp initrd on each client?
17:57
to update them to the server installation?
18:04* vagrantc would guess not, unless there's some unusual context
18:04mnevans2 has left IRC (mnevans2!8102b419@129-2-180-25.wireless.umd.edu, Ping timeout: 260 seconds)
18:05
<vagrantc>
alkisg: going for a release soonish :)
18:11
<alkisg>
mnevans: no, i meant "ltsp initrd is only needed if you make changes in ltsp.conf under [clients] sections, not under [server] section"
18:11
vagrantc: great, it should be good to go
18:12
<vagrantc>
i must admit it's a bit of a learning curve knowing what has to be run when
18:13
i don't know if there's some way to "check" so the end-user doesn't have to track which commands to run
18:14
ltsp do-the-things-and-don't-bother-me :)
18:15
alkisg: i struggled to get a working ubuntu 19.10 .iso to work ... but wasn't sure what the steps were ... remember doing it in the past
18:15
<alkisg>
You should be able to just put it to images/ubuntu.img and run ltsp kernel ubuntu
18:16
<vagrantc>
it was missing sshfs, i think ... there's somewhere to drop an sshfs binary
18:17
i also built an image with mmdebstrap, and it seemed to successfully authenticate (and login from the console worked), but gdm didn't start
18:18
er... gdm started ... but it failed to start a session for the user
18:18
who knows what i was missing :)
18:20
same process worked with debian bullseye, though
18:33
<alkisg>
if you put sshfs in /etc/ltsp/ssh-arch, or if you use nfs
18:34
(or you create a local home with POST_INIT_somthing
18:34
<vagrantc>
very clever :)
18:49
tagged, pushed ...
18:49
and uploaded to Debian
18:49
should be in the archive in 6 or so hours
18:50
alkisg: and then you file a sync request for ubuntu? or do you have to wait till it lands in debian testing?
18:59section1 has left IRC (section1!~section1@178.33.109.106, Quit: Leaving)
19:00kjackal has joined IRC (kjackal!~quassel@2a02:587:3115:3000:e5a1:8ff8:992d:2899)
19:00
<alkisg>
vagrantc: nice! It should sync from unstable in a couple of days
19:02statler has left IRC (statler!~Georg@gwrz3.lohn24.de, Ping timeout: 240 seconds)
19:06vagrantc_ has joined IRC (vagrantc_!~vagrant@unaffiliated/vagrantc)
19:14statler has joined IRC (statler!~Georg@gwrz.lohn24.de)
19:18statler has left IRC (statler!~Georg@gwrz.lohn24.de, Remote host closed the connection)
19:52
<vagrantc_>
alkisg: the release announcement seems to be missing some changelog entries ... or i'm not reading carefully
20:01
<alkisg>
I left out 2 of mine that were regression fixes
20:01
so they shouldn't really be there
20:02
<vagrantc_>
got it
20:03
i think adding "Gbp-Dch: Ignore" would make them not appear in debian/changelog when running "gbp dch" ... but i don't usually bother, and just manually edit it anyways.
20:05* alkisg hears about gbp for the first time
20:05
<vagrantc_>
it's in git-buildpackage ...
20:05
<alkisg>
I see
20:06
Is that what made two sections for each of us?
20:06
<vagrantc_>
it's a full suite of stuff to generate debian packages from git, but i typically only use "dbp dch"
20:07
alkisg: yes. which isn't wrong, per se, as sometimes commits depend on previous commits and thus chronological makes more sense
21:05mnevans has left IRC (mnevans!8008b09d@zero.geol.umd.edu, Remote host closed the connection)
21:26woernie has left IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de, Remote host closed the connection)
21:40vagrantc_ has left IRC (vagrantc_!~vagrant@unaffiliated/vagrantc, Quit: leaving)
21:48kjackal has left IRC (kjackal!~quassel@2a02:587:3115:3000:e5a1:8ff8:992d:2899, Ping timeout: 246 seconds)
22:16Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving)