IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 19 February 2017 (all times are UTC)
| 00:40 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 01:03 | adrianor1 has joined IRC (adrianor1!~adrianorg@189.114.157.65) | |
| 01:05 | adrianorg has left IRC (adrianorg!~adrianorg@177.134.60.21, Ping timeout: 240 seconds) | |
| 01:38 | adrianorg has joined IRC (adrianorg!~adrianorg@177.156.230.162) | |
| 01:40 | adrianor1 has left IRC (adrianor1!~adrianorg@189.114.157.65, Ping timeout: 240 seconds) | |
| 01:42 | adrianorg has left IRC (adrianorg!~adrianorg@177.156.230.162, Ping timeout: 255 seconds) | |
| 01:43 | adrianorg has joined IRC (adrianorg!~adrianorg@186.213.154.253) | |
| 01:52 | adrianorg has left IRC (adrianorg!~adrianorg@186.213.154.253, Ping timeout: 260 seconds) | |
| 01:58 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 02:00 | adrianorg has joined IRC (adrianorg!~adrianorg@177.18.50.74) | |
| 05:03 | IRCFrEAK has joined IRC (IRCFrEAK!~gk.1wm.su@2a03:4a80:2:2d3:2d3:9c14:a427:77be) | |
| 05:03 | IRCFrEAK has left IRC (IRCFrEAK!~gk.1wm.su@2a03:4a80:2:2d3:2d3:9c14:a427:77be) | |
| 05:18 | Freejack has left IRC (Freejack!~Freejack@unaffiliated/freejack, Ping timeout: 268 seconds) | |
| 05:22 | Freejack has joined IRC (Freejack!~Freejack@unaffiliated/freejack) | |
| 09:02 | ricotz has joined IRC (ricotz!~ricotz@p5B2A8B89.dip0.t-ipconnect.de) | |
| 09:02 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 09:06 | Statler has joined IRC (Statler!~Georg@p579FEB0D.dip0.t-ipconnect.de) | |
| 09:58 | markus_e92 has left IRC (markus_e92!~markus_e9@80-121-122-6.adsl.highway.telekom.at, Ping timeout: 260 seconds) | |
| 10:01 | markus_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:36 | adrianorg has left IRC (adrianorg!~adrianorg@177.18.50.74, Quit: leaving) | |
| 13:35 | adrianorg 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:29 | bennabiy has left IRC (bennabiy!~bennabiy@unaffiliated/bennabiy, Quit: http://www.yellowdeli.com) | |
| 14:29 | markus_e92 has left IRC (markus_e92!~markus_e9@62-46-97-172.adsl.highway.telekom.at, Ping timeout: 260 seconds) | |
| 14:36 | markus_e92 has joined IRC (markus_e92!~markus_e9@62-46-100-174.adsl.highway.telekom.at) | |
| 14:43 | markus_e92 has left IRC (markus_e92!~markus_e9@62-46-100-174.adsl.highway.telekom.at, Ping timeout: 240 seconds) | |
| 14:47 | markus_e92 has joined IRC (markus_e92!~markus_e9@80-121-120-147.adsl.highway.telekom.at) | |
| 15:20 | kjackal_ 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:53 | adrianor1 has joined IRC (adrianor1!~adrianorg@187.58.155.153) | |
| 17:56 | adrianorg has left IRC (adrianorg!~adrianorg@187.113.251.15, Ping timeout: 240 seconds) | |
| 18:51 | forum has joined IRC (forum!~Icedove@193-154-244-93.adsl.highway.telekom.at) | |
| 19:13 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 19:54 | forum has left IRC (forum!~Icedove@193-154-244-93.adsl.highway.telekom.at, Remote host closed the connection) | |
| 19:54 | forum has joined IRC (forum!~Icedove@193-154-244-93.adsl.highway.telekom.at) | |
| 20:04 | forum has left IRC (forum!~Icedove@193-154-244-93.adsl.highway.telekom.at, Quit: forum) | |
| 20:08 | markit 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:14 | Statler 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:15 | adrianor1 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:40 | markit has left IRC (markit!~marco@88-149-177-66.v4.ngi.it, ) | |
| 20:40 | forum has joined IRC (forum!~Icedove@193-154-244-93.adsl.highway.telekom.at) | |
| 20:48 | forum 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:32 | adrianorg 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:27 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 23:05 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |