Re: Orphaning package procedure. (icewm, spring, springlobby)

[Gilboa Davara]

> Hello. Gilboa, i would like to continue maintaining IceWM. And i interesting 
> in 'springlobby' package. Please add me as co-maintainer. FAS: atim.

Hello,

Done. Please verify.

- Gilboa
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaning package procedure. (icewm, spring, springlobby)

[Gilboa Davara]

On Mon, Apr 6, 2020 at 9:49 PM Kevin Fenzi  wrote:
>
> On Mon, Apr 06, 2020 at 04:59:14PM +0300, Gilboa Davara wrote:
> > Hello,
> >
> > Due to the extreme time constraints that I'm forced to orphan most of my
> > remaining packages.
> > Namely icewm (which has an active co-maintainer), spring and springlobby.
> > Following the procedure in wiki [1], I should use Pagure to orphan both
> > packages.
> > However, the list of projects in the Pagure is empty, and I can only view
>
> What exact URL are you going to?
>
> it should be:
>
> https://src.fedoraproject.org/rpms/PACKAGE_NAME/settings
>
> where PACKAGE_NAME is one of the packages...
>

That worked. Thanks!

- Gilboa
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Orphaning package procedure. (icewm, spring, springlobby)

[Gilboa Davara]

Hello,

Due to the extreme time constraints that I'm forced to orphan most of my
remaining packages.
Namely icewm (which has an active co-maintainer), spring and springlobby.
Following the procedure in wiki [1], I should use Pagure to orphan both
packages.
However, the list of projects in the Pagure is empty, and I can only view
my list of active packages in
https://src.fedoraproject.org/dashboard/projects

If possible, what is the correct procedure to orphan my packages and/or
pass them to some willing co-maintainer?

Thanks,
Gilboa

[1]
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#About_Orphan_and_Retired_.28Deprecated.29_Packages
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F24: systemd fails to mount 128 LVM partitions. (udev issue?)

[Gilboa Davara]

On Thu, Jul 28, 2016 at 3:23 PM, Tomasz Torcz <to...@pipebreaker.pl> wrote:
> On Thu, Jul 28, 2016 at 03:04:12PM +0300, Gilboa Davara wrote:
>> On Thu, Jul 28, 2016 at 6:07 AM, Zbigniew Jędrzejewski-Szmek
>> <zbys...@in.waw.pl> wrote:
>> >
>> > It is possible that udevd is failing for whatever reason... but apart
>> > from the fact that some of the devices links are missing you don't
>> > provide any info. At the minimum: boot logs, and information which links
>> > are missing.
>>
>> Boot log info is pretty scarce. I only see a lot of systemd timed-out
>> log messages:
>> E.g.
>>
>> systemd[1]: dev-VolRoot-LogStorageMData_P123.device: Job
>> dev-VolRoot-LogStorageMData_P123.device/start timed out.
>> systemd[1]: dev-VolRoot-LogStorageMData_P125.device: Job
>> dev-VolRoot-LogStorageMData_P125.device/start timed out.
>> systemd[1]: dev-VolRoot-LogStorageMData_P124.device: Job
>> dev-VolRoot-LogStorageMData_P124.device/start timed out.
>> systemd[1]: dev-VolRoot-LogStorageMData_P122.device: Job
>> dev-VolRoot-LogStorageMData_P122.device/start timed out.
>> systemd[1]: dev-VolRoot-LogStorageMData_P127.device: Job
>> dev-VolRoot-LogStorageMData_P127.device/start timed out.
>> systemd[1]: dev-VolRoot-LogStorageMData_P123.device: Job
>> dev-VolRoot-LogStorageMData_P123.device/start timed out.
>> systemd[1]: dev-VolRoot-LogStorageMData_P126.device: Job
>> dev-VolRoot-LogStorageMData_P126.device/start timed out.
>>
>> I did see some udev / LVM error messages:
>> systemd-udevd[2181]: fork of '/usr/sbin/dmsetup splitname
>> --nameprefixes --noheadings --rows VolRoot-LogStorageMData_P96'
>> failed: Resource temporarily unavailable
>
> Hm, do you have TasksMax=infinity in systemd-udevd.service?
> (commit de2edc008a612e152f0690d5063d53001c4e13ff)
>

Nope. I don't see TasksMax in systemd-udevd.service.

Actually, funny that you mention it. (Maybe the following will help others)
I use the server to run some type of proprietary service that spawns
~2000+ process. This service stopped working the second I switched to
F24.
After spending a couple of hours banging my head against the wall, I
noticed that systemd is ignoring the service user's limits.d nproc
limit (also the service unit's LimitNPROC limit) preventing it from
forking more than 256 process.
Adding TasksMax=infinity to the service's unit solved the problem.

Related?

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

Re: F24: systemd fails to mount 128 LVM partitions. (udev issue?)

[Gilboa Davara]

On Thu, Jul 28, 2016 at 9:59 AM, Lennart Poettering
<mzerq...@0pointer.de> wrote:
> On Wed, 27.07.16 21:35, Gilboa Davara (gilb...@gmail.com) wrote:
>
>> Hello all,
>>
>> I need help trying to debug a weird bug that I'm hitting.
>> I've got a server with fairly large storage (>100TB) that needs to
>> handle very-small-files.
>> Due to performance considerations I decided to split the large array
>> into 128 ext4 partitions (rather than use a single xfs partition).
>>
>> I recently upgraded the server to F24 (w/ kernel 4.5.5, 4.6.4 refuses
>> to boot on the machine) and I'm now facing a weird problem: On boot,
>> systemd fails to mount all the partition dropping to emergency shell.
>>
>> At least as far as I can see, udev fails to create some symbolic links
>> under /dev/, even though it has no issues creating the same
>> symbolic links under /dev/mapper/-_PXX.
>> On the other hand systemd still uses the broken /dev/
>> device units, even though we moved all the entries in fstab to
>> /dev/mapper/-_PXX and manually ran
>> systemd-fstab-generator.
>
> LVM questions are best directed to the LVM people, we have very little
> experience with that and the LVM ruleset is quite invasively altering
> the udev logic.
>
> Lennart
>


Lennart,

Seems that its indeed lvm related.
(Boot log attached to previous reply mail)

Thanks,
Gilboa
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24: systemd fails to mount 128 LVM partitions. (udev issue?)

[Gilboa Davara]

On Thu, Jul 28, 2016 at 6:07 AM, Zbigniew Jędrzejewski-Szmek
 wrote:
>
> It is possible that udevd is failing for whatever reason... but apart
> from the fact that some of the devices links are missing you don't
> provide any info. At the minimum: boot logs, and information which links
> are missing.

Boot log info is pretty scarce. I only see a lot of systemd timed-out
log messages:
E.g.

systemd[1]: dev-VolRoot-LogStorageMData_P123.device: Job
dev-VolRoot-LogStorageMData_P123.device/start timed out.
systemd[1]: dev-VolRoot-LogStorageMData_P125.device: Job
dev-VolRoot-LogStorageMData_P125.device/start timed out.
systemd[1]: dev-VolRoot-LogStorageMData_P124.device: Job
dev-VolRoot-LogStorageMData_P124.device/start timed out.
systemd[1]: dev-VolRoot-LogStorageMData_P122.device: Job
dev-VolRoot-LogStorageMData_P122.device/start timed out.
systemd[1]: dev-VolRoot-LogStorageMData_P127.device: Job
dev-VolRoot-LogStorageMData_P127.device/start timed out.
systemd[1]: dev-VolRoot-LogStorageMData_P123.device: Job
dev-VolRoot-LogStorageMData_P123.device/start timed out.
systemd[1]: dev-VolRoot-LogStorageMData_P126.device: Job
dev-VolRoot-LogStorageMData_P126.device/start timed out.

I did see some udev / LVM error messages:
systemd-udevd[2181]: fork of '/usr/sbin/dmsetup splitname
--nameprefixes --noheadings --rows VolRoot-LogStorageMData_P96'
failed: Resource temporarily unavailable

Either way, I've attached a boot log.

> Note that just running the generator by hand has no effect. You need
> systemctl daemon-reload to reload the units, but that will re-run the
> generators by itself.

Just to be certain: Changing fstab requires systemctl daemon-reload?

>
> I'd suggest commenting out (or adding "noauto") the mount points in 
> /etc/fstab,
> (and of course also disabling any units which make use of them if they are
> not conditionalized), and debugging in a booted system. It's most likely to
> be easier this way.
>

The attached log seems to suggest this indeed a udev/lvm issue.
Thanks for taking the time to help :)

- Gilboa


boot.log.bz2
Description: BZip2 compressed data
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

F24: systemd fails to mount 128 LVM partitions. (udev issue?)

[Gilboa Davara]

Hello all,

I need help trying to debug a weird bug that I'm hitting.
I've got a server with fairly large storage (>100TB) that needs to
handle very-small-files.
Due to performance considerations I decided to split the large array
into 128 ext4 partitions (rather than use a single xfs partition).

I recently upgraded the server to F24 (w/ kernel 4.5.5, 4.6.4 refuses
to boot on the machine) and I'm now facing a weird problem: On boot,
systemd fails to mount all the partition dropping to emergency shell.

