Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

src Organization #5

Closed
RainbowHackerHorse opened this issue Jan 29, 2016 · 10 comments
Closed

src Organization #5

RainbowHackerHorse opened this issue Jan 29, 2016 · 10 comments

Comments

@RainbowHackerHorse
Copy link
Member

Once upstream code mirrors are in place, alter code tarball creation and buildscript to use the new SRC layout directory, in line with the ultimate locations of software on the filesystem.
Example:
src/bin/bash-$version
src/usr/bin/file-$version
src/usr/sbin/portsnag.sh

@ghost
Copy link

ghost commented Jan 29, 2016

i actually have a branch specifically for features to introduce after the mirrors are up, so i'll add this there. should streamline things a lot

@RainbowHackerHorse
Copy link
Member Author

Sounds good, please keep this todo up to date.

@RainbowHackerHorse RainbowHackerHorse changed the title SRC Organization src Organization Jan 29, 2016
@ghost
Copy link

ghost commented Feb 9, 2016

can you spec the hierarchy for where on the filesystem you want things laid out? e.g.

/path/to/filename-version.tar.xz (for the combined src tarball on the pkg mirror/host)

as far as internal tarball hierarchy, from the above, it sounds like you want a single dir to extract ('src'), and then inside there have the destination-structure.

additionally, since we're decompressing the source tarballs and recompressing anyways, what do you think of this? instead of e.g.:

src/bin/bash-$version/

we do:

src/bin/bash/

this way we won't have to edit the build script every time a new upstream source is released. thoughts?

@RainbowHackerHorse
Copy link
Member Author

Works for me.
The script will need to generate a /VERSIONS.txt document stating what versions of each piece of software exist in the tree at any given time the tree is updates, but yeah.

@ghost
Copy link

ghost commented Mar 7, 2016

update per a previous conversation (via irc private message, 02.29.2016 ~0145EST)

pur_src/{core,contrib}

pur_src/core will need to contain sourcedirs:
bash
binutils
bzip2
check
coreutils
dejagnu
diffutils
expect
file
findutils
gawk
gcc
gettext
glibc
gmp
grep
gzip
linux
m4
make
man-db
mpc
mpfr
ncurses
patch
perl
sed
tar
tcl
texinfo
tzdata
util-linux
xz
zlib

i have yet to implement contrib. but...
in pur_src/contrib we need (so far) the sourcedirs:
libressl
ntpsec
rc.subr
rc
zfs

@RainbowHackerHorse
Copy link
Member Author

Sounds good. But we forked rc and rc.subr, so those won't go in contrib.
Otherwise, looks good

@ghost
Copy link

ghost commented Mar 8, 2016

doubletrue. here's what i currently have in contrib:

[pur@archdev ~]$ ls -1 pur_src/contrib/
eudev
libressl
net-tools
ntpsec
versions.txt

cleaning up purbuild.sh to work with the new src tarball layout, but i think i have it licked. i didn't include zfs in contrib because i'm not sure how you want to do that (does it need to patch/build against the kernel sources, if you know?) via issue #15 and hold off on the rc stuff pending issue #13 (and issue #1) but this'll at least give a good alpha i think.
once i get a good src tarball, how do you want that distributed? it might be a good idea for you to do a detached ascii-armored GPG signature (or i can, or we both can, or whatever). i have a .sha256 for it, but that's just for confirming the download. i also have an mtree spec file for the contents of the uncompressed tarball if someone wants to confirm the checksums of the entire source tree for base.

ideally you/we should sign all three of those files (because the more verification we have, the better- see the recent Linux Mint fiasco).

@ghost
Copy link

ghost commented Mar 8, 2016

@RainbowHackerHorse SO!
https://github.com/bts368/Pur-Linux/commit/7c9f46f3492ea3649991efd49a14b495d775e433

review that (especially the purbuild.sh stuff)- just had a successful build of the basic core with it using the newly structured tarball. (note to self- need to move pur_src/base to pur_src/core, "01:48:22 since both are technically base") if you OK, i'll push to CURRENT in the main repo.

the relevant files are:

http://g.rainwreck.com/pur/pur_src.2016.04-RELEASE.tar.xz
http://g.rainwreck.com/pur/pur_src.2016.04-RELEASE.tar.xz.sha256
and, not used in the script (since mtree has a linux port but it isn't in stock repos for almost any distro), but uses a freebsd-compatible mtree format for verification of actual source integrity:
http://g.rainwreck.com/pur/pur_src.2016.04-RELEASE.mtree

these obviously aren't finalized (because no zfs or rc yet), but should give a good working model while those are worked out.

@ghost ghost mentioned this issue Mar 8, 2016
@RainbowHackerHorse
Copy link
Member Author

Go ahead and import into CURRENT.

@ghost
Copy link

ghost commented Mar 20, 2016

src tree established, modifications to the build script implemented (not yet pushed- still undergoing testing of chrooted builds and contrib software)

@ghost ghost closed this as completed Mar 20, 2016
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant