[opensuse-factory] Packaging of Rust compiler.
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
Luke Jones <luke.nukem.jones@gmail.com> 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
On Friday 2016-12-16 00:05, Kristoffer Grönlund wrote:
Luke Jones <luke.nukem.jones@gmail.com> 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
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
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 <rguenther@suse.de> 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
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.
-- Richard Biener <rguenther@suse.de> 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 <rguenther@suse.de> 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 <rguenther@suse.de> 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
On Fri, 16 Dec 2016, Kristoffer Grönlund wrote:
Richard Biener <rguenther@suse.de> 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 <rguenther@suse.de> 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 <rguenther@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
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
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)
On Fri, 16 Dec 2016 14:52:49 +0100, Stefan Knorr <sknorr@suse.de> 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/
On 12/17/2016 02:21 AM, H.Merijn Brand wrote:
On Fri, 16 Dec 2016 14:52:49 +0100, Stefan Knorr <sknorr@suse.de> 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
participants (9)
-
Alberto Planas Dominguez -
H.Merijn Brand -
İsmail Dönmez -
Jan Engelhardt -
Kristoffer Grönlund -
Luke Jones -
Richard Biener -
Simon Lees -
Stefan Knorr