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


Channel log from 19 February 2017   (all times are UTC)

00:40vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
01:03adrianor1 has joined IRC (adrianor1!~adrianorg@189.114.157.65)
01:05adrianorg has left IRC (adrianorg!~adrianorg@177.134.60.21, Ping timeout: 240 seconds)
01:38adrianorg has joined IRC (adrianorg!~adrianorg@177.156.230.162)
01:40adrianor1 has left IRC (adrianor1!~adrianorg@189.114.157.65, Ping timeout: 240 seconds)
01:42adrianorg has left IRC (adrianorg!~adrianorg@177.156.230.162, Ping timeout: 255 seconds)
01:43adrianorg has joined IRC (adrianorg!~adrianorg@186.213.154.253)
01:52adrianorg has left IRC (adrianorg!~adrianorg@186.213.154.253, Ping timeout: 260 seconds)
01:58vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
02:00adrianorg has joined IRC (adrianorg!~adrianorg@177.18.50.74)
05:03IRCFrEAK has joined IRC (IRCFrEAK!~gk.1wm.su@2a03:4a80:2:2d3:2d3:9c14:a427:77be)
05:03IRCFrEAK has left IRC (IRCFrEAK!~gk.1wm.su@2a03:4a80:2:2d3:2d3:9c14:a427:77be)
05:18Freejack has left IRC (Freejack!~Freejack@unaffiliated/freejack, Ping timeout: 268 seconds)
05:22Freejack has joined IRC (Freejack!~Freejack@unaffiliated/freejack)
09:02ricotz has joined IRC (ricotz!~ricotz@p5B2A8B89.dip0.t-ipconnect.de)
09:02ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
09:06Statler has joined IRC (Statler!~Georg@p579FEB0D.dip0.t-ipconnect.de)
09:58markus_e92 has left IRC (markus_e92!~markus_e9@80-121-122-6.adsl.highway.telekom.at, Ping timeout: 260 seconds)
10:01markus_e92 has joined IRC (markus_e92!~markus_e9@62-46-97-172.adsl.highway.telekom.at)
10:50
<al-geo>
help please. i cant start ssh on my fat clients. after restart ssh is not started while i reinstall it (on client). and if i reinstall openssh-server on server chroot it didnt works
10:54
and on client systemctl status ssh (or sshd) answer is | not-found inactive and no such file or directory
11:00
<muppis>
Just for check: After installation in chroot, you rebuilded the image and rebooted the client?
11:00
<al-geo>
yep
11:01
<muppis>
Can you manually start the daemon in client?
11:01
<al-geo>
manualy add links in systemd/system/multi-user.wants
11:01
when i try it isnt there
11:02
<muppis>
Are required ssh keys in place?
11:04
<al-geo>
strange thing. ls -la to multi-user.wants/ssh.service says No such file or directory
11:09
<muppis>
Can't really help more. :( Right now I don't have working system where to test.
11:11
<quinox>
it works for me
11:12
FYiit's 'service sshd'
11:12
any errors during installation?
11:13
<al-geo>
if you know: is there some dir to write down package name and while ltsp-build-image ?
11:13
<quinox>
yes, late-packages
11:15
# Space separated list of programs to install.
11:15
# The java plugin installation contained in ubuntu-restricted-extras
11:15
# needs some special care, so let's use it as an example.
11:15
LATE_PACKAGES="
11:15
ubuntu-restricted-extras
11:15
gimp
11:15
nfs-client
11:15
"
11:15
from https://help.ubuntu.com/community/UbuntuLTSP/FatClients
11:16
if that list gets long you might want to not use it; in my experience it's a bit sensitive, any error here will cause the build to fail
11:17
I install packages by hand after building/testing a vanilla image
11:22
<al-geo>
i have ltsp-pnp installation so its not works for me
11:22
<quinox>
correct, in that case you get whatever you have on your server
11:22
(or not?)
11:23
I never used ltsp-pnp actually so I could very well be wrong
11:23
<al-geo>
yes but on server ssh works fine
11:24
<quinox>
so what happens when you run 'apt-get install openssh-server' on a client?
12:13
<al-geo>
if apt remove and apt install than it works fine
12:13
if just apt install than openssh-server is already installed
12:33
<alkisg>
al-geo: you no longer have ltsp-pnp as you have a chroot now
12:33
al-geo: ltsp-update-image removes sshd from the chroot, let me get you a link to fix that...
12:33
al-geo: https://bugs.launchpad.net/ltsp/+bug/1324545
12:36adrianorg has left IRC (adrianorg!~adrianorg@177.18.50.74, Quit: leaving)
13:35adrianorg has joined IRC (adrianorg!~adrianorg@187.113.251.15)
13:42
<al-geo>
alkisg thank you pal. i comment 'etc/ssh/ssh_host_*_key' in /etc/ltsp/ltsp-update-image.excludes. , => rm -rf opt/ltsp/* and ltsp-build-image and hope it helps :D
14:29bennabiy has left IRC (bennabiy!~bennabiy@unaffiliated/bennabiy, Quit: http://www.yellowdeli.com)
14:29markus_e92 has left IRC (markus_e92!~markus_e9@62-46-97-172.adsl.highway.telekom.at, Ping timeout: 260 seconds)
14:36markus_e92 has joined IRC (markus_e92!~markus_e9@62-46-100-174.adsl.highway.telekom.at)
14:43markus_e92 has left IRC (markus_e92!~markus_e9@62-46-100-174.adsl.highway.telekom.at, Ping timeout: 240 seconds)
14:47markus_e92 has joined IRC (markus_e92!~markus_e9@80-121-120-147.adsl.highway.telekom.at)
15:20kjackal_ has left IRC (kjackal_!~quassel@2a02:587:3102:cf00:48c7:5851:ea72:7e16, Ping timeout: 255 seconds)
15:40
<alkisg>
al-geo: erm... ltsp-build-image will delete your previous ltsp-pnp chroot
15:41
It will now be a thin chroot only
17:53adrianor1 has joined IRC (adrianor1!~adrianorg@187.58.155.153)
17:56adrianorg has left IRC (adrianorg!~adrianorg@187.113.251.15, Ping timeout: 240 seconds)
18:51forum has joined IRC (forum!~Icedove@193-154-244-93.adsl.highway.telekom.at)
19:13vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
19:54forum has left IRC (forum!~Icedove@193-154-244-93.adsl.highway.telekom.at, Remote host closed the connection)
19:54forum has joined IRC (forum!~Icedove@193-154-244-93.adsl.highway.telekom.at)
20:04forum has left IRC (forum!~Icedove@193-154-244-93.adsl.highway.telekom.at, Quit: forum)
20:08markit has joined IRC (markit!~marco@88-149-177-66.v4.ngi.it)
20:09
<markit>
hi alkisg :) I've 2 problems, one at school and one here at home. At home: ltsp-pnp, LDM_AUTOLOGIN=True, created user ltsp145 pwd ltsp145, client has ip .145 but does not log automatically
20:09
<alkisg>
Heya markit
20:10
Does it try to login and fail, or it doesn't try at all and stays at ldm?
20:10
<markit>
the first problem, and is the reason I've that PC here at home, is that at school, old 12.04 installation, 8 PC does not come to graphical part, I've black screen (unfortunately I've not tested if is related with autologin or not, other 15 PC work fine, and are the oldest)
20:10
alkisg: how can I tell? I mean, I get the ldm seems imediately
20:11
<alkisg>
Do you see ldm?
20:11
<markit>
yes
20:11
<alkisg>
Then your LDM_AUTOLOGIN is not read by the client
20:11
Something wrong in lts.conf
20:11
<markit>
for the second problem, the pnp not autologin working, I have
20:12
nano /var/lib/tftpboot/ltsp/amd64/lts.conf
20:12
<alkisg>
Open a shell on the client with epoptes (right click open root terminal), and run getltscfg -a
20:12
<markit>
AH, ok
20:12
I've put the autologin as last statement
20:12
but maybe is in a section
20:12
<alkisg>
getltscfg -a | nc termbin.com 9999
20:12
<markit>
yes, [OLD MONITOR]
20:12
<alkisg>
Right
20:12
Wrong place to put it there
20:13
<markit>
new demo lts.conf is tricky
20:13
sorry for the noise, let me try again
20:14
alkisg: the worse problem is that I went to school, they told me that I had to change some cmos battery because "some computer don't boot"
20:14Statler has left IRC (Statler!~Georg@p579FEB0D.dip0.t-ipconnect.de, Remote host closed the connection)
20:14
<markit>
I've set autologin as true, and tested
20:14
2 had that problem, but 6 boot fine but at the "I'm going to graphical desktop now" phase I've black screen
20:14
<alkisg>
What was the message, "CMOS checksum mismatch, press F1 to continue?" That's normal for old PCs, you just change the battery...
20:15
<markit>
don't know when this happend, I hate teachers of "my" schools
20:15
<alkisg>
How do you set up that the ip is .145?
20:15
<markit>
autologin here at my home with .145 went fine, thanks
20:15
the same pc at school has black screen instead
20:15adrianor1 has left IRC (adrianor1!~adrianorg@187.58.155.153, Ping timeout: 240 seconds)
20:15
<alkisg>
If it has ip=146 is won't login
20:15
(at school)
20:16
So basically you should do something like this:
20:16
[mac-address]
20:16
HOSTNAME=pc01
20:16
<markit>
I've ltspXYZ in the dhcp range, as far as I remember
20:16
<alkisg>
LDM_USERNAME=guest01
20:16
And, set LDM_PASSWORD either at a section or globally
20:16
<markit>
but yes, could be that I changed the range and did not updated the users, nice shot
20:16
<alkisg>
You have 250 sections?
20:16
Ah, 250 users?!
20:17
<markit>
no, I've dhcp in the range 100-130 and 31 users, ltsp100...ltsp130
20:17
<alkisg>
So if the ip changes, the students of the same pc will get different account?
20:17
<markit>
no no, autologin is ONLY for test reasons
20:17
I don't want to have to enter 28 users/passwords just to test if they all boot fine
20:17
<alkisg>
I prefer to name the PCs, with HOSTNAME
20:17
Are they fat clients?
20:17
<markit>
yes
20:18
<alkisg>
You can have a test local user
20:18
<markit>
and every student has username/password (28 pc, 300 students)
20:18
<alkisg>
Anyway, whatever works for you
20:18
<markit>
"a test local user"?
20:18
<alkisg>
We do that here in the tech office, but never mind
20:18
It's so that we have 1 user for all PCs that get serviced
20:19
<markit>
ok, but except if is a ltsp autologin problem due to a mistmach between IP and ltspXYZ user, when I don't have ldm and pc just goes black screen, does some simple reason comes to your mind?
20:19
(so I can take note and try tomorrow night)
20:20
<alkisg>
Problems with the graphics driver; check /var/log/Xorg.0.log
20:20
Basically, Xorg.0.log.old, if you see that it ends with EE error xxx, then take note of the error
20:20
<markit>
of course in the PC, but how can I login? ctrl+alt+F1?
20:21
<alkisg>
Right click from epoptes, open root terminal
20:21
You keep forgetting that :D
20:21
<markit>
hehehe, you are right, my fault
20:21
I've just used epoptes for lan test (and is great!)
20:22
I must learn that is important for other troubleshooting stuff
20:22
<alkisg>
I never help users if they don't have epoptes installed :)
20:22
<markit>
btw, would love to have epoptes reporting me something I can paste in calc with basin info abut clients, like ram, 32 vs 64 bit cpu, video info, etc
20:22
<alkisg>
It saves sooo much time that it's essential
20:23
File bug reports!
20:23
<markit>
for remote help yes, true, but I've teachers that are not skilled at all, you can't even understand what happens
20:23
<alkisg>
!vnc-edide
20:23
<ltsp>
vnc-edide: To share your screen with me, open Epoptes → Help menu → Remote support → Host: srv1-dide.ioa.sch.gr, and click the Connect button
20:23
<alkisg>
That's what I tell them, and they all can do it
20:24
From there, I have full control to both the server and the clients
20:24
<markit>
yes, but they tell "pc don't start" and you don't know if does not power on, does not boot, boots but black screen afterward, etc
20:24
<alkisg>
tail -f /var/log/syslog, and I tell them to reboot the pc
20:24
Then I can see for myself where it reaches
20:24* markit takes note
20:25
<markit>
alkisg: when will you write a "ltsp troubleshooting guide from a real Guru" book?
20:26
<alkisg>
Haha, I don't think that will be a best seller; it'll be read by 100 people at most :D
20:26
I've had wiki pages with more readers!
20:29
<markit>
alkisg: maybe my foult, but I've often no idea about what to look at and where start troubleshoot
20:31
<alkisg>
markit: there are varying levels of experience for sysadmins; I've been coding in assembly and various languages for 25 years now, that gives me some experience...
20:35
<markit>
mee too, but never the less (probably because I'm only marginally working on ltsp) I'm often lost. I mean, I rarely need to troubleshoot ltsp (works so well!), but when I need I'm lost
20:36
btw, if I remove user ltsp145 I've black screen, so could be the problem I had at school... but I took 8 PC from 3° flor of the school to my home because of that, and now I've to do it back
20:36
just for my ignorance
20:36
(or not having come to irc chat to ask alkisg ;P)
20:36
<alkisg>
Haha
20:36
<markit>
in any case, I've to do some other business now and just have to THANK YOU once more again
20:37
btw, do you have a "fat client" you have tested, is cheap but works fine, to suggest?
20:37
I remember your links when you showed me that raspberry is non-sense
20:38
but I mean something you have really tested and are sure it works with ubuntu 16.04?
20:38
(possibly 4GB ram)
20:38
<alkisg>
markit: no, we buy i3's here
20:38
!cheap-client
20:38
<ltsp>
cheap-client: (#1) http://www.gearbest.com/tv-box-mini-pc/pp_343636.html, or (#2) https://www.aliexpress.com/store/product/New-arrival-Beelink-Pocket-Z83-Windows-10-Mini-PC-Z8300-64bit-1-84GHz-2GB-RAM-32GB/1871240_32640039781.html
20:38
<markit>
in this school we have old P4 and other "trashware", a lot of cables and children are messing it sometime
20:39
<alkisg>
That's what I googled last, but I haven't tested them
20:39
<markit>
i3? what brand/model of pc?
20:39
<alkisg>
markit, use google translate on this: http://blogs.sch.gr/plinetio/specifications
20:40
It has links for specific clients
20:40
<markit>
ok, thanks A LOT, good night :)
20:40markit has left IRC (markit!~marco@88-149-177-66.v4.ngi.it, )
20:40forum has joined IRC (forum!~Icedove@193-154-244-93.adsl.highway.telekom.at)
20:48forum has left IRC (forum!~Icedove@193-154-244-93.adsl.highway.telekom.at, Quit: forum)
20:55
<vagrantc>
alkisg: best idea i've come up with is for upstream to maintain a debian-upstream directory, and then the recipe merges that as debian/
20:56
alkisg: and local builds can be done with a symlink
20:56
alkisg: that wouldn't interfere with my workflow as a debian maintainer ... still basically requires forking
20:56
alkisg: but i'm presuming upstream changes are rare
20:56
<alkisg>
vagrantc: that would work, if...
20:57
you base your work on that, and not just keep a separate and unrelated tree,
20:57
because then ubuntu would inherit your packaging, not the upstream packaging,
20:57
making our efforts worthless; just for the ppa builds
20:57
<vagrantc>
alkisg: i'll have to manually merge changes in, but since i don't expect it to change a lot, should be doable.
20:58
<alkisg>
Cool
20:58
<vagrantc>
alkisg: i was assuming the ubuntu builds would still just sync with debian
20:58
<alkisg>
So, can't git have 2 branches with different names, that both have a directory named debian?
20:59
<vagrantc>
alkisg: that's also possible, but since we're dealing with bzr for upstream, and git for debian...
20:59
alkisg: that would actually be easier, though
20:59
<alkisg>
Epoptes has only git
20:59
There's no need to involve bzr at all there
20:59
<vagrantc>
alkisg: the problem is with the debian workflow, i want to only merge new upstream versions when ip update the corresponding packaging
21:00
alkisg: which is conflict prone if you merge back and forth
21:00
<alkisg>
For ltsp, since I have to keep a bzr import anyway, it does not matter if the source is any git branch
21:00
What's wrong with snapshots?
21:00
<vagrantc>
alkisg: i don't know what you mean with snapshots
21:00
<alkisg>
We both maintain the upstream debian dir
21:01
Then, at some point you want to release a version on debian
21:01
You just fork the upstream debian dir then, and have a "series" there
21:01
<vagrantc>
alkisg: problem is, it's best if the debian dir and upstream code are all in one branch
21:01
alkisg: which makes it hard to merge versions that are evolving constantly
21:02
<alkisg>
It's the normal way to keep supporting a series of some software; like kernel 4.4 or libreoffice 5.x etc
21:02
<vagrantc>
the problem is that we're not just releasing versions of upstream software, but backporting patches in a quilt series
21:02
<alkisg>
They all have their upstreams, and they clone specific versions/series that are supported with backported patches etc for a period of time
21:02
<vagrantc>
and patches of patches of patches is complicated
21:03
<alkisg>
Why would you have patches of patches?
21:03
The upstream debian dir has no patches
21:03
When you fork, you have no patches
21:03
<vagrantc>
i'm not explaining it well
21:03
<alkisg>
If upstream then has a few commits that interest you, you backport them as patches
21:03
It's the normal way to support releases...
21:03
<vagrantc>
which is basically what i do now, without the upstream debian branch
21:04
<alkisg>
Right, and all I'm asking is to share a common upstream with us
21:04
<vagrantc>
the problem is that there are two different projects
21:04
there's upstream, and there's debian (and derivatives, and so on)
21:05
alkisg: for one thing, debian/changelog *should* only contain changes uploaded to Debian
21:05
alkisg: whereas, for the upstream code, it would presumably contain all the upstream daily builds or whatever?
21:05
<alkisg>
It's not /changelog, it's debian/changelog,
21:05
so, I would update it whenever some debian-based release occurs
21:06
I.e. when building for debian or ubuntu or ppa
21:06
And I would expect it to appear in the next debian release
21:06
<vagrantc>
the or ubuntu or ppa part would cause *lots* of conflicts
21:06
<alkisg>
Why?
21:07
Suppose that I want to release to debian experimental, and sync to ubuntu from there
21:07
Where's the problem in that?
21:07
<vagrantc>
every time i need to merge that branch, debian/changelog will have divergent histories that are frustrating to resolve
21:07
it's just a lot of effort
21:07
<alkisg>
No, it wouldn't
21:07
<vagrantc>
yes, it would
21:07
i've been here before, back in 2006
21:08
it was awful
21:08
<alkisg>
You keep thinking this as "stretch changelog is the next version of the jessie changelog",
21:08
instead of "stretch changelog is a snapshot of the upstream changelog at the time of the freeze",
21:08
and "jessie changelog is a snapshot of the upstream changelog at the time of the freeze",
21:08
They are not a continuum
21:08
They are series
21:09
<vagrantc>
whatever words you want to put on it, it creates merge conflicts that seem like a waste of time to resolve.
21:09
i've been there, i've done this, i don't want to go back to it
21:09
i've been working with packaging workflows for roughly 17 years now, i've tried lots of different models
21:09
<alkisg>
What conflicts did you have with epoptes the years that I've been maintaining it?
21:10
<vagrantc>
alkisg: the debian/changelog was almost never modified, so it worked out ok, though there were some challenging merges i had to figure out when the upstream tree diverged from the debian dir.
21:11
<alkisg>
Can you give me an example?
21:11
<vagrantc>
i don't really want to re-hash this. i had a proposal i thought might work, and you seemed to think it might work, but now we're back to this discussion, and i don't have the energy for it
21:12
<alkisg>
But I said "as long as it's the same thing that goes to ubuntu",
21:12
and you said "no, it'll be a different tree"
21:12
So I'm not sure we reached a workable solution there...
21:13
<vagrantc>
ok, i give up
21:13
<alkisg>
Maybe I didn't understand something, dunno
21:13* alkisg re-reads the conversation...
21:13
<vagrantc>
i can't distill 17 years of experience into one specific example
21:14
<alkisg>
OK so let's just sum up
21:14
We have an epoptes branch for the code,
21:14
a debian branch for the packaging,
21:14
(or if you want us to name it debian-upsteam, no problem there),
21:15
and you maintain another (or many others) debian-stretch (or plain debian) branches for debian
21:15
Is that ok?
21:15
<vagrantc>
for debian, we want a single repository/branch to point to that has the current packaging uploaded to experimental or unstable (whichever is most current)
21:16
so i would only fork for debian-stretch when i stop uploading stuff targeted for stretch to unstable
21:17
the problem is, if you want me to maintain packaging changes for debian-upstream in the same way i maintain them for debian
21:17
<alkisg>
OK, is it possible for the unstable branch to not contain upstreamed patches?
21:17
<vagrantc>
no
21:17
i mean, by chance, sometimes it will happen
21:17
but i can't guarantee that will never happen
21:17
<alkisg>
I think that's the part that I don't understand
21:18
<vagrantc>
we're in a freeze, i can't upload new upstream versions to unstable
21:18
<alkisg>
I.e. when the debian maintainers have control over upstream code, why would they include debian/patches in unstable
21:18
<vagrantc>
therefore, patches in debian packaging branch
21:18
<alkisg>
Ah packages go first to unstable before they migrate to testing
21:18
OK, what about experimental?
21:18
<vagrantc>
there are some patches for LTSP that actually shouldn't go upstream but are really correct for Debian.
21:19
<alkisg>
Those should be the same in ubuntu too
21:19
I don't mind about those
21:19
(and in the ppa and everywhere)
21:19
<vagrantc>
so, i believe that a debian dir can really only be correct for a specific version of upstream software
21:20
<alkisg>
(11:18:08 μμ) vagrantc: we're in a freeze, i can't upload new upstream versions to unstable ==> but at the time of the freeze, wouldn't you have forked to a debian-stretch directory?
21:20
<vagrantc>
sometimes, it works longer than that, but you can't rely on that
21:20
alkisg: no, i would only do that once stretch releases
21:20
alkisg: uploads targetted for stretch still go through unstable
21:20
<alkisg>
So the main issue is, from the time of the freeze, until the time of the release?
21:21
<vagrantc>
alkisg: that's the main issue
21:21
alkisg: but it also happens during other times ... e.g. there might be a bunch of commits upstream, but i need to fix a specific bug that's also fixed upstream later in the series
21:22
<alkisg>
I would consider that to be a "debian-unstable" fork then, and name the "debian-upstream" one as "debian-experimental" or something. One that keeps up the pace with upstream.
21:22
<vagrantc>
experimental may not necessarily keep current with upstream either
21:22
<alkisg>
Is it allowed to do so though?
21:22
If it is allowed, and it makes our life easier, then that's what makes sense to me...
21:23
<vagrantc>
i don't think it makes it any easier, it's the same problem
21:23
<alkisg>
OK, let's sum up again
21:23
<vagrantc>
(and i don't want to commit to keeping experimental in sync with upstream)
21:24
<alkisg>
That would be *my* work
21:24
<vagrantc>
i don't think it's good practice for debian
21:24
<alkisg>
That's what I want that branch for
21:24
OK so anyway, I can have a debian-something branch where I can update the packaging when I do source changes in epoptes
21:25
You can keep whatever branches you like for debian,
21:25
The question is, will you ever sync from the "debian-upstream" branch? Will I ever see my commits to ubuntu?
21:26
<vagrantc>
maybe :)
21:26
so two thoughts that would make this easier ...
21:27
"upstream" commits should only modify things outside of debian dir
21:27
upstream gets merged into debian-upstream whenever a release or snapshot is made ...
21:27
and packaging fixes are fixed there
21:28
bah.
21:28
and now we're back to debian/changelog conflicts
21:28
<alkisg>
In my scenario, debian-upstream doesn't have code, only packaging
21:28
Let's call the branches "code", "debian-upstream", and "debian-release"
21:28
I maintain code and debian-upstream, you maintain debian-release,
21:28
In debian-upstream, I only have a debian/ dir, nothing else
21:29
<vagrantc>
if it contains only packaging, then it will be really hard to merge into the debian branches targeted at Debian
21:29
<alkisg>
In debian-release, I think you want to have both?
21:29
<vagrantc>
yes
21:29
<alkisg>
OK, tell me how you want it then, I didn't get it
21:30
<vagrantc>
i realized a flaw in my workflow
21:30
basically, our desired workflows are incompatible
21:30
<alkisg>
My requirement is, "i want to be able to update the packaging so that I can have daily builds, without having to fork all the time". I don't think I"m unreasonable...
21:31
<vagrantc>
agreed, that's not an unreasonable request
21:32
but i don't see any way to easily merge branches that contain only upstream code + only debian packaging with branches that contain both upstream code and debian packaging
21:32adrianorg has joined IRC (adrianorg!~adrianorg@187.113.251.146)
21:32
<vagrantc>
i *might* be able to cherry-pick stuff from a debian-dir only branch, as long as the debian-dir commits never modify things outside of the debian-dir
21:33
but then the debian/changelog and the packaging commits need to be separate
21:33
<alkisg>
So, if there's only one branch, that has both the code and debian/, and we never push to debian/ along with code, that would work for you?
21:33
<vagrantc>
i don't want to have to merge debian/changelog
21:34
*maybe*
21:34
but the debian/changelog changes are kind of important
21:34
<alkisg>
You decide whatever you like; I don't mind to organize the commits however you want them, as long as my request above is met...
21:35
<vagrantc>
another aspect of my workflow has been to only update debian/changelog when a release is made
21:35
<alkisg>
When "a" release, or a "debian" release?
21:36
<vagrantc>
debian release, since it's debian/changelog i'm talking about
21:36
<alkisg>
But ubuntu also uses debian/changelog
21:37
What would apt changelog show, if I don't update debian/changelog for new releases, that just don't align with debian?
21:37
<vagrantc>
my packaging workflow is: merge new upstream version, update debian/* as needed, generate debian/changelog from commits to debian/* and any noteworthy upstream changes
21:37
alkisg: and ubuntu typically has a mangled history in it's debian/changelog files
21:38
<alkisg>
I'm fine with that workflow, as long as it allows me to create new debian releases in experimental whenever i need them
21:38
I can sync to ubuntu from experimental
21:38
<vagrantc>
do you mean debian experimental?
21:38
<alkisg>
Yes
21:38
<vagrantc>
debian experimental shouldn't just be a staging area for ubuntu...
21:39
<alkisg>
I'm also a debian packager
21:39
And also a ppa user
21:39
Where I test, shouldn't matter...
21:39
If debian wants to block ubutu, maybe that's the issue then
21:40
<vagrantc>
well, it does matter if you're using a project's resources consistant with the way that project works
21:40
<alkisg>
So ubuntu isn't consistent with debian?
21:40
They should stop pulling?
21:41
<vagrantc>
ubuntu can do whatever they want, and they've made that quite clear over the years that they will do whatever they want
21:41
they're welcome to pull from whatever branches in debian make sense for ubuntu
21:41
<alkisg>
I always respected debian and wanted to make sure my software runs there without needing modifications
21:41
But I can't accept it if debian doesn't want me to be able to run my software in ubuntu too
21:42
Or wants me to do additional work
21:42
<vagrantc>
i think you're overgeneralizing what i'm saying into "debian doesn't want me to ..."
21:42
<alkisg>
I'm willing to test both and maintain both
21:42
But not fork my own code
21:42
Anyway, enough with the theories
21:43
In practise, do we have a solution with specific dirs and branches?
21:43
One that meets my request?
21:44
<vagrantc>
i still think maintaining a branch in upstream distro/debian with upstream's idea of what packaging should be like would work.
21:45
<alkisg>
So, the debian/ dir would be in the same branch with the code, as it was in the past?
21:45
<vagrantc>
it doesn't allow cherry-picking of changes as easily, but i don't expect it to have a lot of updates, so i can handle manually merging those changes in Debian packages
21:45
alkisg: it's important that it be in a separate directory
21:46
alkisg: so a ppa would require nesting it into the debian/ dir
21:46
alkisg: or a manual build to symlink debian/ -> distro/debian
21:46
<alkisg>
vagrantc: https://github.com/Epoptes/epoptes/branches
21:46
We have 3 branches
21:47
Should I create a debian directory in the master branch?
21:47
Or create a fourth debian-upstream branch?
21:47
<vagrantc>
alkisg: if you did what i just proposed, i would put that into the master branch as distro/debian/
21:48
<alkisg>
vagrantc: recipes can't rename directories
21:48
They can merge a different branch in a directory
21:48
<vagrantc>
alkisg: sure you can, you can next the subdirectory
21:48
er, nest
21:48
<alkisg>
nest takes a branch and puts it in a dir
21:48
It doesn't rename a dir
21:49
<vagrantc>
the launchpad documentation suggests you can nest it into a specific directory
21:49
<alkisg>
OK, which 2 branches I would nest?
21:49
One would be the master branch
21:49
Which branch would be the nested one?
21:49
<vagrantc>
nest-part
21:49
you'd nest-part the master branch's distro/debian onto debian
21:50
<alkisg>
I would merge the master branch with the master branch again?
21:50
<vagrantc>
not merge, nest-part
21:50
<alkisg>
I'm not sure if that's a syntax error or allowed, I can try it
21:50
<vagrantc>
nest-part packaging lp:~some-person/some-project/trunk-with-packaging debian debian
21:51
so this would be nest-part packaging git:.../master distro/debian debian
21:51
<alkisg>
Why "distro/debian" instead of "debian-upstream"? Which distro would I put there?
21:52
<vagrantc>
alkisg: i've seen the convention in other projects for this sort of use-case
21:52
alkisg: it allows for other distros
21:52
<alkisg>
I would put ubuntu there, or the word "distro"?
21:52
<vagrantc>
"distro"
21:52
<alkisg>
Ah
21:53
<vagrantc>
so distro/arch, distro/redhat, distro/debian, distro/mint (ha ha)
21:53
<alkisg>
And the problem is that I wouldn't be able to ship a buildable tarball...
21:53
But OK, that's not very significant
21:53
<vagrantc>
it's a simple way to keep "example" packaging upstream without interferring with downstream
21:54
alkisg: don't the ppa's ship buildable tarballs?
21:54
<alkisg>
I mean something like, git clone epoptes; cd epoptes; debuild -b -tc
21:54
That wouldn't work because it wouldn't have a debian dir
21:54
<vagrantc>
alkisg: interestingly enough, putting the debian dir into the upstream tarball is fine with recent debian packaging formats.
21:55
alkisg: it would require a: ln -s distro/debian before debuild
21:55
<alkisg>
Right
21:55
OK, sounds workable
21:55* vagrantc sighs
21:56* alkisg hopes that he won't have a so diverged debian/ dir from the distro/debian dir, that will cause issues in ubuntu and will need re-testing everything... :D
21:56
<vagrantc>
alkisg: if you've got a good upstream, the packaging is trivial :)
21:57
i'm not much worried about most of the packaging... debian/changelog is where i've encountered all the merge changes
21:57
er, merge challenges
21:58
<alkisg>
vagrantc: ok with epoptes; what about ltsp, is there something we could do there to have daily builds, besides forking from the latest debian release?
21:58
<vagrantc>
the pain of this discussion on my end was from trying to sync ubuntu and debian dirs from ~2006 till fairly recently
21:58
alkisg: immediately, it's going to require forking
21:59
alkisg: but long-term, i don't see why a similar workflow wouldn't work
21:59
<alkisg>
I may switch some or all the schools to debian at some point; i'd hate to have to maintain different packaging for them...
21:59
Cool, I don't think it's worth it for ltsp5, but at least we could do it for ltsp6
22:00
<vagrantc>
or at least, i *think* this will work
22:00
hopefully launchpad doesn't needlessly balk on the fact you're using the same repository twice for the ppa recipes
22:01
<alkisg>
Well if it gets to that, I can import twice from github, to 2 different repositories
22:01
I wonder how we'll get the history back for the distro/debian dir though
22:01
<vagrantc>
once from github, once from launchpad :)
22:01
<alkisg>
in the epoptes master branch
22:02
Nah, imports from github to launchpad-a, and from github to launchpad-b, and then merge/nest launchpad-a with launchpad b
22:02
Recipes can't import on the fly from github
22:02
Only from launchpad branches
22:02
<vagrantc>
ah
22:03
getting the history... htat's going to be harder
22:03
but hopefully we won't need to change the packaging that much
22:03
<alkisg>
No I mean, we separated the debian/ dir from upstream code, into a different branch,
22:03
and now we basically need to put it back, but to a different dir..
22:04
<vagrantc>
the other obvious option is to keep the packaging in a separate branch, and then we can cherry-pick history into the Debian branches when needed
22:04
<alkisg>
and the history of all the commits to distro/debian won't show up in github
22:04
<vagrantc>
e.g. fork my debian branch(es) as they are now, merge upstream into them
22:04
<alkisg>
That sounds easier to me; it's not like we have any differences between debian-based distros in epoptes...
22:05
<vagrantc>
then you'll need to merge upstream into the debian-upstream branch whenever you want to do a build
22:05
you don't want to merge debian-upstream into upstream ever
22:05
or debian into upstream
22:06
unless you like madness :)
22:06
insanity, and so on
22:06
but that should allow clean cherry-picking for the debian branches
22:07* alkisg hopes he understood the proposed process correctly...
22:07
<vagrantc>
i just have to avoid commits that tweak debian/changelog
22:08
alkisg: git checkout -b debian-upstream debian ; git merge upstream
22:09
i think this is a little easier with git, honestly
22:09
<alkisg>
Mixing git and bzr in recipes isn't allowed
22:09
So ltsp was a lot harder that what epoptes will be, which is only git...
22:10
I had to import the ltsp packaging from git to bzr, and then do nest-part
22:10
<vagrantc>
lots of conflicts...
22:10
gah.
22:10
right, the directory removal.
22:10
<alkisg>
They do sound silly when we are the maintainers for all the code and packaging... :D
22:11
<vagrantc>
i understand that it sounds silly, but it's necessary for different projects with different workflows
22:11
i know how to wear different hats
22:12
and try to think about things from a different angle
22:12
often, it doesn't make much difference, but when it does, it's good to have the clear delineation
22:12
<alkisg>
...as long as all the angles are convered :)
22:12
Ty for the chat vagrant... bed time now!
22:12
<vagrantc>
obviously, that's where the clarity matters :)
22:12
alkisg: thanks to you too
22:12
<alkisg>
*covered
22:12* alkisg waves!
22:12
<vagrantc>
rest up
22:13* vagrantc suspects this will require a little more merge conflict resolution, but hopefully that's a one-time issue
22:19
<vagrantc>
alkisg: well, hopefully you're already asleep, but there are some technical glitches i'll need to resolve with this (at least for epoptes).
22:22
i think i've figured out how to get git to recognize the old history
22:27vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
23:05ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)