[opensuse-factory] Packaging of Rust compiler.

newer
[opensuse-factory] is this fix in...

Luke Jones

15 Dec 2016 15 Dec '16

22:12

Hi all, I was recently added to the maintainer role for the rust compiler devel project; as rust is something I use daily, I feel I am a good fit for the task. I would now like to raise some discussion about the current state of packaging for Rust. At present the build process is relying on the previous version of Rust being packaged with a naming scheme of 'rustc-1_11' for example, which is used for building the next version of Rust. The issue I have with this is that we will end up with a large amount of previous versions at some point, along with a long list of obsoletes/provides in the spec files. The way I would like to counter this is by; 1. including the bootstrap tarball (for each arch) with the src rpm. 2. use the bootstrap tarballs to build the current compiler version 3. use spec file functionality to choose which tarball arch to use based on the cpu arch being built for. At this point I feel this is the best course of action to prevent future issues, it also has the benefit of the source rpm providing all the needed sources to build that version of Rust, rather than relying on a previously packaged version. It's a little extra work, but would be worth doing. I will get a trial package up in the next few days to see how it goes, then if all is okay and other agree with it, I'll switch over the official rpm build to that. Regards, Luke. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Show replies by date

Kristoffer Grönlund

15 Dec 15 Dec

23:05

Luke Jones writes:

...

Hi all,

I was recently added to the maintainer role for the rust compiler devel project; as rust is something I use daily, I feel I am a good fit for the task.

I would now like to raise some discussion about the current state of packaging for Rust. At present the build process is relying on the previous version of Rust being packaged with a naming scheme of 'rustc-1_11' for example, which is used for building the next version of Rust.

The issue I have with this is that we will end up with a large amount of previous versions at some point, along with a long list of obsoletes/provides in the spec files. The way I would like to counter this is by; 1. including the bootstrap tarball (for each arch) with the src rpm. 2. use the bootstrap tarballs to build the current compiler version 3. use spec file functionality to choose which tarball arch to use based on the cpu arch being built for.

At this point I feel this is the best course of action to prevent future issues, it also has the benefit of the source rpm providing all the needed sources to build that version of Rust, rather than relying on a previously packaged version. It's a little extra work, but would be worth doing.

I will get a trial package up in the next few days to see how it goes, then if all is okay and other agree with it, I'll switch over the official rpm build to that.

I'd say go with that - having to keep all the versions around is terrible and won't work long term, and at least I haven't been able to get any other variant to work. Cheers, Kristoffer

...

Regards, Luke. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-- // Kristoffer Grönlund // kgronlund@suse.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt

16 Dec 16 Dec

10:28

On Friday 2016-12-16 00:05, Kristoffer Grönlund wrote:

...

Luke Jones writes:

...
At present the build process is relying on the previous version of Rust being packaged with a naming scheme of 'rustc-1_11' for example, which is used for building the next version of Rust.

The issue I have with this is that we will end up with a large amount of previous versions at some point[...] [approaches:] 1. including the bootstrap tarball (for each arch) with the src rpm. 2. use the bootstrap tarballs to build the current compiler version 3. use spec file functionality to choose which tarball arch to use based on the cpu arch being built for.

4. Two concurrent versions Steps: When rust N=S+1 comes along: 1. have d:l:r/rustc-S use rustc-S 2. set d:l:r/rustc-N to <useforbuild>no</useforbuild> 3. have d:l:r/rustc-N use rustc-S 4. Create linked package for rustc-N 5. Eliminiate useforbuild in linked package 6. SR rustc S & N to Factory This is more or less the gcc approach, except that gcc has a lot bigger span than +1, because it's not as immature as rust. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Alberto Planas Dominguez

09:10

On Fri, 2016-12-16 at 11:12 +1300, Luke Jones wrote:

...

Hi all,

I was recently added to the maintainer role for the rust compiler devel project; as rust is something I use daily, I feel I am a good fit for the task.

This is really nice. Did you checked what Debian is doing? https://internals.rust-lang.org/t/debian-rust-packaging-policy-draft/44 53 Maybe can be of use to align here. -- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Richard Biener

09:51

On Fri, 16 Dec 2016, Luke Jones wrote:

...

Hi all,

I was recently added to the maintainer role for the rust compiler devel project; as rust is something I use daily, I feel I am a good fit for the task.

I would now like to raise some discussion about the current state of packaging for Rust. At present the build process is relying on the previous version of Rust being packaged with a naming scheme of 'rustc-1_11' for example, which is used for building the next version of Rust.

The issue I have with this is that we will end up with a large amount of previous versions at some point, along with a long list of obsoletes/provides in the spec files. The way I would like to counter this is by; 1. including the bootstrap tarball (for each arch) with the src rpm. 2. use the bootstrap tarballs to build the current compiler version 3. use spec file functionality to choose which tarball arch to use based on the cpu arch being built for.

I think that's the worst thing to do and is going to be rejected by legal review as well I guess. Richard.

...

At this point I feel this is the best course of action to prevent future issues, it also has the benefit of the source rpm providing all the needed sources to build that version of Rust, rather than relying on a previously packaged version. It's a little extra work, but would be worth doing.

I will get a trial package up in the next few days to see how it goes, then if all is okay and other agree with it, I'll switch over the official rpm build to that.

Regards, Luke.

-- Richard Biener SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Richard Biener

11:13

On Fri, 16 Dec 2016, Richard Biener wrote:

...

On Fri, 16 Dec 2016, Luke Jones wrote:

...
Hi all,

I was recently added to the maintainer role for the rust compiler devel project; as rust is something I use daily, I feel I am a good fit for the task.

I would now like to raise some discussion about the current state of packaging for Rust. At present the build process is relying on the previous version of Rust being packaged with a naming scheme of 'rustc-1_11' for example, which is used for building the next version of Rust.

The issue I have with this is that we will end up with a large amount of previous versions at some point, along with a long list of obsoletes/provides in the spec files. The way I would like to counter this is by; 1. including the bootstrap tarball (for each arch) with the src rpm. 2. use the bootstrap tarballs to build the current compiler version 3. use spec file functionality to choose which tarball arch to use based on the cpu arch being built for.

I think that's the worst thing to do and is going to be rejected by legal review as well I guess.

To elaborate a bit I do not see the need to work around the requirement of an existing rust compiler -- in fact we require GCC to built GCC as well. If there is a complication with the Stagings in the Factory build process with regarding to packages having such bootstrap issues and that are not in Ring:0 then it has to be solved there IMHO and not worked around by putting binaries in sources... So I suppose the "easiest" is to put rustc into Ring:0. I see Factory has rustc-stage0 already (containing something that looks like binaries). But that looks like a hack to me -- a better "hack" would be to have an _aggregate in rusts "Ring" aggregating from full Factory (like how we aggregate the initial Ring:0 for bootstrapping). Richard.

...

Richard.

...
At this point I feel this is the best course of action to prevent future issues, it also has the benefit of the source rpm providing all the needed sources to build that version of Rust, rather than relying on a previously packaged version. It's a little extra work, but would be worth doing.

I will get a trial package up in the next few days to see how it goes, then if all is okay and other agree with it, I'll switch over the official rpm build to that.

Regards, Luke.

Kristoffer Grönlund

12:17

Richard Biener writes:

...

On Fri, 16 Dec 2016, Richard Biener wrote:

...
On Fri, 16 Dec 2016, Luke Jones wrote:

...
Hi all,

I was recently added to the maintainer role for the rust compiler devel project; as rust is something I use daily, I feel I am a good fit for the task.

I would now like to raise some discussion about the current state of packaging for Rust. At present the build process is relying on the previous version of Rust being packaged with a naming scheme of 'rustc-1_11' for example, which is used for building the next version of Rust.

The issue I have with this is that we will end up with a large amount of previous versions at some point, along with a long list of obsoletes/provides in the spec files. The way I would like to counter this is by; 1. including the bootstrap tarball (for each arch) with the src rpm. 2. use the bootstrap tarballs to build the current compiler version 3. use spec file functionality to choose which tarball arch to use based on the cpu arch being built for.

I think that's the worst thing to do and is going to be rejected by legal review as well I guess.

To elaborate a bit I do not see the need to work around the requirement of an existing rust compiler -- in fact we require GCC to built GCC as well. If there is a complication with the Stagings in the Factory build process with regarding to packages having such bootstrap issues and that are not in Ring:0 then it has to be solved there IMHO and not worked around by putting binaries in sources...

So I suppose the "easiest" is to put rustc into Ring:0.

I see Factory has rustc-stage0 already (containing something that looks like binaries). But that looks like a hack to me -- a better "hack" would be to have an _aggregate in rusts "Ring" aggregating from full Factory (like how we aggregate the initial Ring:0 for bootstrapping).

The issue here is that there is a need for new stage0 binaries every 6 weeks, because each new version of rust doesn't just need rustc, it needs a specific version of rustc to compile itself. This is like GCC at light speed. Well, that's ONE issue. There are plenty. But I don't want to discourage anyone. Please do help us to work this out :) Cheers, Kristoffer

...

Richard.

...
Richard.

...
At this point I feel this is the best course of action to prevent future issues, it also has the benefit of the source rpm providing all the needed sources to build that version of Rust, rather than relying on a previously packaged version. It's a little extra work, but would be worth doing.

I will get a trial package up in the next few days to see how it goes, then if all is okay and other agree with it, I'll switch over the official rpm build to that.

Regards, Luke.

-- Richard Biener SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-- // Kristoffer Grönlund // kgronlund@suse.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Richard Biener

12:28

On Fri, 16 Dec 2016, Kristoffer Grönlund wrote:

...

Richard Biener writes:

...
On Fri, 16 Dec 2016, Richard Biener wrote:

...
On Fri, 16 Dec 2016, Luke Jones wrote:

...
Hi all,

I was recently added to the maintainer role for the rust compiler devel project; as rust is something I use daily, I feel I am a good fit for the task.

I would now like to raise some discussion about the current state of packaging for Rust. At present the build process is relying on the previous version of Rust being packaged with a naming scheme of 'rustc-1_11' for example, which is used for building the next version of Rust.

The issue I have with this is that we will end up with a large amount of previous versions at some point, along with a long list of obsoletes/provides in the spec files. The way I would like to counter this is by; 1. including the bootstrap tarball (for each arch) with the src rpm. 2. use the bootstrap tarballs to build the current compiler version 3. use spec file functionality to choose which tarball arch to use based on the cpu arch being built for.

I think that's the worst thing to do and is going to be rejected by legal review as well I guess.

To elaborate a bit I do not see the need to work around the requirement of an existing rust compiler -- in fact we require GCC to built GCC as well. If there is a complication with the Stagings in the Factory build process with regarding to packages having such bootstrap issues and that are not in Ring:0 then it has to be solved there IMHO and not worked around by putting binaries in sources...

So I suppose the "easiest" is to put rustc into Ring:0.

I see Factory has rustc-stage0 already (containing something that looks like binaries). But that looks like a hack to me -- a better "hack" would be to have an _aggregate in rusts "Ring" aggregating from full Factory (like how we aggregate the initial Ring:0 for bootstrapping).

The issue here is that there is a need for new stage0 binaries every 6 weeks, because each new version of rust doesn't just need rustc, it needs a specific version of rustc to compile itself. This is like GCC at light speed.

Well, but I hope that rustc compiles rustc+1, no? So you only need to do timely enough updates to never run into the situation that Factory has rustc-5 and you want to update to rustc-7 which can only be compiled by rustc-6. Btw, I would complain _very_ loudly to the rust folks if they are not able to bootstrap with a reasonably older rustc...

...

Well, that's ONE issue. There are plenty. But I don't want to discourage anyone. Please do help us to work this out :)

Maybe it's just too premature to package rust if the language is that unstable ;) As a third party developer programming in Rust I'd be very annoyed in having to change my 1M-line code-base every two weeks because the language is so unstable... Richard.

...

Cheers, Kristoffer

...
Richard.

...
Richard.

...
At this point I feel this is the best course of action to prevent future issues, it also has the benefit of the source rpm providing all the needed sources to build that version of Rust, rather than relying on a previously packaged version. It's a little extra work, but would be worth doing.

I will get a trial package up in the next few days to see how it goes, then if all is okay and other agree with it, I'll switch over the official rpm build to that.

Regards, Luke.

-- Richard Biener SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-- Richard Biener SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)

Stefan Knorr

13:52

Hi Richard,

...

Maybe it's just too premature to package rust if the language is that unstable ;)

This is pretty much unavoidable, since Firefox is going to ship pieces written in Rust soon... (I think they are already using some Rust code Nightlies, eventually those will graduate to become part of stable releases [1].) Stefan. [1] I am not 100% sure about the timeline. I am only sure that Firefox is going to contain a whole bunch of Rust pretty soon. --- . SUSE Linux GmbH. Geschäftsführer: Felix Imendörffer, Jane Smithard, Graham Norton. HRB 21284 (AG Nürnberg). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

