FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CRUX > CRUX

 
 
LinkBack Thread Tools
 
Old 06-29-2011, 11:31 AM
Moritz Wilhelmy
 
Default crux-bin: binary packages for crux

Hi folks,

I've been putting this mail off for a long time, but I finally decided
to get some initial toolchain going, and it seems to work quite well so
far.

So this is crux-bin, a little community project that builds binary
packages for crux.

My project goals so far are:

- because the system on the build machine is really lightweight, it
makes it easier to find out about footprint mismatches and missing
dependencies. This is probably the most important for people who don't
actually intend to use my packages. I will report anything that
breaks, be prepared for a flood in the bugtracker

- The obvious: Build binary packages for crux; This is similar to BSD
where ports as well as binary packages are being built. Since crux is
influenced by BSD, why not?
If you're familiar with BSD, you might notice that the directory
hierarchy is similar to the ftp trees of the major BSD distributions.

- A crux-specific source mirror: Most of the source mirrors out there
seem to be for gentoo, which often means they are outdated or certain
files are missing. Since I have to download the source files anyway in
order to build the packages, I decided to download them from the
original website only (which helps finding md5 mismatches, another
side-effect), sort them by ports collection and put them into rsync.

The build isn't automated yet, but I'll hack something together that
will notify me if something breaks and build automated once a day via
cron otherwise. Packages are stripped down to a minimal set after build
to eliminate implicit dependencies. If you want these implicit
dependencies, you can always build from source.
I'll explain the details on demand.

Things that are planned for the future (volunteers?

- A binary package manager.
We have pkg-get, but it's simply not made to play nicely on a lot of
different setups, and requires custom files. crux-bin contains only
ordinary crux packages, because everything else is assumed to be in
the ports tree. Maybe something that integrates nicely with prt-get
by changing the "addcommand" and "makecommand" to default to binary
packages for some few binary packages would be nice.

- There are currently no x86_64 packages. I'm building this in an
lxc-jail on a 32-bit ubuntu (the host system needs to run some old,
32-bit only software) on a spare i7 at work. If anyone wants to help
out, be my guest, although I might wind up with something. I
personally don't use 64-bit crux at all, because I only own 32-bit
machines, so this feels a little pointless..


Thanks to pitillo and sepen for prt-clean and prologic for the offer to
mirror my efforts!

See rsync://crux-bin.wzff.de/ for a list of what's currently there, but
it might still take a while until DNS is in sync.

Note:
This announcement will probably be my only mail regarding crux-bin to
any of the official crux mailing lists since this is an entirely
unofficial community effort that's not really related to the real crux
and I don't want to spam anyone's inbox with emails about a project
spinoff they don't care about, however there is a mailing list at
crux-bin@lists.barfooze.de to which anyone interested can subscribe by
sending a mail to crux-bin+subscribe@lists.barfooze.de.

Best regards,

Moritz
_______________________________________________
CRUX mailing list
CRUX@lists.crux.nu
http://lists.crux.nu/mailman/listinfo/crux
 
Old 06-29-2011, 11:31 AM
Moritz Wilhelmy
 
Default crux-bin: binary packages for crux

Hi folks,

I've been putting this mail off for a long time, but I finally decided
to get some initial toolchain going, and it seems to work quite well so
far.

So this is crux-bin, a little community project that builds binary
packages for crux.

My project goals so far are:

- because the system on the build machine is really lightweight, it
makes it easier to find out about footprint mismatches and missing
dependencies. This is probably the most important for people who don't
actually intend to use my packages. I will report anything that
breaks, be prepared for a flood in the bugtracker

- The obvious: Build binary packages for crux; This is similar to BSD
where ports as well as binary packages are being built. Since crux is
influenced by BSD, why not?
If you're familiar with BSD, you might notice that the directory
hierarchy is similar to the ftp trees of the major BSD distributions.

- A crux-specific source mirror: Most of the source mirrors out there
seem to be for gentoo, which often means they are outdated or certain
files are missing. Since I have to download the source files anyway in
order to build the packages, I decided to download them from the
original website only (which helps finding md5 mismatches, another
side-effect), sort them by ports collection and put them into rsync.

The build isn't automated yet, but I'll hack something together that
will notify me if something breaks and build automated once a day via
cron otherwise. Packages are stripped down to a minimal set after build
to eliminate implicit dependencies. If you want these implicit
dependencies, you can always build from source.
I'll explain the details on demand.

Things that are planned for the future (volunteers?

- A binary package manager.
We have pkg-get, but it's simply not made to play nicely on a lot of
different setups, and requires custom files. crux-bin contains only
ordinary crux packages, because everything else is assumed to be in
the ports tree. Maybe something that integrates nicely with prt-get
by changing the "addcommand" and "makecommand" to default to binary
packages for some few binary packages would be nice.

- There are currently no x86_64 packages. I'm building this in an
lxc-jail on a 32-bit ubuntu (the host system needs to run some old,
32-bit only software) on a spare i7 at work. If anyone wants to help
out, be my guest, although I might wind up with something. I
personally don't use 64-bit crux at all, because I only own 32-bit
machines, so this feels a little pointless..


Thanks to pitillo and sepen for prt-clean and prologic for the offer to
mirror my efforts!

See rsync://crux-bin.wzff.de/ for a list of what's currently there, but
it might still take a while until DNS is in sync.

Note:
This announcement will probably be my only mail regarding crux-bin to
any of the official crux mailing lists since this is an entirely
unofficial community effort that's not really related to the real crux
and I don't want to spam anyone's inbox with emails about a project
spinoff they don't care about, however there is a mailing list at
crux-bin@lists.barfooze.de to which anyone interested can subscribe by
sending a mail to crux-bin+subscribe@lists.barfooze.de.

Best regards,

Moritz
_______________________________________________
CRUX mailing list
CRUX@lists.crux.nu
http://lists.crux.nu/mailman/listinfo/crux
 
Old 06-29-2011, 04:05 PM
Chris Bolton
 
Default crux-bin: binary packages for crux

I've actually been wanting to work on my own package manager for awhile.. might be interested

On Wed, Jun 29, 2011 at 4:31 AM, Moritz Wilhelmy <ml+crux@barfooze.de> wrote:

Hi folks,



I've been putting this mail off for a long time, but I finally decided

to get some initial toolchain going, and it seems to work quite well so

far.



So this is crux-bin, a little community project that builds binary

packages for crux.



My project goals so far are:



- because the system on the build machine is really lightweight, it

*makes it easier to find out about footprint mismatches and missing

*dependencies. This is probably the most important for people who don't

*actually intend to use my packages. I will report anything that

*breaks, be prepared for a flood in the bugtracker



- The obvious: Build binary packages for crux; This is similar to BSD

*where ports as well as binary packages are being built. Since crux is

*influenced by BSD, why not?

*If you're familiar with BSD, you might notice that the directory

*hierarchy is similar to the ftp trees of the major BSD distributions.



- A crux-specific source mirror: Most of the source mirrors out there

*seem to be for gentoo, which often means they are outdated or certain

*files are missing. Since I have to download the source files anyway in

*order to build the packages, I decided to download them from the

*original website only (which helps finding md5 mismatches, another

*side-effect), sort them by ports collection and put them into rsync.



The build isn't automated yet, but I'll hack something together that

will notify me if something breaks and build automated once a day via

cron otherwise. Packages are stripped down to a minimal set after build

to eliminate implicit dependencies. If you want these implicit

dependencies, you can always build from source.

I'll explain the details on demand.



Things that are planned for the future (volunteers?



- A binary package manager.

*We have pkg-get, but it's simply not made to play nicely on a lot of

*different setups, and requires custom files. crux-bin contains only

*ordinary crux packages, because everything else is assumed to be in

*the ports tree. Maybe something that integrates nicely with prt-get

*by changing the "addcommand" and "makecommand" to default to binary

*packages for some few binary packages would be nice.



- There are currently no x86_64 packages. I'm building this in an

*lxc-jail on a 32-bit ubuntu (the host system needs to run some old,

*32-bit only software) on a spare i7 at work. If anyone wants to help

*out, be my guest, although I might wind up with something. I

*personally don't use 64-bit crux at all, because I only own 32-bit

*machines, so this feels a little pointless..





Thanks to pitillo and sepen for prt-clean and prologic for the offer to

mirror my efforts!



See rsync://crux-bin.wzff.de/ for a list of what's currently there, but

it might still take a while until DNS is in sync.



Note:

This announcement will probably be my only mail regarding crux-bin to

any of the official crux mailing lists since this is an entirely

unofficial community effort that's not really related to the real crux

and I don't want to spam anyone's inbox with emails about a project

spinoff they don't care about, however there is a mailing list at

crux-bin@lists.barfooze.de to which anyone interested can subscribe by

sending a mail to crux-bin+subscribe@lists.barfooze.de.



Best regards,



Moritz

_______________________________________________

CRUX mailing list

CRUX@lists.crux.nu

http://lists.crux.nu/mailman/listinfo/crux



_______________________________________________
CRUX mailing list
CRUX@lists.crux.nu
http://lists.crux.nu/mailman/listinfo/crux
 
Old 06-29-2011, 04:05 PM
Chris Bolton
 
Default crux-bin: binary packages for crux

I've actually been wanting to work on my own package manager for awhile.. might be interested

On Wed, Jun 29, 2011 at 4:31 AM, Moritz Wilhelmy <ml+crux@barfooze.de> wrote:

Hi folks,



I've been putting this mail off for a long time, but I finally decided

to get some initial toolchain going, and it seems to work quite well so

far.



So this is crux-bin, a little community project that builds binary

packages for crux.



My project goals so far are:



- because the system on the build machine is really lightweight, it

*makes it easier to find out about footprint mismatches and missing

*dependencies. This is probably the most important for people who don't

*actually intend to use my packages. I will report anything that

*breaks, be prepared for a flood in the bugtracker



- The obvious: Build binary packages for crux; This is similar to BSD

*where ports as well as binary packages are being built. Since crux is

*influenced by BSD, why not?

*If you're familiar with BSD, you might notice that the directory

*hierarchy is similar to the ftp trees of the major BSD distributions.



- A crux-specific source mirror: Most of the source mirrors out there

*seem to be for gentoo, which often means they are outdated or certain

*files are missing. Since I have to download the source files anyway in

*order to build the packages, I decided to download them from the

*original website only (which helps finding md5 mismatches, another

*side-effect), sort them by ports collection and put them into rsync.



The build isn't automated yet, but I'll hack something together that

will notify me if something breaks and build automated once a day via

cron otherwise. Packages are stripped down to a minimal set after build

to eliminate implicit dependencies. If you want these implicit

dependencies, you can always build from source.

I'll explain the details on demand.



Things that are planned for the future (volunteers?



- A binary package manager.

*We have pkg-get, but it's simply not made to play nicely on a lot of

*different setups, and requires custom files. crux-bin contains only

*ordinary crux packages, because everything else is assumed to be in

*the ports tree. Maybe something that integrates nicely with prt-get

*by changing the "addcommand" and "makecommand" to default to binary

*packages for some few binary packages would be nice.



- There are currently no x86_64 packages. I'm building this in an

*lxc-jail on a 32-bit ubuntu (the host system needs to run some old,

*32-bit only software) on a spare i7 at work. If anyone wants to help

*out, be my guest, although I might wind up with something. I

*personally don't use 64-bit crux at all, because I only own 32-bit

*machines, so this feels a little pointless..





Thanks to pitillo and sepen for prt-clean and prologic for the offer to

mirror my efforts!



See rsync://crux-bin.wzff.de/ for a list of what's currently there, but

it might still take a while until DNS is in sync.



Note:

This announcement will probably be my only mail regarding crux-bin to

any of the official crux mailing lists since this is an entirely

unofficial community effort that's not really related to the real crux

and I don't want to spam anyone's inbox with emails about a project

spinoff they don't care about, however there is a mailing list at

crux-bin@lists.barfooze.de to which anyone interested can subscribe by

sending a mail to crux-bin+subscribe@lists.barfooze.de.



Best regards,



Moritz

_______________________________________________

CRUX mailing list

CRUX@lists.crux.nu

http://lists.crux.nu/mailman/listinfo/crux



_______________________________________________
CRUX mailing list
CRUX@lists.crux.nu
http://lists.crux.nu/mailman/listinfo/crux
 
Old 06-29-2011, 06:00 PM
Jose V Beneyto
 
Default crux-bin: binary packages for crux

Hi,



On 06/29/11 18:05, Chris Bolton wrote:
I've actually been wanting to work on my own package
manager for awhile.. might be interested




maybe you should take a look of pkg-get(8) first.



On Wed, Jun 29, 2011 at 4:31 AM, Moritz
Wilhelmy <ml+crux@barfooze.de>
wrote:


[...]

- because the system on the build machine is really
lightweight, it

*makes it easier to find out about footprint mismatches and
missing

*dependencies. This is probably the most important for people
who don't

*actually intend to use my packages. I will report anything
that

*breaks, be prepared for a flood in the bugtracker



- The obvious: Build binary packages for crux; This is similar
to BSD

*where ports as well as binary packages are being built. Since
crux is

*influenced by BSD, why not?

*If you're familiar with BSD, you might notice that the
directory

*hierarchy is similar to the ftp trees of the major BSD
distributions.



[...]






Well, did you think about the problems between build-dependencies
and runtime-dependencies? so you should take care about the number
of packages will be listed as dependencies, and also note that most
-mature- binary package managers like apt-get, yum, etc. are plenty
of options and switches to select which dependencies, versions or
flavours (-cli, -gui, -fbdev, etc.) for the same package to install.



I think that working with deps it's not as easy, for example:



1. you have a package 'foo' that depends on 'bar'

2. 'bar' size is 100MB and contains some binaries, libraries,
pixmaps, config files, misc docs and also library headers

3. What to do?

*** a) listed 'bar' as a dep and split them:* bar-headers, bar-libs,
bar (depends on bar-headers and bar-libs)

*** b) listed 'bar' as a dep

* * c) ?

4. What about when 'bar' changed their build dependencies? should
you update them to?

5. Could you imagine the same scenario for a complete and large
deptree of a package like smplayer which depends on qt4, mplayer,
etc.

6. Do you think that the complete system will be easily
maintainable?



IMHO is it not as easy, so the problem appears when you should
decide between build or runtime dependencies and that should be
solved as first.






- A binary package manager.

*We have pkg-get, but it's simply not made to play nicely on a
lot of

*different setups, and requires custom files. crux-bin
contains only

*ordinary crux packages,




What means ordinary packages for you?



because everything else is assumed to be
in

*the ports tree. Maybe something that integrates nicely with
prt-get

*by changing the "addcommand" and "makecommand" to default to
binary

*packages for some few binary packages would be nice.






In the past I wrote a mail [1] talking about the use of prt-get as a
package manager also for generated packages living in
$PKGMK_PACKAGE_DIR, but to do the trick you'll need ports (always
uptodate) + prt-get



I wrote that mail because I used to recycle my own build packages
and shared them (via nfs) for an old laptop in which compile was
completely discarded, but nowadays I think that most hardware are
ready to use prt-get directly to build your own packages with the
buildtime dependencies you have installed previously, and most
important, with your own CFLAGS to optimize packages



IMHO the idea to have a binary repository with non-optimized
packages it's fine for installations, but it's hard to maintain for
more than the core collection, anyways I'm glad that people look for
ideas to try to improve things, thanks.





[1] http://lists.crux.nu/pipermail/crux-devel/2008-June/003554.html
(excuse my bad english explanation ;D)





Best regards,

--
Jose V Beneyto | http://sepen.mine.nu


_______________________________________________
CRUX mailing list
CRUX@lists.crux.nu
http://lists.crux.nu/mailman/listinfo/crux
 
Old 06-29-2011, 07:51 PM
James Mills
 
Default crux-bin: binary packages for crux

Hey,
Just a quick note to say that I wouldmore likely participate in this projectif you moved the mailing list over toGoogle Groups (or something).


Recently I*unsubscribed*myself frommany mailing lists as I simply don't havethe time to sit there going through my(what was)*enormous*inbox
cheers

James
James Mills

Director | Short Circuit Services Pty Ltd
james.mills@shortcircuit.net.au*|*shortcircuit.net .au


Mobile: 0488 33 44 81



On Wed, Jun 29, 2011 at 21:31, Moritz Wilhelmy <ml+crux@barfooze.de> wrote:


Hi folks,



I've been putting this mail off for a long time, but I finally decided

to get some initial toolchain going, and it seems to work quite well so

far.



So this is crux-bin, a little community project that builds binary

packages for crux.



My project goals so far are:



- because the system on the build machine is really lightweight, it

*makes it easier to find out about footprint mismatches and missing

*dependencies. This is probably the most important for people who don't

*actually intend to use my packages. I will report anything that

*breaks, be prepared for a flood in the bugtracker



- The obvious: Build binary packages for crux; This is similar to BSD

*where ports as well as binary packages are being built. Since crux is

*influenced by BSD, why not?

*If you're familiar with BSD, you might notice that the directory

*hierarchy is similar to the ftp trees of the major BSD distributions.



- A crux-specific source mirror: Most of the source mirrors out there

*seem to be for gentoo, which often means they are outdated or certain

*files are missing. Since I have to download the source files anyway in

*order to build the packages, I decided to download them from the

*original website only (which helps finding md5 mismatches, another

*side-effect), sort them by ports collection and put them into rsync.



The build isn't automated yet, but I'll hack something together that

will notify me if something breaks and build automated once a day via

cron otherwise. Packages are stripped down to a minimal set after build

to eliminate implicit dependencies. If you want these implicit

dependencies, you can always build from source.

I'll explain the details on demand.



Things that are planned for the future (volunteers?



- A binary package manager.

*We have pkg-get, but it's simply not made to play nicely on a lot of

*different setups, and requires custom files. crux-bin contains only

*ordinary crux packages, because everything else is assumed to be in

*the ports tree. Maybe something that integrates nicely with prt-get

*by changing the "addcommand" and "makecommand" to default to binary

*packages for some few binary packages would be nice.



- There are currently no x86_64 packages. I'm building this in an

*lxc-jail on a 32-bit ubuntu (the host system needs to run some old,

*32-bit only software) on a spare i7 at work. If anyone wants to help

*out, be my guest, although I might wind up with something. I

*personally don't use 64-bit crux at all, because I only own 32-bit

*machines, so this feels a little pointless..





Thanks to pitillo and sepen for prt-clean and prologic for the offer to

mirror my efforts!



See rsync://crux-bin.wzff.de/ for a list of what's currently there, but

it might still take a while until DNS is in sync.



Note:

This announcement will probably be my only mail regarding crux-bin to

any of the official crux mailing lists since this is an entirely

unofficial community effort that's not really related to the real crux

and I don't want to spam anyone's inbox with emails about a project

spinoff they don't care about, however there is a mailing list at

crux-bin@lists.barfooze.de to which anyone interested can subscribe by

sending a mail to crux-bin+subscribe@lists.barfooze.de.



Best regards,



Moritz

_______________________________________________

CRUX mailing list

CRUX@lists.crux.nu

http://lists.crux.nu/mailman/listinfo/crux



_______________________________________________
CRUX mailing list
CRUX@lists.crux.nu
http://lists.crux.nu/mailman/listinfo/crux
 
Old 06-29-2011, 07:51 PM
James Mills
 
Default crux-bin: binary packages for crux

Hey,
Just a quick note to say that I wouldmore likely participate in this projectif you moved the mailing list over toGoogle Groups (or something).


Recently I*unsubscribed*myself frommany mailing lists as I simply don't havethe time to sit there going through my(what was)*enormous*inbox
cheers

James
James Mills

Director | Short Circuit Services Pty Ltd
james.mills@shortcircuit.net.au*|*shortcircuit.net .au


Mobile: 0488 33 44 81



On Wed, Jun 29, 2011 at 21:31, Moritz Wilhelmy <ml+crux@barfooze.de> wrote:


Hi folks,



I've been putting this mail off for a long time, but I finally decided

to get some initial toolchain going, and it seems to work quite well so

far.



So this is crux-bin, a little community project that builds binary

packages for crux.



My project goals so far are:



- because the system on the build machine is really lightweight, it

*makes it easier to find out about footprint mismatches and missing

*dependencies. This is probably the most important for people who don't

*actually intend to use my packages. I will report anything that

*breaks, be prepared for a flood in the bugtracker



- The obvious: Build binary packages for crux; This is similar to BSD

*where ports as well as binary packages are being built. Since crux is

*influenced by BSD, why not?

*If you're familiar with BSD, you might notice that the directory

*hierarchy is similar to the ftp trees of the major BSD distributions.



- A crux-specific source mirror: Most of the source mirrors out there

*seem to be for gentoo, which often means they are outdated or certain

*files are missing. Since I have to download the source files anyway in

*order to build the packages, I decided to download them from the

*original website only (which helps finding md5 mismatches, another

*side-effect), sort them by ports collection and put them into rsync.



The build isn't automated yet, but I'll hack something together that

will notify me if something breaks and build automated once a day via

cron otherwise. Packages are stripped down to a minimal set after build

to eliminate implicit dependencies. If you want these implicit

dependencies, you can always build from source.

I'll explain the details on demand.



Things that are planned for the future (volunteers?



- A binary package manager.

*We have pkg-get, but it's simply not made to play nicely on a lot of

*different setups, and requires custom files. crux-bin contains only

*ordinary crux packages, because everything else is assumed to be in

*the ports tree. Maybe something that integrates nicely with prt-get

*by changing the "addcommand" and "makecommand" to default to binary

*packages for some few binary packages would be nice.



- There are currently no x86_64 packages. I'm building this in an

*lxc-jail on a 32-bit ubuntu (the host system needs to run some old,

*32-bit only software) on a spare i7 at work. If anyone wants to help

*out, be my guest, although I might wind up with something. I

*personally don't use 64-bit crux at all, because I only own 32-bit

*machines, so this feels a little pointless..





Thanks to pitillo and sepen for prt-clean and prologic for the offer to

mirror my efforts!



See rsync://crux-bin.wzff.de/ for a list of what's currently there, but

it might still take a while until DNS is in sync.



Note:

This announcement will probably be my only mail regarding crux-bin to

any of the official crux mailing lists since this is an entirely

unofficial community effort that's not really related to the real crux

and I don't want to spam anyone's inbox with emails about a project

spinoff they don't care about, however there is a mailing list at

crux-bin@lists.barfooze.de to which anyone interested can subscribe by

sending a mail to crux-bin+subscribe@lists.barfooze.de.



Best regards,



Moritz

_______________________________________________

CRUX mailing list

CRUX@lists.crux.nu

http://lists.crux.nu/mailman/listinfo/crux



_______________________________________________
CRUX mailing list
CRUX@lists.crux.nu
http://lists.crux.nu/mailman/listinfo/crux
 
Old 08-19-2011, 05:06 PM
Moritz Wilhelmy
 
Default crux-bin: binary packages for crux

Hello,

I just wanted to inform you that there is a website now at
http://crux-bin.wzff.de:8080/ (Sorry, can't run it on port 80 for now).
Since pkgutils don't support downloading via rsync (yet? was this ever
planned?), this might make the distfiles section more interesting.
FTP is not planned for now.

Best regards,

Moritz
_______________________________________________
CRUX mailing list
CRUX@lists.crux.nu
http://lists.crux.nu/mailman/listinfo/crux
 

Thread Tools




All times are GMT. The time now is 07:08 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org