- This topic has 17 replies, 4 voices, and was last updated Mar 30-10:08 pm by Anonymous.
-
Posts
-
ex_Koo
Just wondering if it is possible to have a software request link in this forum.?
I don’t want to keep asking Stevo as he has a enough to with keeping up with MX.Anonymous
I would prefer to see a nice “howto build it your own $#%@self link” here instead.
Or, at least a fair trade (of expended effort) ~~ seekers would be required to contribute something, in advance of placing a packaging request. Post some howto writeups in Tip-n-Tricks, or chip in toward performing localization translations, or contribute by drafting more complete documentation for the antiX applications…
cyrilus31
@skidoo : I share your point of view but from what I understand sometimes building a package may be tricky/ need powerful hardware. BUT you’re right that would be a good idea.
skidoo
Yes that would be Great idea. I have ask about building packages before but not in the right place.
Would like to know how to build my own packages, would test install then on an old laptop, but build them on my main machine hopefully it is powerful enough.Some links I have found
How to build packages
IntroDebianPackaging
HowToPackageForDebiancyrilus
What do you mean by powerful hardware. How powerful ?- This reply was modified 4 years, 1 month ago by ex_Koo. Reason: edit links
I just build my first deb package with pbuilder. mpd 0.21.5-3
What I did.
Installed = pbuilder debootstrap devscripts
If you don’t like the command line leave now..
After installed run = sudo pbuilder –create
(This command will create a chroot in /var/cache/pbuilder with 3 folders inside /aptcache , build , base.tgz/ this is where building takes place)Before I could build a package I had to download 4 files from debian
/ mpd_0.21.5-3.dsc , mpd_0.21.5.orig.tar.xz , mpd_0.21.5.orig.tar.xz.asc , mpd_0.21.5-3.debian.tar.xz . I saved them all in one folder ~/TestingNow the fun bit.
I typed this command remember to add the files path to the command. I guess the .dsc file like a make file.? After a minute or so it was finish
sudo pbuilder –build /home/koo/Testing/mpd_0.21.5-3.dsc
After you run the build command for the first time a new folder is made in /var/cache/pbuilder/result this is where your finished files will be after the build.
- This reply was modified 4 years, 1 month ago by ex_Koo.
cyrilus31
cyrilus
What do you mean by powerful hardware. How powerful ?source : https://forum.mxlinux.org/viewtopic.php?f=134&t=48635&p=493282#p493282
seaken64
I guess my software needs are few. I haven’t had any software needs that were not already met in antiX. But I know there are a lot more choices out there and some folks get used to certain programs that are not in the antiX repos. I do see antiX as more a DIY type of system. I suspect that one day I will have to learn how to compile my own kernel or other programs. Is learning to “package” software for antiX easier than learning to compile? I’d be happy to contribute once I learn what needs to be done. I would do this for my own systems and then if it works properly I could branch out to share it as a contributor. The last thing we need is poor packaging from some rookie! Ha ha!
Seaken64
Is learning to “package” software for antiX easier than learning to compile?
. . .
I would do this for my own systems and then if it works properly I could branch out to share it as a contributor.That’s where I have landed ~~ packaging for my own system, for machines that I maintain. IMO, someone else should check my code changes, and perform packaging using their signed key if that code is destined for redistribution. At some point, I reread the github TOS and discovered that we are, in fact, permitted to upload compiled binaries there (earlier I had the impression that was not allowed). After reading carefully, the only limitation I noticed was “max 1Gb storage per free-hosted account” but if I upload a .deb there, I consider it to be only intended for betatesters.
For me, “learning the compiling” has been harder than coding. Learning to package, so far, has seemed a lot easier than learning the esoteric intricacies/quirks of the various build helpers (make, automake, qmake). To be fair, the tools and the compiler are VERY verbose & they attempt to tell you exactly what’s wrong when something’s wrong… but I find myself continually websearching, trying to grok the terminology. Example, while attempting to build opensnitch recently, the Go compiler spewed “blablah ‘dep’ not found”. Hahahaha, cruel joke ~~ it _was_ telling me _exactly_ what the problem was. It even displayed the name ‘dep’ inside single quotes… how was I expected to know “dep is the name of a prerequisite Go module and, um, sorry but a package containing that module is not available via debian repos“? Every time the compiler halts with an error, I’ve learned that I should carefully read the output line-by-line, upward from the bottommost line, until I discover the “exact thing” it’s grumbling about, then (usually) websearch to learn whatever this new-to-me “exact thing” is//does//means. Ah, ccache (not a typo) has occasionally been helpful and, thankfully, it usually “just works” silently does the right thing without demanding attention/tweaks.
Packaging? Contrary to, or at least different from, what I have read that others are using and recommending… I have used only the dpkg-buildpackage tool. The other tools may be comparatively faster, or more strict, or more “correct-per-debian-policy”. I clicked the links in the post above and none of those pages look familiar to me. I’ll check my bookmarks, but at the moment I can only recall that the most helpful set of debian packaging guidelines pages I found, they had pink / red page theming. So, [____edited: removed silly joking remark____] various packaging tools are available; use whatever works for you.
All in all, I regard packaging as an unnecessary nuisance ~~ especially for standalone scripted programs ~~ and I’m not singling-out debian packaging. For python projects, the setup.py brings administrivial overhead… as do the “scaffolding”(?) build tool helpers which have become commonplace across various programming languages. They add complexity (learning their quirks and lingo) while claiming to pursue simplicity. No, I don’t have a full grasp of the myriad automake options. I never will, but that doesn’t mean I’ll ever be enthusiastic about using the “simplified” nextgen tools, tools that accommodate only A/B/C fixed set of limited options.
The last thing we need is poor packaging from some rookie!
( shhhh! you’ll frighten the children… )
Well, it’s an Inconvenient Truth ~~ in many instances that’s exactly what we’ve got. “Upstream packagers” are primarily a group of overworked “best effort” volunteers, many of ’em not sufficiently skilled, or not motivated, to understand and to audit the code they are (re)packaging. Worse, nowadays, seems like the most prolific group among the upstream debian camp is the “Debian Gnome Team” (their self-described name, not a term I’ve invented) who are bent on you-know-what (or maybe you don’t, but that’s fodder for a separate topic).
Speaking of “best effort”:
In case you didn’t notice (or noticed but were too polite to jibe)
yeah, I botched (jumped the gun) announcing a not-sufficiently-tested revised version of gksu recently.Skidoo
I,m so sorry that all the information I have added to this post has been totally useless to you. I will now seek information else where.If debhelper picks yer mom up at the laundramat, and debsmoosher takes care of ‘fakeroot’… hey, that’s swell. Use whatever works for you.
Sorry debhelper this mom is dead no pickup for you today.
That windows and game server & forum word (mom , mum).I have compiled mpd from source code before if you have the dependences already installed works well but, if you do not every error in building the code must be downloaded and installed before you can continue the build.
What I would like to know is how are theses files made /mpd.dsc , mpd.orig.tar.xz , mpd.orig.tar.xz.asc , mpd.debian.tar.xz/
mpd-dmo 18 March 2019
- This reply was modified 4 years, 1 month ago by ex_Koo.
- This reply was modified 4 years, 1 month ago by ex_Koo.
Koo, I apologize for having offended you. Honestly, I neither intended to imply “useless” nor “useless to me”. Alien, unfamiliar — my point was to highlight that multiple tools are available, and that I have used only one of those tools (actually, I did peek at pbuilder once), and that I’m painfully aware that I may not be doing things the right/best way (so am probably unfit to attempt “coaching”)…
how are theses files made /mpd.dsc , mpd.orig.tar.xz , mpd.orig.tar.xz.asc , mpd.debian.tar.xz/
mkdir -p /tmp/mympd/debian && mkdir /tmp/med && cd /tmp/mpd
wget https://www.deb-multimedia.org/pool/main/m/mpd-dmo/mpd-dmo_0.19.9.orig.tar.gz
wget https://www.deb-multimedia.org/pool/main/m/mpd-dmo/mpd-dmo_0.21.6-dmo1.debian.tar.xzthen via spacefm, double-click each of those files to extract
then browse to /tmp/mpd-dmo_0.19.9.orig/whateversubdirectory, “copy all”
then paste ’em into /tmp/mympd
then browse to /tmp/mpd-dmo_0.21.6-dmo1.debian/whateversubdirectory/, “copy all”
then paste ’em into /tmp/mympd/debianAt this point, I would “create a waypoint” by browsing to /tmp/mympd, “select all”,
right-click, New}}Archive … and name it something like “mympd_orig.tar.gz”
Copy it away for safekeeping, then
rm -rf /tmp/mpd-dmo_0.19.9.orig && rm -rf /tmp/mpd-dmo_0.21.6-dmo1.debiancd /tmp/mympd/debian
and the command
dpkg-buildpackage -b -us -uc
^—- will generate (if all build dependencies are satisfied, and no errors)
/tmp/mpd-dmo_0.19.9.deb
/tmp/mpd-dmo_0.19.9.changes
/tmp/mpd-dmo_0.19.9.buildinfo {—– only marginally interesting for you|meIf, for some reason you actually want to generate
/tmp/mpd-dmo_0.19.9.dsc {—- really not interesting/useful for you|me
man dpkg-buildpackage and check which different runtime option(s) you might prefer to use.If the build failed, b/c dependencies could not be fullfilled from packages within my current set of repos… at that point, I would probably stop.
For something retrieved from deb-multimedia, if installing the deb-multimedia versions of additional packages is required… might as well “roll the dice” by just enabling their repo and installing their prebuilt .deb
If you are running from a throwaway session (virtualbox, or liveboot and you can elect no save at shutdown), you might install the build-depends packages (any missing, needed packages will be reported in the failed dpkg-buildpackage output, or you can find them listed within the /tmp/mympd/debian/control file)
To change the stated version number of your created .deb file, edit debian/changelog and add a new entry atop the file (or just edit the version and/or date of the topmost existing line. This is what dpkg-buildpackage references (and AFAIK the other deb tools as well) when setting the package filename.
many words above, yet I’m unsure they fully answer your direct question.
Q. “How are these files made?”
A. Although we can create them manually, they were each probably created automatically by runtime options specified for whichever build tool was used to generate the packagefile.————-
To avoid polluting the source directory with build artifacts, we should build from copies placed in a separate directory. After building the .deb, that working directory should be deleted. While repeatedly, wrestling, tweaking toward achieving a successful build, can leave the already-built stuff in place and just edit the one or 3 files there needing attention. Any portions successfully built during prior runs don’t need to be rebuilt each time.
In my workflow, I do not keep these 2 as separate source directories:
/tmp/mpd-dmo_0.21.6-dmo1.orig
/tmp/mpd-dmo_0.21.6-dmo1.debian
If you did keep them separate, or prior to deleting them, you could enter the “…orig” directory
and “select all” then }} NewArchive and choose filename “mpd.orig.tar.xz”Skidoo, I find your replies humorous. Sometimes I break out in laughter! I didn’t understand more than 75% of what you said but I liked the style!
Koo, I’m also sorry if you were offended. I appreciated your questions and I was only wondering if I may someday become competent enough to contribute to building packages for the antiX community. I don’t think Skidoo was being personal. I will probably come back here to this thread and try the tutorial given.
Seaken64
I would prefer to see a nice “howto build it your own $#%@self link” here instead.
Or, at least a fair trade (of expended effort) ~~ seekers would be required to contribute something, in advance of placing a packaging request. Post some howto writeups in Tip-n-Tricks, or chip in toward performing localization translations, or contribute by drafting more complete documentation for the antiX applications…
I ended up here at antiX because I could not get where I wanted to be in Slackware and Vector. I’ve learned more about how linux works from antiX and MX developers and forum contributors in two or three years than I did in 10 years with Slackware. I just found it too hard to learn how to do it myself. I’m feeling more confident now than I ever have that I can learn this stuff. If I can learn to do packaging for antiX I would be pleased. But I’ve never been a coder or developer. So, it might be a stretch. In the meantime I can share what I can here in the forum.
Seaken64
skidoo
Thanks for the info this has been more then hopeful. Not really interested in uploading to a repo just want to learn something new, and have bit of fun and surprise myself more then anything else.
skidoo & seaken64
Don’t worry I have not been offended, sometimes I read more into things then is actually their. And really I would not be where I am today with Linux if it was not for antiX and MX Thanks to a great community.
- This reply was modified 4 years, 1 month ago by ex_Koo.
My walkthrough probably should not have suggested use of /tmp
It’s considered poor practice to use /tmp because it bears world-writable permissions.
Although the further nested subdirectories would be 0755 youruser:youruser,
in the example I posted, the generated debfile and others are output to /tmpAlso, in hindsight, I should have emphasized that none of the steps required elevated permissions.
Not required until the further step, installing the package: “sudo dpkg -i /path/to/mynewpackage.deb”Hmm, what else?
When you inspect an existing debian source package, the debian/compat file contains a single line, a digit. That number indicates which debian release the package is intended for (stretch ~= debian9, buster ~= debian10). If the system you are building the package from is antiX17+debianStable repos as of today, the number declared in the compat file must be 9.
- You must be logged in to reply to this topic.
