Re: grubby - /boot on btrfs support

[Nathaniel McCallum]

I have created an update for F27 which contains this feature:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-badf6d0f9e

Testing is more than welcome!

On Fri, Mar 9, 2018 at 2:43 PM, Nathaniel McCallum <npmccal...@redhat.com>
wrote:

> Thomasz, could you please leave karma on the bodhi update?
>
> https://bodhi.fedoraproject.org/updates/grubby-8.40-10.fc28
>
> I already have a patch against anaconda.
>
> https://github.com/rhinstaller/anaconda/pull/1375
>
> On Fri, Mar 9, 2018 at 4:04 AM, Tomasz Kłoczko <kloczko.tom...@gmail.com>
> wrote:
>
>> On 7 March 2018 at 04:12, Nathaniel McCallum <npmccal...@redhat.com>
>> wrote:
>> >
>> > https://bodhi.fedoraproject.org/updates/grubby-8.40-10.fc28
>> >
>> > We've built grubby with support for /boot on btrfs. We're trying to
>> > land this in F28. But we need testers. That's where you come in! If
>> > you ever interact with grubby and especially if you have an exotic
>> > grub2 setup, please download and test this release. As usual provide
>> > feedback in Bodhi (link at the top of this email). Thanks!
>>
>> Just tested new grubby on two systems. Here is my subvols layout from one
>> of those systems (my laptop):
>>
>> # btrfs subvolume list -R /
>> ID 257 gen 1381846 top level 5 received_uuid -
>>  path root
>> ID 535 gen 1381846 top level 257 received_uuid -
>>path var
>> ID 536 gen 1376990 top level 257 received_uuid -
>>path home
>> ID 537 gen 1381838 top level 257 received_uuid -
>>path boot
>> ID 746 gen 1381846 top level 535 received_uuid -
>>path var/lib/mysql
>> ID 1287 gen 1364400 top level 535 received_uuid -
>>path var/lib/machines
>> ID 1325 gen 1381846 top level 536 received_uuid -
>>path home/tkloczko
>> ID 1326 gen 1381756 top level 1325 received_uuid -
>>  path home/tkloczko/git
>> ID 1327 gen 1381846 top level 1326 received_uuid -
>>  path home/tkloczko/git/fedora
>> ID 1328 gen 1381756 top level 1326 received_uuid -
>>  path home/tkloczko/git/linux-git
>> ID 1329 gen 1380131 top level 1325 received_uuid -
>>  path home/tkloczko/src-packages
>> ID 1331 gen 1381807 top level 1329 received_uuid -
>>  path home/tkloczko/src-packages/fedora
>> ID 1332 gen 1381082 top level 1329 received_uuid -
>>  path home/tkloczko/src-packages/suse
>> ID 1333 gen 1381554 top level 1329 received_uuid -
>>  path home/tkloczko/src-packages/altlinux
>> ID 1334 gen 1380955 top level 1329 received_uuid -
>>  path home/tkloczko/src-packages/centos
>> ID 1335 gen 1381188 top level 1329 received_uuid -
>>  path home/tkloczko/src-packages/mageia
>> ID 1336 gen 1381748 top level 1329 received_uuid -
>>  path home/tkloczko/src-packages/debian
>>
>> Looks like it works.
>> On the second system, I have no separated /boot and grub2.cfg has been
>> updated correctly as well.
>> Good job 
>> Now it would be good to remove from anaconda blocking use btrfs on roofs
>> as well 
>>
>> kloczek
>> --
>> Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>
>>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: grubby - /boot on btrfs support

[Nathaniel McCallum]

Thomasz, could you please leave karma on the bodhi update?

https://bodhi.fedoraproject.org/updates/grubby-8.40-10.fc28

I already have a patch against anaconda.

https://github.com/rhinstaller/anaconda/pull/1375

On Fri, Mar 9, 2018 at 4:04 AM, Tomasz Kłoczko <kloczko.tom...@gmail.com>
wrote:

> On 7 March 2018 at 04:12, Nathaniel McCallum <npmccal...@redhat.com>
> wrote:
> >
> > https://bodhi.fedoraproject.org/updates/grubby-8.40-10.fc28
> >
> > We've built grubby with support for /boot on btrfs. We're trying to
> > land this in F28. But we need testers. That's where you come in! If
> > you ever interact with grubby and especially if you have an exotic
> > grub2 setup, please download and test this release. As usual provide
> > feedback in Bodhi (link at the top of this email). Thanks!
>
> Just tested new grubby on two systems. Here is my subvols layout from one
> of those systems (my laptop):
>
> # btrfs subvolume list -R /
> ID 257 gen 1381846 top level 5 received_uuid -
>path root
> ID 535 gen 1381846 top level 257 received_uuid -
>  path var
> ID 536 gen 1376990 top level 257 received_uuid -
>  path home
> ID 537 gen 1381838 top level 257 received_uuid -
>  path boot
> ID 746 gen 1381846 top level 535 received_uuid -
>  path var/lib/mysql
> ID 1287 gen 1364400 top level 535 received_uuid -
>path var/lib/machines
> ID 1325 gen 1381846 top level 536 received_uuid -
>path home/tkloczko
> ID 1326 gen 1381756 top level 1325 received_uuid -
>path home/tkloczko/git
> ID 1327 gen 1381846 top level 1326 received_uuid -
>path home/tkloczko/git/fedora
> ID 1328 gen 1381756 top level 1326 received_uuid -
>path home/tkloczko/git/linux-git
> ID 1329 gen 1380131 top level 1325 received_uuid -
>path home/tkloczko/src-packages
> ID 1331 gen 1381807 top level 1329 received_uuid -
>path home/tkloczko/src-packages/fedora
> ID 1332 gen 1381082 top level 1329 received_uuid -
>path home/tkloczko/src-packages/suse
> ID 1333 gen 1381554 top level 1329 received_uuid -
>path home/tkloczko/src-packages/altlinux
> ID 1334 gen 1380955 top level 1329 received_uuid -
>path home/tkloczko/src-packages/centos
> ID 1335 gen 1381188 top level 1329 received_uuid -
>path home/tkloczko/src-packages/mageia
> ID 1336 gen 1381748 top level 1329 received_uuid -
>path home/tkloczko/src-packages/debian
>
> Looks like it works.
> On the second system, I have no separated /boot and grub2.cfg has been
> updated correctly as well.
> Good job 
> Now it would be good to remove from anaconda blocking use btrfs on roofs
> as well 
>
> kloczek
> --
> Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

grubby - /boot on btrfs support

[Nathaniel McCallum]

https://bodhi.fedoraproject.org/updates/grubby-8.40-10.fc28

We've built grubby with support for /boot on btrfs. We're trying to
land this in F28. But we need testers. That's where you come in! If
you ever interact with grubby and especially if you have an exotic
grub2 setup, please download and test this release. As usual provide
feedback in Bodhi (link at the top of this email). Thanks!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Help Reviewing a FreeOTP (Android) Pull Request in Korean

[Nathaniel McCallum]

The pull request has been updated here:

https://github.com/freeotp/freeotp-android/pull/166

On Wed, Dec 6, 2017 at 9:47 AM, Nathaniel McCallum
<npmccal...@redhat.com> wrote:
> Do you speak (I think) Korean and English? Can you code? If so, I
> could use your help.
>
> The Fedora-associated FreeOTP project has received this pull request:
> https://github.com/freeotp/freeotp-android/pull/165
>
> The comments and commit descriptions are almost entirely in Korean and
> I don't know how to make heads or tails of them. Communication with
> the patch submitter is also difficult since I don't speak Korean and
> they don't speak English. However, I'd really like to give the
> submitter a fair shot.
>
> Is there anyone in the Fedora community that would be willing to
> assist? This is a great opportunity to demonstrate the diversity of
> open source!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Help Reviewing a FreeOTP (Android) Pull Request in Korean

[Nathaniel McCallum]

Do you speak (I think) Korean and English? Can you code? If so, I
could use your help.

The Fedora-associated FreeOTP project has received this pull request:
https://github.com/freeotp/freeotp-android/pull/165

The comments and commit descriptions are almost entirely in Korean and
I don't know how to make heads or tails of them. Communication with
the patch submitter is also difficult since I don't speak Korean and
they don't speak English. However, I'd really like to give the
submitter a fair shot.

Is there anyone in the Fedora community that would be willing to
assist? This is a great opportunity to demonstrate the diversity of
open source!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Help Testing FreeOTP + Jelling

[Nathaniel McCallum]

Thanks!

On Wed, Dec 6, 2017 at 7:16 AM, Jakub Jelen <jje...@redhat.com> wrote:
> On Tue, 2017-12-05 at 16:05 -0500, Nathaniel McCallum wrote:
>> Hello Fedoraland!
>>
>> I recently blogged about an effort to improve multi-factor
>> authentication with OTPs by sending the OTP code from your phone to
>> your computer directly using Bluetooth. The full story can be read
>> here:
>>
>> http://npmccallum.gitlab.io/post/sending-freeotp-codes-over-bluetooth
>> /
>>
>> However, I'm unable to get Jelling for Linux to work on Fedora at all
>> with my devices. I'm very keen to see if anyone is able to get it to
>> work with their combination of devices. Can you help?
>>
>> Testing instructions are available here in the upstream repo:
>> https://github.com/freeotp/jelling-linux
>>
>> If I can get this working on at least one combination of devices, I'd
>> like to bring it to Fedora ASAP. So your help testing is invaluable!
>
> I see the same behavior with my ThinkPad T470s (Fedora 27) and Xiaomi
> A1 (Android 7.1.2). Not even advertisement works, no errors, nothing.
>
> If it will work, I would be happy to test it further.
>
> Regards,
> --
> Jakub Jelen
> Software Engineer
> Security Technologies
> Red Hat, Inc.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Help Testing FreeOTP + Jelling

[Nathaniel McCallum]

Hello Fedoraland!

I recently blogged about an effort to improve multi-factor
authentication with OTPs by sending the OTP code from your phone to
your computer directly using Bluetooth. The full story can be read
here:

http://npmccallum.gitlab.io/post/sending-freeotp-codes-over-bluetooth/

However, I'm unable to get Jelling for Linux to work on Fedora at all
with my devices. I'm very keen to see if anyone is able to get it to
work with their combination of devices. Can you help?

Testing instructions are available here in the upstream repo:
https://github.com/freeotp/jelling-linux

If I can get this working on at least one combination of devices, I'd
like to bring it to Fedora ASAP. So your help testing is invaluable!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS-UP] cryptsetup-2.0.0-rc1 - libcryptsetup soname bump

[Nathaniel McCallum]

Most of the below packages are mine. I'm fine with this rebuild. I
will retire deo as upstream (me) is dead.

On Thu, Nov 2, 2017 at 6:17 AM, Ondrej Kozina  wrote:
> Hi again,
>
> just brief update with some tests before the soname bump takes effect.
>
> I've tested rebuilds of packages depending on libcryptsetup with following
> results. Basically there's only volume_key package that breaks:
>
>> clevis-udisks2-0:6-3.fc27.x86_64
>
>
> Rebuild passed with no issues.
>
>> deo-disks-0:0.5.1-2.fc24.x86_64
>
>
> Failed to rebuild but unrelated to libcryptsetup.
> No symbol that will get removed with cryptsetup-2.0.0 update is used.
>
>> libblockdev-crypto-0:2.13-1.fc28.x86_64
>
>
> No issues in libblockdev except the subpackage depends on volume_key (see
> below)
>
>> libluksmeta-0:8-1.fc28.x86_64
>> luksmeta-0:8-1.fc28.x86_64
>
>
> Rebuild passed with no issues.
>
>> pam_mount-0:2.15-3.fc24.x86_64
>
>
> Rebuild passed with no issues.
>
>> systemd-0:235-2.fc28.x86_64
>> systemd-tests-0:235-2.fc28.x86_64
>> systemd-udev-0:235-2.fc28.x86_64
>
>
> Rebuild passed with no issues.
>
>> volume_key-0:0.3.9-16.fc28.x86_64
>> volume_key-libs-0:0.3.9-16.fc28.x86_64
>
>
> uses removed symbol crypt_get_error
>
> libtool: link: gcc -O2 -g -pipe -Wall -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
> --param=ssp-buffer-size=4 -grecord-gcc-switches
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -Wall -W
> -Wcast-align -Wmissing-noreturn -Wnested-externs -Wpointer-arith -Wshadow
> -Wundef -Wwrite-strings -Wl,-z -Wl,relro
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o src/.libs/volume_key
> src/src_volume_key-volume_key.o  lib/.libs/libvolume_key.so -L/usr/lib64
> -lblkid -lgpgme -lcryptsetup -lglib-2.0 -lssl3 -lsmime3 -lnss3 -lnssutil3
> -lplds4 -lplc4 -lnspr4 -lpthread -ldl
> lib/.libs/libvolume_key.so: undefined reference to `crypt_get_error'
> collect2: error: ld returned 1 exit status
> make[2]: *** [Makefile:665: src/volume_key] Error 1
>
> known issue, reported since cryptsetup-2.0.0-rc0.
> https://pagure.io/volume_key/issue/13 (patch submitted in the issue)
>
>> zulucrypt-console-0:5.2.0-3.fc27.x86_64
>> zulucrypt-libs-0:5.2.0-3.fc27.x86_64
>
>
> Rebuild passed with no issues.
>
> O.
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: yubico-piv-tool & p11-kit

[Nathaniel McCallum]

On Mon, Dec 5, 2016 at 10:35 AM, Nikos Mavrogiannopoulos
<n...@redhat.com> wrote:
> On Mon, 2016-12-05 at 10:23 -0500, Nathaniel McCallum wrote:
>
>> > Indeed, in the case where one has both ykcs11 and opensc, he would
>> > have
>> > to supply --detailed-urls to p11tool to be able to distinguish
>> > between
>> > objects. That is, because they will have identical URLs except for
>> > the
>> > library-description and library-manufacturer fields, which are not
>> > normally printed.
>> >
>> > That would be a bit more than just inconvenience because of the
>> > duplicate listings, it would be that if you don't specify the
>> > library
>> > fields on the URL, you wouldn't know which module was used for the
>> > operation.
>>
>> They don't, in fact, have different URIs. If I add a .module file for
>> ykcs11.so, I get the attached output for p11tool --list-tokens.
>
> You forgot to attach it :)

Let's try again. :)

>> > We should ping yubico on that. Is there some reason they didn't
>> > implement the key generation on opensc? Ideally we won't ship that
>> > additional module.
>>
>> I don't know. But I suspect it would require hardware change. There
>> are a lot of existing YubiKeys out there.
>
> opensc-pkcs11 is an alternative driver for the same hardware, the same
> as ykcs11. As it is now, it seems that opensc misses only the
> generation part, and I think it would be preferable to pointing yubico
> in adding that functionality in opensc, rather than shipping a separate
> driver in fedora.

I agree. However, I suspect that the two drivers are using two
different hardware interfaces. And I suspect that YubiKeys may not
implement key creation through the SC hardware interface. I may
misunderstand this. Corrections are welcome.

If key creation is only supported by a proprietary YubiKey interface,
then I'm not sure we have much choice but to support two drivers (one
for the SC interface, one for the YK interface).

We should note that we are already shipping two drivers and what we
need to do now is define the relationship between them.
Token 0:
URL: 
pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System%20Trust
Label: System Trust
Type: Trust module
Manufacturer: PKCS#11 Kit
Model: p11-kit-trust
Serial: 1
Module: p11-kit-trust.so


Token 1:
URL: 
pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=Default%20Trust
Label: Default Trust
Type: Trust module
Manufacturer: PKCS#11 Kit
Model: p11-kit-trust
Serial: 1
Module: p11-kit-trust.so


Token 2:
URL: 
pkcs11:model=1.0;manufacturer=Gnome%20Keyring;serial=1%3aSSH%3aHOME;token=SSH%20Keys
Label: SSH Keys
Type: Generic token
Manufacturer: Gnome Keyring
Model: 1.0
Serial: 1:SSH:HOME
Module: gnome-keyring-pkcs11.so


Token 3:
URL: 
pkcs11:model=1.0;manufacturer=Gnome%20Keyring;serial=1%3aSECRET%3aMAIN;token=Secret%20Store
Label: Secret Store
Type: Generic token
Manufacturer: Gnome Keyring
Model: 1.0
Serial: 1:SECRET:MAIN
Module: gnome-keyring-pkcs11.so


Token 4:
URL: 
pkcs11:model=1.0;manufacturer=Gnome%20Keyring;serial=1%3aUSER%3aDEFAULT;token=Gnome2%20Key%20Storage
Label: Gnome2 Key Storage
Type: Generic token
Manufacturer: Gnome Keyring
Model: 1.0
Serial: 1:USER:DEFAULT
Module: gnome-keyring-pkcs11.so


Token 5:
URL: 
pkcs11:model=1.0;manufacturer=Gnome%20Keyring;serial=1%3aXDG%3aDEFAULT;token=User%20Key%20Storage
Label: User Key Storage
Type: Generic token
Manufacturer: Gnome Keyring
Model: 1.0
Serial: 1:XDG:DEFAULT
Module: gnome-keyring-pkcs11.so


Token 6:
URL: 
pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29
Label: PIV_II (PIV Card Holder pin)
Type: Hardware token
Manufacturer: piv_II
Model: PKCS#15 emulated
Serial: 
Module: opensc-pkcs11.so


Token 7:
URL: 
pkcs11:model=YubiKey%20NEO;manufacturer=Yubico;serial=1234;token=YubiKey%20PIV
Label: YubiKey PIV
Type: Hardware token
Manufacturer: Yubico
Model: YubiKey NEO
Serial: 1234
Module: /usr/lib64/libykcs11.so.1


Token 8:
URL: 
pkcs11:model=YubiKey%20NEO;manufacturer=Yubico;serial=1234;token=YubiKey%20PIV
Label: YubiKey PIV
Type: Hardware token
Manufacturer: Yubico
Model: YubiKey NEO
Serial: 1234
Module: /usr/lib64/libykcs11.so.1


Token 9:
URL: 
pkcs11:model=YubiKey%20

Re: yubico-piv-tool & p11-kit

[Nathaniel McCallum]

On Mon, Dec 5, 2016 at 2:41 AM, Jakub Jelen <jje...@redhat.com> wrote:
> On 12/03/2016 01:50 PM, Nathaniel McCallum wrote:
>>
>> So apparently yubico-piv-tool ships $libdir/libykpkcs11.so*, but this
>> doesn't get picked up by p11-kit by default. I suspect it has gone
>> unnoticed largely because for most crucial operations the opensc
>> module also works with Yubikeys. However, this is not true for all
>> operations (in particular, in my case, key creation).
>>
>> How can we make this happen? Is there some intentional reason Yubico's
>> PKCS#11 module has been excluded?
>
> Hello,
> In case of the modules accessing the same hardware tokens, there is a
> problem that they shows up more times while listed by p11-kit. We had
> similar problem with opensc && coolkey once both of them worked with PIV
> cards.
>
> Ideal solution would be to implement the PIV key creation in OpenSC (what
> exactly does not work with which yubikey?). We can't use only yubico module,
> since PIV is not only the yubico one.

$ pkcs11-tool --module /usr/lib64/libykcs11.so.1 -l --login-type so -k
--key-type EC:prime256v1 -d 1 --usage-sign
Using slot 0 with a present token (0x0)
Logging in to "YubiKey PIV".
Please enter SO PIN:
Key pair generated:
Private Key Object; EC
  label:  Private key for Card Authentication
  ID: 01
  Usage:  sign
Public Key Object; EC  EC_POINT 256 bits
  EC_POINT:   
04410434d393db4a9ba3ca022404e3f887fa98d3b1d9e35c2d4b901bf62b31bfecd3beee4919b310c02677edac6eef482fd2881f5fae0ac61d3765ef5b6c390221a4ab
  EC_PARAMS:  06082a8648ce3d030107
  label:  Public key for Card Authentication
  ID: 01
  Usage:  verify

$ pkcs11-tool --module /usr/lib64/opensc-pkcs11.so -l --login-type so
-k --key-type EC:prime256v1 -d 1 --usage-sign
Using slot 0 with a present token (0x0)
Logging in to "PIV_II (PIV Card Holder pin)".
Please enter SO PIN:
error: PKCS11 function C_Login failed: rv = CKR_ARGUMENTS_BAD (0x7)

$ pkcs11-tool --module /usr/lib64/opensc-pkcs11.so -l --login-type so -k
Using slot 0 with a present token (0x0)
Logging in to "PIV_II (PIV Card Holder pin)".
Please enter SO PIN:
error: PKCS11 function C_Login failed: rv = CKR_ARGUMENTS_BAD (0x7)

$ pkcs11-tool --module /usr/lib64/opensc-pkcs11.so -l -k --key-type
EC:prime256v1 -d 1 --usage-sign
Using slot 0 with a present token (0x0)
Logging in to "PIV_II (PIV Card Holder pin)".
Please enter User PIN:
error: Generate EC key mechanism not supported

$ pkcs11-tool --module /usr/lib64/opensc-pkcs11.so -l -k
Using slot 0 with a present token (0x0)
Logging in to "PIV_II (PIV Card Holder pin)".
Please enter User PIN:
error: PKCS11 function C_GenerateKeyPair failed: rv =
CKR_FUNCTION_NOT_SUPPORTED (0x54)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: yubico-piv-tool & p11-kit

[Nathaniel McCallum]

On Mon, Dec 5, 2016 at 3:00 AM, Nikos Mavrogiannopoulos <n...@redhat.com> wrote:
> On Mon, 2016-12-05 at 08:41 +0100, Jakub Jelen wrote:
>> On 12/03/2016 01:50 PM, Nathaniel McCallum wrote:
>> > So apparently yubico-piv-tool ships $libdir/libykpkcs11.so*, but
>> > this
>> > doesn't get picked up by p11-kit by default. I suspect it has gone
>> > unnoticed largely because for most crucial operations the opensc
>> > module also works with Yubikeys. However, this is not true for all
>> > operations (in particular, in my case, key creation).
>> >
>> > How can we make this happen? Is there some intentional reason
>> > Yubico's
>> > PKCS#11 module has been excluded?
>> Hello,
>> In case of the modules accessing the same hardware tokens, there is
>> a problem that they shows up more times while listed by p11-kit. We
>> had similar problem with opensc && coolkey once both of them worked
>> with PIV cards.
>
> Indeed, in the case where one has both ykcs11 and opensc, he would have
> to supply --detailed-urls to p11tool to be able to distinguish between
> objects. That is, because they will have identical URLs except for the
> library-description and library-manufacturer fields, which are not
> normally printed.
>
> That would be a bit more than just inconvenience because of the
> duplicate listings, it would be that if you don't specify the library
> fields on the URL, you wouldn't know which module was used for the
> operation.

They don't, in fact, have different URIs. If I add a .module file for
ykcs11.so, I get the attached output for p11tool --list-tokens.

Strangely, this shows the same yubikey 7 times (perhaps a bug?).
Notice that token 6 and tokens 7-13 are in fact the same token.

> On the other hand, if we have another pkcs11 module for yubikeys
> shipped on a package, it seems natural to be included in the p11-kit
> listings, and maybe it makes sense to make p11tool print the long URL
> versions by default.

I'd like to include ykcs11.so in the listings, but I don't think we
need to enable the long URI versions since there is no overlap between
opensc and ykcs11.

>> Ideal solution would be to implement the PIV key creation in OpenSC
>> (what exactly does not work with which yubikey?). We can't use only
>> yubico module, since PIV is not only the yubico one.
>
> We should ping yubico on that. Is there some reason they didn't
> implement the key generation on opensc? Ideally we won't ship that
> additional module.

I don't know. But I suspect it would require hardware change. There
are a lot of existing YubiKeys out there. We should give our best
effort to support them.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

yubico-piv-tool & p11-kit

[Nathaniel McCallum]

So apparently yubico-piv-tool ships $libdir/libykpkcs11.so*, but this
doesn't get picked up by p11-kit by default. I suspect it has gone
unnoticed largely because for most crucial operations the opensc
module also works with Yubikeys. However, this is not true for all
operations (in particular, in my case, key creation).

How can we make this happen? Is there some intentional reason Yubico's
PKCS#11 module has been excluded?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[Nathaniel McCallum]

On Mon, Nov 28, 2016 at 3:10 AM, Alexander Bokovoy  wrote:
> On su, 27 marras 2016, Ken Dreyer wrote:
>>
>> On Wed, Nov 23, 2016 at 7:17 AM, Alexander Bokovoy 
>> wrote:
>>>
>>> Heimdal does not support MS-KKDCP spec, so you are left with direct
>>> Kerberos communication over port 88/tcp or 88/udp, but these are enabled
>>> in Fedora infrastructure, yes.
>>
>>
>> I thought direct Kerberos service was going to be disabled, to prevent
>> attackers sniffing and brute-forcing the encrypted preauth timestamp?
>
> This is really a question to Fedora Infra people but last time we
> discussed, RHEL 6-based clients and alike were not getting MS-KKDCP
> features backported to older MIT Kerberos versions so to support them,
> direct access is required.

Correct. The Fedora Infrastructure team needs to balance the risk of
MitM offline dictionary attacks with the need for RHEL6 client access.

IMHO, there should already be a plan to sunset RHEL6 instances. But I
can't judge this based upon Fedora's internal needs.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[Nathaniel McCallum]

On Mon, Nov 21, 2016 at 10:03 AM, Alexander Bokovoy  wrote:
> On ma, 21 marras 2016, Florian Weimer wrote:
>>
>> On 11/21/2016 01:31 PM, Stephen Gallagher wrote:
>>
>> Thanks for your explanation.
>>
>>> So yes, we have protection against that. FreeIPA (which is backing this
>>> solution) requires preauthentication for all user accounts.
>>
>>
>> “That” meaning offline attacks without intercepted packets.  With
>> intercepted packets, offline attacks are still feasible, right?
>
> Right -- if you get initial exchange in the traditional Kerberos 5.
> We have been working for several years already to reduce these
> possibilities via different means:
> - enablement for HTTPS-based tunnel for Kerberos flows based on
>   MS-KKDCP specification;
>
> - DNS-based announcement of Kerberos MS-KKDCP proxy using DNS URI;
>
> - SPAKE exchange support in MIT Kerberos (slated for 1.15-1.16)
>
> Fedora infrastructure uses MS-KKDCP proxy with Fedora certificate to
> tunnel Kerberos 5 traffic. If you have recent Fedora, you'll get it used
> automatically with the help of DNS URI. For older clients which don't
> support DNS-based discovery you can configure MS-KKDCP proxy access
> manually by stating 'kdc=https://id.fedoraproject.org/KdcProxy' for
> FEDORAPROJECT.ORG realm. For very old clients that don't support
> MS-KKDCP (RHEL 6, for example), you are back to use naked Kerberos 5
> traffic.
>
> Our effort is to get to SPAKE sooner than later.

I'll be working with Robbie Harwood to implement SPAKE in the coming
months. So let me add some clarification here.

1. Like Stephen said, preauth now prevents offline dictionary attack
without interception. This has been true for years.

2. Offline dictionary attack is theoretically possible with MitM
(though is somewhat mitigated by the added timestamp entropy). This
can be further mitigated by using the HTTPS proxy as stated by
Alexander. I am not aware of any successful attacks using this method.

3. SPAKE is a new technique to make this whole problem irrelevant (as
well as provide an implicitly trusted tunnel for 2FA without
additional trust anchors). The draft is available here:
https://tools.ietf.org/html/draft-mccallum-kitten-krb-spake-preauth-00.
A new draft is forthcoming shortly. SPAKE works like a normal
Password-Authenticated Key Exchange, and thus is entirely protected
from offline attacks the same way Diffie-Hellman is. There is already
a 1FA implementation in an upstream branch which we are going to
expand to support 2FA and then merge. The server-side will only land
in newer Fedoras. However, should need arise, we might be able to
backport the client-side as a plugin.  I'm hoping to land this in F26.

Nathaniel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

python-cryptography 0.8.2 [F21/F22]

[Nathaniel McCallum]

I have submitted new packages for python-cryptography to F21 and F22:

https://admin.fedoraproject.org/updates/python-cryptography-vectors-0.8.2-1.fc22,python-cryptography-0.8.2-1.fc22

https://admin.fedoraproject.org/updates/python-cryptography-vectors-0.8.2-1.fc21,python-cryptography-0.8.2-1.fc21

This includes an upstream fix and a fix for a missing dependency 
(python*-pyasn1). Please test. Thanks!

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: python-yubico updates (testing wanted)

[Nathaniel McCallum]

On Mon, 2015-03-23 at 13:08 -0400, Nathaniel McCallum wrote:
 https://admin.fedoraproject.org/updates/python-yubico-1.2.3-1.fc20
 https://admin.fedoraproject.org/updates/python-yubico-1.2.3-1.fc21
 https://admin.fedoraproject.org/updates/python-yubico-1.2.3-1.fc22
 
 I have just created updates for python-yubico. This new upstream 
 release just adds support for new YubiKey devices (such as YubiKey 
 NEO). I'd love some testing!
 
 To test:
 1. Install the new python-yubico package
 2. Insert your YubiKey
 3. Run:
 $ python -c 'import yubico; yubico.find_yubikey()'
 
 If this command silently returns, everything should be working.

I seem to have managed to get Bodhi into a strange state and I'm not 
sure how to resolve it.

As you can see, I pushed updates to F20, F21 and F22 at the same time. 
I enabled karma automatism. The F22 update has +1 karma and the F21 
update has +3.

When the F21 update was being automatically pushed to stable, 
taskotron reported that the upgradepath test failed and that push to 
stable was unavailable. The failure was because F22 has a lower 
version than F21. However, this is because F21's package was getting 
pushed (this test should really take into consideration updates-
testing). It says I can re-enable the automatic push but when I 
attempted to do that it failed. Nor can I push to stable manually.

Where do I go from here?

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

python-yubico updates (testing wanted)

[Nathaniel McCallum]

https://admin.fedoraproject.org/updates/python-yubico-1.2.3-1.fc20
https://admin.fedoraproject.org/updates/python-yubico-1.2.3-1.fc21
https://admin.fedoraproject.org/updates/python-yubico-1.2.3-1.fc22

I have just created updates for python-yubico. This new upstream 
release just adds support for new YubiKey devices (such as YubiKey 
NEO). I'd love some testing!

To test:
1. Install the new python-yubico package
2. Insert your YubiKey
3. Run:
$ python -c 'import yubico; yubico.find_yubikey()'

If this command silently returns, everything should be working.

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

OpenSSL missing NIST p224r1

[Nathaniel McCallum]

On Fedora 21, OpenSSL doesn't appear to support NIST p224r1, but *does*
support other NIST curves. I presume this was intentional, but I'm not
sure why. Can someone enlighten me?

$ openssl ecparam -list_curves
  secp384r1 : NIST/SECG curve over a 384 bit prime field
  secp521r1 : NIST/SECG curve over a 521 bit prime field
  prime256v1: X9.62/SECG curve over a 256 bit prime field

Nathaniel

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Rawhide LDFLAGS (-pie)

[Nathaniel McCallum]

FreeIPA is experiencing build-failure in Koji Rawhide.

http://koji.fedoraproject.org/koji/packageinfo?packageID=11554

This is due to -pie being present in the LDFLAGS on rawhide. This in
turn requires that all code be compiled with -fPIC, which is not
normally required for simple executables. Nor is -fPIC being added to
the list of CFLAGS by Koji.

Where does this bug lie, and who needs to fix it? I could add -fPIC to
FreeIPA, but this doesn't seem correct.

Nathaniel

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: SELinux RPM scriplet issue annoucement

[Nathaniel McCallum]

Is it possible to build a one-time build of selinux-policy without
scriptlets so that the update will succeed?


On Sat, Jan 18, 2014 at 3:47 PM, Rahul Sundaram methe...@gmail.com wrote:

 Hi

 Since updates don't automatically fix the issue created by
 https://bugzilla.redhat.com/show_bug.cgi?id=1054350 and users are
 required to run a set of steps as a workaround,  shouldn't this be
 announced via the fedora announce list and posted in the Fedora website
 prominently as well?


 Rahul

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [389-devel] ACL: Adding object based on owner attribute

[Nathaniel McCallum]

On Fri, 2013-12-20 at 17:31 -0500, Nathaniel McCallum wrote:
 I'm working on this project: http://www.freeipa.org/page/V3/OTP
 
 Users need to be able to create, edit and delete their own tokens. Each
 token has an attribute: ipatokenOwner.
 
 I attempted creating this ACL: (target =
 ldap:///ipatokenuniqueid=*,cn=otp,dc=example,dc=com;)(targetfilter =
 (objectClass=ipaToken))(version 3.0; acl token-add-delete; allow
 (add, delete) userattr = ipatokenOwner#USERDN;)
 
 After much debugging I found out this is impossible because of this:
 https://git.fedorahosted.org/cgit/389/ds.git/tree/ldap/servers/plugins/acl/acllas.c#n1282
 
 Now, in the general case, I can very much understand why this shouldn't
 be allowed by default. What alternatives are there with the current
 code? Would 389DS be willing to accept a patch to enable this (with a
 I_KNOW_WHAT_I_AM_DOING flag)?
 
 The general reason why this feature works in my case is that each object
 created restricts the user, rather than granting new privileges. This
 seems like a valid use case.

I really appreciate the quick fix for this
(a9cd4e78f1fd1af5de06aca46c8c10ed70bbe4e1)!

Any idea when this will be available in a release and/or Fedora Rawhide?

Nathaniel

--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

[389-devel] ACL: Adding object based on owner attribute

[Nathaniel McCallum]

I'm working on this project: http://www.freeipa.org/page/V3/OTP

Users need to be able to create, edit and delete their own tokens. Each
token has an attribute: ipatokenOwner.

I attempted creating this ACL: (target =
ldap:///ipatokenuniqueid=*,cn=otp,dc=example,dc=com;)(targetfilter =
(objectClass=ipaToken))(version 3.0; acl token-add-delete; allow
(add, delete) userattr = ipatokenOwner#USERDN;)

After much debugging I found out this is impossible because of this:
https://git.fedorahosted.org/cgit/389/ds.git/tree/ldap/servers/plugins/acl/acllas.c#n1282

Now, in the general case, I can very much understand why this shouldn't
be allowed by default. What alternatives are there with the current
code? Would 389DS be willing to accept a patch to enable this (with a
I_KNOW_WHAT_I_AM_DOING flag)?

The general reason why this feature works in my case is that each object
created restricts the user, rather than granting new privileges. This
seems like a valid use case.

Nathaniel

--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: Proposed F19 Feature: Enterprise / distributed two-factor authentication

[Nathaniel McCallum]

FYI, FreeIPA is hoping to land two-factor auth support with MIT krb5 in
roughly the same time-frame.

Nathaniel


On Tue, Jan 29, 2013 at 9:48 AM, Jaroslav Reznik jrez...@redhat.com wrote:

 = Features/EnterpriseTwoFactorAuthentication =
 https://fedoraproject.org/wiki/Features/EnterpriseTwoFactorAuthentication

 Feature owner(s): Daniel Pocock dan...@pocock.com.au

 Provide a flexible solution for two-factor authentication on a distributed
 basis, suitable for enterprise and SSO.

 == Detailed description ==
 Most OTP solutions for two-factor authentication require some kind of
 storage
 backend for counters or other volatile data. Early implementations work
 with
 flat files on a single host. dynalogin was created to bring stability and
 flexibility, storing counters in just about any type of database. Other
 solutions such as totp-cgi have similar goals (although it only mentions
 Postgres support, whereas dynalogin can use MySQL thanks to UNIXODBC).
 dynalogin has been successfully integrated with the SimpleID provider for
 OpenID authentication.
 ___
 devel-announce mailing list
 devel-annou...@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Making rygel build in rawhide

[Nathaniel McCallum]

The attached patches upgrade gupnp-dlna to 0.9.4 and fix the rygel 0.17.7
build. Please apply to get people working again.

I have also emailed the typo fix patch upstream. I've attached it here for
convenience.

It would be nice if upstream rygel didn't require us to strip rpath after
the build.

Nathaniel


On Sat, Jan 26, 2013 at 5:01 AM, Krzesimir Nowak qdl...@gmail.com wrote:

 2013/1/26 Nathaniel McCallum nathan...@natemccallum.com

 Could someone apply this patch to rygel so at least we can get a
 successful build?
 http://git.gnome.org/browse/rygel/commit/?h=wip/new-gupnp-dlnaid=118af0f588879703e0dd7d01787897b5893032e0


 That won't do. Gupnp-dlna 0.9.4 has to hit rawhide first. Then instead of
 patching, packaging Rygel 0.17.7 should be enough.


 Thanks,
 Nathaniel

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel



 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel



0001-update-to-gupnp-dlna-0.9.4.patch
Description: Binary data


0001-make-rygel-0.17.7-actually-build-add-docs-subpackage.patch
Description: Binary data


rygel-0.17.7-typofix.patch
Description: Binary data
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Making rygel build in rawhide

[Nathaniel McCallum]

Could someone apply this patch to rygel so at least we can get a successful
build?
http://git.gnome.org/browse/rygel/commit/?h=wip/new-gupnp-dlnaid=118af0f588879703e0dd7d01787897b5893032e0

Thanks,
Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Torvalds:requiring root password for mundane things is moronic

[Nathaniel McCallum]

On Wed, Feb 29, 2012 at 7:41 AM, Giovanni Campagna 
scampa.giova...@gmail.com wrote:


 PS: it would be useful to have some GUI tool to configure PolicyKit.
 Everytime I clean my system I have to dig through dozens of manual
 pages just to get virt-manager without a password for my user.


Actually, I've been hoping that virt-manager would support session://qemu
in the UI for a while now. It seems to work fine once you add it manually
to gconf.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

systemd system unit files and UsrMove

[Nathaniel McCallum]

I'm a fan of systemd [1]. And although I didn't like the fact that unit
files were stored in /lib, I understood the rationale since there was no
/share. However, I've just recently discovered [2] that after UsrMove unit
files will be stored in /usr/lib. Can we not do better than this? And I'd
really rather not work around the problem [3].

Seriously, please don't do this.

Nathaniel

1 - http://nathaniel.themccallums.org/2012/01/28/systemd-rocks-my-world/
2 - https://bugzilla.redhat.com/show_bug.cgi?id=791229
3 - https://bugzilla.redhat.com/show_bug.cgi?id=794777
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd system unit files and UsrMove

[Nathaniel McCallum]

On Fri, Feb 17, 2012 at 11:48 AM, Toshio Kuratomi a.bad...@gmail.comwrote:

 On Fri, Feb 17, 2012 at 10:46:58AM -0500, Nathaniel McCallum wrote:
  I'm a fan of systemd [1]. And although I didn't like the fact that unit
 files
  were stored in /lib, I understood the rationale since there was no
 /share.
  However, I've just recently discovered [2] that after UsrMove unit files
 will
  be stored in /usr/lib. Can we not do better than this? And I'd really
 rather
  not work around the problem [3].
 
  Seriously, please don't do this.
 
  Nathaniel
 
  1 - http://nathaniel.themccallums.org/2012/01/28/systemd-rocks-my-world/
  2 - https://bugzilla.redhat.com/show_bug.cgi?id=791229
  3 - https://bugzilla.redhat.com/show_bug.cgi?id=794777

 Yeah -- so I see three options -- move systemd unit files to /usr/share,
 revert /usr/move, change rpmlint (or a fourth -- ignore this warning for
 f17
 and move systemd unit files to /usr/share for f18).

 Which are you advocating?


Move systemd unit files to /usr/share and provide simple logic to fall back
/lib, so as not to break upgrades with custom unit files. I am certainly
not advocating a bad user experience. If the schedule doesn't permit it,
I'm ok with delaying the move to /usr/share until f18. However, I would
want to avoid two moves at all costs. I can't imagine moving them to
/usr/shared is a huge task (considering any bugs you would hit would likely
already be hit by UsrMove anyway) or that moving the unit files from /lib
to /usr/share is any different than moving them from /lib to /usr/lib. So
the upgrade experience can't be really harmed by such a move.

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd system unit files and UsrMove

[Nathaniel McCallum]

2012/2/17 Jóhann B. Guðmundsson johan...@gmail.com

 On 02/17/2012 04:48 PM, Toshio Kuratomi wrote:

 Yeah -- so I see three options -- move systemd unit files to /usr/share,
 revert /usr/move, change rpmlint (or a fourth -- ignore this warning for
 f17
 and move systemd unit files to /usr/share for f18).

 Which are you advocating?


 If you are going to move units to /usr/share I suspect you want to move
 the rest as well  udev, modprobe, depmod, tmpfiles, modules-load etc...


 Sure, as time permits and when such can be done without harming user
experience.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd system unit files and UsrMove

[Nathaniel McCallum]

On Fri, Feb 17, 2012 at 12:04 PM, Reindl Harald h.rei...@thelounge.netwrote:



 Am 17.02.2012 18:00, schrieb Nathaniel McCallum:
  Move systemd unit files to /usr/share and provide simple logic to fall
 back /lib, so as not to break upgrades with
  custom unit files. I am certainly not advocating a bad user experience.
 If the schedule doesn't permit it, I'm ok
  with delaying the move to /usr/share until f18. However, I would want to
 avoid two moves at all costs. I can't
  imagine moving them to /usr/shared is a huge task (considering any bugs
 you would hit would likely already be hit
  by UsrMove anyway) or that moving the unit files from /lib to /usr/share
 is any different than moving them from
  /lib to /usr/lib. So the upgrade experience can't be really harmed by
 such a move.

 you are missing the point that /lib/ to /usr/lib is a theoretical
 not invasive change by replacing /lib with a symlink!


I'm fine if you want to symlink /usr/lib/systemd/system to
/usr/share/systemd/system or something else comparable. That should be just
as noninvasive. My point is that custom files installed in /lib already
have to be moved to /usr/lib. Why not also cleanly move systemd unit files
to a more standard location?


 moving things around the filesystem means you are breaking
 each sort of scripts and whatever customized software is
 runnign at the users machines - can we please stop to
 enforce permanently chaning paths all over the world for
 some beautniess reason without any technical point for it


Well, we've already decided to do these kinds of changes (aka UsrMove). If
we are going to do so, why not do it right? Besides, we already have nice
mechanisms like pkg-config variables to find the right paths for things,
your scripts should use those. And what script is going to break by the
move to /usr/share that won't be broken by the move to /usr/lib when the
proper symlinks are in place?

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd system unit files and UsrMove

[Nathaniel McCallum]

On Fri, Feb 17, 2012 at 12:17 PM, Reindl Harald h.rei...@thelounge.netwrote:



 Am 17.02.2012 18:09, schrieb Nathaniel McCallum:
 
 
  2012/2/17 Jóhann B. Guðmundsson johan...@gmail.com mailto:
 johan...@gmail.com
 
  On 02/17/2012 04:48 PM, Toshio Kuratomi wrote:
 
  Yeah -- so I see three options -- move systemd unit files to
 /usr/share,
  revert /usr/move, change rpmlint (or a fourth -- ignore this
 warning for f17
  and move systemd unit files to /usr/share for f18).
 
  Which are you advocating?
 
 
  If you are going to move units to /usr/share I suspect you want to
 move the rest as well  udev, modprobe,
  depmod, tmpfiles, modules-load etc...
 
 
   Sure, as time permits and when such can be done without harming user
 experience.

 FOR WHAT REASON?

 such changes do ALWAYS harming user experience

 why?
 becaus eoperating systems are (or where it seems) made to give users
 the base for their own work, scripts, automatisms and the idea of
 linux once was give users a CUSTOMIZEABLE system

 by permanently change thins for the sake of the change you
 are killing the customizeable becasue it is better not
 do this at all to be safe for useless changes made from bored
 people upstream your OS

 PLEASE STOP THIS BAD ATTITUDE DAMAGE PERMANENTLY CUSTOMIZED
 SYSTEMS JUST FOR FUN OR YOU WILL NEVER IN THIS LIFE HAVE
 USERS USING LINUX IF THEY WANT TO DO MORE THAN INSERT A DVD
 AND EAT WHAT SOMEONE OTHER DECIDED IS GOOD FOR THEM


So we should never change anything, right? Tone down the rhetoric please.
I'm asking for gradual evolution here without pain.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: The question of rolling release?

[Nathaniel McCallum]

On Tue, Jan 24, 2012 at 6:23 AM, mike cloaked mike.cloa...@gmail.comwrote:

 Having looked at the way releasing packages and versions in linux has
 been moving in a number of distributions it is interesting that there
 are several that now have a rolling-release model.

 Three of these are:

 Debian CUT:
 http://www.omgubuntu.co.uk/2011/03/debian-cut-a-new-rolling-release/
 http://cut.debian.net/

 Opensuse Tumbleweed:
 http://en.opensuse.org/Portal:Tumbleweed

 Arch Linux:
 https://wiki.archlinux.org/index.php/Arch_Linux

 Gentoo is also essentially a rolling release distribution.

 Fedora would appear to be out of line in not taking on board the
 potential user base for a rolling release version.  For servers there
 would be huge advantages in management of systems.

 Is there any support at all within the development community for a
 rolling release version of Fedora (and possibly ulitimately Redhat)?
 Is there a possibility that not moving to rolling release could
 ultimately damage Fedora in the future as other distributions increase
 their support base?

 I thought this might lead to a useful discussion and this post is not
 supposed to be a flame bait but a genuine question that is potentially
 quite fundamental to the future of Fedora. Applying innovative and
 careful thought to this question might be helpful to the Fedora
 project as a whole.


+1

The structure I'd like to see is: rawhide - testing - stable and then
every 6 months release a hardened fork off of stable as a static release
(Fedora N). If you want to run the stable or testing branches you install
the latest Fedora N release and then yum upgrade to stable. This seems to
me like not a lot of work besides the new policy that would obviously
govern packagers and how they merge to the branches. I also think this
would provide a marked benefit of stability to the static releases.

Perhaps someone can fill us in on what work would need to be done to make
this happen?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Testing needed (mongodb)

[Nathaniel McCallum]

I've built packages of MongoDB 2.0.2 for f15, f16 and f17. This should be a
drop in replacement for your 1.8.x server. See
http://www.mongodb.org/display/DOCS/2.0+Release+Notes#2.0ReleaseNotes-Upgradingfor
further details.

However, I had to rewrite the patch providing js 1.8.5 support. So I'd like
some hands on testing before I push out this update.

The builds should appear shortly in updates-testing and you can
provide here:
https://admin.fedoraproject.org/updates/mongodb-2.0.2-5.fc15
https://admin.fedoraproject.org/updates/mongodb-2.0.2-5.fc16

Thanks!

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Testing needed (mongodb)

[Nathaniel McCallum]

On Tue, Jan 17, 2012 at 2:12 PM, Jon VanAlten jon.vanal...@redhat.comwrote:



 - Original Message -
  From: Nathaniel McCallum nathan...@natemccallum.com
  To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
  Sent: Tuesday, January 17, 2012 1:24:25 PM
  Subject: Testing needed (mongodb)
 
  I've built packages of MongoDB 2.0.2 for f15, f16 and f17. This
  should be a
  drop in replacement for your 1.8.x server. See
 
 http://www.mongodb.org/display/DOCS/2.0+Release+Notes#2.0ReleaseNotes-Upgradingfor
  further details.
 
  However, I had to rewrite the patch providing js 1.8.5 support. So
  I'd like
  some hands on testing before I push out this update.
 
  The builds should appear shortly in updates-testing and you can
  provide here:
  https://admin.fedoraproject.org/updates/mongodb-2.0.2-5.fc15
  https://admin.fedoraproject.org/updates/mongodb-2.0.2-5.fc16
 
  Thanks!
 
  Nathaniel
 
  --
  devel mailing list
  devel@lists.fedoraproject.org
  https://admin.fedoraproject.org/mailman/listinfo/devel

 Hi,

 Am using the java driver not javascript so I can't really comment to your
 rewritten patch, but I can say that the F15 packages seem to be functioning
 fine as dropin replacement.


Great! And in fact you are using the javascript patch, it is used internally
by mongod. The patch itself, though long, is pretty much a menial changing
of function signatures, so I don't see a lot of risk here (or the compiler
would have yelled at me!).


 There is, however, a new SELinux alert (pasted below).  I don't see
 anything terrible in /var/log/mongodb/mongodb.log and this alert doesn't
 seem to affect functionality.


Good catch! However, I'm not sure what the best way to fix this is. Any SELinux
folk care to comment?


 cheers,
 jon

 SELinux is preventing /usr/bin/mongod from getattr access on the file
 /proc/sys/vm/zone_reclaim_mode.

 *  Plugin catchall (100. confidence) suggests
  ***

 If you believe that mongod should be allowed getattr access on the
 zone_reclaim_mode file by default.
 Then you should report this as a bug.
 You can generate a local policy module to allow this access.
 Do
 allow this access for now by executing:
 # grep mongod /var/log/audit/audit.log | audit2allow -M mypol
 # semodule -i mypol.pp

 Additional Information:
 Source Contextsystem_u:system_r:mongod_t:s0
 Target Contextsystem_u:object_r:sysctl_vm_t:s0
 Target Objects/proc/sys/vm/zone_reclaim_mode [ file ]
 Sourcemongod
 Source Path   /usr/bin/mongod
 Port  Unknown
 Host  HOST
 Source RPM Packages   mongodb-server-2.0.2-5.fc15
 Target RPM Packages
 Policy RPMselinux-policy-3.9.16-48.fc15
 Selinux Enabled   True
 Policy Type   targeted
 Enforcing ModeEnforcing
 Host Name toxin
 Platform  Linux HOST 2.6.41.4-1.fc15.x86_64 #1 SMP
 Tue Nov
  29 11:53:48 UTC 2011 x86_64 x86_64
 Alert Count   3
 First SeenTue 17 Jan 2012 02:00:14 PM EST
 Last Seen Tue 17 Jan 2012 02:02:46 PM EST
 Local ID  bc6ed9f8-5013-4aff-8b7d-c45c3add2e04

 Raw Audit Messages
 type=AVC msg=audit(1326826966.315:388): avc:  denied  { getattr } for
  pid=28298 comm=mongod path=/proc/sys/vm/zone_reclaim_mode dev=proc
 ino=515586 scontext=system_u:system_r:mongod_t:s0
 tcontext=system_u:object_r:sysctl_vm_t:s0 tclass=file
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Testing needed (mongodb)

[Nathaniel McCallum]

Daniel, can you point me to some docs on how to do this?

On Tue, Jan 17, 2012 at 3:41 PM, Daniel J Walsh dwa...@redhat.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 01/17/2012 02:12 PM, Jon VanAlten wrote:
 
 
  - Original Message -
  From: Nathaniel McCallum nathan...@natemccallum.com To:
  Development discussions related to Fedora
  devel@lists.fedoraproject.org Sent: Tuesday, January 17, 2012
  1:24:25 PM Subject: Testing needed (mongodb)
 
  I've built packages of MongoDB 2.0.2 for f15, f16 and f17. This
  should be a drop in replacement for your 1.8.x server. See
 
 http://www.mongodb.org/display/DOCS/2.0+Release+Notes#2.0ReleaseNotes-Upgradingfor
 
 
 further details.
 
  However, I had to rewrite the patch providing js 1.8.5 support.
  So I'd like some hands on testing before I push out this update.
 
  The builds should appear shortly in updates-testing and you can
  provide here:
  https://admin.fedoraproject.org/updates/mongodb-2.0.2-5.fc15
  https://admin.fedoraproject.org/updates/mongodb-2.0.2-5.fc16
 
  Thanks!
 
  Nathaniel
 
  -- devel mailing list devel@lists.fedoraproject.org
  https://admin.fedoraproject.org/mailman/listinfo/devel
 
  Hi,
 
  Am using the java driver not javascript so I can't really comment
  to your rewritten patch, but I can say that the F15 packages seem
  to be functioning fine as dropin replacement.  There is, however, a
  new SELinux alert (pasted below).  I don't see anything terrible in
  /var/log/mongodb/mongodb.log and this alert doesn't seem to affect
  functionality.
 
  cheers, jon
 
  SELinux is preventing /usr/bin/mongod from getattr access on the
  file /proc/sys/vm/zone_reclaim_mode.
 
  *  Plugin catchall (100. confidence) suggests
  ***
 
  If you believe that mongod should be allowed getattr access on the
  zone_reclaim_mode file by default. Then you should report this as a
  bug. You can generate a local policy module to allow this access.
  Do allow this access for now by executing: # grep mongod
  /var/log/audit/audit.log | audit2allow -M mypol # semodule -i
  mypol.pp
 
  Additional Information: Source Context
  system_u:system_r:mongod_t:s0 Target Context
  system_u:object_r:sysctl_vm_t:s0 Target Objects
  /proc/sys/vm/zone_reclaim_mode [ file ] Source
  mongod Source Path   /usr/bin/mongod Port
  Unknown Host  HOST Source RPM Packages
  mongodb-server-2.0.2-5.fc15 Target RPM Packages Policy RPM
  selinux-policy-3.9.16-48.fc15 Selinux Enabled   True
  Policy Type   targeted Enforcing Mode
  Enforcing Host Name toxin Platform
  Linux HOST 2.6.41.4-1.fc15.x86_64 #1 SMP Tue Nov 29 11:53:48 UTC
  2011 x86_64 x86_64 Alert Count   3 First Seen
  Tue 17 Jan 2012 02:00:14 PM EST Last Seen Tue
  17 Jan 2012 02:02:46 PM EST Local ID
  bc6ed9f8-5013-4aff-8b7d-c45c3add2e04
 
  Raw Audit Messages type=AVC msg=audit(1326826966.315:388): avc:
  denied  { getattr } for  pid=28298 comm=mongod
  path=/proc/sys/vm/zone_reclaim_mode dev=proc ino=515586
  scontext=system_u:system_r:mongod_t:s0
  tcontext=system_u:object_r:sysctl_vm_t:s0 tclass=file

 I have no problem adding this access.
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.11 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAk8V3RIACgkQrlYvE4MpobPT1gCgye893V1cMrUPA58ta0Gmt4sW
 i2AAoKPU29J9def7CYVTsRXTJRQ8m7aK
 =VS7p
 -END PGP SIGNATURE-
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Anyone interested in abi-compatibility-checker?

[Nathaniel McCallum]

Yes, I'll review it.

On Mon, Nov 14, 2011 at 2:46 PM, Richard Shaw hobbes1...@gmail.com wrote:
 I was looking for a way to check abi compatibility for a package I
 maintain that does not control API/ABI compatibility and found this:

 http://forge.ispras.ru/projects/abi-compliance-checker

 I already have it packaged for my own use so I thought I'd check to
 see if anyone else is interested in it, and if so, if someone will
 want to review it.

 Thanks,
 Richard
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Anyone interested in abi-compatibility-checker?

[Nathaniel McCallum]

If its perl, I'm probably not qualified. Anyone else want to take this?

On Mon, Nov 14, 2011 at 3:13 PM, Richard Shaw hobbes1...@gmail.com wrote:
 On Mon, Nov 14, 2011 at 1:48 PM, Nathaniel McCallum
 nathan...@natemccallum.com wrote:
 Yes, I'll review it.

 https://bugzilla.redhat.com/show_bug.cgi?id=753900

 It's perl based so if you're not familiar with perl packaging (this is
 my first perl package) it might help to get someone from the perl-sig
 to review it as well.

 Thanks,
 Richard
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does git merge have so much trouble with Fedora package branches?

[Nathaniel McCallum]

On Wed, Nov 9, 2011 at 8:46 PM, Adam Williamson awill...@redhat.com wrote:
 I'm currently going through and bumping several packages whose Rawhide
 builds have got behind their F16 builds.

 I've come across several packages where git merge hit 'conflicts' for no
 readily apparently reason in this case.

http://nathaniel.themccallums.org/2010/10/18/using-git-fast-forward-merging-to-keep-branches-in-sync/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: When are Qemu SPARC/PPC coming back?

[Nathaniel McCallum]

On Wed, Sep 14, 2011 at 8:13 PM, Josh Boyer jwbo...@gmail.com wrote:
 On Wed, Sep 14, 2011 at 7:29 PM, Nathaniel McCallum
 nathan...@natemccallum.com wrote:
 The context for this question can be found here:
 http://lists.fedoraproject.org/pipermail/virt-maint/2011-March/002289.html
 https://bugzilla.redhat.com/show_bug.cgi?id=679179

 What I'm not fine with is that there seems to be no desire to bring
 these packages back. I spoke with several Red Hat virt people and the
 consensus was that SPARC/PPC don't work. I beg to differ. I am
 building asm software on them right now. They are an invaluable
 software testing platform, even with their relative age.

 So in short, can we please bring back SPARC/PPC? I realize that we'll
 need a bit of build system magickery, but I really think its worth it.

 No.  Not magickery.  Basically, it needs a build-able openbios or SLOF
 (in the ppc case).  And since Fedora doesn't provide cross
 compilation, that is going to be hard to do in this case.

 As I see it, there is likely one option.  It is possible that we
 leverage the secondary architecture builders for PPC and SPARC and
 natively build the code, then allow an exception for i686/x86_64
 packages to use that natively built openbios/slof.  It would need
 FESCo approval, but exceptions for bootstrapping have been granted
 before.

 All of this is predicated on someone stepping forward to do the work.
 So far, we've found people that don't want to do the work but we need
 to work the opposite angle.

No. Not magickery. ... Fedora doesn't provide cross compilation ...

How is this not magickery? Heck, even the build them natively and
allow other arches to use them is magickery...

Of course, there is a second option, and one that require far less
work: use the binaries that qemu provides. Yes, I know its evil and
all that (and I agree). Except that in this case the binaries are made
form open code that's just hard to build (and absent investment in
infrastructure, won't get any easier) and for which upstream already
does the hard work. Further these binary firmwares are actually
running in an emulator and as such the possible damage is approaching
0. Will it be harder to debug? Maybe, but I doubt it. In fact, you
could make an argument that shipping the upstream bios builds is the
best way to get upstream support for our build.

I'm happy for this issue to go to FESCo, but I don't think this issue
should be dropped. Having the ability to test software on the
not-so-obscure PPC and SPARC (seriously, we ship sh4/m68k, but not
these two?) is a really important feature, the lack of which will cost
people real money (or worse, they'll just go to Debian/Ubuntu who seem
to have no problem packaging it).

And lastly, lest I just seem like I'm asking for stuff for free, let
me know what I can do to help.

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: When are Qemu SPARC/PPC coming back?

[Nathaniel McCallum]

On Wed, Sep 14, 2011 at 9:12 PM, Josh Boyer jwbo...@gmail.com wrote:
 On Wed, Sep 14, 2011 at 8:45 PM, Nathaniel McCallum
 nathan...@natemccallum.com wrote:
 On Wed, Sep 14, 2011 at 8:13 PM, Josh Boyer jwbo...@gmail.com wrote:
 On Wed, Sep 14, 2011 at 7:29 PM, Nathaniel McCallum
 nathan...@natemccallum.com wrote:
 The context for this question can be found here:
 http://lists.fedoraproject.org/pipermail/virt-maint/2011-March/002289.html
 https://bugzilla.redhat.com/show_bug.cgi?id=679179

 What I'm not fine with is that there seems to be no desire to bring
 these packages back. I spoke with several Red Hat virt people and the
 consensus was that SPARC/PPC don't work. I beg to differ. I am
 building asm software on them right now. They are an invaluable
 software testing platform, even with their relative age.

 So in short, can we please bring back SPARC/PPC? I realize that we'll
 need a bit of build system magickery, but I really think its worth it.

 No.  Not magickery.  Basically, it needs a build-able openbios or SLOF
 (in the ppc case).  And since Fedora doesn't provide cross
 compilation, that is going to be hard to do in this case.

 As I see it, there is likely one option.  It is possible that we
 leverage the secondary architecture builders for PPC and SPARC and
 natively build the code, then allow an exception for i686/x86_64
 packages to use that natively built openbios/slof.  It would need
 FESCo approval, but exceptions for bootstrapping have been granted
 before.

 All of this is predicated on someone stepping forward to do the work.
 So far, we've found people that don't want to do the work but we need
 to work the opposite angle.

 No. Not magickery. ... Fedora doesn't provide cross compilation ...

 How is this not magickery? Heck, even the build them natively and
 allow other arches to use them is magickery...

 Not it's not.  You build them as noarch.  It's not magic at all.

 Of course, there is a second option, and one that require far less
 work: use the binaries that qemu provides. Yes, I know its evil and
 all that (and I agree). Except that in this case the binaries are made
 form open code that's just hard to build (and absent investment in
 infrastructure, won't get any easier) and for which upstream already
 does the hard work. Further these binary firmwares are actually
 running in an emulator and as such the possible damage is approaching
 0. Will it be harder to debug? Maybe, but I doubt it. In fact, you
 could make an argument that shipping the upstream bios builds is the
 best way to get upstream support for our build.

 You could try and get an exception from FESCo for that, yes.  I'm not
 sure it would be approved until someone actually tries building them
 first.

Care to walk me through the process?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Compiling 32bit on 64bit Fedora

[Nathaniel McCallum]

gcc -m32 -o foo foo.c gives me:
/usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file
or directory

If I copy the gnu/stubs-32.h file from the 32bit glibc-devel package
into the right place and run the command above again I get:
/usr/bin/ld: cannot find crt1.o: No such file or directory
/usr/bin/ld: cannot find crti.o: No such file or directory
/usr/bin/ld: skipping
incompatible /usr/lib/gcc/x86_64-redhat-linux/4.6.1/libgcc_s.so when
searching for -lgcc_s
/usr/bin/ld: cannot find -lgcc_s
/usr/bin/ld: skipping incompatible /usr/lib64/libc.so when searching for
-lc
/usr/bin/ld: cannot find -lc
/usr/bin/ld: skipping
incompatible /usr/lib/gcc/x86_64-redhat-linux/4.6.1/libgcc_s.so when
searching for -lgcc_s
/usr/bin/ld: cannot find -lgcc_s
/usr/bin/ld: cannot find crtn.o: No such file or directory
collect2: ld returned 1 exit status

Hrm...

Am I doing something wrong? Or is this a packaging bug? I can't think of
any reason why I shouldn't be able to compile at least a basic C program
with no deps as 32bit on 64bit.

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Compiling 32bit on 64bit Fedora

[Nathaniel McCallum]

On Wed, Sep 7, 2011 at 11:56 AM, Ricky Zhou ri...@fedoraproject.org wrote:
 On 2011-09-07 11:52:58 AM, Nathaniel McCallum wrote:
 gcc -m32 -o foo foo.c gives me:
 /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file
 or directory

 If I copy the gnu/stubs-32.h file from the 32bit glibc-devel package
 into the right place and run the command above again I get:
 I don't think you should need to copy files manually like that - just
 install glibc-devel.i686 and libgcc.i686.

That was what I thought... Sot it was the first thing I tried (note,
this is F16):
$ sudo yum install glibc-devel.i686
Loaded plugins: fastestmirror, langpacks, presto, refresh-packagekit,
remove-with-leaves, rpm-warm-cache, show-
  : leaves, versionlock
Loading mirror speeds from cached hostfile
 * fedora: www.gtlib.gatech.edu
 * updates: mirrors.servercentral.net
 * updates-testing: mirror.fdcservers.net
Setting up Install Process
No package glibc-devel.i686 available.
Error: Nothing to do
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Compiling 32bit on 64bit Fedora

[Nathaniel McCallum]

On Wed, Sep 7, 2011 at 12:04 PM, Nathaniel McCallum
nathan...@natemccallum.com wrote:
 On Wed, Sep 7, 2011 at 11:56 AM, Ricky Zhou ri...@fedoraproject.org wrote:
 On 2011-09-07 11:52:58 AM, Nathaniel McCallum wrote:
 gcc -m32 -o foo foo.c gives me:
 /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file
 or directory

 If I copy the gnu/stubs-32.h file from the 32bit glibc-devel package
 into the right place and run the command above again I get:
 I don't think you should need to copy files manually like that - just
 install glibc-devel.i686 and libgcc.i686.

 That was what I thought... Sot it was the first thing I tried (note,
 this is F16):
 $ sudo yum install glibc-devel.i686
 Loaded plugins: fastestmirror, langpacks, presto, refresh-packagekit,
 remove-with-leaves, rpm-warm-cache, show-
              : leaves, versionlock
 Loading mirror speeds from cached hostfile
  * fedora: www.gtlib.gatech.edu
  * updates: mirrors.servercentral.net
  * updates-testing: mirror.fdcservers.net
 Setting up Install Process
 No package glibc-devel.i686 available.
 Error: Nothing to do

Could this be related to the recent events surrounding glibc that
caused RPMs to be pulled from the repo?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Compiling 32bit on 64bit Fedora

[Nathaniel McCallum]

On Wed, Sep 7, 2011 at 12:15 PM, Ricky Zhou ri...@fedoraproject.org wrote:
 On 2011-09-07 12:04:06 PM, Nathaniel McCallum wrote:
 That was what I thought... Sot it was the first thing I tried (note,
 this is F16):
 $ sudo yum install glibc-devel.i686
 Loaded plugins: fastestmirror, langpacks, presto, refresh-packagekit,
 remove-with-leaves, rpm-warm-cache, show-
               : leaves, versionlock
 Loading mirror speeds from cached hostfile
  * fedora: www.gtlib.gatech.edu
  * updates: mirrors.servercentral.net
  * updates-testing: mirror.fdcservers.net
 Setting up Install Process
 No package glibc-devel.i686 available.
 Error: Nothing to do
 Strange - just tried a yum clean all followed by yum install
 glibc-devel.i686 libgcc.i686 on Kevin's F16 test machine - maybe
 whatever issue with glibc-devel in the repos has been fixed now?

I don't appear to have any i[356]86 packages in any of the repos on my
F16 box. Is there an rpm I'm missing?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Compiling 32bit on 64bit Fedora

[Nathaniel McCallum]

On Wed, Sep 7, 2011 at 1:04 PM, Kevin Fenzi ke...@scrye.com wrote:
 On Wed, 7 Sep 2011 12:23:11 -0400
 Nathaniel McCallum nathan...@natemccallum.com wrote:

 I don't appear to have any i[356]86 packages in any of the repos on my
 F16 box. Is there an rpm I'm missing?

 No, it should show them out of the box.

 Does:

 yum --noplugins list glibc-devel.i686

 work?

Yes, It does! Which plugin would filter those out?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Need Little IT advice Here...

[Nathaniel McCallum]

xguest is the way to do this because it involves much more than simply
wiping the hard drive. xguest also locks down the account with selinux
so that the vector for attacks is quite minimal.

On Fri, Aug 12, 2011 at 3:21 AM, Dave Quigley seli...@davequigley.com wrote:
 You should look into the xguest package on Fedora. It provides a
 sandboxed user which gets wiped on logout. If you need to add more tools
 for the guest to use I'd suggest contacting Dan Walsh for additional
 help since he is the maintainer.

 Dave

 On 8/11/2011 11:58 PM, Manuel Escudero wrote:
 Hi, I was Wondering if there was a tool for Linux in general
 that let me undo the system changes at reboot or something
 like that, For example:

 I want to set a standard configuration in a machine and then
 let that machine to be used by many users, but as soon as
 the user Log Out (preferably in that moment)
 I want the machine to undo all the possible
 changes the user may have done while he/she was using it.

 I've seen this behavior on Windows Machines in Schools and Offices,
 and I know it has something to do about a server controlling all the
 individual computers but I want to apply that behavior to a Single Linux
 computer without having the server in the middle...

 If there's not a General Linux Tool I would like to Know wich
 distro and desktop enviroment are the best choice to get this done,
 using what tools,

 P.S. it's like... Having a customized LiveCD Behavior but with
 the system installed, so if I need to do changes, I can ensure I can
 do them without many problems, and then Lock the system again...

 Hope somebody knows,

 Thanks!

 --
 Manuel Escudero
 Linux User #509052
 Twitter: @Jmlevick http://twitter.com/Jmlevick
 Blogger: Blog Xenode http://xenodesystems.blogspot.com/
 PGP/GnuPG: E2F5 12FA E1C3 FA58 CF15  8481 B77B 00CA C1E1 0FA7
 Xenode Systems - xenodesystems.com http://www.xenodesystems.com/ -
 Conéctate a Tu Mundo



 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fwd: Rapid DHCP

[Nathaniel McCallum]

On Wed, Aug 3, 2011 at 1:38 PM, Bill McGonigle b...@bfccomputing.com wrote:
 On 08/03/2011 01:19 PM, Dan Williams wrote:
 The Ubuntu NM maintainer has posted a WIP patch that makes NM say it's
 connected immediately if at least one of IPv4 or IPv6 completes.
 Currently if both are enabled, NM won't say it's connected until both
 are done (and result in either success or failure).  That at least
 speeds up the perceived connection speed, which isn't a bad thing.

 Nice, that will help almost everybody, but possibly it could break
 somebody who's depending explicitly on IPv6 (or IPv4 in the other case)
 for an app and now thinks the network is up.

 How do apps, e.g. Thunderbird, know when they're online?  dbus, /sys?

 If this change happens, there ought to be a way for that small slice of
 apps to check to see that the stack they demand is really up, if they're
 depending on it (more directly than parsing text output of userland
 tools).  Probably this already exists, right?

It seems like NM's state transitions need to become more explicit.
1. IPv4 connected
2. IPv6 connected
3. internet connected (including proxy discovery)

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fwd: Rapid DHCP

[Nathaniel McCallum]

On Wed, Aug 3, 2011 at 1:43 PM, Nathaniel McCallum
nathan...@natemccallum.com wrote:
 On Wed, Aug 3, 2011 at 1:38 PM, Bill McGonigle b...@bfccomputing.com wrote:
 On 08/03/2011 01:19 PM, Dan Williams wrote:
 The Ubuntu NM maintainer has posted a WIP patch that makes NM say it's
 connected immediately if at least one of IPv4 or IPv6 completes.
 Currently if both are enabled, NM won't say it's connected until both
 are done (and result in either success or failure).  That at least
 speeds up the perceived connection speed, which isn't a bad thing.

 Nice, that will help almost everybody, but possibly it could break
 somebody who's depending explicitly on IPv6 (or IPv4 in the other case)
 for an app and now thinks the network is up.

 How do apps, e.g. Thunderbird, know when they're online?  dbus, /sys?

 If this change happens, there ought to be a way for that small slice of
 apps to check to see that the stack they demand is really up, if they're
 depending on it (more directly than parsing text output of userland
 tools).  Probably this already exists, right?

 It seems like NM's state transitions need to become more explicit.
 1. IPv4 connected
 2. IPv6 connected
 3. internet connected (including proxy discovery)

I have also thought that it would be interesting to handle the case of
VPNs in this way as well. That way an app can discover if a resource
(like a mail server) requires a certain VPN to be up. It can then
request the VPN to be connected, or at least not throw up connection
errors if the VPN is down.

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fwd: Rapid DHCP

[Nathaniel McCallum]

Dan, that works on wireless networks. On wired networks the ARP technique
determines *which* of the valid leases you should attempt to restore. So on
a wired network you:
1. ARP the known DHCP server IPs to discover the subnet.
2. ARP the IP from the valid lease on that subnet to avoid collision.
3. Restore the ifconfig from the still valid lease.
4. Renew the lease.

This should be pretty sane and gives large speedups to resuming on wired
(which people with docks do a lot).

Nathaniel
On Jul 30, 2011 6:45 PM, Dan Williams d...@redhat.com wrote:
 On Sat, 2011-07-30 at 11:46 -0400, Genes MailLists wrote:
 On 07/30/2011 10:37 AM, Lennart Poettering wrote:
  On Sat, 30.07.11 10:31, Genes MailLists (li...@sapience.com) wrote:
 
  http://cafbit.com/entry/rapid_dhcp_or_how_do
 

 
  IIRC connman (i.e. NM's competition) can do the ARP magic, too.
 
  Lennart
 


 Seems like a pretty reasonable thing to do - surely better than just
 waiting for a timeout to decide if the server is not there ... are you
 aware of any gotcha's ?

 NM already keeps DHCP information around based on the network you're
 connecting to, so we don't need to ARP a bunch of servers just to
 determine whether the DHCP server we wanted is still there. dhclient is
 smart enough to attempt to reclaim the lease if it's not already
 expired. Note that the Mac attempts to ARP a number of different DHCP
 servers (192.168.2.1, 192.168.4.1, 192.168.1.1) which would be pointless
 with NetworkManager, because it's extremely unlikely that the DHCP
 server on your wifi network has changed; NM would simply know that the
 last DHCP server used *on that wifi network* was 192.168.1.1 and not
 bother to try talking to other ones like Mac OS X appears to do.

 NM could use the same method of ARPing multiple DHCP servers that Mac OS
 X does, but it wouldn't provide much additional benefit, if any, at
 least on WiFi networks. It could be used on wired networks to (a)
 determine which wired network you're connected to, and (b) do rapid
 DHCP. Again, NM already knows what DHCP server and what lease was last
 used on the specific wifi network you just connected to, and it won't
 bother doing a DISCOVER, it'll just jump to RENEW if your lease is still
 valid.

 What's unique about the method described there is that the Mac
 configures the interface with the same IP address it previously had if
 the lease is still valid, while NetworkManager waits for the DHCP server
 confirm the lease. So we could presumptuously configure the interface
 with the previous address from the lease and then only tear it down if
 the DHCP server fails or rejects the renewal.

 Of course, none of this helps if your DHCP leases are short, but it
 certainly helps if you put your laptop to sleep a lot and wake it up in
 the same location.

 Dan

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rfc/headsup: graphics driver packaging in F16+

[Nathaniel McCallum]

On Tue, 2011-04-12 at 13:38 -0400, Adam Jackson wrote:
 On Tue, 2011-04-12 at 12:23 -0400, Bill Nottingham wrote:
  Adam Jackson (a...@redhat.com) said: 
   So that's the rough plan.  Comments appreciated if I'm overlooking
   anything.
  
  The question would be how we ensure that these additional drivers are in the
  install image, or in the installed system, if necessary. Or do we not care
  if they get vesa?  How would users be informed/able to install drivers if
  necessary? (I don't know that PK search is good here.)
 
 To a first approximation, I deeply do not care.  If you're choosing to
 use an s3virge in 2011 you've already decided to make your life hard.
 
 But if we're trying to be completionists about it, import the data
 from /usr/share/hwdata/videoaliases/*.xinf into virtual Provides for
 each driver package and teach packagekit or whatever how to cope.
 Something like this:
 
 http://lists.fedoraproject.org/pipermail/devel/2010-April/135004.html
 
 But then, if we had _that_, comps could grow a fourth class for
 as-needed and we'd just list all driver packages there, including cups
 and webcam drivers and etc.  Install image creation would pull them all
 in; anaconda would filter the available as-needed's based on target
 hardware.
 
 In that scenario you'd still need to do manual selection of some driver
 packages for critpathness, but, okay.

With this approach, you have lost a critical feature: the ability for
you to change your hardware (or move the software bits to a different
computer) and have everything automatically work.

Nathaniel

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rfc/headsup: graphics driver packaging in F16+

[Nathaniel McCallum]

On Tue, 2011-04-12 at 13:57 -0400, Casey Dahlin wrote:
 On Tue, Apr 12, 2011 at 01:48:19PM -0400, Nathaniel McCallum wrote:
  
  With this approach, you have lost a critical feature: the ability for
  you to change your hardware (or move the software bits to a different
  computer) and have everything automatically work.
  
  Nathaniel
 
 You lose it for a couple of strange usecases though:
 
 1) Moving from a card that is up to date in what it supports to an older
 card that isn't (rare).
 
 2) Moving from one crappy ancient card to another (plausible, but still
 rare).
 
 The vesa driver should mean some workable video support in either case,
 and from there, if we were really, truly concerned, we could detect the
 need for the driver and prompt to install it. That's starting to sound
 like the bad old days of kudzu though, and I'd be surprised if anyone
 really felt this was worth that effort.

I think losing it in those cases is probably acceptable.  My thought is
that the disk space for drivers is minimal, lets just support everything
(or at least the current stuff) in a single install.  My concern isn't
moving to and/or between rare old cards.  My concern is moving from
nouveau to intel or radeon...  The big drivers should definitely be
installed on every system, regardless of its hardware.

Nathaniel

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rfc/headsup: graphics driver packaging in F16+

[Nathaniel McCallum]

On Tue, 2011-04-12 at 14:00 -0400, Adam Jackson wrote:
 On Tue, 2011-04-12 at 13:48 -0400, Nathaniel McCallum wrote:
  On Tue, 2011-04-12 at 13:38 -0400, Adam Jackson wrote:
   But then, if we had _that_, comps could grow a fourth class for
   as-needed and we'd just list all driver packages there, including cups
   and webcam drivers and etc.  Install image creation would pull them all
   in; anaconda would filter the available as-needed's based on target
   hardware.
   
   In that scenario you'd still need to do manual selection of some driver
   packages for critpathness, but, okay.
  
  With this approach, you have lost a critical feature: the ability for
  you to change your hardware (or move the software bits to a different
  computer) and have everything automatically work.
 
 Assuming pk actually had this feature, the next time you booted pk would
 happily tell you about what driver you're missing.

*If* it booted to a sane state where pk could tell you this, then yes I
agree.

Nathaniel

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rfc/headsup: graphics driver packaging in F16+

[Nathaniel McCallum]

On Tue, 2011-04-12 at 19:06 +0100, Matthew Garrett wrote:
 On Tue, Apr 12, 2011 at 01:48:19PM -0400, Nathaniel McCallum wrote:
 
  With this approach, you have lost a critical feature: the ability for
  you to change your hardware (or move the software bits to a different
  computer) and have everything automatically work.
 
 You change the card, the system comes up in VESA, Packagekit (or 
 whatever) notices new hardware and installs the drivers. Seems pretty 
 automatic?

Limited to video drivers? yes.  I just can't help but think that some
will be unable to resist the temptation to do the same thing for
firmware.  In this case, pk will happily notify you, but you won't have
access to the repo to handle the change to the new networking card, etc.

Nathaniel

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rfc/headsup: graphics driver packaging in F16+

[Nathaniel McCallum]

On Tue, 2011-04-12 at 19:06 +0100, Matthew Garrett wrote:
 On Tue, Apr 12, 2011 at 01:48:19PM -0400, Nathaniel McCallum wrote:
 
  With this approach, you have lost a critical feature: the ability for
  you to change your hardware (or move the software bits to a different
  computer) and have everything automatically work.
 
 You change the card, the system comes up in VESA, Packagekit (or 
 whatever) notices new hardware and installs the drivers. Seems pretty 
 automatic?

I should say that about 2.5 years ago I wrote a patch for xorg to print
out an inventory of the hardware a given driver supported.
http://cgit.freedesktop.org/xorg/xserver/commit/?id=8e368cf5b964f1d29fda0a463f9510457619b14d

The patch was subsequently removed by an overzealous committer who
thought it would be fun to remove useful functionality he thought xorg
didn't need anymore (name concealed to protect the guilty).

That patch above, or a similar version, could be used to automatically
generate the PK list from the binary at rpm build time, as well as be
useful in a variety of other cases.

Nathaniel

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rfc/headsup: graphics driver packaging in F16+

[Nathaniel McCallum]

On Tue, 2011-04-12 at 13:18 -0500, Chris Adams wrote:
 Once upon a time, Nathaniel McCallum nathan...@natemccallum.com said:
  With this approach, you have lost a critical feature: the ability for
  you to change your hardware (or move the software bits to a different
  computer) and have everything automatically work.
 
 That has been the case off and on for a long time, with kernels and
 glibc split for i386/i686, and then kernels for PAE.  Old hardware is
 always going to fall off the tail.
 
 It isn't like the packages are going to be removed, and they'll probably
 not get any less testing than they do today.  Also, since VESA will
 still be included, it should work on most any hardware.

Sure.  To be blunt: I'm in support of the move, I just want to make sure
we think about the case of hardware changes and not boot to an unusable
system...

Nathaniel

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Shared library permissions in Debian-land and Red Hat-land

[Nathaniel McCallum]

On Mon, 2011-03-28 at 16:05 -0400, Przemek Klosowski wrote:
 On 03/24/2011 02:49 PM, Kevin Kofler wrote:
  On Thursday 24 March 2011, you wrote:
  Hmm, I thought there'd be a catch. What's executable permission needed
  for? Isn't that just reading/parsing? I can do some work but I am
  totally unfamiliar with this area.
 
  Files which aren't executable aren't even considered as candidates for being
  ELF files to extract debuginfo from.
 
  Without execute permission, you'd have to check EVERY SINGLE installed FILE
  for being ELF, that might be a significant performance hit. It'd have to be
  tried at least.
 
 OK, so executable permission is used as a tag for identifying ELF files.
 It's a little inelegant because there are some negative side effects
 from executing those non-executable files.
 
 If, hypothetically, we wanted to change that, is there any other way to
 reliably mark ELF files? I could think of those:
 
 - extended  filesystem attributes? works but might be FS-dependent
 - make the files owned by a special ELF group
 - a system-level directory of ELF files maintained by e.g. RPM

Well, technically you could still use +x for other non-shared library
ELF files, you'd just also need to look for .so files.  That seems to me
the simplest solution and should still be fast since the filename is in
the directory inode (which you have to read anyway).

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firefox 4 for f14?

[Nathaniel McCallum]

On Wed, 2011-03-23 at 16:41 -0500, Adam Miller wrote:
 On Wed, Mar 23, 2011 at 10:35:55PM +0100, Joshua C. wrote:
  Hi,
  
  fedora is known for offering the latest and greates software and
  being on the edge etc. So I was just wondering if the latest f14
  will ever get the latest firefox 4.0?
  
  Recompilation of the packages from f15 is not such a good option.
  
  --jason
 
 While we are known for latest and greatest, I'm not 100% sure the jump
 from Firefox 3.x to Firefox 4.x is within the most recent Updates 
 Policy[0] because of the drastic changes between the two releases and
 the amount of user visible change that would result. I am also not the 
 maintainer of Firefox so can't really speak to this in any form of 
 authority but wanted to reply mainly for this next tid bit  with 
 many thanks to Spot, there is currently a fully functional Firefox 4 
 repository for Fedora 14, more information and instructions here: 

There are packages in the critical path which depend on xulrunner.
Firefox 4's xulrunner is neither ABI nor API compatible with earlier
versions.  I can't help but think that such an update would be unwise.

Nathaniel

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

[Nathaniel McCallum]

On Wed, 2011-02-23 at 09:27 -0500, Josef Bacik wrote:
 On Wed, Feb 23, 2011 at 9:18 AM, John Reiser jrei...@bitwagon.com wrote:
  On 02/23/2011 05:07 AM, drago01 wrote:
  Defaults should be chooses on the metric what provides the best
  experience for the users not based on what we have been doing in the
  past (i.e stagnation).
 
  *One* data corruption constitutes EPIC FAIL.  Btrfs is too young,
  and will be for yet a while longer.
 
 
 Well if data corruption is the test then we shouldn't be using Ext4
 either, there was one fixed as recently as the beginning of this
 month.  File systems are software like anything else, there will be
 bugs.  Off the top of my head I can think of 3 data corrupters we've
 had in 4 years of working on BTRFS, and they've all been hard to hit
 and have not to my knowledge been seen by users, only us developers in
 testing.  BTRFS is young, but we have to start somewhere.  Thanks,

From a user's perspective, I've been using btrfs for about 1.5 years on
multiple computers and I've been very happy (particularly on my netbook
where the transparent compression increases the disk writes
considerably).  I had one small problem where btrfs wouldn't mount, but
by booting off of a newer kernel I had no problems.

Thanks for your hard work on btrfs everyone!

Nathaniel

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Can someone please give this ticket some attention?

[Nathaniel McCallum]

https://bugzilla.redhat.com/show_bug.cgi?id=625187

This bug basically makes Fedora completely unusable in rawhide for
NVA{3,5,8} users.  At this point I think it should be made a blocker.
Multiple people have volunteered help to resolve it, but there has been
no movement for months, no link to an upstream bug and no advice on how
to move the ticket forward.  Please advise.

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Rawhide: Gnome totally busted after today's (?) round of updates

[Nathaniel McCallum]

On 01/11/2011 05:28 PM, Horst H. von Brand wrote:
 After yum eraseing rhythmbox (it did hold back some hundreds of updates),
 and rebooting into my Gnome/Openbox session (and leaving, the screensaver
 kicked in) I found the background flickering. I gave the password to the
 screensaver, and the background stabilized, but nothing else (Gnome panels,
 etc) did show up.
 
 Went to alt-ctrl-F2, logged into root and did:
 
 telinit 3
 telinit 5
 
 No X did show up. Rebooted by ctrl-alt-del, and tried with plain Gnome. No
 dice either. Rebooted again, now running XFCE4.

Same for me, also running XFCE.  I also created a new/clean user to see
if there was a problem with my gnome config, but the problem exists
there as well.  I searched for bugs, but didn't find anything.  I'm not
sure what component to file it under.

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Testing Requested: Natus

[Nathaniel McCallum]

There are now builds of Natus for all versions of Fedora and EL6.  I'd
love some testing and karma if possible.  You can find builds here:
http://koji.fedoraproject.org/koji/packageinfo?packageID=11322

Bodhi updates are here:
https://admin.fedoraproject.org/updates/natus

Thanks!

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Review Swap: Natus

[Nathaniel McCallum]

Anyone have a review they would like to swap?

https://bugzilla.redhat.com/show_bug.cgi?id=662349
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 15, new and exciting plans

[Nathaniel McCallum]

On 11/15/2010 10:11 AM, Adam Jackson wrote:
 On Fri, 2010-11-12 at 09:35 -0700, Kevin Fenzi wrote:
 
 * Can we finally remove hal? (xfce4.8 shouldn't need it anymore with
   any luck). 
 
 Only 30 packages left requiring it, according to repoquery.  smolt's
 probably the most interesting one to fix, if anyone's looking for a
 project.

For the curious, the 30 packages (in rawhide) are:

HAL itself (and its satellite packages):
hal-0:0.5.14-6.fc15.x86_64
hal-devel-0:0.5.14-6.fc15.i686
hal-devel-0:0.5.14-6.fc15.x86_64
hal-docs-0:0.5.14-6.fc15.x86_64
hal-info-0:20090716-3.fc12.noarch
hal-storage-addon-0:0.5.14-6.fc15.x86_64

Others:
beldi-0:0.9.25-2.fc12.x86_64
blueman-0:1.21-6.fc15.x86_64
exaile-0:0.3.2.0-2.fc14.noarch
fedora-setup-keyboard-0:0.6-1.fc13.x86_64
gnome-device-manager-libs-0:0.2-6.fc12.i686
gnome-device-manager-libs-0:0.2-6.fc12.x86_64
ifuse-0:1.0.0-1.fc14.x86_64
kdelibs-6:4.5.3-2.fc15.i686
kdelibs-6:4.5.3-2.fc15.x86_64
libconcord-0:0.21-10.fc14.i686
libconcord-0:0.21-10.fc14.x86_64
lxsession-0:0.4.4-1.fc14.x86_64
matahari-0:0.0.5-4.fc15.x86_64
nut-0:2.4.3-8.fc15.x86_64
nut-cgi-0:2.4.3-8.fc15.x86_64
nut-client-0:2.4.3-8.fc15.i686
nut-client-0:2.4.3-8.fc15.x86_64
nut-hal-0:2.4.3-8.fc15.x86_64
ovirt-server-installer-0:0.100-5.fc15.noarch
razertool-0:0.0.7-7.fc14.x86_64
smolt-0:1.4.2.2-3.fc15.noarch
xfce4-cddrive-plugin-0:0.0.1-3.fc13.x86_64
xfce4-power-manager-0:0.8.5-1.fc15.x86_64
xfce4-volstatus-icon-0:0.1.0-6.fc12.x86_64

I know that at least a few of these are just an upgrade and/or rebuild away.

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: git merge problem

[Nathaniel McCallum]

On 10/27/2010 10:38 AM, Neal Becker wrote:
 Sorry to be so stupid.  I don't really have a lot of time to spend on this, 
 maybe someone can give me a clue.
 
 I updated unuran master just fine.
 
 Then I did my usual dance:
 
 fedpkg switch-branch f14
 git merge master
 fedpkg push
 fedpkg build
 bohdi ...
 
 fedpkg switch-branch f13
 Branch f13 set up to track remote branch f13/master from origin.
 [nbec...@nbecker1 unuran]$ git merge master
 Auto-merging .gitignore
 CONFLICT (add/add): Merge conflict in .gitignore
 Auto-merging sources
 CONFLICT (content): Merge conflict in sources
 Auto-merging unuran.spec
 CONFLICT (content): Merge conflict in unuran.spec
 Automatic merge failed; fix conflicts and then commit the result.
 
 What's wrong and how to fix it?

See my recent blog on this topic:

http://nathaniel.themccallums.org/2010/10/18/using-git-fast-forward-merging-to-keep-branches-in-sync/

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide report: 20101019 changes

[Nathaniel McCallum]

On 10/19/2010 11:25 AM, seth vidal wrote:
 On Tue, 2010-10-19 at 16:22 +0100, Matthew Garrett wrote:

 Hmm, So when this was broken a lot of bugs were triggered? 

 Sure seems like if a lot of bugs are being triggered then it is NOT a
 niche usecase.

 You can't have it both ways.

 Very few people do it. When they do, lots of things break. It's kind of 
 like trying to run Fedora under the NetBSD Linux emulation. Nobody does 
 it, but if they did they'd find that a surprising quantity of code 
 wouldn't work.
 
 you keep asserting this claim - and yet all the evidence in terms of
 concerned users comes to the contrary.
 
 Can you document or backup your assertion?

This seems like a question smolt should be able to answer...

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: libgpod 0.8.0 in F13

[Nathaniel McCallum]

On 10/13/2010 09:37 AM, Rex Dieter wrote:
 Nathaniel McCallum wrote:
 
 I've just tagged libgpod 0.8.0 for F13 updates-testing.  This is the
 first step to an updated Banshee (1.8.0) in F13 as well as better
 iPhone/iPad support in the existing Rhythmbox.  I'd really like to get
 some testing on this, so please, if you are using updates-testing and
 have any Apple-brand device, please check to see that your device will
 successfully sync with Rhythmbox with the new libgpod.
 
 Do you expect other libgpod-using apps need to be rebuilt too?  (I can test 
 amarok against my ipod touch, which currently doesn't work as-is).

No apps should need to be rebuilt.  So you can upgrade libgpod and
amarok *should* just work, as long as nothing is broken.

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

libgpod 0.8.0 in F13

[Nathaniel McCallum]

I've just tagged libgpod 0.8.0 for F13 updates-testing.  This is the
first step to an updated Banshee (1.8.0) in F13 as well as better
iPhone/iPad support in the existing Rhythmbox.  I'd really like to get
some testing on this, so please, if you are using updates-testing and
have any Apple-brand device, please check to see that your device will
successfully sync with Rhythmbox with the new libgpod.

Thanks!
Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

RFC: Upgrade Banshee to 1.8.0 in F13

[Nathaniel McCallum]

I'd like to propose that we upgrade banshee (and
banshee-community-extensions) to 1.8.0 in F13.  I estimate that this
will close about half our open bugs.  Doing this will require the
following package upgrades in F13:

* clutter-sharp - Upgrade (I'm pretty sure Banshee is the only user)
* gio-sharp - New
* gudev-sharp - New
* gkeyfile-sharp - New
* gtk-sharp-beans - New
* libgpod - Upgrade (0.7.93  0.7.95; bugfix release)

The only thing complicated here is the buildroot override requirement
and making sure that we ship the new banshee-community-extensions in the
same update as the new banshee.

Currently, I do not think it is feasible to backport this to F12, so F13
would be the latest version.

Thoughts? Comments?

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Upgrade Banshee to 1.8.0 in F13

[Nathaniel McCallum]

Well, seeing as I am one of the maintainers, I don't have a problem with
that.  Does anyone know if it is disabled for a reason?

On 10/11/2010 12:38 PM, Andy Shevchenko wrote:
 Agree if the maintainer enables the MPRISv2 support there.
 
 On Mon, Oct 11, 2010 at 7:20 PM, Nathaniel McCallum
 nathan...@natemccallum.com wrote:
 I'd like to propose that we upgrade banshee (and
 banshee-community-extensions) to 1.8.0 in F13.  I estimate that this
 will close about half our open bugs.  Doing this will require the
 following package upgrades in F13:

 * clutter-sharp - Upgrade (I'm pretty sure Banshee is the only user)
 * gio-sharp - New
 * gudev-sharp - New
 * gkeyfile-sharp - New
 * gtk-sharp-beans - New
 * libgpod - Upgrade (0.7.93  0.7.95; bugfix release)

 The only thing complicated here is the buildroot override requirement
 and making sure that we ship the new banshee-community-extensions in the
 same update as the new banshee.

 Currently, I do not think it is feasible to backport this to F12, so F13
 would be the latest version.

 Thoughts? Comments?

 Nathaniel
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel

 
 
 

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Upgrade Banshee to 1.8.0 in F13

[Nathaniel McCallum]

I don't actually see that as a build option in either banshee or
banshee-community-extensions.  Am I missing something?

Nathaniel

On 10/11/2010 12:38 PM, Andy Shevchenko wrote:
 Agree if the maintainer enables the MPRISv2 support there.
 
 On Mon, Oct 11, 2010 at 7:20 PM, Nathaniel McCallum
 nathan...@natemccallum.com wrote:
 I'd like to propose that we upgrade banshee (and
 banshee-community-extensions) to 1.8.0 in F13.  I estimate that this
 will close about half our open bugs.  Doing this will require the
 following package upgrades in F13:

 * clutter-sharp - Upgrade (I'm pretty sure Banshee is the only user)
 * gio-sharp - New
 * gudev-sharp - New
 * gkeyfile-sharp - New
 * gtk-sharp-beans - New
 * libgpod - Upgrade (0.7.93  0.7.95; bugfix release)

 The only thing complicated here is the buildroot override requirement
 and making sure that we ship the new banshee-community-extensions in the
 same update as the new banshee.

 Currently, I do not think it is feasible to backport this to F12, so F13
 would be the latest version.

 Thoughts? Comments?

 Nathaniel
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel

 
 
 

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Upgrade Banshee to 1.8.0 in F13

[Nathaniel McCallum]

On 10/11/2010 01:50 PM, Todd Zullinger wrote:
 Kevin Fenzi wrote:
 Would the libgpod update require rebuilding or changing anything
 else?  How many other packages depend on that?
 
 The libgpod update should be safe.  Though if it was up to me I'd wait
 for libgpod to reach 0.8.0.  Upstream is treating 0.7.95 like a
 release candidate.  I don't know how long it might take though.
 
 The big change between 0.7.93 and 0.7.95 is that the mono bindings
 were added, which is what Banshee 1.8 needs.  I don't have an opinion
 on whether Banshee should or shouldn't be updated in a stable release.
 I don't use it.

As someone who works closely with upstream, I can attest that 0.7.95 has
no API/ABI changes and can be seamlessly upgraded without rebuilds. 0.8
will probably be released (and packaged by me) before any of this hits
F13.  I only mentioned 0.7.95 since banshee requires this version or later.

One should keep in mind that the 0.7.9x series is the development series
leading up to 0.8.0.  Since 0.7.93 is already in F13, 0.8.0 is a natural
upgrade path.

There is only one change in 0.7.95 that may cause problems with existing
apps: stop_sync() must be called an equal number of times in order to
make the Syncing... screen on iphones/ipads/ipod touches disappear.
Previously the screen was removed after the first call to stop_sync()
(this was a bug in libgpod).  Since stop_sync() should be called once
per start_sync() invocation, this should not be a problem and since it
is a known issue, we know how to test for it. Applications depending on
the previous behaviour were depending on a bug.  Worst case is an
entirely cosmetic bug.

Nathaniel

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Upgrade Banshee to 1.8.0 in F13

[Nathaniel McCallum]

On 10/11/2010 01:37 PM, Kevin Fenzi wrote:
 On Mon, 11 Oct 2010 12:20:54 -0400
 Nathaniel McCallum nathan...@natemccallum.com wrote:
 
 I'd like to propose that we upgrade banshee (and
 banshee-community-extensions) to 1.8.0 in F13.  I estimate that this
 will close about half our open bugs.  Doing this will require the
 following package upgrades in F13:

 * clutter-sharp - Upgrade (I'm pretty sure Banshee is the only user)
 * gio-sharp - New
 * gudev-sharp - New
 * gkeyfile-sharp - New
 * gtk-sharp-beans - New
 * libgpod - Upgrade (0.7.93  0.7.95; bugfix release)

 The only thing complicated here is the buildroot override requirement
 and making sure that we ship the new banshee-community-extensions in
 the same update as the new banshee.

 Currently, I do not think it is feasible to backport this to F12, so
 F13 would be the latest version.

 Thoughts? Comments?
 
 Well, lets see: 
 
 F13 currently has version 1.6.1 in it. Looks like they follow an 'odd
 is unstable/devel, even is release/stable' method. So, all the 1.7.x
 releases were development ones. 

Correct.

 I see a lot of bugs fixed, but also a bunch of new features: 
 http://banshee.fm/download/archives/1.8.0/
 
 I see 9 open fedora bugs. 

Yes, and I think 1.8 should solve roughly half of them (I'm unable to
reproduce most of them in 1.8).  Given our limited resources, I have no
current plans to spend time on fixing bugs in the 1.6.x series (others
are free of course to work on this).

 Has the UI changed since 1.6.1? I would suspect so. 

UI has not really seen many changes.  Changes would be things like:
* Amazon MP3 Store Service
* Miro podcast guide
* iPhone support

These changes should not impact a user in any significant way (they just
show up as additional sources on the left side).

One one potentially confusing change is that the preferences dialog was
re-arraigned.  Since all preferences are transparently migrated and the
majority of users only set preferences once, this impact should be minimal.

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]

[Nathaniel McCallum]

On 10/06/2010 10:41 AM, Ralf Corsepius wrote:
 On 10/06/2010 04:08 PM, Michal Schmidt wrote:
 On Wed, 06 Oct 2010 15:26:59 +0200 Ralf Corsepius wrote:
 On 10/06/2010 02:49 PM, Matej Cepl wrote:
 Nonsense, trademarks exists to protect users and to avoid living off
 somebody else brand recognition.

 I disagree - trademarks exist to protect the manufacturer from
 loosing profits because of their products being copied.

 Ask Adidas or Nike why they sue Chinese manufacturers and you'll see.
 They'll tell you that they loose money because of being copied.

 Of course. But there's in fact no disagreement, only looking at
 different aspects of the same thing.

 Why do you think the copying takes place? Because the companies have
 built a good reputation and brand, allowing them to increase profit.

 Good quality =  good reputation =  solid brand =  better profits.
 
 I am not disagreeing that restrictive trademarks, patents, restricive 
 license etc. all make sense in the commerical world.
 
 However, this here is Fedora, a project that once was aiming at 
 Freedom - As trivial as it is, restrictive trademark policies simply 
 do not fit into this philosophy.
 
 Then copyists try to get better profits too without bothering to
 build their own good reputation, by deceiving the buyers into thinking
 the original company with good reputation produced their goods.


 I'm really quite surprised about this thread. Of all the stuff
 often put under the confusing term intellectual property I expected
 trademarks to be the least controversial.
 Well, my view differs:
 To me, restrictive trademarks are in the same league as patents and 
 closed source.
 Last century's, commercial world's instruments of protectionism which 
 contradict the philosophy behind FLOSS. It's just thanks to the fact 
 restrictive prosecution of trademarks are rare in the FLOSS world, 
 which has caused it to get away more or less unattended.

I have an idea... I'm going to create a fork of Fedora.  I'm going to
fill it full of proprietary shit.  I'm going to find the buggiest closed
drivers I can find and load them into the kernel.  I'll also make it so
that you have to type in your credit card number just to login.  I'll
register a fedora derivative domain name and SEO the hell out of it.
Then, I'll tell people my distro is called Fedora Ultimate Edition.
Everyone will believe me because I'll leave all the Fedora artwork in
place.  I'll also publish is under the pseudonym of Ralf Corsepius: Ralf
Corsepius' Fedora Ultimate Edition.

Doing this harms real people and a real organization.  The freedom to
do this is not freedom at all but lunacy.  Its quite simple.  You're
free use my work however you like, even for evil.  But you are not
allowed to claim you are me.  Fedora and Mozilla go way beyond this.
They give you the FREEDOM to call yourself Fedora and/or Mozilla so long
as the work actually represents them. That is where the freedom is
found: freedom with conditions.  Just like every single Free/Open
license: freedom with conditions.  The default state of copyright is
that you have few freedoms.  Copyleft works by granting you additional
freedoms so long as your exercise of those freedoms don't damage anyone
else's use of those freedoms.  The trademark grants of Fedora and
Mozilla work the same way: you can use the trademark so long as your use
of the trademark doesn't impede on anyone else's use of the trademark
(including the original author).  Thus, your argument actually undoes
the entire power of the GPL.

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]

[Nathaniel McCallum]

On 10/06/2010 12:12 PM, Bruno Wolff III wrote:
 On Wed, Oct 06, 2010 at 10:59:08 -0400,
   Nathaniel McCallum nathan...@natemccallum.com wrote:

 I have an idea... I'm going to create a fork of Fedora.  I'm going to
 fill it full of proprietary shit.  I'm going to find the buggiest closed
 drivers I can find and load them into the kernel.  I'll also make it so
 that you have to type in your credit card number just to login.  I'll
 register a fedora derivative domain name and SEO the hell out of it.
 Then, I'll tell people my distro is called Fedora Ultimate Edition.
 Everyone will believe me because I'll leave all the Fedora artwork in
 place.  I'll also publish is under the pseudonym of Ralf Corsepius: Ralf
 Corsepius' Fedora Ultimate Edition.
 
 The Fedora project goes pretty far in making it easy to produce an unbranded
 version of Fedora for people that want to do that. The trademark protected
 stuff is supposed to be in just a few packages that have alternative packages
 in the distro already, that can replace them. I think that makes a point
 that Fedora isn't trying to abuse trademarks to keep supposedly open source
 closed.
 
 I don't think Mozilla is trying to abuse their trademarks either (though
 there have been open source projects that have). I don't think they go as
 far as fedora in making it easy to make a rebranded application, but they
 certainly don't make it very difficult either as there is an Iceweasel
 out there.
 
 The issue seems to be that Mozilla's policies for their brand conflict
 with Fedora's policies for their brand and that Fedora has limited
 resources. I don't think anyone is being evil here. There are reasonable
 positions on both sides of the argument.

Agreed, I'm just trying to point out the absurdity of saying that any
restriction on trademark impedes the freedoms of the GPL (etc...).  My
point is that it is precisely the limitations that guarantee those freedoms.

I don't see any conflict between Fedora's policy and Mozilla's policy.
Both say that if you redistribute and change code you have to
re-trademark.  Those policies are fair and sensible.  We can either
patch and re-trademark Firefox or ship upstream.  One of the values of
Fedora is stay close to upstream.  Another value is the Firefox brand.
This is a no-brainer choice for Fedora: ship upstream Firefox.  I really
can't believe this thread is as long as it is.

The only possible room for debate that I see is that there is, in
Firefox, a potential conflict between our ship upstream and don't
bundle libs values.  We have FESco to sort that out.

In short: No big deal. Close the thread. Move on. ;)

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Making Fedora work with laptops on docking station with external monitor

[Nathaniel McCallum]

On 10/06/2010 12:50 PM, Till Maas wrote:
 On Tue, Oct 05, 2010 at 11:22:44AM +0100, Richard Hughes wrote:
 
 Well, I guess some people would want the laptop to suspend, but it's a
 very good question. Now all it needs is someone willing and able to
 write a little patch for me :-)
 
 Do you know which components need patching to make Fedora work
 flawlessly with docking stations? I noticed problems, too, but even
 bigger problems to find out how the information flows e.g. if a notebook
 is inserted or ejected from a docking station. On thinkpads it seems not
 generate some event that cycles through the output configurations.

I'm pretty sure docking stations are irrelevant to this whole thread.
The issue is about lids and video outputs.  If you think lids are all
over the place (as mjg59 points out), docks are even worse.  Lets not
drag them into the conversation if they don't need to be.

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Making Fedora work with laptops on docking station with external monitor

[Nathaniel McCallum]

On 10/06/2010 01:17 PM, Till Maas wrote:
 On Wed, Oct 06, 2010 at 12:54:41PM -0400, Nathaniel McCallum wrote:
 
 I'm pretty sure docking stations are irrelevant to this whole thread.
 The issue is about lids and video outputs.  If you think lids are all
 over the place (as mjg59 points out), docks are even worse.  Lets not
 drag them into the conversation if they don't need to be.
 
 I have to use docking stations, therefore they are not irrelevant for
 me. And I only encountered problems in use-cases involving docking
 stations, but I never had any problem with my other Thinkpad and the
 lid. Therefore I am all for making Fedora not suck by default when I use
 a docking station. And even more I am interested in what is happening
 with all the frameworks, e.g. u\* or whatever is acting on changes.
 One interesting questions is, what do I have to do to get no change in
 the screen setup if I move from one docking station to another.

I'm with you.  I use docking stations too. However, for the topic of why
doesn't Fedora show on my monitor when the lid is closed in my docking
station, the docking station is actually irrelevant.  Its just a video
output.

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Making Fedora work with laptops on docking station with external monitor

[Nathaniel McCallum]

On 10/05/2010 09:12 AM, Dariusz J. Garbowski wrote:
 On 05/10/10 07:09 AM, Nathaniel McCallum wrote:
 On 10/05/2010 09:02 AM, Dariusz J. Garbowski wrote:
 On 05/10/10 05:00 AM, Peter Robinson wrote:
 On Tue, Oct 5, 2010 at 11:22 AM, Richard Hughes
 hughsi...@gmail.com wrote:
 On 5 October 2010 09:55, FlorianFesti ffe...@redhat.com wrote:
 Sorry for my may be naive question: Why do we need to know if we are
 docked or not. Isn't there exactly the same situation if the external
 Monitor is directly connected to the laptop? If there is an external
 monitor and the lid is closed don't we want to switch off the display
 regardless whether there is a docking station involved or not?
 Well, I guess some people would want the laptop to suspend, but it's a
 very good question. Now all it needs is someone willing and able to
 write a little patch for me :-)
 For the Dell docking stations at least there is a power button on the
 dock and the general way they are used (in that this is the way it
 works with Windows) is that if the power button on the dock is used
 and the lid is closed (power button is above the keyboard) it uses the
 external monitor. I've no idea if its possible to differentiate which
 botton is used. This is the case in our off with Dell D series and E
 series Latitude and HP dock capable laptops.
 There's also the case used quite often in my company with Dell
 docking stations, where
 the lid is open and the user uses both external and internal display
 in multi-monitor setup.
 Another case, used more often, is two external monitors connected to
 the dock and closed lid
 in multi-monitor setup.

 The good news is that I'm pretty sure the dock is irrelevant (other
 than are we on battery power) in all those cases.  The only thing that
 matters is which outputs are connected and what happens when the lid is
 closed. This seems like a cut-and-dry GPM policy issue.
 
 What about the case where we are on battery power and a projector or
 external monitor connected
 to the VGA port, no dock (with lid either open or closed for single or
 multi-monitor setup)?

If the lid is open, both output should be enabled by default (you are
free to manually disable one).  If the lid is closed on battery power
the system should suspend (unless you choose otherwise in GPM prefs).

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Making Fedora work with laptops on docking station with external monitor

[Nathaniel McCallum]

On 10/05/2010 11:21 AM, Christoph Frieben wrote:
 2010/10/5 Florian Festi:
 I wonder if there are latops that can be booted with lid closed and that
 make a subtle sematic difference between the lid was just being closed
 and is lid was already closed when we booted up.
 
 IBM ThinkPad T23.

Actually, pretty much any laptop in a dock can be booted with the lid
down.  It doesn't make any difference since the laptop screen should
still be off.

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Making Fedora work with laptops on docking station with external monitor

[Nathaniel McCallum]

On 10/05/2010 11:53 AM, Adam Williamson wrote:
 On Tue, 2010-10-05 at 09:35 +0100, Richard Hughes wrote:
 On 5 October 2010 05:30, Orion Poplawski or...@cora.nwra.com wrote:
 Are we really stuck with gdm/kdm/lxdm/...dm
 implementing it?

 No, I think what we need to do is to teach GPM how to turn off the
 internal panel when docked and with the lid closed. The only missing
 piece is for the kernel to export some kind of sysfs boolean saying
 in-dock. From talks with mjg59, detecting a dock is pretty hard.
 
 Maybe just 'lid closed and external monitor connected' would be close
 enough? Is there a use case where you'd want to have an external monitor
 connected and the internal system's lid closed, but still have the
 internal system's display turned on?

FYI, doing so could damage the laptop.

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Making Fedora work with laptops on docking station with external monitor

[Nathaniel McCallum]

On 10/05/2010 02:16 PM, Adam Williamson wrote:
 On Tue, 2010-10-05 at 19:05 +0100, Matthew Garrett wrote:
 On Tue, Oct 05, 2010 at 08:53:12AM -0700, Adam Williamson wrote:

 Maybe just 'lid closed and external monitor connected' would be close
 enough? Is there a use case where you'd want to have an external monitor
 connected and the internal system's lid closed, but still have the
 internal system's display turned on?

 No, but there is a use case where you'd want to have an external monitor 
 connected and the system report that the lid is closed, but still have 
 the internal system's display turned on. Hardware lies.
 
 that is a hardware/kernel/acpi bug. The appropriate way to fix it, IMHO,
 is to have the sensor report the correct information if it's at all
 possible to fix it in the kernel/acpi layer, or if not, blacklist that
 specific system so that its lid sensor is completely ignored.

Agreed, the hardware may lie, but the kernel is the arbiter of truth, at
least in this case.

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Making Fedora work with laptops on docking station with external monitor

[Nathaniel McCallum]

On 10/05/2010 02:25 PM, Matthew Garrett wrote:
 On Tue, Oct 05, 2010 at 02:18:20PM -0400, Nathaniel McCallum wrote:
 
 Agreed, the hardware may lie, but the kernel is the arbiter of truth, at
 least in this case.
 
 The range of ways that lid switches can be broken is large. One machine 
 I've seen tries to read from a GPIO that's off by 16, because Intel's 
 GPIO/GPE numbering is complicated. Another generates an event on lid 
 close and generates a different event on lid open, but there's no 
 handler for the open event and so the state variable never gets updated. 
 The world is full of bad hardware and the kernel can't always be there 
 to shield userspace from reality.

Of course, but where possible it should sanitize.  Userspace is like a
teenager, you expose them to just enough reality to know what's out
there, but in general they have no idea just how scary it really is. :)

Nathaniel

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Need new package reviews for Banshee iPhone support

[Nathaniel McCallum]

gudev-sharp: https://bugzilla.redhat.com/show_bug.cgi?id=639346
gkeyfile-sharp: https://bugzilla.redhat.com/show_bug.cgi?id=639348
gio-sharp: https://bugzilla.redhat.com/show_bug.cgi?id=639350
gtk-sharp-beans: https://bugzilla.redhat.com/show_bug.cgi?id=639351

Thanks!

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd or why will user fall away from fedora?

[Nathaniel McCallum]

On 08/25/2010 06:20 AM, Christof Damian wrote:
 On Tue, Aug 24, 2010 at 23:06, Mike McGrath mmcgr...@redhat.com wrote:
 On Tue, 24 Aug 2010, Till Maas wrote:
 If they like a faster bootup, then yes, they will. And I as a
 workstation user like it.


 [citation needed]

 I asked for this and was told by developers they were reluctant to post
 the data.
 
 I also wonder who these people are who boot their computers so often
 that boot-up speed makes any difference over a whole day.

I reboot my computer ~5-10 times a day due to this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=625187

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: The slip down memory lane

[Nathaniel McCallum]

On 08/12/2010 02:39 PM, Mike McGrath wrote:
 On Thu, 12 Aug 2010, Jason L Tibbitts III wrote:
 
 BN == Bill Nottingham nott...@redhat.com writes:

 BN I can't help but note that the slips have become more frequent as we
 BN started to actually *have* release criteria to test against. We
 BN didn't slip nearly as much when we weren't testing it.

 To me this implies that we should begin testing earlier (or, perhaps,
 never stop testing) and treat any new failure as an event of
 significance.  It's tough to meet a six month cycle if we spend half of
 it telling people to expect everything to be broken.

 
 Possibly also stop changing earlier?  It's hard to test a moving target.
 
 Would an 8[1] month cycle cause fewer slips per release?  Fewer bugs?

I'm not sure that an increased cycle would really help.

One thing I am curious about is why, when slipping for an Alpha target,
the whole schedule slips.  Can't we just take a week out of the Beta
cycle?  The amount of testing time is roughly the same.

The other general thing is to utilize http://repos.fedorapeople.org to
get wider testing for new features before merging them.  Perhaps we
could have a 6mo release schedule but a 12mo feature schedule.  Thus, I
would propose features *now* for F15, get them conditionally accepted
and work on them in repos.fp.org (or rawhide if that is not possible).
Then, we fork F15 from F14+updates and only merge in features that have
proven stable enough for wider testing.

The only way to make schedules more predictable is to keep trunk from
breaking as much as possible.  Breakage should occur as much as possible
in private repos.

Just some thoughts, hope they're helpful.

Nathaniel

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: The slip down memory lane

[Nathaniel McCallum]

On 08/12/2010 02:39 PM, drago01 wrote:
 On Thu, Aug 12, 2010 at 8:19 PM, Mike McGrath mmcgr...@redhat.com wrote:
 
 Since 2006 I counted 18 slips (I think one or two of those may just be a
 single slip listed twice).  Lets not yell, lets not flame war, lets not
 point fingers.  How can we fix this?
 
 It isn't broken so there is nothing to fix; slipping to fix issues
 found is a feature not a bug.
 We don't have any reason to rush.

I disagree, the feature is shipping on time.  Shipping on time enables
others in the Fedora community (people who build on, deploy, etc) know
with some assurance what their schedules will look like.  If I were a
project manager looking at using a Linux OS in my project, a
demonstrated lack of ability to ship on time is a *huge* mark against
using that OS.

If our schedules aren't reasonably fixed, than others have a hard time
working with us.  Loosing users (especially companies with resources to
invest in Fedora, even if just testing) make our quality go down.  Thus,
in the long run, continual slips actually contribute to lack of quality.

I think my point from my previous email is worth repeating: we need
wider testing of new features outside rawhide/N+1 before they are
merged.  This avoids upheaval and we can find bugs earlier.

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: The slip down memory lane

[Nathaniel McCallum]

On 08/12/2010 03:03 PM, Bruno Wolff III wrote:
 On Thu, Aug 12, 2010 at 13:19:29 -0500,
   Mike McGrath mmcgr...@redhat.com wrote:
 Since 2006 we've slipped at least 16-18 weeks by my count. That's more
 than half of a full release cycle.

 Thoughts?
 
 One thing I have noticed is people landing big changes (such as python and
 systemd) that break things for a while, delay a lot of other testing. So
 that when the bigger changes get fixed up, other bugs get unhidden with little
 time to react.
 
 I'd like to see the big changes land a lot earlier, maybe a month before
 the branch, so that by the branch most things should be easily testable.

+1

Perhaps our feature proposals need a better risk assessment. ie. Will
this change create system-wide impact?  Will reverting it be difficult?
 If the answer is yes to either of those questions, we should require
(either):
1. Testing in an external repo until a some stability is demonstrated.
2. Early merge with an early risk assessment / rollback.

Nathaniel


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: The slip down memory lane

[Nathaniel McCallum]

On 08/12/2010 03:08 PM, Jon Ciesla wrote:
   On 08/12/2010 01:39 PM, Mike McGrath wrote:
 On Thu, 12 Aug 2010, Jason L Tibbitts III wrote:

 BN == Bill Nottinghamnott...@redhat.com  writes:
 BN  I can't help but note that the slips have become more frequent as we
 BN  started to actually *have* release criteria to test against. We
 BN  didn't slip nearly as much when we weren't testing it.

 To me this implies that we should begin testing earlier (or, perhaps,
 never stop testing) and treat any new failure as an event of
 significance.  It's tough to meet a six month cycle if we spend half of
 it telling people to expect everything to be broken.

 Possibly also stop changing earlier?  It's hard to test a moving target.

 Would an 8[1] month cycle cause fewer slips per release?  Fewer bugs?

  -Mike

 [1] Just picked some number slightly longer then the current cycle for
 purposes of discussion, not suggesting it.
 I think that will turn into 10 quickly.  I advocate rigorous testing, 
 and sticking as close to 6 as we can.  I mean, if we have to slip 
 because of a nasty blocker, yeah, slip, of course.  But I don't see how 
 a slip decreases the user experience.  Quite the opposite.

If slips are occasional, than this is correct.  If slips are so routine
that schedules become unpredictable, than you shift the schedules of
everyone who builds something on top of Fedora.  Doing this too much
results in decreased technical users who provide development and
testing.  The end result is decreased quality.

In short, predictable, regular releases increase quality.  Occasional
slips happen, regular slips should not.

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: webkitgtk abi bump

[Nathaniel McCallum]

libproxy is done too

2010/7/5 Simon Wesp cassmod...@fedoraproject.org:
 Am Freitag, den 02.07.2010, 10:36 -0400 schrieb Matthias Clasen:
 surf
 done, thank you for this info!

 --
 Mit freundlichen Grüßen aus dem schönen Hainzell
 Simon Wesp

 http://www.fedoraproject.org/wiki/SimonWesp

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: To construct a Zope skyscraper on Fedora

[Nathaniel McCallum]

On 06/20/2010 05:08 AM, Robin 'cheese' Lee wrote:

The spec file for each  per-module package I just created is generated
through a little and nasty script which converts spec files generated by
setuptools to ones complying with Fedora standards. (The script is too
nasty to open its source.)

A better solution is to hack setuptools, and/or distutils, itself to
generate standard-complying spec files directly. But this may take some
time.


I've attached a script called zopespec.  zopespec works similarly to 
(and probably could be merged with) rpmdev-newspec.  You run it and give 
it a package name.  This can be zope.copy, zope-copy or zope-copy.spec.


Given the name zope-copy, zopespec looks up the latest version from 
pypi.python.org, downloads it and extracts a bunch of metadata.  This 
metadata gets substituted into the spec that is created.  It should be 
generally speaking functional, but of course the generated spec needs to 
be reviewed by a human.  Let me know if you have any thoughts.


Nathaniel
#!/bin/bash

appname=`echo $1 | sed 's|-|.|' | sed 's|\.spec$||'`
prjpage=http://pypi.python.org/pypi/$appname
urlprfx=http://pypi.python.org/packages/source/$(echo $appname | sed -r 
's|^(.).*|\1|')/$appname
endings=(\\.tar\\.gz|\\.tgz|\\.tar\\.bz2|\\.tbz2|\\.zip)
rematch=.*$urlprfx/$appname-([0-9.]+)$endings#md5=([0-9a-fA-F]{32}).*

# Fetch the application's project page
# We'll use this to find the version, archive type and md5sum
tmpf=`mktemp`
if ! wget -q -O $tmpf $prjpage; then
echo Unable to find version!
rm -f $tmpf
exit 1
fi

# Get the version, archive type and md5sum
vers=$(sed -n -r s!$rematch!\1 \2 \3!p $tmpf | sort -r -n | head -n1 | cut 
-d' ' -f1)
arch=$(sed -n -r s!$rematch!\1 \2 \3!p $tmpf | sort -r -n | head -n1 | cut 
-d' ' -f2)
hash=$(sed -n -r s!$rematch!\1 \2 \3!p $tmpf | sort -r -n | head -n1 | cut 
-d' ' -f3)
pkgf=${appname}-${vers}${arch}
rm -f $tmpf

# Download the actual source code
tmpd=`mktemp -d`
if ! wget -q -O ${tmpd}/$pkgf $urlprfx/$pkgf; then
echo Unable to download $urlprfx/$pkgf!
rm -rf $tmpd
exit 1
fi
if [ `md5sum ${tmpd}/$pkgf | cut -d' ' -f1` != $hash ]; then
echo Tarball has invalid md5 sum!
rm -rf $tmpd
exit 1
fi

# Extract the source code
case $arch in
*gz)
tar xzf ${tmpd}/$pkgf -C $tmpd
;;
*bz2)
tar xjf ${tmpd}/$pkgf -C $tmpd
;;
*zip)
unzip -qq ${tmpd}/$pkgf -d $tmpd
;;
*)
echo Invalid archive format!
rm -rf $tmpd
exit 1
;;
esac

# Fetch the summary and description fields and a list of all the requires
pkgi=$tmpd/${appname}-$vers/src/$appname.egg-info/PKG-INFO
preq=$tmpd/${appname}-$vers/src/$appname.egg-info/requires.txt
docs=`echo $(ls $tmpd/${appname}-$vers/ | grep \.txt$)`
summ=$(sed -n -r 's!^Summary: (.*)$!\1!p' $pkgi)
dscr=$(awk '/^[ \t]*$/   { bl=bl + 1 }
/^(Description:|[ \t]+)/ {
if (bl  2  match($0, ^[ \t]*$) == 0) {
sub(^(Description:[ \t]*|[ \t]*), );
print $0;
}
}' $pkgi)

# Start building our spec file
tmpf=`mktemp`
awk '{ if (start) print $0; } /^@@START_OF_SPEC@@$/ { start=1; }' $0  $tmpf

# Substitue a bunch of variables
sed -i -r s|@MODNAME@|$appname|g $tmpf
sed -i -r s|@VERSION@|$vers|g $tmpf
sed -i -r s|@ARCHIVE@|$arch|g $tmpf
sed -i -r s|@SUMMARY@|$summ|g $tmpf
sed -i -r s|@DOCS@|$docs|g $tmpf
sed -i -r s|@DESCRIPTION@|$(echo $dscr)|g $tmpf

# Generate our requires
awk '/^\[/ { stop=1; } { if (!stop  $0) print $0; }' $preq \
| grep -v ^setuptools \
| sed -r 's!\.!-!' | sed -r 's!(.*)!python-\1!' \
| while read req; do
  sed -i -r s|^BuildRequires:( 
*)python-setuptools$|BuildRequires:\1python-setuptools\nRequires: 
\1${req}| $tmpf
  done

# Fix BuildArch if necessary
if find $tmpd | grep '\.c$'; then
sed -i -r s|^BuildArch: *noarch$|| $tmpf
fi

# Make sure that we have a wrapped description and a proper changelog
dashname=`echo $appname | sed 's!\.!-!'`
fold $tmpf -s  python-$dashname.spec
rpmdev-bumpspec python-$dashname.spec
rm -rf $tmpd $tmpf

exit 0
@@START_OF_SPEC@@
%{!?python_sitelib: %global python_sitelib %(%{__python} -c
from distutils.sysconfig import get_python_lib; print(get_python_lib()))}

%global modname @MODNAME@
%global fedranm %(echo %{modname} | sed -r 's|\\.|-|')
%global pathnam %(echo %{modname} | sed -r 's|\\.|/|')
%global frstltr %(echo %{modname} | sed -r 's|^(.).*|\\1|')

%global version @VERSION@
%global release 0

%global srcbase http://pypi.python.org/packages/source/%{frstltr}/%{modname}

Name:   python-%{fedranm}
Version:%{version}
Release:%{release}%{?dist}
Summary:@SUMMARY@

Group:  Development/Libraries
License:ZPLv2.1
URL:http://pypi.python.org/pypi/%{modname}

Re: To construct a Zope skyscraper on Fedora

[Nathaniel McCallum]

On 06/20/2010 07:00 AM, Robin 'cheese' Lee wrote:
 On 06/20/2010 12:22 PM, Jonathan Steffan wrote:
 On Fri, 2010-06-18 at 21:08 +0800, Robin 'cheese' Lee wrote:

 The 'zope' package itself is most kept under the same conventions of the
 legacy 2.10.x 'zope' package.

 With zope 2.12 supporting py2.6, I think we might actually have a shot
 at making this work. However, immediately off the bat if we stick 2.12.x
 into zope what happens to grok? What packages are going to break? Too
 many things need zope 2.x so updating the zope namespace to zope 3
 would break a lot of good software. What happens to plone? Do we just
 ditch Plone 3 and only support Plone 4?[2]

 This is really worrying.


For our own sanity we are going to have to make some tough choices.  I 
don't think we can please everyone.  I do however, think we can please 
most people.

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: To construct a Zope skyscraper on Fedora

[Nathaniel McCallum]

On 06/20/2010 05:42 AM, Robin 'cheese' Lee wrote:
 On 06/20/2010 12:45 PM, Nathaniel McCallum wrote:
 On 06/20/2010 12:22 AM, Jonathan Steffan wrote:

 On Fri, 2010-06-18 at 21:08 +0800, Robin 'cheese' Lee wrote:

 The 'zope' package itself is most kept under the same conventions of the
 legacy 2.10.x 'zope' package.

 We have a unique opportunity to address many of the failings of the
 current zope namespace. We should get anyone interested (and willing to
 do the work) into a meeting soon. Every time I go back to building up
 zope again I run out of steam and end up just being frustrated. I
 foresee issues with splitting out every module in this stack but it just
 needs to be discussed. The current package layout is far from optimal
 and it's not the best idea to ship a default standalone instance with
 the package. Shipping standalone/zeo instance configs/etc. in
 subpackages is a far better idea. I've never been able to address this
 as there is just about no upgrade path (that I've been able to design)
 that would allow for a safe re-layout of the current package.

 We should consider the current zope namespace dead and start from
 scratch. It's far too complex of an application to be able to have
 everything in one namespace (speaking to zope2 vs zope3.) I've only
 briefly looked into all of the specs you've worked on and already can
 see we are going to run into issues with cross-product dependencies. I
 could be convinced that the zope namespace should be the latest 2.x
 and then address the need for zope 3 in the zope3 namespace. However,
 how do we distinguish a module built for zope 2 vs zope 3? This, again,
 could be solved but will need discussion.

 With zope 2.12 supporting py2.6, I think we might actually have a shot
 at making this work. However, immediately off the bat if we stick 2.12.x
 into zope what happens to grok? What packages are going to break? Too
 many things need zope 2.x so updating the zope namespace to zope 3
 would break a lot of good software. What happens to plone? Do we just
 ditch Plone 3 and only support Plone 4?[2]

 We could also modularize everything and have things like zope,
 plone, grok and zenoss have dependencies based on their release
 recipes. There are a lot of common modules in these projects, but they
 all have their own specific version requirements. This would be a lot of
 work and could potentially cause us to package ourselves into a corner
 where we are having to do absolute requires or just end up with broken
 software when absolute requirements are not properly documented.

 I really look forward to others being involved with this. Count me in
 for the SIG.[2]

 - Jonathan Steffan

 [1] http://plone.org/documentation/faq/plone-versions
 [2] http://fedoraproject.org/wiki/SIGs/Zope

 I agree, we've got lots to talk about.  The most important things are:
 1. Packaging guidelines
 2. Component upgrade guidelines
 3. Namespace issues (addressed above)
 4. Zope 2 vs Zope 3 (again, addressed above)

 Zope 3 seems no more going, and a new project named BlueBream[1][2]
 replacing it is being developed.

 There are also other blueprint-like and amazing projects[3][4] being
 worked on in the Zope world.

 But after all, the most productive and widely used is still Zope 2 which
 should gets higher priority.

 [1] http://en.wikipedia.org/wiki/BlueBream
 [2] https://launchpad.net/bluebream
 [2] http://codespeak.net/z3/five/
 [3] http://repoze.org/

I suspect BlueBream solves our namespace issue; namely, the zope 
namespace will be zope2 only.

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: To construct a Zope skyscraper on Fedora

[Nathaniel McCallum]

On 06/20/2010 12:22 AM, Jonathan Steffan wrote:
 On Fri, 2010-06-18 at 21:08 +0800, Robin 'cheese' Lee wrote:
 The 'zope' package itself is most kept under the same conventions of the
 legacy 2.10.x 'zope' package.

 We have a unique opportunity to address many of the failings of the
 current zope namespace. We should get anyone interested (and willing to
 do the work) into a meeting soon. Every time I go back to building up
 zope again I run out of steam and end up just being frustrated. I
 foresee issues with splitting out every module in this stack but it just
 needs to be discussed. The current package layout is far from optimal
 and it's not the best idea to ship a default standalone instance with
 the package. Shipping standalone/zeo instance configs/etc. in
 subpackages is a far better idea. I've never been able to address this
 as there is just about no upgrade path (that I've been able to design)
 that would allow for a safe re-layout of the current package.

 We should consider the current zope namespace dead and start from
 scratch. It's far too complex of an application to be able to have
 everything in one namespace (speaking to zope2 vs zope3.) I've only
 briefly looked into all of the specs you've worked on and already can
 see we are going to run into issues with cross-product dependencies. I
 could be convinced that the zope namespace should be the latest 2.x
 and then address the need for zope 3 in the zope3 namespace. However,
 how do we distinguish a module built for zope 2 vs zope 3? This, again,
 could be solved but will need discussion.

 With zope 2.12 supporting py2.6, I think we might actually have a shot
 at making this work. However, immediately off the bat if we stick 2.12.x
 into zope what happens to grok? What packages are going to break? Too
 many things need zope 2.x so updating the zope namespace to zope 3
 would break a lot of good software. What happens to plone? Do we just
 ditch Plone 3 and only support Plone 4?[2]

 We could also modularize everything and have things like zope,
 plone, grok and zenoss have dependencies based on their release
 recipes. There are a lot of common modules in these projects, but they
 all have their own specific version requirements. This would be a lot of
 work and could potentially cause us to package ourselves into a corner
 where we are having to do absolute requires or just end up with broken
 software when absolute requirements are not properly documented.

 I really look forward to others being involved with this. Count me in
 for the SIG.[2]

 - Jonathan Steffan

 [1] http://plone.org/documentation/faq/plone-versions
 [2] http://fedoraproject.org/wiki/SIGs/Zope

I agree, we've got lots to talk about.  The most important things are:
1. Packaging guidelines
2. Component upgrade guidelines
3. Namespace issues (addressed above)
4. Zope 2 vs Zope 3 (again, addressed above)

I think we should talk sooner rather than later.  Anyone want to setup a 
meeting time?

Just an FYI, it is my current plan (probably because I am completely 
ignorant as to how much pain this will cause) is to simply package the 
latest version of all Zenoss dependencies and then work through whatever 
bugs I find.  I'm in a somewhat unique situation though in that I have 
the ability to commit to upstream.  This may be a less than ideal plan 
for other applications.

As I mentioned to Jonathan on IRC, I think the best plan is to try to 
get something working'ish as soon as possible and then try to shakedown 
the details from there.  If we bog ourselves down in policy (an easy 
quagmire to get stuck in when in zopeland) we may get too discouraged to 
continue.  Not to dismiss what will be the very needed policy, I just 
want to make sure no-one gets burned out.

One thing we may want to consider is a tenant policy.  That is, the 
zope stack as a whole has tenants (Zenoss, Plone, etc).  The tenants 
would be formally defined and any upgrade to any component in the 
platform would require signoff from all the tenants who depend on that 
component (or some derivation thereof).  I suspect that the short-term 
trade-off of buildouts/bundling is not as valuable as the long-term 
value of testing a software product across multiple versions of its 
dependencies.

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: To construct a Zope skyscraper on Fedora

[Nathaniel McCallum]

On 06/18/2010 09:08 AM, Robin 'cheese' Lee wrote:
 Hello, all!

 And the foundations and first floors of this skyscraper is Zope2 and its
 dependencies, which I have built up. The latest version of Zope2 is 2.12.7.

 All the spec files are accessible through my git repo:
 http://fedorapeople.org/gitweb?p=cheeselee/public_git/rpm.git;a=tree;h=refs/heads/master;hb=master

 And an yum repo (i686 and SRPM) for F-13 is also available:
 http://cheeselee.fedorapeople.org/yum/zope/

 Steps to make a trivial test:
 $ wget http://cheeselee.fedorapeople.org/yum/zope-cheese.repo
 $ su -c cp zope-cheese.repo /etc/yum.repos.d/
 $ su -c yum install zope
 $ su -c service zope start
 $ xdg-open http://localhost:8080/

 The 'zope' package itself is most kept under the same conventions of the
 legacy 2.10.x 'zope' package.

 So, you can see, there are about 70 source packages to be review.

 And I hope for the co-maintainership of following packages, which are
 required by Zope2:
 https://admin.fedoraproject.org/pkgdb/acls/name/python-mechanize
 https://admin.fedoraproject.org/pkgdb/acls/name/python-transaction
 https://admin.fedoraproject.org/pkgdb/acls/name/python-zope-interface

 Other Zope2 applications including Plone and other related frameworks
 like Grok and Zope3(BlueBream) are not yet touched. But I should have
 the ambition to get them to Fedora, and even more importantly, to (ep)el6.

 And after all, any help or instruction is really wanted.

This is awesome!  I've already started packaging Zenoss's bundled deps. 
  Zope 2.12 was close to next on my list.  I'm sure we can work together 
as soon as Ian Weller approves my sponsorship. :) *nudge*

https://bugzilla.redhat.com/show_bug.cgi?id=603518
https://bugzilla.redhat.com/show_bug.cgi?id=603521

Nathaniel

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: To construct a Zope skyscraper on Fedora

[Nathaniel McCallum]

On 06/18/2010 09:48 AM, LI Rui Bin wrote:
 On 06/18/2010 09:33 PM, Nathaniel McCallum wrote:
 On 06/18/2010 09:08 AM, Robin 'cheese' Lee wrote:
 Hello, all!

 And the foundations and first floors of this skyscraper is Zope2 and its
 dependencies, which I have built up. The latest version of Zope2 is
 2.12.7.

 All the spec files are accessible through my git repo:
 http://fedorapeople.org/gitweb?p=cheeselee/public_git/rpm.git;a=tree;h=refs/heads/master;hb=master


 And an yum repo (i686 and SRPM) for F-13 is also available:
 http://cheeselee.fedorapeople.org/yum/zope/

 Steps to make a trivial test:
 $ wget http://cheeselee.fedorapeople.org/yum/zope-cheese.repo
 $ su -c cp zope-cheese.repo /etc/yum.repos.d/
 $ su -c yum install zope
 $ su -c service zope start
 $ xdg-open http://localhost:8080/

 The 'zope' package itself is most kept under the same conventions of the
 legacy 2.10.x 'zope' package.

 So, you can see, there are about 70 source packages to be review.

 And I hope for the co-maintainership of following packages, which are
 required by Zope2:
 https://admin.fedoraproject.org/pkgdb/acls/name/python-mechanize
 https://admin.fedoraproject.org/pkgdb/acls/name/python-transaction
 https://admin.fedoraproject.org/pkgdb/acls/name/python-zope-interface

 Other Zope2 applications including Plone and other related frameworks
 like Grok and Zope3(BlueBream) are not yet touched. But I should have
 the ambition to get them to Fedora, and even more importantly, to
 (ep)el6.

 And after all, any help or instruction is really wanted.

 This is awesome!  I've already started packaging Zenoss's bundled
 deps.  Zope 2.12 was close to next on my list.  I'm sure we can work
 together as soon as Ian Weller approves my sponsorship. :) *nudge*

 https://bugzilla.redhat.com/show_bug.cgi?id=603518
 https://bugzilla.redhat.com/show_bug.cgi?id=603521

 Nathaniel



 That's good. So you may also make an yum repo depending on my zope repo,
 to let others know the final target of your work.

Do you have a page for the TODO of the zope project?  Does it have links 
to all the package review tickets?  I could certainly use the info on 
our Zenoss page: https://fedoraproject.org/wiki/Zenoss

Nathaniel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel