@js@nil.im
@js@nil.im avatar

js

@js@nil.im

That weird dude with the mission to make sure Objective-C works on every platform this planet invented.

This profile is from a federated server and may be incomplete. Browse more on the original instance.

js, to debian
@js@nil.im avatar

I’m trying to create a package for @objfw and it’s really a big mess. I want to have the same structure as on Fedora, which is a meta package that depends on the subpackages. But I cannot find any documentation on how to do that in Debain other than that debian/control should list them all. Ok, that’s easy. But it doesn’t document how to specify which file goes into which package. Nothing. Nada. RPM? Just look for %files, all neatly documented. OK, so after googling around, you find dh_movefiles. Ah, but that’s deprecated! OK, supposedly I need to use dh_install. Let’s look at the documentation of that. Nothing that mentions packages! So in the end, I do trial and error. And just doing dh_install usr/bin/foo foo/usr/bin doesn’t work. But dh_install usr/bin/foo ../foo/usr/bin does! Is that correct or a hack? I don’t know! Debian won’t tell me!

Dear developers. Your entire packaging system seems to be multiple layers of wrappers around old and horrible things, trying to hide them, but without documenting anything. Please get your documentation in order. Have a look at how Fedora and RPM are documented and learn from it.

Also, for the love of god, please consider using some version control system such as Git, so that it becomes easy to see changes, see what other packages did and learn from them. That would have helped me immensely with seeing how other packages solved that Debian’s custom tooling is too old and chokes on binaries generated by clang because of new debug symbols.

I’ve packaged @objfw for all the BSDs, Alpine, ArchLinux, Fedora, OpenIndiana, MSYS2 and many more and no other experience was nearly as bad as Debian.

PS: And in the end, I’m still stuck, because apparently something doesn’t like the Depends: on one of the other packages built from the same source. And I have no idea why. No useful error message or anything.

js,
@js@nil.im avatar

@bugaevc @objfw How so? First there is a Makefile called debian/rules. That by default calls a bunch of dh_* tools. Those call other tools again. And in the end you override stuff in debian/rules to call other dh_* tools again. How is this not layers upon layers to hide legacy?

js,
@js@nil.im avatar

@bugaevc @objfw That’s what I did and it complains that it cannot parse it:

dpkg-gencontrol: Fehler: Pakets »libobjfwrt1-dev« Feld Depends wird ausgewertet: libobjfwrt1 (= 1.1.1-1)

That’s like the most unhelpful error I could expect.

Yes, it’s in German, but that doesn’t even parse as a German sentence.

js,
@js@nil.im avatar

@bugaevc Oops :). I’m so used to people disagreeing with me when I say something bad about software that I misread it and added a “don’t” :flan_XD:.

js,
@js@nil.im avatar

@bugaevc I posted the entire thing here: https://ap.nil.im/notice/AgvAAJyjPnxyRZylJw :)

js,
@js@nil.im avatar

@bugaevc Ah, two swapped lines indeed! Thx! Now it works, but there’s some more other problems.

As for for the soname in theh dev package: I found somewhere on debian.org in the documentation that you should include it but have a Provoides: and Conflicts:.

As for the amount of subpackages, it’s the same way in Fedora. and allows you to use just the tools if you want to. Or just the runtime. Or whatever.

js,
@js@nil.im avatar

@bugaevc Right, there’s so many levels of wrappers that I forgot about half of them :flan_wink:.

js, to random
@js@nil.im avatar

In today’s “ @objfw keeps finding broken OSes and compilers” episode:

Clang likes to forget a variable: https://github.com/llvm/llvm-project/issues/88706
Clang hang in an infinite loop: https://bugzilla.redhat.com/show_bug.cgi?id=2275090

I think I should change the goal for ObjFW and just turn it into a compiler and OS test suite and encourage everybody to include it…

js, to random
@js@nil.im avatar

One of the sad side-effects of the is that many projects feel like they need to move away from , when the problem wasn’t autoconf itself, but shipping a bunch of .m4 files – and that nobody diffed repo vs tarball (if nobody does that, it doesn’t matter what you do in the repo, e.g. switching build systems).

This is sad because it means cross-compiling stuff will soon no longer be possible, as autoconf is so far the only thing that gets cross-compiling right. CMake is a complete mess, Meson is far from great for cross-compiling and everything else just outright doesn’t support it.

