Nuxified GNU/Linux Help Forums - forum topic - Comments

A solution that will not

reptiler — Fri, 04 Jul 2008 15:17:20 +0200

A solution that will not give you packages that contain what they need, as you actually wanted here, but gives you nice packages that you can install through the package-manager of your system (and thus later remove or replace) might be checkinstall. With this you compile the package yourself and then use checkinstall to build a package out of it. It supports RPM, DPkg and Slackware-packages.

From what I remember also

reptiler — Fri, 04 Jul 2008 15:16:26 +0200

From what I remember also RPM just requires one file. But I have to admit that it's been a while since I last wrote one of those.

The fact that sources are retrieved from where they actually come from really is a nice idea. The disadvantage might be that patches might be missing. Don't know if the program also takes care of that.

I know about checkinstall.

libervisco — Fri, 04 Jul 2008 13:47:00 +0200

I know about checkinstall. It's a great program and I used it quite a few times on Ubuntu/Debian and Slackware.

About the problem with glibc and things like OSS, it's a good point, but then I think the game developer can release a new version of their .run package for a new version of kernel and glibc as it progresses. Really, those two components are what makes up the core of an operating system, Linux + GNU stuff. Also, if the game is freedomware (at least the engine which is enough for this) then anyone could compile and make up a new universal binary like .run for the new versions of kernel and glibc. Besides, games have new versions occassionally too so chances are they'll be keeping up with such significant system changes.

reptiler wrote:

It's not quite the same. With ABS you don't actually have a repository of source files at all, only PKGBUILD files which get the actual source code from wherever they are originally distributed (like Sourceforge, BerliOS etc.). So you don't have specific patches bundled within such packages because there are no packages. If you want to patch it up with something, you just make the PKGBUILD download the patch from some mirror and do the work.

RPM and DEB are still also pretty distro specific, source or not and you therefore at least have different ways of doing the same thing. EDIT: What I mean here is that it breaks this universality which is the goal as every distro ends up having a different set of steps for doing the same thing. If you would have an universally applicable build/packaging system (at least as an add on to the "official" one) you can tell a new GNU/Linux user a single procedure and it'll work on whatever distro he is on. This seems like the kind of thing people screaming for distro unification would like. It doesn't unite all distros into one, just provides a sort of a compatibility layer that connects them all where it really matters most: obtaining software.

Also, if source RPM repositories match the binary RPM repositories it's possible that some source RPM's are still missing and therefore you wouldn't use the same build process for such things and may in fact benefit more from something like PKGBUILD's which instead of specially formatted source packages depend on the actual original source tarballs, which is much more universal. I guess you could create source RPM's and then use the RPM's build process, but I don't quite see the point - why add an extra step? "KISS" seems to apply.

reptiler wrote:

Writing RPM-build-files isn't that hard either.

Well I can't tell as I didn't try it, but I've seen PKGBUILD's and I think they're fairly managable. Also, do you have multiple files necessary for building a source RPM? PKGBUILD is just one file.

Here's an explanation of ABS: http://wiki.archlinux.org/index.php/ABS

And here is also a thread I've started on Arch forums about the idea of making ABS the universal package manager: http://bbs.archlinux.org/viewtopic.php?pid=389398

There's a chance we'll be compiling ABS for other distros.

Cheers

Some points

reptiler — Fri, 04 Jul 2008 07:56:34 +0200

libervisco wrote:

Interestingly there are examples of something like this in practice scattered here and there, like those .run files distributed by certain game developers. They are pretty much distro agnostic.

As nice as these files are (and I agree that they are pretty nice) they will stop working if the ABI (Application Binary Inferface) of GLibC changes in an incompatible way. If this is done in only a few distros that like using recent code, Fedora comes into mind here, then the packages will continue working on distros with older code, like Debian, but not anymore on the ones with newer code. Thus the developers would need to provide another package for these distros, or just tell people that they can forget about playing "Hardcore Shooter 4D Extreme" (TM ) on this specific distro, and sooner or later on any distro, as even distros like Debian in some distant future may evolve to use a newer GLibC.
The same goes for OSS. Commercial games on Linux as far as I know (and I've tried some, including Civilization: Call to Power, Unreal Tournament 2004, Doom3 and a few others, Doom3 being the most recent of those I have tried) use OSS for sound-output. Not that this already gives some problems (at least until KDE3 Arts used to grab the sound-device and lock it, so that other applications could not access it, now this might be the case with PulseAudio, but also some other systems like ESD), but if finally OSS is removed from the kernel, and I actually do see this coming at some point as it's out-dated and I think not even maintained anymore, then these games will also have big problems, no sound-output. OSS is marked "DEPRECATED" in the kernel-config, that means people should not use it anymore, and it will ultimately lead to it's removal, I am pretty sure.
Of course Alsa does offer an OSS-compatibility-layer, but will this always be there? ArtsDSP offers the re-routing of OSS-signals through Arts, and there's something for PulseAudio that does the same, but will those solutions be kept in there forever?
But I guess I'm drifting away too far from the original topic... And actually this is a problem of all binary-packages, just I think that these distro-independent packages of commercial software have the bigger problems here.

libervisco wrote:

Other distros offer something like this too. Fedora and Debian have source-repositories. For Fedora I am pretty sure that in this repository you find SRPM-files, which are source-RPMs, ready to be built and packaged.
I am quite confident when saying that this sounds more or less the same like what you just described for Arch.

libervisco wrote:

Now here's an interesting thought: packaging ABS for other distros. All you need is a PKGBUILD file and you can install anything. The next step in its evolution then might be to become the universal package manager (instead of building stuff locally, it just gets and installs binary tarballs).

Writing RPM-build-files isn't that hard either.

You're not late. There's no

libervisco — Fri, 04 Jul 2008 04:00:00 +0200

You're not late. There's no specific speed at which a thread must move.

You're pointing out some valid problems indeed, which just further underscore how much room there is for improvement here. We could say that prevalent freedomware package management systems are already quite innovative compared to the way this is done in windows, but like many things on freedomware platforms "innovative" often comes with "fragmented" because there are always quite a few parties who want to do it better (as they see it) and so we end up in a kind of dilemma where we are missing compatibility between all these innovative options and yet facing a clear need for some sort of standardization, universalization if not unification.

I think what a_thing described, a synergy, and ideas to that effect, may very well be the way to go. We can hardly expect for major distributions and package management systems to change so drastically as to mold into a single universal packaging system, let alone remove certain limitations such as treating essentially the whole repository of all software as a whole OS.. So we can either patch up these systems with a provision for an alternate way of installing that would actually work, the way a_thing described, or simply have an additional, meta-system of sorts, that applies to just about all distributions - like source tarballs are today (with an obvious disadvantage of having to compile them and look for dependencies yourself).

Interestingly there are examples of something like this in practice scattered here and there, like those .run files distributed by certain game developers. They are pretty much distro agnostic.

The LSB Package API seems like something that would fit that "synergy" vision too, but I'd have to read more on it.

Btw, the problem with having to download the whole package for a minor change of content is, iirc, solved by the Conary package manager which is used by Foresight Linux.

Meanwhile I've switched to Arch and I intend to stick with it. It's come a long way. Arch is interesting to this thread in that in addition to its own package management system (which is fast, simple and pretty powerful), pacman, it also features "ABS" (Arch Build System) which allows you to build your own packages in a rather systematic way. You create PKGBUILD files which are like recipe scripts telling the system what needs to be done and what needs to be acquired to build a particular piece of software. This has a bit of a learning curve, but it's not too complicated. In fact the whole idea of arch is predicated on the "Keep It Simple Silly" principle.

It's, in the end, definitely not THE solution I was looking for in this thread, but at least it provides for a nice (probably best there is) way to use the one type of "packaging" which truly is distro-universal: source code tarballs. ABS is further empowered by the fact that these PKGBUILD's are en masse contributed to the "AUR" repository meaning that most packages you want to build already has a recipe necessary and all you need is use a special tool like "yaourt" to download the recipe and use it to build your package. And you can also modify it in case you wish to change something specific, without writing the whole process on your own. This is how I recently installed a special version of ffmpeg without an option I wanted to disable in order to try something out.

It's similar to gentoo actually, except probably a bit simpler and for being a primary binary distro with the build system benefit.

Here is a result:

libervisco — Wed, 02 Jul 2008 23:09:14 +0200

Here is a result: http://www.libervis.com/files/libervis_logo.ogg

So I now know how to create a GIF animation and convert it to video and add audio to it using only Inkscape, ImageMagick, ffmpeg and PiTiVi.

Once I know the process and have all the commands saved up handy this is actually not a bad way to do videos on GNU/Linux considering the alpha state of most freedomware video editors.

Also, for animations where something specific needs to be done it may actually be easier to do it this way than using a full application.

Cheers

Interesting how after hours

libervisco — Wed, 02 Jul 2008 18:54:00 +0200

Interesting how after hours of searching last night I couldn't quite find the right solution and today I got it with one search query. I guess I just had to search for the right thing...

Anyway, here is the solution:

convert test.gif test%05d.jpg
ffmpeg -r 25 -i test%05d.jpg -y -an test.avi

The first is a command from the ImageMagick suite which converts every frame in a given GIF animation into a JPG file.

The second command takes those JPG's and stitches them into an AVI file. You can also use other extensions like .ogg which will make a nice OGG video.

With -r you can set the framerate to make the video slower or faster.

Yay!

sorry im late to the party

sakuramboo — Wed, 02 Jul 2008 16:57:35 +0200

sorry im late to the party here, but here are my two cents.

there is a difference between a package and an application. in GNU/Linux, they are treated the same and this is the biggest problem with package management. the only thing that needs constant attention are libraries (in terms of packages). as long as the libraries are up to date and all applications utilize those libraries properly, there wont be any problems.

unfortunately, this isnt the case. making programs bundled in a nice little .deb or .rpm is great to get your software out there, and helps in keeping file system integrity. but, if i am updating my system, why must i redownload 5+ gigs of games just to update the rpm package from f8 to an f9 suffix? the two packages are identical, but because one ends in .f8.i386.rpm and the other ends in .f9.i386.rpm, i am supposed to redownload the entire package?

the other cent goes to package maintaining. if i remember correctly, the package for the game Abuse-SDL for fedora is still labeled as for fedora 6 and has never been updated, let alone the bug with shooting behind you fixed. one of the reasons why the developers dont bother with packaging their programs is because there are just WAY too many to make. which is yet another reason for a unified packaging system for third party applications.

so far, i think the best option is coming from the Linux Foundation, the LSB Package API.

http://www.linuxfoundation.org/en/LSB_Package_API

I've asked about this on

libervisco — Tue, 01 Jul 2008 19:16:45 +0200

I've asked about this on CDFreaks and although we didn't make much progress there I think it's pretty evident that the drive is getting faulty. It may work most of the time, as it reads all CD's and probably most of non-traxdata DVDs and can also burn everything, the fact that it can't read burned traxdata DVDs yet another burner can is pretty telling by itself.

And it's not necessarily that it wont read only traxdata DVDs, I just don't have many other brands to test with. It's quite possible it might not be able to read some others too.

Considering that the warranty expired a couple of months ago and I planned on getting a SATA burner anyway, and burners aren't that expensive nowadays I'll probably be buying a new one.

No actually. It wouldn't

libervisco — Sun, 29 Jun 2008 15:38:09 +0200

No actually. It wouldn't read even older Traxdata DVDs which weren't from the same new package I got. They also don't look damaged.

I now even tried in Ubuntu 7.04 (feisty) which is fairly old now, and surprisingly the same thing happens. :S

So I guess my DVD burner is to blame, but.. I don't get it.

Finished

ariadacapo — Sun, 29 Jun 2008 10:07:37 +0200

I have just received the official paper (oooh) from the Préfecture, with our information written in bold underlined capital letters and a signature. Our updated bylaws are now official and the change should be published in the Journal Officiel in the coming month.
[I'm eagerly waiting the time when paper photocopies will give way to PGP-signed, CACert-proofed digital procedures.]

The announcement is here. One last formality at the bank so they know about it, and we will be finished.

Thank you all for your patience.

1. What soundcard

a thing — Sun, 29 Jun 2008 10:03:13 +0200

1. What soundcard specifically are you using?

2. As root, look at /etc/yum.conf and the files in /etc/yum.repos.d/ and delete any text that has to do with Livna. Then just run "rpm -ivh http://rpm.livna.org/livna-release-9.rpm".

individual disk quality

a thing — Sun, 29 Jun 2008 09:23:24 +0200

libervisco wrote:

Especially considering that the same Traxdata media I tried now and had a problem with actually worked alright before.

Do you mean DVDs from the same package? Some damage could have been done (either before or after you got them) to only a select few disks.

Yes, the 2.6.25-kernel was

reptiler — Sun, 29 Jun 2008 05:26:57 +0200

Yes, the 2.6.25-kernel was released after F8, but it comes through the updates. Yes, Fedora is that advanced.

That ISO660 is not listed in filesystems makes you think.
Here's mine:

nodev   sysfs
nodev   rootfs
nodev   bdev
nodev   proc
nodev   cgroup
nodev   cpuset
nodev   binfmt_misc
nodev   debugfs
nodev   securityfs
nodev   sockfs
nodev   usbfs
nodev   pipefs
nodev   anon_inodefs
nodev   futexfs
nodev   tmpfs
nodev   inotifyfs
nodev   devpts
nodev   ramfs
nodev   hugetlbfs
        iso9660
nodev   mqueue
nodev   selinuxfs
        ext3
nodev   fuse
        fuseblk
nodev   fusectl

OK, looks like this is

libervisco — Sun, 29 Jun 2008 05:26:57 +0200

OK, looks like this is happening only with Traxdata DVD-R (16x capable) media. I tried some others and it works, including Traxdata CD-R's, but whichever Traxdata DVD I try it does the same thing, in both Pardus and Debian.

Now, it didn't do this before. Such DVD's worked fine and I'm not sure I burned any Traxdata DVDs while on sid before the one I burned when this first happened on sid so it is still possible that there is a software bug of some sort. It's just weird that it would affect only Traxdata DVD reading (even burning them seems to work). Even if it was a hardware issue it is still weird why only Traxdata.

Especially considering that the same Traxdata media I tried now and had a problem with actually worked alright before. Also, Traxdata are media I generally consider to be of good quality.

So I'm just puzzled. :S