| gnarface | dynastar: still there? first thing that comes to mind for me is to suspect the storage; are you using a usb key or a microSD card or something like that? are any of the partitions nearly full? | 01:01 |
|---|---|---|
| gnarface | i dunno what DNS resolution would have to do with your file manager, but if you have avahi-daemon installed and running who knows... | 01:01 |
| freem | I think the nick changed to Xenguy? | 01:08 |
| freem | oh, no, sorry | 01:08 |
| freem | misread | 01:09 |
| Xenguy | o/ | 01:09 |
| freem | sorry for ping, was a mistake | 01:10 |
| Xenguy | not a problem | 01:19 |
| paculino | Hello, I'm trying to turn my C code into a .deb. I can compile it fine, but this is not very convenient for sharing. The guide I found on the debian wiki assumes there is already a debian/ directory. What is a resource that only assumes starting with the bare minimum (code, executable, readme, and license)? | 07:12 |
| gnarface | did you look at the debian new maintainer's guide? | 07:14 |
| gnarface | you might have to create that directory by hand, but there's at least documentation on the contents there | 07:14 |
| gnarface | i forget if there's automation | 07:15 |
| paculino | Not recently; I was under the impression that the maintainer guide was about the organizational/bureaucratic aspects | 07:15 |
| gnarface | it leads with that, but technical details start around chapter 6 | 07:15 |
| gnarface | the stuff you want anyway i think starts about there | 07:15 |
| gnarface | you can skip the bureaucratic part if this is just for your personal use | 07:16 |
| gnarface | only other thing i can think of is check git.devuan.org but stick around, someone else here might know more... | 07:17 |
| paculino | I've figured out using dch to get the changelog template started, but that's all from the packaging guide | 07:17 |
| paculino | Thank you | 07:18 |
| paculino | (if anyone finds this in logs later, the url for that chapter is https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.en.html as of 2024) | 07:38 |
| freem | paculino: if the point is only to provide a binary package, then the easier is imo to use `dpkg-deb -b`, but this will require you to know the basics of how a binary package is built. It is quite simple, though, and any developper should be able to deduce all they need from an existing binary package. You will find plenty of those in /var/cache/apt/archives, and you can extract their content with `dpkg-deb -x` or other tooling. In a previous life, I | 08:02 |
| freem | wrote a simple to use script for my colleagues so that we'd just run it, get the binary uploated to a local server, and get the street equipments' computers installed automatically with latest stuff & all. | 08:02 |
| paculino | I have modified octave's .deb a few times. Would this be about the same? | 08:03 |
| paculino | So copying and modifying control and such from random packages is standard practice to get a template? | 08:04 |
| freem | I don't know what is octave's deb, but perhaps. The big lines are that there is both a DEBIAN/ directory which only strictly required file (if not changed) is the `control` file, and the other stuff are an "image" of what dpkg should apply on the target system | 08:05 |
| freem | no | 08:05 |
| freem | I didn't said it is standard. It is an ugly but very quick to do way of doing it | 08:05 |
| freem | it would never be accepted by a distro, notably, for obvious reasons. | 08:06 |
| freem | oh, you could also use cmake's cpack feature! this totally slipped out of my mind, since I never used it | 08:07 |
| freem | but I have to say I doubt my colleagues would have been able to understand how to use it... they had enough troubles installing their IDE, really. | 08:07 |
| freem | so I wrote a script which would babysit them and contains only the strict minimum for things to technically work. With time I improved it to be less ugly, but I would not consider this good, still | 08:08 |
| paculino | I do not expect what I'm doing to make it into any distro. However, why does the start matter for acceptance? If only used as a template, the relevant stuff will be all that remains and will be modified to suit it, will it not? | 08:08 |
| freem | I don't know what are best practices. The guide and documentation are all way too verbose to just get something which works in 5minutes, and reverse engineering a binary to reproduce it was easier | 08:09 |
| freem | easier and faster | 08:09 |
| freem | still, I would not claim it's a good idea, people here might have much better advices to give you. | 08:10 |
| freem | perhaps I just enjoy hacking and NiH too much, after all :D | 08:10 |
| freem | (now, knowing how to do this also allowed me to send a bug and it's fix to trenchbroom's authors, so me be that that was not entirely useless for open source I guess) | 08:12 |
| freem | now that I think about it... back then, I was starting to dislike cmake more than a bit, but not enough yet to just write a makefile or ninja.build. Those days, I think I would just get a script or template of those, instead, which would be cleaner, and possibly easier to use for small pet projects like I do now | 08:13 |
| freem | I honestly think debian's toolchain to build packages is quite complicated, too much for me. It does make sense to have all this stuff to reach debian's quality and portability, I guess, but it's too heavy for small stuff, and is the reason behind the reputation that making a debian package is ultra complicated. | 08:15 |
| paculino | Perhaps it would be useful practice for me another time to make a package for dillo+; the required control file should be quite similar to that for dillo | 08:17 |
| freem | I think it depends on your goal, really | 08:22 |
| freem | sharing what, whith whom, and under which conditions. Even my quick and dirty script was an improvement compared to what we had before, and there was no licence problem since the stuff was only to be installed on devices owned by my company. | 08:23 |
| freem | nothing open source was modified, so licences were obeyed, as far as I know | 08:24 |
| paculino | Well, dillo+ is a fork of dillo, so it already covers license stuff | 08:25 |
| paculino | It would have minimal changes | 08:25 |
| freem | what does this fork brings, btw? Dillo is an interesting project, but hardly usable for most usages sadly | 08:26 |
| paculino | It slightly improves css support, adds gemini/gopher support, and better supports more filetypes | 08:41 |
| freem | nice | 08:41 |
| paculino | Sorry, I didn't notice the message | 08:41 |
| freem | np | 08:41 |
| paculino | I only browse dev1galaxy using it and monocles (on phone) | 08:43 |
| freem | out of curiosity, do you know why it is a fork and not contributed back? | 08:43 |
| rrq | paculino: this one is a good startpoint too https://www.debian.org/doc/manuals/debmake-doc/ | 08:43 |
| paculino | The original website sort-of went MIA for a bit and iirc, that is when dillo-ng was forked. The original dev hasn't done much since afaik | 08:44 |
| paculino | Thank you, rrq | 08:44 |
| freem | ok, thx for info | 08:44 |
| paculino | Oh, coincidentally, I also use dillo for debian wiki (I added the search macro for both the wiki and packages) | 08:45 |
| paculino | https://www.debian.org/doc/manuals/maint-guide/dother.en.html is good as well | 08:52 |
| rrq | as usual the options makes the documentation a bit unfocused | 08:58 |
| rrq | I tend to use dpkg-buildpackage for very ad-hoc packaging, and "gbp buildpackage" for more serious projects | 08:59 |
| rrq | the latter is good for separating "upstream" from the debian packaging | 09:00 |
| rrq | within a git project (separate branches) | 09:00 |
| rrq | but "gbp buildpackage" enforces/requires a more strict upgrade procedure | 09:02 |
| rrq | you can use "dh_make" to generate templates for the debian files | 09:15 |
| al1r4d | freem, "hardly usable", yeah ia gree | 12:37 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!