People, clean up your configure.ac, get rid of .m4 and audit repo vs. tarball! That’s less work, much more effective and doesn’t kill cross-compiling!

Also, if you absolutely must blame a piece of software that was used by xz for this: That’ll be , which was the reason for the insane amount of .m4 files in the first place. gettext is a mess and that is really something we should get rid of.

lanodan, to random
@lanodan@queer.hacktivis.me avatar

Cross-compiling when autotools
is involved is a fools
errand.

js,
@js@nil.im avatar

@lanodan Hah, you clearly haven’t tried cross-compiling with any of the alternatives!

js,
@js@nil.im avatar

@lanodan That sounds like a problem with the software using autotools and not autotools itself.

You’ll be delighted to hear that everything that isn’t autoconf will basically assume everything once you try cross-compiling.

js,
@js@nil.im avatar

@lanodan Yeah, CMake needs a file describing the target, so does Meson. SCons etc. just outright don’t support cross-compiling. So autoconf is the best hope you have. However, unfortunately, even autoconf won’t help you if people don’t know how to write proper configure scripts. But cross-compiling with autoconf and properly written configure scripts is a breeze.

js,
@js@nil.im avatar

@lanodan A configure script doesn’t guess, it checks. Unless done wrong, of course. But many people just copy-paste some garbage they’ve seen elsewhere.

js,
@js@nil.im avatar

@lanodan I know how to write a clean configure script: https://objfw.nil.im/file?name=configure.ac&ci=trunk

So, yes, I can confidently say the problem is often the user and not the tool.

jwildeboer, to random
@jwildeboer@social.wildeboer.net avatar

People sending me e-mails, me replying to them only to find out that their mailserver is blocking my mailserver for weird reasons, forcing me to reconfigure my mailserver so I can get through with their mailserver which immediately blocks me again for "abusive behaviour". Well, sorry, fan of my blog. You'll never get my reply I guess. Also dear mailbox.org: your laziness wrt throwing blacklists in your server config is excluding small servers. You are NOT helping with decentralising e-mail.

js,
@js@nil.im avatar

@jwildeboer Giving you less than a /64 is not RFC compliant from what I remember. So yes, they are indeed right here that OVH is doing it wrong.

js,
@js@nil.im avatar

@jwildeboer The entire idea of the RFC is that you don’t spam routing tables, block lists etc. by something more fine grained than a /64. That’s why they say a /64 is a user. Would you also complain to Spamhaus is OVH puts you behind NAT and you share an IP with someone sending spam? Because this is basically the IPv6-equivalent of NAT.

js,
@js@nil.im avatar

@jwildeboer According to documentation, you should get a /64 from them anyway? https://help.ovhcloud.com/csm/en-gb-dedicated-servers-network-ipv6?id=kb_article_view&sysparm_article=KB0043764

ncommander, to random
@ncommander@restless.systems avatar

Trying to figure out what to write about illumos is difficult, because for me personally, the entire experience has been pretty terrible from start to finish.

That said, I really don't want to shit on a project that appears to be struggling with commercial support, and frankly, I'm not exactly playing to its strengths.

As I'm using it, its basically still just SVR4 UNIX, and I'm ignoring the advancements based in ZFS, Dtrace, etc.

js,
@js@nil.im avatar

@ncommander @ptribble When you say Illumos, which distribution is that? That’s like saying “I’ve had a bad experience with Linux”.

js,
@js@nil.im avatar

@ncommander @ptribble I can agree on the lack of documentation, but the toolchain is pretty standard? At least in OI. I was actually positively surprised at how their package infrastructure works once I understood how it works, which yeah, required experimentation as there was little to no documentation.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • normalnudes
  • kavyap
  • GTA5RPClips
  • vwfavf
  • DreamBathrooms
  • mdbf
  • magazineikmin
  • Youngstown
  • ngwrru68w68
  • slotface
  • thenastyranch
  • ethstaker
  • khanakhh
  • rosin
  • megavids
  • InstantRegret
  • modclub
  • osvaldo12
  • anitta
  • everett
  • Durango
  • cisconetworking
  • cubers
  • Leos
  • provamag3
  • tacticalgear
  • tester
  • JUstTest
  • All magazines
    •