At least as far as I can see, udev fails to create some symbolic links
under /dev/, even though it has no issues creating the same
symbolic links under /dev/mapper/-_PXX.
On the other hand systemd still uses the broken /dev/
device units, even though we moved all the entries in fstab to
/dev/mapper/-_PXX and manually ran
systemd-fstab-generator.

Valid mapper:
$ ls -l /dev/mapper/VolRoot-LogStorageMData_P* | wc -l
128

Invalid VGName:
$ ls -l /dev/VolRoot/LogStorageMData_P* | wc -l
95 <--- Should be 128.

fstab:
$ cat /etc/fstab | grep VolRoot-LogStorageMData_P | wc -l
128

systemd broken unit files:
$ systemctl -a --no-pager | /bin/grep dev-VolRoot-LogStorageMData | wc -l
95 <--- Should be 128.

Any suggestions are welcome.

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

Re: ExclusiveArch: %{ix86} x86_64 ignored, SRPMs sent to arm builder?

[Gilboa Davara]

On Sat, Nov 8, 2014 at 4:41 PM, Dan Horák d...@danny.cz wrote:
 On Sat, 8 Nov 2014 16:35:39 +0200
 Gilboa Davara gilb...@gmail.com wrote:

 Hello all,

 I'm trying to push a fresh build of spring.
 Currently spring upstream is limited to x86_64 and i686.
 The SPEC has ExclusiveArch: %{ix86} x86_64 (following a suggestion
 from -devel ML), but never the less, its being sent to the ARM builder
 and fails.
 What am I doing wrong?

 nothing is wrong, the arm builder owns the top level build task, but the
 actual builds are done on a x86 builders

 from build.log
 ...
 -- Could NOT find SDL2 (missing:  SDL2_LIBRARY SDL2_INCLUDE_DIR
 SDL2_VERSION_STRING)
 ...



/me smacks head against the table.

Thanks :)

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

ExclusiveArch: %{ix86} x86_64 ignored, SRPMs sent to arm builder?

[Gilboa Davara]

Hello all,

I'm trying to push a fresh build of spring.
Currently spring upstream is limited to x86_64 and i686.
The SPEC has ExclusiveArch: %{ix86} x86_64 (following a suggestion
from -devel ML), but never the less, its being sent to the ARM builder
and fails.
What am I doing wrong?

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

https://pkgs.fedoraproject.org uses self-signed certificates?

[Gilboa Davara]

Hello all,

When trying to download my package source files from pkgs.fedoraproject.org
I'm getting self-signed SSL certificates (see details below).
While it's most likely a minor infrastructure issue, I'd suggest exercising
caution when downloading sources from pkgs.fedoraproject.org.
I've also sent an email to ad...@fedoraproject.org.

FWIW, the certificate information is:

Subject Name:
--
C (Country):US
ST (State):North Carolina
O (Organization):Fedora Project
OU (Organizational Unit):Fedora Builders
CN (Common Name):pkgs.fedoraproject.org
EMAIL (Email Address):build...@fedoraproject.org

Issuer Name:
--
C (Country):US
ST (State):North Carolina
L (Locality):Raleigh
O (Organization):Fedora Project
OU (Organizational Unit):Fedora Project CA
CN (Common Name):Fedora Project CA
EMAIL (Email Address):ad...@fedoraproject.org

Thanks,
Gilboa
-- 
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: https://pkgs.fedoraproject.org uses self-signed certificates?

[Gilboa Davara]

On Wed, Oct 1, 2014 at 3:41 PM, Matthew Miller mat...@fedoraproject.org wrote:
 On Wed, Oct 01, 2014 at 03:02:34PM +0300, Gilboa Davara wrote:
 When trying to download my package source files from pkgs.fedoraproject.org
 I'm getting self-signed SSL certificates (see details below).
 While it's most likely a minor infrastructure issue, I'd suggest exercising
 caution when downloading sources from pkgs.fedoraproject.org.
 I've also sent an email to ad...@fedoraproject.org.

 Take a look at https://fedorahosted.org/fedora-infrastructure/ticket/2324

 The certificate in use is issued by Fedora's CA and the server cert can be
 obtained via https with a publicly-signed cert at
 https://admin.fedoraproject.org/accounts/fedora-server-ca.cert

 As I understand it, this is directly verified by some of our infrastructure
 which uses pkgs.fedoraproject.org, and although the ticket above outlines a
 migration plan, it hasn't become a priority.


OK. Thanks for the info.
I believe me original message left something out. I'm using
Firefox/wget to download the sources (E.g.
https://pkgs.fedoraproject.org/repo/pkgs/icewm/) of my packages, and
both shout like crazy about the self-signed certificates. Somehow I
never got a self signed cert before. Go figure.

Guess I'll have to stick to using fedpkg for the time being.

Thanks again for the info and sorry for the noise.
- Gilboa
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Orphaning spring-install.

[Gilboa Davara]

Hello all,

I'm orphaning spring-install.
Up-stream is completely dead and currently its much easier to use the
(actively maintained) springlobby client to download maps, etc.

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

ExcludeArch being ignored when building spring f20.

[Gilboa Davara]

Hello all,

I'm facing a weird issue when trying to build a new version of spring.
First and foremost, the spring.spec has ExcludeArch:ppc ppc64
%{arm}, which should exclude arm* and ppc* (both not supported by
upstream).

When trying to build F20, I got the following error:

Building spring-95.0-1.fc20 for f20-candidate
Created task: 6205737
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=6205737
Watching tasks (this may be safely interrupted)...
6205737 build (f20-candidate,
/spring:bdcff90c696261332269632c667ad2b3505b749c): open
(buildppc-01.phx2.fedoraproject.org)
  6205738 buildSRPMFromSCM
(/spring:bdcff90c696261332269632c667ad2b3505b749c): open
(arm02-builder10.arm.fedoraproject.org)
  6205738 buildSRPMFromSCM
(/spring:bdcff90c696261332269632c667ad2b3505b749c): open
(arm02-builder10.arm.fedoraproject.org) - FAILED: BuildError: error
building srpm, mock exited with status 1; see build.log for more
information
  0 free  1 open  0 done  1 failed
6205737 build (f20-candidate,
/spring:bdcff90c696261332269632c667ad2b3505b749c): open
(buildppc-01.phx2.fedoraproject.org) - FAILED: BuildError: error
building srpm, mock exited with status 1; see build.log for more
information
  0 free  0 open  0 done  2 failed

6205737 build (f20-candidate,
/spring:bdcff90c696261332269632c667ad2b3505b749c) failed

Why is arm and ppc being built?
I should point out that F21 was built just fine...

Thanks,
- Gilboa
-- 
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: ExcludeArch being ignored when building spring f20.

[Gilboa Davara]

On Wed, Nov 20, 2013 at 5:26 PM, Josh Boyer jwbo...@fedoraproject.org wrote:
 On Wed, Nov 20, 2013 at 10:23 AM, Gilboa Davara gilb...@gmail.com wrote:
 Hello all,

 I'm facing a weird issue when trying to build a new version of spring.
 First and foremost, the spring.spec has ExcludeArch:ppc ppc64
 %{arm}, which should exclude arm* and ppc* (both not supported by
 upstream).

 When trying to build F20, I got the following error:

 They aren't.  The SRPM koji builds from git is failing because of:

 error: Bad source: /builddir/build/SOURCES/spring-95-dso.patch: No
 such file or directory

 SRPM creation can be done on any architecture builder.

 I should point out that F21 was built just fine...

 You probably forgot to add the patch on the f20 branch?

 josh

Missing patch on my end.
Thanks for help.

- Gilboa
-- 
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: ExcludeArch being ignored when building spring f20.

[Gilboa Davara]

On Wed, Nov 20, 2013 at 5:55 PM, Dan Horák d...@danny.cz wrote:
 On Wed, 20 Nov 2013 17:23:33 +0200
 Gilboa Davara gilb...@gmail.com wrote:

 Hello all,

 I'm facing a weird issue when trying to build a new version of spring.
 First and foremost, the spring.spec has ExcludeArch:ppc ppc64
 %{arm}, which should exclude arm* and ppc* (both not supported by
 upstream).

 also a question is whether you should rather do ExclusiveArch: %[ix86}
 x86_64 because there are other arches in Fedora like s390 or aarch64
 which are very likely also unsupported

Good idea. I'll issue new specs.

- Gilboa
-- 
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: excellent work!

[Gilboa Davara]

On Wed, Jul 3, 2013 at 2:13 PM, Neal Becker ndbeck...@gmail.com wrote:
 Just want to say I updated 2 machines using fedup, and everything seems to 
 have
 gone perfectly.

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

I second the above.
Thus far I upgraded 20 machines ranging from high-end Xeon servers
down to atom embedded systems and for the first time since, well,
more-or-less ever (and I've been using Fedora/RedHat since RHL 6.1..),
*all* the machines successfully went from Fedora 18 to Fedora 19 with
zero manual intervention.

Huge (!) congrats to the fedup team.

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

Re: Weird broken deps.

[Gilboa Davara]

On Mon, Apr 8, 2013 at 8:00 PM, Michael Schwendt mschwe...@gmail.com wrote:

 On Mon, 8 Apr 2013 19:51:15 +0300, Gilboa Davara wrote:

  Hello all,
 
  Can anyone help me make sense of the following broken-dep message?
 
  springlobby has broken dependencies in the rawhide tree:
  On i386:
  springlobby-0.169-2.fc20.i686 requires
  bdb835272157f37cbb0067c02ab4fc437596ed.debug
  springlobby-0.169-2.fc20.i686 requires
  508df0cdc1c9e84cded295738bec13842f070d.debug
  Please resolve this as soon as possible.
 
  ?!?!
  - Gilboa

 On platforms where %_libdir is /usr/lib, don't include

   %{_libdir}/*

 in the %files section, because it will include the -debuginfo package
 files. Be more specific about which files you want to include in your
 package.

Got it. Thanks.

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

Weird broken deps.

[Gilboa Davara]

Hello all,

Can anyone help me make sense of the following broken-dep message?

springlobby has broken dependencies in the rawhide tree:
On i386:
springlobby-0.169-2.fc20.i686 requires
bdb835272157f37cbb0067c02ab4fc437596ed.debug
springlobby-0.169-2.fc20.i686 requires
508df0cdc1c9e84cded295738bec13842f070d.debug
Please resolve this as soon as possible.

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

Re: Kernel panic Issue

[Gilboa Davara]

On Wed, Feb 27, 2013 at 1:00 PM, Darin Vivekananad
didforsa...@gmail.com wrote:

 Kernel Panic Error and got demsg and shows like this. Can any one tell any 
 issues with my machine

 Warning: dmesg info
 Linux version 2.6.17-1.2187_FC5smp (brewbuil...@hs20-bc2-2.build.redhat.com) 
 (gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)) #1 SMP Mon

1. Fedora Core 5 has been deprecate for ~6 years now. Your chances of
getting help are fairly slim.
2. You didn't include the actual kernel panic message or what you were
doing to trigger it. Without this information it's unlikely that
anyone here will be able to help you.

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

Re: Kernel panic Issue

[Gilboa Davara]

On Wed, Feb 27, 2013 at 1:09 PM, Gilboa Davara gilb...@gmail.com wrote:
 On Wed, Feb 27, 2013 at 1:00 PM, Darin Vivekananad
 didforsa...@gmail.com wrote:

 Kernel Panic Error and got demsg and shows like this. Can any one tell any 
 issues with my machine

 Warning: dmesg info
 Linux version 2.6.17-1.2187_FC5smp (brewbuil...@hs20-bc2-2.build.redhat.com) 
 (gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)) #1 SMP Mon

 1. Fedora Core 5 has been deprecate for ~6 years now. Your chances of
 getting help are fairly slim.
 2. You didn't include the actual kernel panic message or what you were
 doing to trigger it. Without this information it's unlikely that
 anyone here will be able to help you.

 - Gilboa

Saw oops message in the another message. Its looks like a network
device related crash - possibly hardware related (its very hard to
tell).
What's the machine hardware configuration?

Beyond that, can you upgrade (.) the machine to something
maintained? In this case (given the apparent age of the hardware) RHEL
5.x or CentOS 5.x? Both should be more-or-less comparable to your
existing FC5 setup, but will carry many (!!!) stability and security
enhancement compared to your existing FC5 installation.

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

Re: Kernel panic Issue

[Gilboa Davara]

On Wed, Feb 27, 2013 at 1:20 PM, Darin Vivekananad
didforsa...@gmail.com wrote:
 Dell poweedge 2900

Its an old machine running a very old and unsupported version of Linux.
How frequent are these crashes? Once in while? every reboot?

As far as I remember, back in the day the bnx drivers was somewhat
short tempered - that of-course, assuming that your old hardware isn't
failing (E.g. mother board, memory, etc)

The only way to be sure it's not a hardware related issue is to:
1. Run memtest.
2. Switch to a supported OS such as CentOS 5.8.

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

Re: Kernel panic Issue

[Gilboa Davara]

(Sorry for top posting - mobile)
Looking at the screenshot you sent it looks like network device driver
(bnx2) related crash.

Given how old both hardware and software are, there is no way of knowing
what was the root cause of this crash by looking at the screenshot.

Start by running memtest - if it passes without fault and you continue to
experience kernel crashes you should really replace Fedora with CentOS.

- Gilboa

Sent from my SGS2
On Feb 27, 2013 3:46 PM, Darin Vivekananad da...@didforsale.com wrote:

 Is it related to NFS sharing as We lost connection for few minutes and
 then its crashed. Any idea on NFS related panic error

 On Wed, Feb 27, 2013 at 4:44 PM, Gilboa Davara gilb...@gmail.com wrote:

 On Wed, Feb 27, 2013 at 1:09 PM, Gilboa Davara gilb...@gmail.com wrote:
  On Wed, Feb 27, 2013 at 1:00 PM, Darin Vivekananad
  didforsa...@gmail.com wrote:
 
  Kernel Panic Error and got demsg and shows like this. Can any one tell
 any issues with my machine
 
  Warning: dmesg info
  Linux version 2.6.17-1.2187_FC5smp (
 brewbuil...@hs20-bc2-2.build.redhat.com) (gcc version 4.1.1 20060525
 (Red Hat 4.1.1-1)) #1 SMP Mon
 
  1. Fedora Core 5 has been deprecate for ~6 years now. Your chances of
  getting help are fairly slim.
  2. You didn't include the actual kernel panic message or what you were
  doing to trigger it. Without this information it's unlikely that
  anyone here will be able to help you.
 
  - Gilboa

 Saw oops message in the another message. Its looks like a network
 device related crash - possibly hardware related (its very hard to
 tell).
 What's the machine hardware configuration?

 Beyond that, can you upgrade (.) the machine to something
 maintained? In this case (given the apparent age of the hardware) RHEL
 5.x or CentOS 5.x? Both should be more-or-less comparable to your
 existing FC5 setup, but will carry many (!!!) stability and security
 enhancement compared to your existing FC5 installation.

 - Gilboa
 --
 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

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

Re: Heads up: glew 1.9.0 coming to F19

[Gilboa Davara]

On Fri, Dec 14, 2012 at 2:01 AM, Adam Jackson a...@redhat.com wrote:

  spring-91.0-1.fc18.src.rpm

 Failed to build, but not my fault:

 /lib64/libIrrXML.so.1: undefined reference to 
 `irr::core::LOCALE_DECIMAL_POINTS'
 collect2: error: ld returned 1 exit status

 Everything else rebuilt fine.


Oh, joy. :(

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

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

[Gilboa Davara]

On Thu, Nov 8, 2012 at 5:55 AM, Adam Williamson awill...@redhat.com wrote:

 On Wed, 2012-11-07 at 21:07 -0600, Conan Kudo (ニール・ゴンパ) wrote:
  Oh my goodness. This is the highest amount of slippage I've seen in
  quite some time. What is wrong with Fedora?

 The new anaconda UI and related features are more or less entirely the
 cause of the slip. Secure boot support is also not done yet (waiting on
 the signature for shim to get sorted out by legal), though I don't know
 whether FESCo yet absolutely decided that has to be in for Beta.

  The slippage is getting worse each and every single release. I love
  Fedora and all, but this is absolutely ridiculous...

 It isn't, if you look at the facts, the slips for the last few releases
 have been fairly similar and there's no pattern of them getting longer.
 This release is special because of the major anaconda change, which it's
 turning out after the fact could have been organized better (hindsight
 is 20/20).


Has anyone (FESCo) considered pushing Anaconda rewrite to F19 and ship
F18 w/ the old Anaconda?
I just tried the latest TC and while Anaconda did give me a working
F18 installation, the experience is still rather raw (Can't say the I
met major bugs, though).

... With all the testing resources pushing toward Anaconda, its very
likely that breakage in (many) other components may go unnoticed.

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

Re: Replacing grubby with grub2-mkconfig in kernel install process

[Gilboa Davara]

On Sun, Jun 17, 2012 at 4:40 PM, Andre Robatino
robat...@fedoraproject.org wrote:
 Ben Rosser rosser.bjr at gmail.com writes:

 It seems to me that we should make the boot menu more consistent somehow. I
 feel like the simplest solution is just to run grub2-mkconfig at every kernel
 update, and stop using grubby for this. Then everything would look
 consistent- the Fedora Linux boot option would have the latest kernel 
 and all
 kernels would always be listed under the submenu. (As far as I know, this 
 would
 just be a change to the kernel specfile, right?).

 +1

 The present system is especially ugly with multiboot. I tend to run
 grub2-mkconfig by hand after each kernel update just to keep the menu clean.

/+100
I found that yum update  grub-mkconfig ... makes my life *far* easier.

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

Re: Xfce 4.10pre1 in rawhide

[Gilboa Davara]

On Sun, Apr 1, 2012 at 11:12 PM, Kevin Fenzi ke...@scrye.com wrote:

 greetings.

 Xfce 4.10pre1 is out... and I am going to look at landing it in rawhide
 in the next few days.

 Hopefully there won't be too much disruption caused by this (it's 17
 packages), just wanted to give rawhide Xfce users a heads up.

 Also, any comments, help, edits with the Xfce 4.10 feature page are
 most welcome:

 https://fedoraproject.org/wiki/Features/Xfce-4.10

 kevin


Hi,

Any chance of building a personal repository for F17 or better yet, F16?

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

Re: Xfce 4.10pre1 in rawhide

[Gilboa Davara]

On Tue, Apr 3, 2012 at 9:55 AM, Frank Murphy frankl...@gmail.com wrote:
 On 03/04/12 07:52, Gilboa Davara wrote:


 Any chance of building a personal repository for F17 or better yet, F16?

 - Gilboa


 https://lists.fedoraproject.org/pipermail/xfce/2012-April/001082.html

The feature page doesn't include any information about F17 or F18,
hence my question.

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

Re: Xfce 4.10pre1 in rawhide

[Gilboa Davara]

On Tue, Apr 3, 2012 at 10:31 AM, Frank Murphy frankl...@gmail.com wrote:
 Hence my reply.

*Sigh*

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

Bodhi problems?

[Gilboa Davara]

Hello all,

Since 06:00 UTC time, I've been trying to get a new icewm build
(el5/6,fc15/16) out of the door and facing a barrage of uninformative
error codes, ranging from 500 Internal error,  build was not
tagged to simple empty page.
In the end, I gave on on trying to push the 4 build together and
started pushing them one by one, it reduced to success failure ratio
to 1/4, but worked.

Two questions:
Is bodhi down? Did I miss some down-time message?
Am I the only one to experience this issue?

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

Re: PA 1.0 for FC16?

[Gilboa Davara]

On Sat, Oct 8, 2011 at 10:36 PM, Peter Robinson pbrobin...@gmail.com wrote:

 On Sat, Oct 8, 2011 at 2:43 PM, Gilboa Davara gilb...@gmail.com wrote:
  Hello all,
 
  Short question:
  PA 1.0 was released ~1 month ago.
  According to the wine developers, the updated mmdevapi layer (the wine
  layer that emulates the Windows sound system) more-or-less requires
  current PA (1.0?) to work reliably. [1]
  For now, sound is completely broken under wine on any of my workstations 
  [2].
  Any chance of having it land in F16 or is it rawhide only for now?
 
  P.S. As far as I can gather, Ubuntu 11.10 will most likely ship w/ PA 1.0.

 Since when has that ever been part of the a decision making process
 for what Fedora does?

 Peter

It was *not* an attempt to trash Fedora release policy.
It *was* an attempt to point out that that most likely wine developers
will view PA 1.0 as standard when targeting their development.

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

Re: PA 1.0 for FC16?

[Gilboa Davara]

On Mon, Oct 10, 2011 at 6:39 PM, Lennart Poettering
mzerq...@0pointer.de wrote:
 On Sat, 08.10.11 18:08, Gilboa Davara (gilb...@gmail.com) wrote:

 I might be completely off target on this one, but assuming that the
 information I've gathered thus far is correct, read: assuming that
 wine *requires* PA 1.0 to work reliably, will it possible to push PA
 1.0 as a post installation upgrade or alternatively, using a personal
 repo?

 PA 1.0 is a feature upgrade and not limited to bugfixes. I am not going
 to push it in that late in the process, and not after the release
 either.

 I firmly believe in that released distribution should not get feature
 uprgades, only bugfixes. And I am definitely not going to change this
 opinion now.

 Lennart

OK. thanks.

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

PA 1.0 for FC16?

[Gilboa Davara]

Hello all,

Short question:
PA 1.0 was released ~1 month ago.
According to the wine developers, the updated mmdevapi layer (the wine
layer that emulates the Windows sound system) more-or-less requires
current PA (1.0?) to work reliably. [1]
For now, sound is completely broken under wine on any of my workstations [2].
Any chance of having it land in F16 or is it rawhide only for now?

P.S. As far as I can gather, Ubuntu 11.10 will most likely ship w/ PA 1.0.

- Gilboa
[1] http://bugs.winehq.org/show_bug.cgi?id=10495
[2] http://bugs.winehq.org/show_bug.cgi?id=28622
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PA 1.0 for FC16?

[Gilboa Davara]

On Sat, Oct 8, 2011 at 3:48 PM, Lennart Poettering mzerq...@0pointer.de wrote:
 On Sat, 08.10.11 15:43, Gilboa Davara (gilb...@gmail.com) wrote:

 Hello all,

 Short question:
 PA 1.0 was released ~1 month ago.

 It was released 12 days ago.

My mistake.


 According to the wine developers, the updated mmdevapi layer (the wine
 layer that emulates the Windows sound system) more-or-less requires
 current PA (1.0?) to work reliably. [1]
 For now, sound is completely broken under wine on any of my workstations [2].
 Any chance of having it land in F16 or is it rawhide only for now?

 I plan to update PA in F17 only.

I might be completely off target on this one, but assuming that the
information I've gathered thus far is correct, read: assuming that
wine *requires* PA 1.0 to work reliably, will it possible to push PA
1.0 as a post installation upgrade or alternatively, using a personal
repo?

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

Re: PA 1.0 for FC16?

[Gilboa Davara]

On Sat, Oct 8, 2011 at 7:04 PM, Rex Dieter rdie...@math.unl.edu wrote:


 I might be completely off target on this one, but assuming that the
 information I've gathered thus far is correct, read: assuming that
 wine *requires* PA 1.0 to work reliably, will it possible to push PA
 1.0 as a post installation upgrade or alternatively, using a personal
 repo?

 I can offer to update,
 http://repos.fedorapeople.org/repos/rdieter/pulseaudio-backport/
 to pa-1.0 (once it hits rawhide) for f16 at least.

 -- rex

Rex,

Please do.
As always, you're the man :)

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

Re: koji: kernel-2.6.40-3.fc15

[Gilboa Davara]

On Fri, 2011-07-29 at 13:53 +0200, Reindl Harald wrote:
 http://koji.fedoraproject.org/koji/buildinfo?buildID=256138
 
 does this mean that F15 will get a rebased 2.6.40 sooner or
 later in stable repos to avoid troubles with the new versioning
 and will not stuck at 2.6.38 the whole life cycle?

Hi,

I know its beyond the scope of this Fedora-proper, but would it be
possible to rebuild the kernel w/ CONFIG_LOCKDEP disabled so people
using the nVidia binary driver will be able to test it?

Thanks.
- Gilboa

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

Orphaning iDesk

[Gilboa Davara]

Hello all,

I've orphaned idesk.
Upstream is long dead and I'm currently do not have the necessary free
time to get it to work under Fedora 15.

- Gilboa

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

Re: F15 / VirtualBox

[Gilboa Davara]

On Mon, 2011-06-13 at 10:25 +0200, Vít Ondruch wrote:
 Dne 11.6.2011 16:21, Gilboa Davara napsal(a):
 
  On Fri, 2011-06-10 at 16:25 +0100, Tom Hughes wrote:
  On 10/06/11 16:12, Michael Cronenworth wrote:
 
  Richard W.M. Jones wrote:

  They are available, but I think you have to build them yourself from
  source.  All the information is here:
  2. Make guest additions dead simple to install. Having to compile them
  with a Windows DDK is not dead simple.
  Actually building the driver (once I'd downloaded the 620Mb DDK) was
  quite easy. I'm still scratching my head over how to actually install it
  though ;-)
  Actually, even if you build the driver and get it to work, you're still
  stuck with the Windows' driver signature enforcement which makes
  installing unsigned drivers (such as one that you build yourself)
  more-or-less impossible (I tried every possible software / hack-ware to
  disable it and failed; ended up getting used to manual F8/Disable
  signature enforcement boot sequence).
 
  I fear that as long as RH doesn't MS the (protection) fees required to
  sign the QXL driver, I fear that this issue will remain unresolved.
  (On the other hand, nothing stops -me- from doing it and yet I don't see
  me running to do it :))
 
 May be this can help: http://www.reactos.org/wiki/Driver_Signing

Thanks.

- Gilboa

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

Re: F15 / VirtualBox

[Gilboa Davara]

On Fri, 2011-06-10 at 16:25 +0100, Tom Hughes wrote:
 On 10/06/11 16:12, Michael Cronenworth wrote:
 
  Richard W.M. Jones wrote:
  
  They are available, but I think you have to build them yourself from
  source.  All the information is here:
 
  2. Make guest additions dead simple to install. Having to compile them
  with a Windows DDK is not dead simple.
 
 Actually building the driver (once I'd downloaded the 620Mb DDK) was 
 quite easy. I'm still scratching my head over how to actually install it 
 though ;-)

Actually, even if you build the driver and get it to work, you're still
stuck with the Windows' driver signature enforcement which makes
installing unsigned drivers (such as one that you build yourself)
more-or-less impossible (I tried every possible software / hack-ware to
disable it and failed; ended up getting used to manual F8/Disable
signature enforcement boot sequence).

I fear that as long as RH doesn't MS the (protection) fees required to
sign the QXL driver, I fear that this issue will remain unresolved.
(On the other hand, nothing stops -me- from doing it and yet I don't see
me running to do it :))

As for the subject at hand, -I- find VB a far inferior solution when it
comes to SMP and IO (disk/network) performance.
Sure, during the years I've create a large chunk of scripts required to
deploy and configure qemu VM's, but once you pass the I fear the qemu
command line phase, KVM runs circles around VB. (Let alone having to
relay on a unsupported 3'rd party kernel module - a huge no-no in server
deployments)
Nothing beats starting a VM in snapshot mode, trashing it, and reverting
to the original without as much a single mouse click...

I do use VB on VT-incapable machines such as my ATOM netbook - but
that's about it.

- Gilboa


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

Re: F15 / VirtualBox

[Gilboa Davara]

 
  1. Easy setup of networking (bridged).
 Just to followup, to setup bridged net on kvm I need to reboot my server.  
 That's a non-starter.

And long as you're will to do the hard work yourself, there's no need to
reboot your machine.

1. Create a bridge configuration for each target network devices (E.g.
ifcfg-vbr0 for ifcfg-eth0).
2. Mark the ethX device as IP-less and boot-protocol-less (IPADDR=,
IPV6_ADDR=, BOOTPROTO=none) and bridge controlled (BRIDGE=brX),
configure the bridge device (DEVICE=brX, TYPE=Brdige, IPADDR, IPV6_ADDR,
etc)
2. Disable NM on both the bridge and the Ethernet device
(NM_CONTROLLED=no).
3. Restart NM. (Or disable it if all your Ethernet devices are bridged)
4. Enable and start network service.
(If you don't want to interrupt incoming connections, you'll have to
start each network device by hand)
5. Profit.

At worse, you'll have a 2-3 second interruption while the bridge assumes
the IP address originally held by the Ethernet device.

- Gilboa


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

gpk-update-icon replacement under XFCE and other alternative DEs.

[Gilboa Davara]

Hello all,

I've upgrade my netbook from F14 to F15.
The netbook is running XFCE 4.8.
Previously, in F14, gpk-update-icon was responsible for display an alert
when updates are available.
As far as I can see, gpk-update-icon is no longer available in
gnome-packagekit and according to yum it's no longer available (yum
whatprovides */gpk-update-icon returns nothing)

The irony is that according to Fedora 15 deployment guide (section 5.3,
PackageKit architecture), gpk-update-icon is still a part of Fedora.

What am I missing?

- Gilboa

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

Re: gpk-update-icon replacement under XFCE and other alternative DEs.

[Gilboa Davara]

On Sun, 2011-05-29 at 11:06 +0100, Frank Murphy wrote:
 
 /usr/bin/gpk-prefs

As far as I can see, gpk-prefs only handles the gpk configuration and
cannot be used as a alert icon.

- Gilboa


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

Re: gpk-update-icon replacement under XFCE and other alternative DEs.

[Gilboa Davara]

On Sun, 2011-05-29 at 11:48 +0100, Frank Murphy wrote:
 On 29/05/11 11:24, Gilboa Davara wrote:
  On Sun, 2011-05-29 at 11:06 +0100, Frank Murphy wrote:
 
  /usr/bin/gpk-prefs
 
  As far as I can see, gpk-prefs only handles the gpk configuration and
  cannot be used as a alert icon.
 
  - Gilboa
 
 
 
 This might be relevant:
 http://comments.gmane.org/gmane.linux.redhat.fedora.xfce/311
 

Ugh. I see.
Thanks for the link.

- Gilboa

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

Re: Delayed encrypted partition mount

[Gilboa Davara]

On Mon, 2011-03-28 at 16:23 +0200, Lennart Poettering wrote:
 On Mon, 21.03.11 09:35, Bruno Wolff III (br...@wolff.to) wrote:
 
  
  On Mon, Mar 21, 2011 at 16:22:59 +0200,
Gilboa Davara gilb...@gmail.com wrote:
   
   My question is simple: Given the fact that I rarely encrypt the root,
   can I somehow delay the encrypted partition mount to right-before-gdm,
   so all the essential services (samba, nfs, cups) - especially network
   and sshd, will be up, so I can remotely type the password required to
   mount the encrypted partitions?
  
  I think under systemd there is a timeout and the system will continue to
  boot without the encrypted devices being mounted.
 
 On systemd systems you can add nofail to the options in
 /etc/crypttab. If used systemd will automatically decrypt the device if
 it is plugged in (you will get a wall message telling you to enter the
 passphrase for that and how to do that), but if it isn't it won't delay
 bootup.
 
 Lennart
 

I'm not sure that we're talking about the same thing:
I'm talking about having /home decrypt failure / timeout being delayed
until GDM starts.
Would nofail help?

- Gilboa

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

Re: ixgbe/udev mystery

[Gilboa Davara]

On Fri, 2011-03-25 at 19:01 +0100, Thomas Bendler wrote:
 2011/3/25 Thomas Bendler m...@bendler-net.de
 [...] 
 
 One remark, the error occured with the standard ixgbe module
 (2.0.62-k2), so I upgraded the module to the latest version
 (3.2.10-NAPI) but still have the same error.
 
 
 And another remark, the network card work without problems when using
 Ubuntu 11.04.2 instead of Fedora (ixgbe driver version 2.0.44-k2).
 
 Regards, Thomas
 

Have you tried using the latest ixgbe drivers from intel.com [1]?
It's far newer (v3.2.10) than the one shipped with the kernel and in the
past, I've had far less issues with it.

- Gilboa
[1]
http://downloadcenter.intel.com/Detail_Desc.aspx?agr=YDwnldID=14687ProdId=2914lang=eng




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

Re: Delayed encrypted partition mount

[Gilboa Davara]

On Mon, 2011-03-21 at 15:32 -0400, Gregory Maxwell wrote: 
 On Mon, Mar 21, 2011 at 10:22 AM, Gilboa Davara gilb...@gmail.com wrote:
  Hello all,
 
  I routinely encrypt all important partitions on my laptops /
  workstations / servers using LUKS both at home and at work.
  However, due to the above, I can no longer remotely reboot the machines
  (at least the ones that doesn't have a serial console attached) as I'm
  required to baby-sit the machine until the password prompt appears.
 
  My question is simple: Given the fact that I rarely encrypt the root,
  can I somehow delay the encrypted partition mount to right-before-gdm,
  so all the essential services (samba, nfs, cups) - especially network
  and sshd, will be up, so I can remotely type the password required to
  mount the encrypted partitions?
 
  I could delete the entries from /etc/cryptab, create a service that will
  mount the partitions late in the boot process, but AFAIK, this will not
  display the graphical password prompt making it less than ideal...
 
 You can use pam_mount (available as part of fedora) to make the system
 mount encrypted file systems at login using the same password you use
 for login.

Nice idea... but won't help.
As (and extra) security measure, I never use user-password(s) to encrypt
partitions.


 I've used this for a number of years, and it's very nice. I recommend it.
 The only problem I've had with it is that the syntax has changed
 between fedora versions and caused me to have to waste a little time
 relearning it... well, that and it adds a few steps to setting up
 a new system.

- Gilboa

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

Delayed encrypted partition mount

[Gilboa Davara]

Hello all,

I routinely encrypt all important partitions on my laptops /
workstations / servers using LUKS both at home and at work.
However, due to the above, I can no longer remotely reboot the machines
(at least the ones that doesn't have a serial console attached) as I'm
required to baby-sit the machine until the password prompt appears.

My question is simple: Given the fact that I rarely encrypt the root,
can I somehow delay the encrypted partition mount to right-before-gdm,
so all the essential services (samba, nfs, cups) - especially network
and sshd, will be up, so I can remotely type the password required to
mount the encrypted partitions?

I could delete the entries from /etc/cryptab, create a service that will
mount the partitions late in the boot process, but AFAIK, this will not
display the graphical password prompt making it less than ideal...

- Gilboa

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

Re: Delayed encrypted partition mount

[Gilboa Davara]

On Mon, 2011-03-21 at 09:35 -0500, Bruno Wolff III wrote:
 On Mon, Mar 21, 2011 at 16:22:59 +0200,
   Gilboa Davara gilb...@gmail.com wrote:
  
  My question is simple: Given the fact that I rarely encrypt the root,
  can I somehow delay the encrypted partition mount to right-before-gdm,
  so all the essential services (samba, nfs, cups) - especially network
  and sshd, will be up, so I can remotely type the password required to
  mount the encrypted partitions?
 
 I think under systemd there is a timeout and the system will continue to
 boot without the encrypted devices being mounted.

Yeah, I saw it.
I was looking for a somewhat cleaner solution.

- Gilboa

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

Re: Retired package by mistake - undo?

[Gilboa Davara]

On Wed, 2010-12-15 at 07:43 -0800, Toshio Kuratomi wrote:
 On Tue, Dec 14, 2010 at 04:21:35PM +0200, Gilboa Davara wrote:
  On Tue, 2010-12-14 at 08:19 -0600, Jason L Tibbitts III wrote:
   OK, I found spring-installer and unretired it as well.  You should log
   into pkgdb and claim both packages as they're currently orphaned.
   
- J
  
  Thanks!
  
 And for reference, the best way to get admin help in the future is by
 opening a SCMAdmin request:
 https://fedoraproject.org/wiki/Package_SCM_admin_requests
 
 -Toshio

Thanks.

- Gilboa

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

Nonreponsive maintainer for atop: Kairo Francisco de Araujo

[Gilboa Davara]

Hello all,

Following the nonresponsive package maintainers policy, a new version of
atop has been released a couple of months ago but never made it into
Fedora, bug report filed (+patch, [1]) 3 weeks ago.

Other open bug listed below. [2,3]

- Gilboa
[1] https://bugzilla.redhat.com/show_bug.cgi?id=657207
[2] https://bugzilla.redhat.com/show_bug.cgi?id=609124
[3] https://bugzilla.redhat.com/show_bug.cgi?id=659629


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

Retired package by mistake - undo?

[Gilboa Davara]

Hello all,

While the click-frenzy required to take ownership over spring and its
sub packages I mistakably retired spring-maps-default / devel and
spring-install / devel.
I tried to unretire them both, but failed.

Admins, help?

- Gilboa 

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

Re: Retired package by mistake - undo?

[Gilboa Davara]

On Tue, 2010-12-14 at 08:19 -0600, Jason L Tibbitts III wrote:
 OK, I found spring-installer and unretired it as well.  You should log
 into pkgdb and claim both packages as they're currently orphaned.
 
  - J

Thanks!

- Gilboa

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

Re: Testing Xfce 4.8 pre 2 packages available

[Gilboa Davara]

On Mon, 2010-12-06 at 00:01 +0100, Christoph Wickert wrote:
 Hi there,
 
 I have packaged Xfce 4-8 pre 2 for Fedora 14 and Rawhide. You can find
 the packages at
 
 http://repos.fedorapeople.org/repos/cwickert/xfce-4.8/

 
 The repo is far from complete. ATM it is still rsyncing and Fedora 13 is
 still building. Also a couple of applications that need a rebuild (e.g.
 xfce4-mixer) are missing and so are most of the goodies. I will continue
 to work on this.
 
 For more information on Xfce 4.8 in Fedora, please take a look at the
 feature page at https://fedoraproject.org/wiki/Features/Xfce48
 
 Feedback welcome!
 
 Regards,
 Christoph

Thanks!

Should I report missing deps?

- Gilboa

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

Re: OO updates - no presto support?

[Gilboa Davara]

On Sat, 2010-12-04 at 19:00 +0530, Rahul Sundaram wrote:
 On 12/04/2010 06:54 PM, Gilboa Davara wrote:
  Hello all,
 
  I've noticed that since the release of F14 a fairly large [1] number of
  OO updates came down the wire - non of them in deltarpm/presto form
  (read: a 100MB download per release).
 
  Is it bug or intended behavior?
  If its a bug, wouldn't it be wise to hold off on releasing
  non-security-fixes until its resolved?
 
  FWIW, I'm on Fedora 14, x86_64.
 
 It is a bug.  Refer to
 
 http://lists.fedoraproject.org/pipermail/users/2010-November/387625.html
 
 Rahul
 

Thanks.
The ML post quite thin on details, any idea if this has been reported on
bugzilla?

- Gilboa

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

OO updates - no presto support?

[Gilboa Davara]

Hello all,

I've noticed that since the release of F14 a fairly large [1] number of
OO updates came down the wire - non of them in deltarpm/presto form
(read: a 100MB download per release).

Is it bug or intended behavior?
If its a bug, wouldn't it be wise to hold off on releasing
non-security-fixes until its resolved?

FWIW, I'm on Fedora 14, x86_64.

- Gilboa
[1]
$ cat /var/log/yum.log | grep openoffice.org-core | grep fc14
Nov 09 11:12:38 Updated: 1:openoffice.org-core-3.3.0-13.3.fc14.x86_64
Nov 21 13:35:30 Updated: 1:openoffice.org-core-3.3.0-14.1.fc14.x86_64
Nov 24 09:18:57 Updated: 1:openoffice.org-core-3.3.0-15.2.fc14.x86_64
Dec 04 14:02:43 Updated: 1:openoffice.org-core-3.3.0-17.2.fc14.x86_64


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

Re: sched_autogroup interactivity patch for the desktop

[Gilboa Davara]

On Tue, 2010-11-16 at 11:39 -0500, Kyle McMartin wrote:
 On Tue, Nov 16, 2010 at 04:58:11PM +0100, Ilyes Gouta wrote:
  Can we have this patch back ported into the current kernel for Fedora 14 and
  possibly posted as an update? :)
  
  Would be wonderful!
  
 
 Try this,
 http://kyle.fedorapeople.org/kernel/2.6.35.8-59.xsched1/
 i686 coming whenever mock finishes.
 
 regards, Kyle.

Thanks!

I'll test it ASAP on my Xeon workstation(s). *

- Gilboa
* That suffer badly when I start too many VM's (via qemu-kvm w/ VNC
head) in the background.

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

Re: Ubuntu 10.10's installer looks rather nice

[Gilboa Davara]

On Wed, 2010-10-13 at 23:51 +0200, Ralf Ertzinger wrote:
 Hi.
 
 On Wed, 13 Oct 2010 22:26:18 +0200, Gilboa Davara wrote
 
  As you pointed out, different drives, can have more-or-less identical
  partition size, with different CHS in the partition table.
 
 I my experience the hard disk vendors have been astonishingly coordinated
 in how much sectors a drive of a given size should have.

... My experience is somewhat different, but as I said, I'm paranoid :)

- Gilboa

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

Re: Ubuntu 10.10's installer looks rather nice

[Gilboa Davara]

On Tue, 2010-10-12 at 18:18 +0100, Evan Dandrea wrote:
 The Ubuntu installer does let you use a NFS root for your installation source.
 
 On the point of needing something more complex, such as LVM or full disk
 encryption, that's what we offer our alternate CD installer (debian-installer)
 for.
 
 I'm not challenging your point that the Fedora installer offers more complex
 options.  I just wanted to clarify our approach, as our users are not screwed
 in these circumstances, we just clearly separate their use cases to different
 CDs.

Thanks for the head's up, I considered suicide when I recently tested
10.10/DVD/amd64 and tried doing some standard partitioning using the
default DVD tool. (Unless I missed something, once you create a
partition is stays put, you cannot edit or move it. Nothing beats
creating 5 partitions, just to find out that the first partition [/boot]
is 20MB instead of 200MB - forcing you to delete and restart... Pure
joy)


- Gilboa


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

Re: Ubuntu 10.10's installer looks rather nice

[Gilboa Davara]

 Hello,
 
 I am doing the same setup, nice to see someone else with those
 requirements. actually without kickstart setting up softraid in
 anaconda was broken (try it manually without precreated partitions...
 it will drive you insane). out of the box booting didnt work when
 /boot was on a mirror raid and the mbr wasnt cloned either. not that
 great of an out of the box experience. i had those issues in f11 f12
 and f13.
 but hey... instead of redundancy having some colored automatically
 selected flags and languages is probably more important after all.
 
 kind regards,
 Rudolf Kastl

When installing Fedora on machine with -large- amount of drives (8-16),
I simply use a single sfdisk script to create the same partition table
on all drives. When dealing with smaller configurations (3-4 drives),
Anaconda is OK. (At least to me)

As for MBR: I assume that like me, you create a small RAID1 for /boot
and RAIDX for the rest, hoping the first disk won't die on a DVD-less
machine :)
In-order to solve it (when I remember to do it :)), I simply dd 446
bytes from the first drive to every other drive.

- Gilboa

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

Re: Ubuntu 10.10's installer looks rather nice

[Gilboa Davara]

On Wed, 2010-10-13 at 11:50 -0400, Przemek Klosowski wrote:
 Just curious: you script the creation of an identical partition table,
 and then you copy 446 bytes which specifically copies the MBR without 
 the partition table which is in bytes 447-512. Why not just copy the 
 entire 512 bytes to all the disks from the first one?
 I guess one reason might be if the disks did not have identical CHS 
 geometry, which can happen for the identically sized disks. I have heard 
 rumors that even a single model drives had been seen with different 
 geometries in different firmware revisions.

I'm paranoid, that why :)
While in most machines, I have identical drives from the same
manufacturer, in others, I specifically buy drive of the same size, but
from different manufacturers and even different dates to reduce the risk
of simultaneous death of multiple drives. (Same drive, same
manufacturer, same batch, same day, etc)
As you pointed out, different drives, can have more-or-less identical
partition size, with different CHS in the partition table.

As I don't trust myself to use the -right- size every time (446 vs 512),
I simply assume the worse.

-- 
Gilboa Davara
http://www.wirex-systems.com


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

Re: Ubuntu 10.10's installer looks rather nice

[Gilboa Davara]

On Mon, 2010-10-11 at 11:41 +0100, Richard W.M. Jones wrote:
 I installed and played with Ubuntu 10.10 over the weekend (in a VM),
 and I have to say that their installer is very smooth indeed.  It's
 starting to make anaconda look distinctly clunky.
 
 Some of the things it does which are IMHO better:
 
  - starts disk formatting / copying / installing in parallel
