Re: [gentoo-dev] The status of the 'minor' arches in gentoo
On 17 February 2013 22:46, Anthony G. Basile wrote: > On 02/17/2013 11:03 AM, Agostino Sarubbo wrote: >> >> In the last time I'm helping some other arches (also arches which I have >> no >> interest) because they appears understaffed. >> >> Days ago, I tried to make a virtual machine with qemu, for SH since the >> dev- >> machine[1] is a bit slow; well, I discovered we have no ISO[2] available >> and >> there is no handbook[3] for it. >> >> The same thing is for S390/S390X/M68K/. So how I am able to install one of >> that _supported_ arches if there isn't any sort of guide? >> >> An interesting fact is that we have an handbook for MIPS[4], a declared >> unsupported architecture (does not make sense for me). > > I am supporting mips for the Lemote loongson2f and for the Atheros AR7161. > I'm trying to get my hands on a godson and Stuart will be sending me two > fulongs, which you can add to that list. Don't let the fact that MIPS is a > ~arch fool you. I don't think we should make it a fully supported arch > because of the number of ISA's and ABI's and endiannesses (if such a word > exists). It is impossible to test for all combos which is what stable > should mean. > > So don't even think of dropping MIPS! Just leave it ~arch and I'll give it > love. I agree with you. MIPS is not going away and the reason we only support ~mips is like you said the vast diversity in hardware and software components. But I think nobody said to drop MIPS right? ;) > > As far as the other arches go, I'm interested in: amd64, arm, mips, ppc, > ppc64 and x86. ppc and ppc64 used to lack manpower. They appear to be in a better state now that Agostino is doing mass stabilisations for them, but I am not sure if the packages are actually tested during runtime or they are just tested for build problems. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] The status of the 'minor' arches in gentoo
On 02/17/13 17:03, Agostino Sarubbo wrote: > In the last time I'm helping some other arches (also arches which I have no > interest) because they appears understaffed. > > Days ago, I tried to make a virtual machine with qemu, for SH since the dev- > machine[1] is a bit slow; well, I discovered we have no ISO[2] available and > there is no handbook[3] for it. > > The same thing is for S390/S390X/M68K/. So how I am able to install one of > that _supported_ arches if there isn't any sort of guide? > Like ARM, most SH devices don't have a CDROM drive, so thats why there's no ISO. Like I told you, the way to install onto those kind of machines is either tftpbooting or putting the disk into another machine and configure it from there. I've installed all my ARM and SH machines using the latter. The reason for not having a manual is like ARM, there are specific boards which require different configurations, kernels, bootloaders, etc. Same reason as why there's no ISO, some boards couldn't even boot from the CDROM, and you'll need a kernel for each board, etc... I've always thought that whoever has a SH board, m68k, or access to a s390 machine, and wants to use Gentoo, is smart enough to do it by itself.
Re: [gentoo-dev] The status of the 'minor' arches in gentoo
On Sun, Feb 17, 2013 at 5:03 PM, Agostino Sarubbo wrote: > Now, imho, we have 2 choice: > > 1)Support them with an iso or at least a manual if we can't do an handbook > 2)Lose the stable keyword and don't waste manpower anymore. > > What do you think about? I haven't seen many problems, except one point: that m68k seems to have much the same level of activity as mips, and it would be nice if we could drop it down in the little CC list on Bugzilla (to the unstable arches part). Cheers, Dirkjan
Re: [gentoo-dev] Packages up for grabs due lack of time
Am Samstag, 16. Februar 2013, 14:08:06 schrieb Pacho Ramos: > Due pva lack of time the following packages are now up for grabs: > app-emulation/e-uae > app-emulation/uae AFAIK both are long dead. The current actively developed uae variant is PUAE, but I'd say it is not ready for a wider audience right now. It syncs regularly with WinUAE, but its GUIs are in a bad shape. The configuration documentation is ... well ... lacking at best. The PUAE maintainer, GnoStiC, has only a Mac to develop on. All linux stuff is currently done by me. And I am busy cleaning up code and getting to a state where I can bring the front-ends back into a working state. PUAE: https://github.com/GnoStiC/PUAE My cleanup-branch: https://github.com/Yamakuzure/PUAE Note: We cross-merge. regularly. Most people use an Amiga emulator for some nostalgic gaming only anyway. Therefore it might be a good idea to add fs-uae (gamerlay-stable) to the tree, if there is any need for it. However, if there is a need to keep uae and e-uae, I could proxy maintain both. The code base I am working on is the same after all. And I have plenty of Amiga stuff lying around to test p-uae (Dragons Megademo anyone? ;)) anyway. Cheers Sven signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Packages up for grabs due lack of time
On Mon, Feb 18, 2013 at 6:47 AM, Ryan Hill wrote:
> He means that until you install the package with all firmware enabled you
> don't
> know what lines you need to put into the savedconfig file.
I have posted a snippet previously — you basically search for
"firmware=..." in kernel modules. It's doesn't always work, though —
e.g., it won't with DVB firmware, I think.
> Even after you do that it's hard to figure out what firmware files you
> actually
> need. I know I need iwl6000 firmware for Intel Ultimate-N 6300 wifi, but
> linux-firmware contains:
>
> iwlwifi-6000-4.ucode
> iwlwifi-6000g2a-5.ucode
> iwlwifi-6000g2a-6.ucode
> iwlwifi-6000g2b-5.ucode
> iwlwifi-6000g2b-6.ucode
>
> Are these different versions? Different cards? Which do I need? I had to
> go back and reinstall sys-firmware/iwl6000-ucode to see which file was the
> right one.
iwlwifi is somewhat special, with its multiple versions and
subversions. In this case, 6000{,g2{a,b}} are different cards, and
-[456] are different firmware APIs, with multiple APIs supported by a
given kernel. See, e.g.,
/usr/src/linux/drivers/net/wireless/iwlwifi/iwl-6000.c.
--
Maxim Kammerer
Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] Re: Packages up for grabs due lack of time
Ryan Hill schrieb: > He means that until you install the package with all firmware enabled you > don't > know what lines you need to put into the savedconfig file. > > Even after you do that it's hard to figure out what firmware files you > actually > need. I know I need iwl6000 firmware for Intel Ultimate-N 6300 wifi, but > linux-firmware contains: Sometimes it can be inferred from dmesg output, where the driver outputs which firmware it requested. > Are these different versions? Different cards? Which do I need? I had to > go back and reinstall sys-firmware/iwl6000-ucode to see which file was the > right one. Which exact firmware file you need also depends on your kernel version. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Packages up for grabs due lack of time
On 02/16/2013 08:08 AM, Pacho Ramos wrote: Due pva lack of time the following packages are now up for grabs: net-firewall/xtables-addons (proxy maintained) net-misc/ipv6calc I can take care of these two. I use both. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] Re: Packages up for grabs due lack of time
Le dimanche 17 février 2013 à 22:47 -0600, Ryan Hill a écrit : > Even after you do that it's hard to figure out what firmware files you > actually > need. I know I need iwl6000 firmware for Intel Ultimate-N 6300 wifi, but > linux-firmware contains: > > iwlwifi-6000-4.ucode > iwlwifi-6000g2a-5.ucode > iwlwifi-6000g2a-6.ucode > iwlwifi-6000g2b-5.ucode > iwlwifi-6000g2b-6.ucode > > Are these different versions? Different cards? Which do I need? Good kernel modules *should* export needed firmwares as module parameters. You *should* then be able to query it with modinfo: modinfo -F firmware Note however that *lots* of modules (especially DVB, in my experience) don't properly set those parameters and you're left grepping the source code or dmesg to find which firmware you'll need... Cheers, Rémi
Re: [gentoo-dev] Ebuilds for nodejs apps - HOWTO?
Le lundi 18 février 2013 à 01:39 +0100, Diego Elio Pettenò a écrit : > On 18/02/2013 00:46, Gilles Dartiguelongue wrote: > > rethinkdb is a young project and its build system is a 1.5k lines > > makefile horror. I wouldn't reintroduce stuff that isn't used in tree > > just for this. I, at least, am not interested in moving this to the > > tree. I just added it to my overlay for a testing work stuff and that > > need is gone for now :). > > It was in my TODO anyway as I was asked about it before. I guess I'll > re-introduce it under p.use.mask until it's actually needed. ok then, have fun :) -- Gilles Dartiguelongue Gentoo signature.asc Description: This is a digitally signed message part
[gentoo-dev] RFC: Gentoo GPG key policies
Hi all, I've been asked a couple of times in IRC and other mediums, about what GPG key settings etc to use. I would not not call these final yet, but should be fairly close to final. This was originally intended to be part of the tree-signing GLEP series, but was in one of the unpublished ones (GLEPxx+3 in the references). I guess if there are no major objections to the below, I'll finalize them into the GLEP. This will replace the conflicting information in: http://devmanual.gentoo.org/general-concepts/manifest/index.html http://www.gentoo.org/doc/en/gnupg-user.xml The following is based on: - NIST SP 800-57 recommendations - Debian GPG documentation - RiseUp.net OpenPGP best practices. Bare minimum requirements: -- 1. SHA2-series output digest (SHA1 digests internally permitted). "personal-digest-preferences SHA256" 2. root key & signing subkey of EITHER: 2.1. DSA, 1024 or 2048 bits 2.2. RSA, >=2048 bits 3. Key expiry: 5 years. Recommendations: 1. SHA2-series digest on output & certifications: "personal-digest-preferences SHA256" "cert-digest-algo SHA256" 2. Root key type of RSA, 4096 bits 2.1. This may require creating an entirely new key. 3. Dedicated Gentoo signing subkey of EITHER: 3.1. DSA 2048 bits 3.2. RSA 4096 bits 4. Key expiry: 4.1. Root key: 3 year max. 4.2. Gentoo subkey: 1 year max. 5. Create a revocation certificate & store it hardcopy offsite securely (it's about ~300 bytes). 6. Encrypted backup of your secret keys. 7. In your gpg.conf: # include an unambiguous indicator of which key made a signature: # (see http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234) sig-notation issuer-...@notations.openpgp.fifthhorseman.net=%g Notes/FAQ: -- 1. "Ok, so how do I follow this?" http://ekaia.org/blog/2009/05/10/creating-new-gpgkey/ http://keyring.debian.org/creating-key.html 2. "How can I be really sure/paranoid enough?" https://we.riseup.net/riseuplabs+paow/openpgp-best-practices 3. Every 3-6 months, and/or before key expiry and major keysigning events, you should update your key expiry date with the 'expire' command (remember to do all subkeys). Put it on your calendar! 4. If you intend to sign on a slow alternative-arch, you may find adding a DSA1024 subkey significantly speeds up the signing. 5. Can you give me a full ~/.gnupg/gpg.conf file? === # -- robbat2's recommendations: keyserver pool.sks-keyservers.net emit-version default-recipient-self # -- All of the below portion from the RiseUp.net OpenPGP best practices, and # -- many of them are also in the Debian GPG documentation. # when outputting certificates, view user IDs distinctly from keys: fixed-list-mode # long keyids are more collision-resistant than short keyids (it's trivial to make a key with any desired short keyid) keyid-format 0xlong # when multiple digests are supported by all recipients, choose the strongest one: personal-digest-preferences SHA512 SHA384 SHA256 SHA224 # preferences chosen for new keys should prioritize stronger algorithms: default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 BZIP2 ZLIB ZIP Uncompressed # If you use a graphical environment (and even if you don't) you should be using an agent: # (similar arguments as https://www.debian-administration.org/users/dkg/weblog/64) use-agent # You should always know at a glance which User IDs gpg thinks are legitimately bound to the keys in your keyring: verify-options show-uid-validity list-options show-uid-validity # include an unambiguous indicator of which key made a signature: # (see http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234) sig-notation issuer-...@notations.openpgp.fifthhorseman.net=%g # when making an OpenPGP certification, use a stronger digest than the default SHA1: cert-digest-algo SHA256 === -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Mon, Feb 18, 2013 at 11:27:46PM +, Robin H. Johnson wrote: > 2. root key & signing subkey of EITHER: > 2.1. DSA, 1024 or 2048 bits > 2.2. RSA, >=2048 bits > 3. Key expiry: 5 years. Clarification on reason: These key sizes are the largest supported by many smartcards. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
[gentoo-dev] last rites: games-strategy/freecraft
# Michael Sterrett (18 Feb 2013) # Quite dead. Use games-engines/stratagus instead. # Masked for removal on 20130320. games-strategy/freecraft
Re: [gentoo-dev] RFC: Gentoo GPG key policies
It may be advantageous to have a gentoo wrapper script that calls GPG with recommended settings to make some tasks easier, > gentoo-gpg-create --recommended > EDITOR=vim gentoo-gpg-rotation --recommended --old=DEADBEEF and gentoo-gpg-rotation would make a templated key-expiry document , edited in $EDITOR, and then cross-signed I may even take a stab at this myself once the GLEP is finalised, just curious what people think. -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Tue, Feb 19, 2013 at 04:36:08PM +1300, Kent Fredric wrote: > It may be advantageous to have a gentoo wrapper script that calls GPG > with recommended settings to make some tasks easier, > > gentoo-gpg-create --recommended > > EDITOR=vim gentoo-gpg-rotation --recommended --old=DEADBEEF > and gentoo-gpg-rotation would make a templated key-expiry document , > edited in $EDITOR, and then cross-signed The key rotation as described in RiseUp best practices should be a very rare occurrence. Each dev is going to run it at most once. However, both the creation helper and an expiry update helper would be useful. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
[gentoo-dev] Re: RFC: Gentoo GPG key policies
On Tue, 19 Feb 2013 16:36:08 +1300 Kent Fredric wrote: > It may be advantageous to have a gentoo wrapper script that calls GPG > with recommended settings to make some tasks easier, > > > gentoo-gpg-create --recommended > > EDITOR=vim gentoo-gpg-rotation --recommended --old=DEADBEEF > > and gentoo-gpg-rotation would make a templated key-expiry document , > edited in $EDITOR, and then cross-signed > > I may even take a stab at this myself once the GLEP is finalised, just > curious what people think. I'd use it. -- gcc-porting toolchain, wxwidgetslearn a language baby, it's that kind of place @ gentoo.org where low card is hunger and high card is taste signature.asc Description: PGP signature
[gentoo-dev] Re: The status of the 'minor' arches in gentoo
On Mon, 18 Feb 2013 10:31:41 +0100 Dirkjan Ochtman wrote: > I haven't seen many problems, except one point: that m68k seems to > have much the same level of activity as mips, and it would be nice if > we could drop it down in the little CC list on Bugzilla (to the > unstable arches part). s390 and sh could also be included in that list IMHO. But if their maintainers want to spend their time dealing with stabilization then that's not our call. -- gcc-porting toolchain, wxwidgetslearn a language baby, it's that kind of place @ gentoo.org where low card is hunger and high card is taste signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Tue, 2013-02-19 at 04:09 +, Robin H. Johnson wrote: > On Tue, Feb 19, 2013 at 04:36:08PM +1300, Kent Fredric wrote: > > It may be advantageous to have a gentoo wrapper script that calls GPG > > with recommended settings to make some tasks easier, > > > gentoo-gpg-create --recommended > > > EDITOR=vim gentoo-gpg-rotation --recommended --old=DEADBEEF > > and gentoo-gpg-rotation would make a templated key-expiry document , > > edited in $EDITOR, and then cross-signed > The key rotation as described in RiseUp best practices should be a very > rare occurrence. Each dev is going to run it at most once. > > However, both the creation helper and an expiry update helper would be > useful. > It can be done as part of gkeys from the gentoo-keys project I've started which will be used to manage gpg keys for validating git commits, release media, layman's repositories.xml list, etc... I welcome help in coding it. http://git.overlays.gentoo.org/gitweb/?p=proj/gentoo-keys.git;a=summary http://wiki.gentoo.org/wiki/Project:Gentoo-keys Sadly, I got sidetracked, so haven't gotten much done lately. But am getting back to it again now.
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Mon, Feb 18, 2013 at 11:27:46PM +, Robin H. Johnson wrote: > Bare minimum requirements: > -- [...] > 3. Key expiry: 5 years. I am assuming we are requiring a maximum of 5 years for key expiry. We might want to make it explicit. On first reading, it sounded like key expiry >= 5 years as a bare minimum. Thanks for the write-up. -- Eray Aslan pgpa5Y0CBt3i2.pgp Description: PGP signature
Re: [gentoo-dev] RFC: Gentoo GPG key policies
> The key rotation as described in RiseUp best practices should be a very > rare occurrence. Each dev is going to run it at most once. > Some material I read recommended doing a key rotation every 6 months, which I did for a while until it got tiresome to perform the rotation. I believe the rationale behind it was basically, the longer you use a key, and the more data you produce signed by a key, the more leverage an attacker has against you to compromise the key. But I have no idea if that is really relevant or not. -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