İsmail Dönmez

13:59

On 16 Dec 14:52, Stefan Knorr wrote:

...

Hi Richard,

...
Maybe it's just too premature to package rust if the language is that unstable ;)

This is pretty much unavoidable, since Firefox is going to ship pieces written in Rust soon... (I think they are already using some Rust code Nightlies, eventually those will graduate to become part of stable releases [1].)

Stefan.

[1] I am not 100% sure about the timeline. I am only sure that Firefox is going to contain a whole bunch of Rust pretty soon.

Yeah soon is now for gecko master: https://groups.google.com/forum/#!msg/mozilla.dev.platform/Gzwh1IbxvHE/7RlO2... Regards, ismail -- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

H.Merijn Brand

15:51

On Fri, 16 Dec 2016 14:52:49 +0100, Stefan Knorr wrote:

...

Hi Richard,

...
Maybe it's just too premature to package rust if the language is that unstable ;)

This is pretty much unavoidable, since Firefox is going to ship pieces written in Rust soon... (I think they are already using some Rust code Nightlies, eventually those will graduate to become part of stable releases [1].)

Stefan.

[1] I am not 100% sure about the timeline. I am only sure that Firefox is going to contain a whole bunch of Rust pretty soon.

Forgive me if I am off-topic here (ignore me if I am), but this thread motivated me to add rust to my list of CSV performances: http://tux.nl/Talks/CSV6/speed5.html That work is based on "The CSV game" by Ewan Higgs: https://bitbucket.org/ewanhiggs/csv-game but with the focus on different ways to parse in perl I wanted to add rust the same way Ewan did in https://bitbucket.org/ewanhiggs/csv-game/src/0dd4ca3abeb52044bad7ba39ac86694... On TumbleWeed, I don't need to add repositories and I can install and build and run the examples $ rpm -q rust cargo rust-1.10.0-1.2.x86_64 cargo-0.13.0-1.1.x86_64 And all goes as planned. Rust is FAST! :) On openSUSE 13.2 however, if I install rust and cargo from http://download.opensuse.org/repositories/home:/Ledest:/devel/openSUSE_13.2/ on my Linux 3.16.7-53-desktop [openSUSE 13.2 (Harlequin)] HP Z220CMT Xeon(R) CPU E3-1245 V2 @ 3.40GHz/1676(8) x86_64 11913 Mb $ rpm -q cargo rust cargo-0.13.0-3.1.x86_64 rust-1.13.0-1.1.x86_64 None of the examples will build: Text-CSV6/rust-libcsv 504 > cargo build --release Compiling csvreader v0.0.1 (file:///pro/3gl/CPAN/Text-CSV6/rust-libcsv) warning: found non-foreign-function-safe member in struct marked #[repr(C)]: found function pointer with Rust calling convention in foreign module; consider using an `extern` function pointer, #[warn(improper_ctypes)] on by default --> src/main.rs:45:26 | 45 | fn csv_init(parser : *mut CSVParser, opt: u8) -> i64; | ^^^^^^^^^^^^^^ warning: found non-foreign-function-safe member in struct marked #[repr(C)]: found function pointer with Rust calling convention in foreign module; consider using an `extern` function pointer, #[warn(improper_ctypes)] on by default --> src/main.rs:46:26 | 46 | fn csv_parse(parser: *mut CSVParser, buf: *mut u8, buflen : size_t, | ^^^^^^^^^^^^^^ warning: found non-foreign-function-safe member in struct marked #[repr(C)]: found function pointer with Rust calling convention in foreign module; consider using an `extern` function pointer, #[warn(improper_ctypes)] on by default --> src/main.rs:50:25 | 50 | fn csv_free(parser: *mut CSVParser); | ^^^^^^^^^^^^^^ error: linking with `cc` failed: exit code: 1 | = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib" "/pro/3gl/CPAN/Text-CSV6/rust-libcsv/target/release/csvreader.0.o" "-o" "/pro/3gl/CPAN/Text-CSV6/rust-libcsv/target/release/csvreader" "-Wl,--gc-sections" "-pie" "-Wl,-O1" "-nodefaultlibs" "-L" "/pro/3gl/CPAN/Text-CSV6/rust-libcsv/target/release/deps" "-L" "/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "-Wl,-Bdynamic" "-l" "csv" "/tmp/rustc.J38H3uxu8Dpd/libstd-a4729905.rlib" "/tmp/rustc.J38H3uxu8Dpd/liballoc_jemalloc-a4729905.rlib" "/tmp/rustc.J38H3uxu8Dpd/libcompiler_builtins-a4729905.rlib" "-l" "util" "-l" "dl" "-l" "pthread" "-l" "gcc_s" "-l" "pthread" "-l" "c" "-l" "m" "-l" "rt" "-l" "util" = note: /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: jemalloc.pic.o: access beyond end of merged section (1505) /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: jemalloc.pic.o: access beyond end of merged section (2540) /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: jemalloc.pic.o: access beyond end of merged section (3011) /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: jemalloc.pic.o: access beyond end of merged section (2703) : : Text-CSV6/rust-csvreader 506 > cargo build --release Compiling csvreader v0.0.1 (file:///pro/3gl/CPAN/Text-CSV6/rust-csvreader) error: linking with `cc` failed: exit code: 1 | = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib" "/pro/3gl/CPAN/Text-CSV6/rust-csvreader/target/release/csvreader.0.o" "-o" "/pro/3gl/CPAN/Text-CSV6/rust-csvreader/target/release/csvreader" "-Wl,--gc-sections" "-pie" "-Wl,-O1" "-nodefaultlibs" "-L" "/pro/3gl/CPAN/Text-CSV6/rust-csvreader/target/release/deps" "-L" "/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "-Wl,-Bdynamic" "/tmp/rustc.5nlBbtpdguoY/libstd-a4729905.rlib" "/tmp/rustc.5nlBbtpdguoY/liballoc_jemalloc-a4729905.rlib" "/tmp/rustc.5nlBbtpdguoY/libcompiler_builtins-a4729905.rlib" "-l" "dl" "-l" "pthread" "-l" "gcc_s" "-l" "pthread" "-l" "c" "-l" "m" "-l" "rt" "-l" "util" = note: /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: jemalloc.pic.o: access beyond end of merged section (1505) /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: jemalloc.pic.o: access beyond end of merged section (2540) /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: jemalloc.pic.o: access beyond end of merged section (3011) : : : -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.25 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/

Simon Lees

22:32

On 12/17/2016 02:21 AM, H.Merijn Brand wrote:

...

On Fri, 16 Dec 2016 14:52:49 +0100, Stefan Knorr wrote:

...
Hi Richard,

...
Maybe it's just too premature to package rust if the language is that unstable ;)

This is pretty much unavoidable, since Firefox is going to ship pieces written in Rust soon... (I think they are already using some Rust code Nightlies, eventually those will graduate to become part of stable releases [1].)

Stefan.

[1] I am not 100% sure about the timeline. I am only sure that Firefox is going to contain a whole bunch of Rust pretty soon.

Forgive me if I am off-topic here (ignore me if I am), but this thread motivated me to add rust to my list of CSV performances: http://tux.nl/Talks/CSV6/speed5.html

That work is based on "The CSV game" by Ewan Higgs: https://bitbucket.org/ewanhiggs/csv-game but with the focus on different ways to parse in perl

I wanted to add rust the same way Ewan did in https://bitbucket.org/ewanhiggs/csv-game/src/0dd4ca3abeb52044bad7ba39ac86694...

On TumbleWeed, I don't need to add repositories and I can install and build and run the examples

$ rpm -q rust cargo rust-1.10.0-1.2.x86_64 cargo-0.13.0-1.1.x86_64

And all goes as planned. Rust is FAST! :)

On openSUSE 13.2 however, if I install rust and cargo from http://download.opensuse.org/repositories/home:/Ledest:/devel/openSUSE_13.2/ on my Linux 3.16.7-53-desktop [openSUSE 13.2 (Harlequin)] HP Z220CMT Xeon(R) CPU E3-1245 V2 @ 3.40GHz/1676(8) x86_64 11913 Mb

13.2 Goes End of Life next month so i'm not sure how much effort its worth putting into it. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

2694

Age (days ago)

2695

Last active (days ago)

List overview

Download

11 comments

9 participants

participants (9)

Alberto Planas Dominguez
H.Merijn Brand
İsmail Dönmez
Jan Engelhardt
Kristoffer Grönlund
Luke Jones
Richard Biener
Simon Lees
Stefan Knorr