with asking user questions
 
  - downloads updates in parallel too
 
  - uses IP geolocation to guess the user's timezone and keyboard
settings (it's been 100% correct for me each time)
 
  - suggests a username and hostname based on the user's real name
(Mac OS X's installer also does this -- it's a nice touch)
 
 This is in contrast to anaconda (certainly from the live CD install)
 which seems to be a usability no-go area.
 
 Thoughts?  Can we switch to their installer?
 
 Rich.
 

Comparing the Ubuntu 10.04 DVD installer (which I use a couple of weeks
ago) to Fedora 13 DVD installer is like comparing the Cessna to a Boeing
747.
Sure, both can accomplish the same task. Read: transporting people from
one airport to another, but lets see you try transporting 400 peoples
from London to NY using a Cessna... 

The same logic applies to the Ubuntu installer: As long as you require a
fairly basic -desktop- configuration (Read: No fancy storage, no LVM, no
fancy setup source [nfs, dvd, http], -very- basic encryption, standard
software set and repository selection, etc), the Ubuntu installer is a
great tool, but once you need something complex, you're screwed.

- Gilboa

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

Re: Ubuntu 10.10's installer looks rather nice

[Gilboa Davara]

On Mon, 2010-10-11 at 12:09 -0400, Jon Masters wrote:
 On Mon, 2010-10-11 at 17:39 +0200, Gilboa Davara wrote:
 
  Comparing the Ubuntu 10.04 DVD installer (which I use a couple of weeks
  ago) to Fedora 13 DVD installer is like comparing the Cessna to a Boeing
  747.
  Sure, both can accomplish the same task. Read: transporting people from
  one airport to another, but lets see you try transporting 400 peoples
  from London to NY using a Cessna... 
  
  The same logic applies to the Ubuntu installer: As long as you require a
  fairly basic -desktop- configuration (Read: No fancy storage, no LVM, no
  fancy setup source [nfs, dvd, http], -very- basic encryption, standard
  software set and repository selection, etc), the Ubuntu installer is a
  great tool, but once you need something complex, you're screwed.
 
 That's all true. I've found the Ubuntu installer looks /very/ polished
 and nice for very common install cases, but I always use LVM on every
 install that I do, and last time I did a VM install of Ubuntu, I had to
 switch to a VT and get LVM sorted on the command line. Not super user
 friendly as compared with Anaconda. Other installers were even more of a
 joke doing this stuff. Tried doing LVM on Gentoo? :) Things like LVM and
 VNC do really matter, and not just for Enterprise users. You don't
 need to use LVM w/wo RAID, you can just do bare partitions if you don't
 care about being able to do anything useful with your disks at all :)

Amen to that.
Given the absurdly cheap price of HD these days, I usually opt for LVM
over software RAID1 / RAID5 on each and every workstation machine I
install.
Achieving the same using the Ubuntu installer would have required a lot
of manual mdadm and lvm pv/vg/lv** commands. (Let alone their basic disk
partitioning tool)

... In their race for Joe-six-pack and Apple like polish, Ubuntu gave up
on many Linux core capabilities. Hopefully Fedora will -not- follow
suite.

- Gilboa

- Gilboa

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

Re: Increase grub timeout

[Gilboa Davara]

On Sat, 2010-05-15 at 11:01 +0200, Richard Zidlicky wrote:
 On Sat, May 15, 2010 at 09:58:27AM +0200, Alexander Boström wrote:
 
  Long story short: There are situations where a grub menu is vital, like
  until you've successfully booted a new kernel.
 
 of course, and I do not think it is so hard to think of a sensible behaviour.
 
 After each (semi)automatic change to grub/kernel conf as well as for the very 
 first 
 boot there should be a timeout as well as visible menu.
 Once the kernel did boot with default command line etc it would be safe to 
 set 
 the timeout to a small value - after asking the user. 
 
 More elaborate solution, there could be two config values - quicktimeout and 
 safetimout.
 After kernel and config changes timeout would be changed to safetimout and 
 once 
 the kernel booted safely it could be reset to quicktimeout automatically.
 
 Richard

Another options will be to test a successful boot flag. (E.g. a touch
file in /boot/).
If the file doesn't exists (Post installation, new kernel, failed
boot/shutdown) grub should switch to a predefined timeout, giving the
user time to react.

The main issue here, is grub changes. Such a feature will require
changes to grub (code), kernel (post install script) and init functions.

While the last two are less problematic (bash scripts), given the fact
that development of grub is slowly shifting to grub2, I doubt that the
Fedora grub maintainers will be willing to spend time on such a feature
when grub is be phased out. (Or is it?)

- Gilboa


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

Re: Increase grub timeout

[Gilboa Davara]

On Sat, 2010-05-15 at 12:19 +0300, Gilboa Davara wrote:
 On Sat, 2010-05-15 at 11:01 +0200, Richard Zidlicky wrote:
  On Sat, May 15, 2010 at 09:58:27AM +0200, Alexander Boström wrote:
  
   Long story short: There are situations where a grub menu is vital, like
   until you've successfully booted a new kernel.
  
  of course, and I do not think it is so hard to think of a sensible 
  behaviour.
  
  After each (semi)automatic change to grub/kernel conf as well as for the 
  very first 
  boot there should be a timeout as well as visible menu.
  Once the kernel did boot with default command line etc it would be safe to 
  set 
  the timeout to a small value - after asking the user. 
  
  More elaborate solution, there could be two config values - quicktimeout 
  and 
  safetimout.
  After kernel and config changes timeout would be changed to safetimout and 
  once 
  the kernel booted safely it could be reset to quicktimeout automatically.
  
  Richard
 
 Another options will be to test a successful boot flag. (E.g. a touch
 file in /boot/).
 If the file doesn't exists (Post installation, new kernel, failed
 boot/shutdown) grub should switch to a predefined timeout, giving the
 user time to react.
 
 The main issue here, is grub changes. Such a feature will require
 changes to grub (code), kernel (post install script) and init functions.
 
 While the last two are less problematic (bash scripts), given the fact
 that development of grub is slowly shifting to grub2, I doubt that the
 Fedora grub maintainers will be willing to spend time on such a feature
 when grub is be phased out. (Or is it?)
 
 - Gilboa
 

Actually, I do remember grub having a fallback feature.
It should solve the failed kernel upgrade problem.
However, it will not solve the failed first boot problem.

- Gilboa


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

Re: Reasons for hall monitoring

[Gilboa Davara]

On Mon, 2010-05-10 at 16:19 -0700, Jesse Keating wrote:
  Let me reverse the question: How did they gather the community input?
  From whom it was gathered?
  What was the question?
  What was the answer?
  
  - Gilboa
  
  
 
 Most likely by reading or participating in the various threads on
 subjects that have happened on this list and the FAB list and the
 desktop list and others.  It seems to be a rather big assumption that
 board decisions are made in a vacuum.

It seems that we don't share the same definition of community input and
community involvement.

For the sake of the Fedora project, I do hope that you're right and I'm
wrong.

- Gilboa

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

Re: Realtek 8192se on F12/F13

[Gilboa Davara]

On Mon, 2010-05-10 at 12:38 +0200, Jos Vos wrote:
 Hi,
 
 What is the status of support for the Realtek 8192se WiFi
 controller in F12 and F13?
 
 I see in some wiki page a reference to the Realtek website,
 at least for (stock) F12.
 
 Is this chipset in the meantime supported in the F12 kernel
 and/or will it be supported in F13?
 
 Thanks,

As far as I know, the 8192se is yet to enter the main kernel tree.
For now, I'm using the latest version of realtek.com [1] (it builds
cleanly on F12), which more-or-less works. (Performance is a bit slow,
but the connection is solid)

- Gilboa
[1] 
http://www.realtek.com/downloads/downloadsView.aspx?Langid=1PNid=21PFid=48Level=5Conn=4DownTypeID=3GetDown=falseDownloads=true


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

Re: Reasons for hall monitoring

[Gilboa Davara]

On Mon, 2010-05-10 at 11:05 -0700, Jesse Keating wrote:
 On Mon, 2010-05-10 at 07:28 +0300, Gilboa Davara wrote:
  I do not agree that that working with zero community input is the way to
  achieve a working compromise. (And input does not equal vote)
  
 What makes you think that no community input is considered?

Let me reverse the question: How did they gather the community input?
From whom it was gathered?
What was the question?
What was the answer?

- Gilboa


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

Re: Reasons for hall monitoring

[Gilboa Davara]

On Sun, 2010-05-09 at 11:09 +0100, Adam Williamson wrote:

 I'm tempted to agree in practice with Matej that it is. I don't think we
 can kid ourselves that we're doing a particularly good job of making a
 desktop for end users; if we were, we wouldn't be being trashed by
 Ubuntu in this area (let alone OS X and Windows). Yes, yes, I know,
 Ubuntu's statistics are unreliable and all that crap. I know we can all
 rationalize for ten hours about how it's all Microsoft's fault for being
 evil and Ubuntu's fault for being good at marketing and users' fault for
 being stupid and blah de freaking blah.
 
 But be practical. When you go to $RANDOM_LINUX_CONFERENCE (never mind
 when you go to the coffee shop, I have never seen anyone else running
 Fedora in any situation outside of the 'Linux world'), how many people
 are running Fedora and how many are running Ubuntu? Have you noticed
 how, whenever _any_ third party site posts reader statistics, the first
 thing you see is that Linux is tiny, and the second thing you see is
 that a heavy pluarality of the Linux numbers are Ubuntu? Example:
 Distrowatch prints user agent stats, not just page hit rankings.
 http://distrowatch.com/awstats/awstats.DistroWatch.com.osdetail.html .
 Ubuntu is at 16.5%. Fedora is at 1.3%, on which number we are being
 beaten by OpenSUSE and PCLinuxOS (and being trounced by Linux Mint, a
 shoestring budgeted Ubuntu derivative), and just outpacing Debian and
 Mandriva. Yep, a grand 1.3% of the people who visit a general-purpose
 Linux news site are running Fedora when they do it. Please, _please_, do
 not attempt to rationalize or excuse or except these numbers; they're
 just an example (I know some people will, despite this explicit request;
 I intend to entirely ignore them). Every site I've ever seen print its
 user agent stats tells a similar story. Does anyone actually want to
 claim that this kind of thing is a stunning success story for Fedora as
 a general purpose desktop operating system?
 
 Those numbers aren't lying. I think this discussion should always be
 informed by the fundamental understanding that, if we're talking about
 making an attractive general-purpose operating system for end users,
 we're currently fairly shit at it. We're not a shit project, we do a lot
 of valuable work that needs to be done, and produce products that are
 great in certain ways. But we should either get a better understanding
 of what we are actually good at and valuable for and work on those
 things, or if we're serious about being an end-user desktop, get a lot
 better at it. Which would probably involve doing some things a lot of
 members of the project would be unhappy with. Frankly, I don't think
 this project is currently laid out in such a way that doing that would
 be very practical; it's very difficult to engender radical change in
 Fedora as a project.
 -- 
 Adam Williamson
 Fedora QA Community Monkey
 IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
 http://www.happyassassin.net

I fully agree with every single word.
(I would imagine that I'm not alone)

... But I'm not sure that FESCo shares your opinion - far from it.

This leaves us in a very precarious position:
One on hand, if FESCo keeps changing Fedora into
hybrid-semi-community-driven-Ubuntu, they risk losing many technical
users/small maintainers such as myself, read: People who prefer Fedora
over Ubuntu -because- it is technical, bleeding edge and community
driven.
On the other hand, if FESCo keeps the uneasy 'statu quo' without any
real definition of what Fedora is really about, neither the technical
group nor the I-want-to-be-Ubuntu group (let alone the I want to be
RHEL/CentOS group) will be happy, and in the end, Fedora will continue
losing both developers and users.

If we, as a -community- project, want to remain relevant, it is time to
decide who we are and what is our goal.
Thus far, it seemed that the both the user and the developer communities
were left out of these proceedings, and everything was more-or-less
decided by FESCO, which left (large?) parts of the developer community
feeling left out.
Far worse, many attempts to try and openly discuss these issues ended up
being shot down by the hall monitors.

As I recall, you've polled FedoraForum users about their view of Fedora
a couple of months ago and as far as I know, there results were
more-or-less ignored.
Maybe its time to repeat this poll (I'd extent it to both FAS users and
FedoraForum users. This should cover both the developer and the
hard-core user communities), but this time with FESCO blessing.

- Gilboa Hopefully this discussion won't be ignored Davara


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

Re: Reasons for hall monitoring

[Gilboa Davara]

On Sun, 2010-05-09 at 15:27 -0500, Mike McGrath wrote:
 If you think we should vote, go join debian.  I think
 they do that there.

First, I never said we should 'vote'. I talked about community
involvement.
Second, if you are looking at the sure path to drive people away,
sending them to go join Debian will be it.
(Though, in your defense, I did the same more than once, so I can't
really blame you without sharing the blame)

 In the meantime our community is suffering far more
 infighting then before because everyone thinks their version is the right
 version.  As we narrow our focus, people are going to find they fall
 outside of that focus.
 
 Bottom line is we should have done what we're doing now long ago, so we're
 suffering the consequences as a result.  Lots of people with conflicting
 views are now here.  Our lack of focus has just hurt us.

I fully agree.
With every single word.

I do not agree that that working with zero community input is the way to
achieve a working compromise. (And input does not equal vote)

 
 Have you used OSX lately?  They're playing in a whole different league and
 a whole different game then we are.  It's not even a comparison.  Not only
 do we copy OSX but we do so poorly.  For those that have problem with
 apple or want a more free OS, Ubuntu's got the share.  We're just not
 there.  Fedora's board isn't driving users and developers away, our OS is.
 
 The worst part is we won't get those users back with a marginally better
 product.

I can't really comment on it. (Don't have OSX, never tried it)
Though, I would imagine that Fedora is compared to Ubuntu and Windows 7;
I doubt that OSX is even on the list.

- Gilboa

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

Re: Proposed udpates policy change

[Gilboa Davara]

On Wed, 2010-03-10 at 13:21 -0800, Adam Williamson wrote:
 On Wed, 2010-03-10 at 23:11 +0200, Gilboa Davara wrote:
 
  Either we (package maintainers) are qualified to make sane decisions
  about our package or we are not. I don't really see a middle ground
  here.
 
 Being qualified to do something does not mean that one always does it
 perfectly. Almost everyone's qualified to drive, yet road traffic
 accidents happen _all the time_. The people who built the LHC were no
 doubt qualified to do yet, yet it turns out to be a bit broken. You can
 pull examples from literally every sphere of human experience.
 
 People make mistakes - even qualified people, even super-proficient
 people who make far fewer mistakes than *most* people. This is why we do
 testing.

 You're behind the debate, in any case; Matthew's proposal was not
 accepted by FESCo at the meeting. No proposal was fully accepted, but
 FESCo asked everyone to go and work from Bill Nottingham's proposal
 (which, if you look at it, is far more moderate) for further review next
 week. But I thought it was important to make the general point. Being
 qualified to do something does not mean that you will always do it
 perfectly.

I just finished reading the fixed proposal (Or actually, I just finished
reading the full thread). Thanks for the head's up.

- Gilboa



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

Missing multi-lib -debuginfo files.

[Gilboa Davara]

Hello all,

I'm trying to debug an issue with 32bit application running on top of
x86_64 F12 installation. (Using multi-lib i686 RPMs)
However, debuginfo install doesn't seem to be able to resolve i686
debuginfo.

$ debuginfo-install alsa-lib.i686 alsa-plugins-pulseaudio.i686
dbus-libs.i686 pulseaudio-libs.i686 glibc.i686
Loaded plugins: dellsysidplugin2, fastestmirror, presto,
refresh-packagekit
Loading mirror speeds from cached hostfile
 * fedora: mirror.isoc.org.il
 * rpmfusion-free: ftp.nb.lug.ro
 * rpmfusion-free-updates: ftp.nb.lug.ro
 * rpmfusion-nonfree: ftp.nb.lug.ro
 * rpmfusion-nonfree-updates: ftp.nb.lug.ro
 * updates: ftp.stw-bonn.de
...
Reading repository metadata in from local files
Could not find debuginfo for main pkg:
alsa-plugins-pulseaudio-1.0.21-2.fc12.i686
Could not find debuginfo pkg for dependency package
libcap-ng-0.6.2-3.fc12.i686
Could not find debuginfo pkg for dependency package
libasyncns-0.8-1.fc12.i686
Could not find debuginfo pkg for dependency package
libsndfile-1.0.20-3.fc12.i686
Could not find debuginfo pkg for dependency package
libsndfile-1.0.20-3.fc12.i686
Could not find debuginfo pkg for dependency package
tcp_wrappers-libs-7.6-56.fc12.i686
Could not find debuginfo pkg for dependency package
nss-softokn-freebl-3.12.4-10.fc12.i686
Could not find debuginfo pkg for dependency package
nss-softokn-freebl-3.12.4-10.fc12.i686
No debuginfo packages available to install

Is it a known issue?
- Gilboa


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

Re: Missing multi-lib -debuginfo files.

[Gilboa Davara]

On Sun, 2010-01-17 at 14:18 +0100, Björn Persson wrote:
 Gilboa Davara wrote:
  I'm trying to debug an issue with 32bit application running on top of
  x86_64 F12 installation. (Using multi-lib i686 RPMs)
  However, debuginfo install doesn't seem to be able to resolve i686
  debuginfo.
 
 That's right. There are only 64-bit debuginfo packages in the 64-bit 
 repositories. Debuginfo files are arranged in a way that tends to cause 
 multilib conflicts. The problem is solvable, but currently the only way I 
 know 
 is to browse the 32-bit repositories until you find the right debuginfo 
 packages, and download and install them manually.
 
 You might want to read this discussion:
 http://lists.fedoraproject.org/pipermail/devel/2009-November/040757.html
 
 Björn Persson

Thanks for the information.
Was it considered to add debuginfo only for 32bit libraries? (Biggest
multi-libs, lowest chance of conflict)

- Gilboa

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