Re: fedora 11 worst then ever release

[Ralf Corsepius]

On 07/27/2009 07:33 AM, David Cantrell wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, 26 Jul 2009, Björn Persson wrote:


Ralf Corsepius wrote:

On 07/26/2009 02:37 PM, Seth Vidal wrote:

On Sat, 25 Jul 2009, Alan Cox wrote:

"all of my system has a wrong openssl version"

all these symptoms sound like your upgrade went horribly wrong. I've
seen preupgrade mash up a box by half upgrading like that. It's the
main
reason
I don't think preupgrade is actually safe to use yet.


Preupgrade's process is to depsolve - using the same method anaconda
does, download the pkgs it solves out. Put them in a cachedir. Download
a kernel and an initrd, Setup a ks.cfg. then reboot the machine and
allow anaconda to do the install.

Specific issues we've had with preupgrade are related to not being able
to find a mirror and/or not being able to get pkgs.


Mine were
* preupgrade running out of diskspace on / when trying to fill
/var/cache/yum (my "/"'s tend to be minimized/small)


You're not blaming Preupgrade for the partition being too small, are
you? If
you want a small root partition you should put /var/cache/yum on another
partition.

Do you mean Preupgrade didn't handle the lack of disk space well?


* anaconda failing during reboots due not being able to process fstab
correctly (FC11's anaconda misparses fstab and is unable able to process
bind-mounts nor nfs-mounts).


Bind mounts are fixed, as far as I know:
https://bugzilla.redhat.com/show_bug.cgi?id=496406

For NFS mounts, I believe it's fixed in commit
40728ffcc1e32eb6b5ccc0cd3b3ddb23216cf199, which was on June 7th. That
should
carry over NFS mounts listed in /etc/fstab if you are doing an upgrade.

Well, to my knowledge these are "FIXED RAWHIDE", only.


* anaconda's depsolving failed when upgrading an FC10 + FC10-updates
system due to NEVR issues.


If you have any details of the failure, it would help.
Unfortunately no. I had not been involved into upgrading the system this 
had happened to from the beginning.


I was called to troubleshoot this upgrade. The situation I found was a 
partially upgraded system, stuck on upgrading yum due to a rpm conflict 
on yum itself. No idea how the person trying to upgrade managed to get 
into this situation.


Ralf

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: fedora 11 worst then ever release

[David Cantrell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, 26 Jul 2009, Björn Persson wrote:


Ralf Corsepius wrote:

On 07/26/2009 02:37 PM, Seth Vidal wrote:

On Sat, 25 Jul 2009, Alan Cox wrote:

"all of my system has a wrong openssl version"

all these symptoms sound like your upgrade went horribly wrong. I've
seen preupgrade mash up a box by half upgrading like that. It's the main
reason
I don't think preupgrade is actually safe to use yet.


Preupgrade's process is to depsolve - using the same method anaconda
does, download the pkgs it solves out. Put them in a cachedir. Download
a kernel and an initrd, Setup a ks.cfg. then reboot the machine and
allow anaconda to do the install.

Specific issues we've had with preupgrade are related to not being able
to find a mirror and/or not being able to get pkgs.


Mine were
* preupgrade running out of diskspace on / when trying to fill
/var/cache/yum (my "/"'s tend to be minimized/small)


You're not blaming Preupgrade for the partition being too small, are you? If
you want a small root partition you should put /var/cache/yum on another
partition.

Do you mean Preupgrade didn't handle the lack of disk space well?


* anaconda failing during reboots due not being able to process fstab
correctly (FC11's anaconda misparses fstab and is unable able to process
bind-mounts nor nfs-mounts).


Bind mounts are fixed, as far as I know:
https://bugzilla.redhat.com/show_bug.cgi?id=496406

For NFS mounts, I believe it's fixed in commit
40728ffcc1e32eb6b5ccc0cd3b3ddb23216cf199, which was on June 7th.  That should
carry over NFS mounts listed in /etc/fstab if you are doing an upgrade.


* anaconda's depsolving failed when upgrading an FC10 + FC10-updates
system due to NEVR issues.


If you have any details of the failure, it would help.  Anaconda relies on yum
to do depsolving and yum relies on correctly configured yum repositories to
provide the information to do depsolving.

If you have details, please file a bug for anaconda.



Those would be Anaconda issues, not Preupgrade issues – which makes them all
the more serious.


- -- 
David Cantrell 

Red Hat / Honolulu, HI

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkptPBYACgkQ5hsjjIy1VkkFlACeNHFf5Tx8Ief3O1qjFgSrYPEm
GBkAnj4Guybso65om2SV88cQb+vU2JiC
=uTAM
-END PGP SIGNATURE--- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: fedora 11 worst then ever release

[Ralf Corsepius]

On 07/26/2009 09:34 PM, John Poelstra wrote:

Ralf Corsepius said the following on 07/26/2009 11:35 AM Pacific Time:
Are there bug numbers for these issues?


I filed some BZs for which I couldn't find as already filed by others 
(some already were):

https://bugzilla.redhat.com/show_bug.cgi?id=503183
https://bugzilla.redhat.com/show_bug.cgi?id=508932
https://bugzilla.redhat.com/show_bug.cgi?id=506396

(Note: These all are "FIXED RAWHIDE/UPSTREAM", i.e. not fixed in FC11!)

Also related to these:

* Responsible for being forced to use preupgrade:
https://bugzilla.redhat.com/show_bug.cgi?id=498720

* Causing troubles in the aftermath of upgrades/updates:
https://bugzilla.redhat.com/show_bug.cgi?id=511076
https://bugzilla.redhat.com/show_bug.cgi?id=511101


Ralf

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: fedora 11 worst then ever release

[Ralf Corsepius]

On 07/26/2009 09:28 PM, Björn Persson wrote:

Ralf Corsepius wrote:

On 07/26/2009 02:37 PM, Seth Vidal wrote:

On Sat, 25 Jul 2009, Alan Cox wrote:

"all of my system has a wrong openssl version"

all these symptoms sound like your upgrade went horribly wrong. I've
seen preupgrade mash up a box by half upgrading like that. It's the main
reason
I don't think preupgrade is actually safe to use yet.


Preupgrade's process is to depsolve - using the same method anaconda
does, download the pkgs it solves out. Put them in a cachedir. Download
a kernel and an initrd, Setup a ks.cfg. then reboot the machine and
allow anaconda to do the install.

Specific issues we've had with preupgrade are related to not being able
to find a mirror and/or not being able to get pkgs.


Mine were
* preupgrade running out of diskspace on / when trying to fill
/var/cache/yum (my "/"'s tend to be minimized/small)


You're not blaming Preupgrade for the partition being too small, are you?

Well, to some extend, I am blaming it, because
a) filling '/' may easily kill a system and may easily cause further 
damage (processes running in parallel to preupgrade might be 
malfunctioning due lack of diskspace).


b) I expect an installer to be able to check whether sufficient space is 
available in advance, rsp. not to leave a system in an unusable state in 
case of something going wrong.


In BZ https://bugzilla.redhat.com/show_bug.cgi?id=503183
I questioned whether using /var/cache/yum is a good choice for 
preupgrade's package cache. Though I meanwhile know that this BZ is was 
a side-effect of the nfs-parser bugs in anaconda, I still think using 
/root or /tmp would be better choices.



If
you want a small root partition you should put /var/cache/yum on another
partition.

This would have worked, if anaconda had been able to process fstab.
Unfortunately, FC11's anaconda isn't able to do so.

Ralf


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: rawhide report: 20090726 changes

[पराग़]

Hi,

On Sun, Jul 26, 2009 at 11:18 PM, Toshio Kuratomi wrote:
> On 07/26/2009 04:17 AM, Rawhide Report wrote:
>> Compose started at Sun Jul 26 06:15:06 UTC 2009
>>
>> New package python-Lightbox
>>         Lightbox photo display widget
>
> Big fat warning!  The license on this package is incorrect.  It says MIT
> but only the python code in the package is licensed MIT.  The Lightbox
> javascript library is licensed with a Creative Commons Attribution license:
>  http://creativecommons.org/licenses/by/2.5
>
> CC licenses are incompatible with the GPL whereas the MIT license is
> compatible so this is an important difference.
>
> This was missed in the review:
>  https://bugzilla.redhat.com/show_bug.cgi?id=508511
>
> It can be a pain but (especially where sources from different upstreams
> are suspected of being mixed, like including javascript files) doing a a
> license audit is very important.

 Thanks. I have asked license verification to Fedora legal in review now.
>
> grep -ri license ${topdir} can help to point out files that need to be
> explored further.

Regards,
Parag,

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Updated Fedora 12 Schedule (take 2)

[John Poelstra]

Mark McLoughlin said the following on 07/24/2009 05:55 AM Pacific Time:

Hi John,

(Cc-ing fedora-devel-list, surprised to see the schedule hasn't been
posted there)


It was approved by FESCo in May 
https://fedorahosted.org/fesco/ticket/143 and should have appeared on 
fedora-devel as part of the meeting recap.


The schedules below are detailed schedules for a specific team.  There 
were no changes to the major milestones originally approved: 
https://fedoraproject.org/wiki/Releases/12/Schedule



On Mon, 2009-07-13 at 21:09 -0700, John Poelstra wrote:


http://poelstra.fedorapeople.org/schedules/f-12/f-12-releng-tasks.html
http://poelstra.fedorapeople.org/schedules/f-12/f-12-releng.ics


In the F-11 schedule, we had 85 days between Feature Freeze and GA. And
then GA slipped by two weeks.
In the F-12 schedule, we now have 99 days between Feature Freeze and GA.


For Fedora 12 An extra week was added to accommodate Linux plumbers 
conference, etc...https://fedorahosted.org/rel-eng/ticket/1271


In addition there are four weeks in the Fedora 12 schedule for Alpha 
(previously known as Beta) versus the three weeks in Fedora 11--this was 
an oversight in the setting of the Fedora 11 schedule which did not 
allow for three weekly snapshots.



This seriously cuts into development time, and we already have a shorter
releases cycle.


This is one of the reasons it was discussed almost a month or more 
before the GA of Fedora 11.


>

Why is that?


To get back on the regular "Halloween/May Day" release schedule.  The 
original alpha (as we used to know it) was dropped by Releng in an 
effort to add more development time back... this was discussed on 
fedora-devel.


John

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: What to do with release number on new EL-5 branch

[Conrad Meyer]

On Sunday 26 July 2009 07:50:14 pm Toshio Kuratomi wrote:
> On 07/26/2009 01:52 PM, Conrad Meyer wrote:
> > On Sunday 26 July 2009 01:47:55 pm Richard Fearn wrote:
> >> Hi,
> >>
> >> I've just had an EL-5 branch created for my disktype[1] package. The
> >> new branch is a copy of the devel branch, so the NVR is currently
> >> disktype-9-5.
> >>
> >> Should I build the package as-is (so the first EPEL version is 9-5),
> >> or clear the changelog and start from 9-1 again for the EL-5 branch?
> >>
> >> I looked on a few pages[2][3][4] for information on this, but couldn't
> >> see anything.
> >>
> >> Thanks,
> >>
> >> Rich
> >>
> >> [1]: https://admin.fedoraproject.org/pkgdb/packages/name/disktype
> >> [2]: http://fedoraproject.org/wiki/Using_CVS_FAQ_for_package_maintainers
> >> [3]: http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure
> >> [4]: http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies
> >
> > There is nothing wrong with starting at 9-5.
>
> Using the disttag can make it clearer that a package comes from epel as
> opposed to someone installing the Fedora package onto an EL-5 system and
> expecting it to work.
>
> https://fedoraproject.org/wiki/Packaging/DistTag
> -Toshio

Er, I am not saying "don't use dist", just that starting at 5%{?dist} instead 
of 1%{?dist} is completely fine.

Regards,
-- 
Conrad Meyer 

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Help needed with fedora-security-guide-en-US-1.0-16.fc12

[Eric Christensen]

On Sun, 2009-07-26 at 20:09 +0100, Richard Fearn wrote:
> Hi Eric,
> 
> > I'm having problems with a Publican package (the Security Guide).  Below 
> > you will see the latest build error from Koji.  I'm not familiar with the 
> > error and I can't find anything listed on the wiki pages that I'm used to 
> > finding solutions to packaging errors.
> >
> > The SPEC file can be seen at 
> > http://sparks.fedorapeople.org/Packages/security-guide/fedora-security-guide-en-US.spec.
> >
> > I'd appreciate any suggestions.
> 
> I just looked at your spec file in CVS (it's newer than the one you
> provided a link to):
> 
> http://cvs.fedoraproject.org/viewvc/rpms/fedora-security-guide-en-US/devel/fedora-security-guide-en-US.spec?revision=1.4&view=markup
> 
> You have this in the %install section:
> 
> desktop-file-install  %{?vendoropt}
> --dir=${RPM_BUILD_ROOT}%{_datadir}/applications %{name}.desktop
> 
> but you have this in the %files section:
> 
> %{_datadir}/applications/%{?vendor}%{name}.desktop
> 
> That "%{?vendor}" causes "Fedora Project" to be inserted into the
> filename, resulting in these errors in build.log:
> 
> Processing files: fedora-security-guide-en-US-1.0-16.fc12.noarch
> error: Two files on one line: /usr/share/applications/Fedora
> error: File must begin with "/": Projectfedora-security-guide-en-US.desktop
> 
> Looks like you need to remove "%{?vendor}".
> 
> Regards,
> 
> Rich
> 

I'll forward this along as this is default coming out of Publican.
Thanks for the eyes, Rich.

-- Eric


signature.asc
Description: This is a digitally signed message part
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: fedora 11 worst then ever release

[Bill McGonigle]

On 07/25/2009 03:15 PM, oleksandr korneta wrote:
> But I dont complain, kind of got used to the idea that fedora is not
> made for upgrades.

I haven't had the best of luck with anaconda/preupgrade, but yum + human
works pretty well.  I've got a machine here doing my SOHO tasks that was
installed as Redhat 9 and has been yum upgraded. FC1->FC2 was the only
tricky one.

The YumUpgradeFAQ is indispensable and sometimes there are conflicts
that need resolving (which, I assume, is why anaconda fails to
depsolve).  But all-in-all it takes far less time to upgrade than
re-install for non-trivial configurations.  We suggest filing bugs
against packages that fail to upgrade, but I believe I've seen those
closed with "we don't support upgrades."  "...yet," I say - it's inevitable.

I really wish there were a way to segregate /etc into system configs and
application configs so that it was easier to do re-installs.

-Bill

-- 
Bill McGonigle, Owner   Work: 603.448.4440
BFC Computing, LLC  Home: 603.448.1668
http://www.bfccomputing.com/Cell: 603.252.2606
Twitter, etc.: bill_mcgonigle   Page: 603.442.1833
Email, IM, VOIP: b...@bfccomputing.com
Blog: http://blog.bfccomputing.com/
VCard: http://bfccomputing.com/vcard/bill.vcf

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: What to do with release number on new EL-5 branch

[Toshio Kuratomi]

On 07/26/2009 01:52 PM, Conrad Meyer wrote:
> On Sunday 26 July 2009 01:47:55 pm Richard Fearn wrote:
>> Hi,
>>
>> I've just had an EL-5 branch created for my disktype[1] package. The
>> new branch is a copy of the devel branch, so the NVR is currently
>> disktype-9-5.
>>
>> Should I build the package as-is (so the first EPEL version is 9-5),
>> or clear the changelog and start from 9-1 again for the EL-5 branch?
>>
>> I looked on a few pages[2][3][4] for information on this, but couldn't
>> see anything.
>>
>> Thanks,
>>
>> Rich
>>
>> [1]: https://admin.fedoraproject.org/pkgdb/packages/name/disktype
>> [2]: http://fedoraproject.org/wiki/Using_CVS_FAQ_for_package_maintainers
>> [3]: http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure
>> [4]: http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies
> 
> There is nothing wrong with starting at 9-5.
> 
Using the disttag can make it clearer that a package comes from epel as
opposed to someone installing the Fedora package onto an EL-5 system and
expecting it to work.

https://fedoraproject.org/wiki/Packaging/DistTag
-Toshio



signature.asc
Description: OpenPGP digital signature
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: fedora 11 worst then ever release

[Bill McGonigle]

On 07/26/2009 09:06 AM, Seth Vidal wrote:
>>
>> can you tell me even one such distro+release when this happened?
>> it's never happened with any of the redhat, fedora, rhel releases.
> 
> fc1->fc2
> fc6->fc7
> rhel4->rhel5
> 
> It's not new.

Is this where we branch to debate a release-number super-epoch?

-Bill

-- 
Bill McGonigle, Owner   Work: 603.448.4440
BFC Computing, LLC  Home: 603.448.1668
http://www.bfccomputing.com/Cell: 603.252.2606
Twitter, etc.: bill_mcgonigle   Page: 603.442.1833
Email, IM, VOIP: b...@bfccomputing.com
Blog: http://blog.bfccomputing.com/
VCard: http://bfccomputing.com/vcard/bill.vcf

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Lower Process Capabilities

[Steve Grubb]

On Sunday 26 July 2009 09:01:14 pm Tom Lane wrote:
> 0005 is certainly not meaningfully more secure than 0555.

There are some secrets in files that semi-trusted root apps should not have 
access to.

-Steve

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Lower Process Capabilities

[Tom Lane]

Steve Grubb  writes:
> On Sunday 26 July 2009 08:38:45 pm Tom Lane wrote:
>> I trust you meant to write 0555?

> No, I really mean 005 so that root daemons are using public permissions. 

What's the point?  The most you will accomplish is to confuse people
(and perhaps programs too).  0005 is certainly not meaningfully more
secure than 0555.

regards, tom lane

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Lower Process Capabilities

[Steve Grubb]

On Sunday 26 July 2009 08:54:26 pm Steve Grubb wrote:
> > I trust you meant to write 0555?
>
> No, I really mean 005 so that root daemons are using public permissions.
> Admins of course have DAC_OVERRIDE and can do anything. Try the script in a
> VM and tell me if there are any problems you see.

I should elaborate more. The issue is that sometimes there are secrets that 
root admins have access to that should not be available to semi-trusted 
daemons. For example, any private keys in /root or /etc. You do not want any 
daemon that could be compromised to have access to these. So, its safest just 
to set the permissions to 0005 so that they have no access to /root.

I expect a few corner cases, but other than /etc/resolve.conf I don't know of 
any problems.

-Steve

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Lower Process Capabilities

[Steve Grubb]

On Sunday 26 July 2009 08:38:45 pm Tom Lane wrote:
> Steve Grubb  writes:
> > The directory for /bin is 0755 root root. So, even if we drop all
> > capabilities, the root acct can still trojan a system.
> >
> > If we change the bin directory to 005, then root cannot write to that
> > directory unless it has the CAP_DAC_OVERRIDE capability.
>
> I trust you meant to write 0555?

No, I really mean 005 so that root daemons are using public permissions. 
Admins of course have DAC_OVERRIDE and can do anything. Try the script in a VM 
and tell me if there are any problems you see.

Thanks,
-Steve

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Lower Process Capabilities

[Tom Lane]

Steve Grubb  writes:
> The directory for /bin is 0755 root root. So, even if we drop all 
> capabilities, the root acct can still trojan a system. 

> If we change the bin directory to 005, then root cannot write to that 
> directory unless it has the CAP_DAC_OVERRIDE capability.

I trust you meant to write 0555?

regards, tom lane

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Lower Process Capabilities

[Steve Grubb]

Hello,

I wanted to send an email to give everyone a heads up about a project I'm 
working on. You can find the write-up here:

https://fedoraproject.org/wiki/Features/LowerProcessCapabilities

The basic idea goes something like this: We would like to do something to 
prevent priv escalation for processes running as root. For this example, lets 
take cupsd to be a good case in point. If the attacker can find a vuln with 
cupsd, then they can have root privs and all that goes with it. (SE Linux may 
prevent total compromise, but some people turn it off.)

What can be done is that we program the application to drop some of the 
capabilities so that its not all powerful. There's just one flaw in this plan. 
The directory for /bin is 0755 root root. So, even if we drop all 
capabilities, the root acct can still trojan a system. 

If we change the bin directory to 005, then root cannot write to that 
directory unless it has the CAP_DAC_OVERRIDE capability. The idea with this 
project is to not allow network facing or daemons have CAP_DAC_OVERRIDE, but 
to only allow it from logins or su/sudo.

This will fundamentally change the permissions you see when doing ls -l, but 
it will work as it always did for admins. If you wanted to test this out for 
yourselves, you can setup a VM and run the following commands:

echo "Hardening files..."
find / -type f -perm /00700 -a -uid 0 -exec chmod u-wrx {} \; 2>/dev/null
find / -type f -perm /00070 -a -gid 0 -exec chmod g-wrx {} \; 2>/dev/null
echo "Hardening directories..."
find / -type d -perm /00200 -a -uid 0 -exec chmod u-w {} \; 2>/dev/null
find / -type d -perm /00020 -a -gid 0 -exec chmod g-w {} \; 2>/dev/null
echo "Correcting a couple things..."
find /sbin -type f -perm /0 -a -uid 0 -exec chmod u+x {} \; 2>/dev/null
find /usr/sbin -type f -perm /0 -a -uid 0 -exec chmod u+x {} \; 2>/dev/null

This project also plans to set the permissions for /etc/shadow and 
/etc/gshadow to  so that daemons running as root, but without DAC_OVERRIDE 
cannot read the shadow file. Login, [gkx]dm, and sshd will still have 
DAC_OVERRIDE or this wouldn't work.

Does a system running like this still work? Yes it does. But there is still 
one rough spot. That is the /etc/resolve.conf file. The problem is that if we 
follow the new theory of only allowing system updates with DAC_OVERRIDE, then 
root daemons cannot update dynamically created files. The solution to this is 
to move those into a directory owned by an account other than root and have 
the daemon running under that account to write the file.

This would mean that anything that writes to /etc/resolve.conf, would need to 
run under this new acct. And /etc/resolve.conf would need to be moved to 
something like /etc/resolve/resolve.conf. And then that is symlinked back to 
/etc/resolve.conf for the transition.

The last phase of the project is to play whack-a-mole and fix permission 
problems in packages that specify file permissions explicitly. The plan is to 
cover @core files first as I would like to make the minimal install work first 
and then branch out to other use cases.

Asbestos underwear is firmly in place. Let me know if any one has concerns. 
Also please try out the script above on a VM before posting so that you can 
assure yourself that everything still works. :)

Thanks,
-Steve

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: rpms/rubygem-rails/devel .cvsignore, 1.8, 1.9 import.log, 1.1, 1.2 rubygem-rails.spec, 1.13, 1.14 sources, 1.8, 1.9

[Todd Zullinger]

Rahul Sundaram wrote:
> On 07/26/2009 04:33 PM, Mamoru Tasaka wrote:
>
>>
>> Especially please be very careful when using cvs-import.sh as using
>> cvs-import.sh will easily lead to this type of reverting.
>
> I thought cvs-import.sh was already fixed to check for cvs updates
> and not revert them? If that hasn't been done already, it would be a
> better solution considering the amount of times this has happened.

The script prints the output of cvs diff and asks the user to review
the changes and abort the commit if things don't look right.  But that
doesn't always stop bad commits from slipping through.

-- 
ToddOpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~
Does it follow that I reject all authority? Perish the thought. In the
matter of boots, I defer to the authority of the boot-maker.
-- Mikhail Bakunin



pgpJiKi8mGjJt.pgp
Description: PGP signature
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: What to do with release number on new EL-5 branch

[Conrad Meyer]

On Sunday 26 July 2009 01:47:55 pm Richard Fearn wrote:
> Hi,
>
> I've just had an EL-5 branch created for my disktype[1] package. The
> new branch is a copy of the devel branch, so the NVR is currently
> disktype-9-5.
>
> Should I build the package as-is (so the first EPEL version is 9-5),
> or clear the changelog and start from 9-1 again for the EL-5 branch?
>
> I looked on a few pages[2][3][4] for information on this, but couldn't
> see anything.
>
> Thanks,
>
> Rich
>
> [1]: https://admin.fedoraproject.org/pkgdb/packages/name/disktype
> [2]: http://fedoraproject.org/wiki/Using_CVS_FAQ_for_package_maintainers
> [3]: http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure
> [4]: http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies

There is nothing wrong with starting at 9-5.

Regards,
-- 
Conrad Meyer 

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: What to do with release number on new EL-5 branch

[Rahul Sundaram]

On 07/27/2009 02:17 AM, Richard Fearn wrote:
> Hi,
> 
> I've just had an EL-5 branch created for my disktype[1] package. The
> new branch is a copy of the devel branch, so the NVR is currently
> disktype-9-5.
> 
> Should I build the package as-is (so the first EPEL version is 9-5),
> or clear the changelog and start from 9-1 again for the EL-5 branch?

IMO, keeping it the same across branches makes it much easier as a
package maintainer.

Rahul

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

What to do with release number on new EL-5 branch

[Richard Fearn]

Hi,

I've just had an EL-5 branch created for my disktype[1] package. The
new branch is a copy of the devel branch, so the NVR is currently
disktype-9-5.

Should I build the package as-is (so the first EPEL version is 9-5),
or clear the changelog and start from 9-1 again for the EL-5 branch?

I looked on a few pages[2][3][4] for information on this, but couldn't
see anything.

Thanks,

Rich

[1]: https://admin.fedoraproject.org/pkgdb/packages/name/disktype
[2]: http://fedoraproject.org/wiki/Using_CVS_FAQ_for_package_maintainers
[3]: http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure
[4]: http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: rpms/rubygem-rails/devel .cvsignore, 1.8, 1.9 import.log, 1.1, 1.2 rubygem-rails.spec, 1.13, 1.14 sources, 1.8, 1.9

[Rahul Sundaram]

On 07/26/2009 04:33 PM, Mamoru Tasaka wrote:

> 
> Especially please be very careful when using cvs-import.sh as using
> cvs-import.sh will easily lead to this type of reverting.

I thought cvs-import.sh was already fixed to check for cvs updates and
not revert them? If that hasn't been done already, it would be a better
solution considering the amount of times this has happened.

Rahul

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: orphaning nopaste // ruby help wanted for broken package

[Simon Wesp]

Am Freitag, 05 Juni 2009 19:45:01 schrieb Iain Arnell:
IA> woot.!I  Was meaning to contact you about this.I already own
IA> perl-App-Nopaste whiich can also proveide /usr/bin/nopatse (with lots
IA> more possibilities than rafb). More than happy to obsolete/provide
IA> (and extend to support fpaste too).
IA> 
IA> If anyone beats me too it - iwannit!
IA> 

Dear Iain,

nopaste is back...
http://agriffis.n01se.net/nopaste/nopaste-2.1
you should include this instead of pearl-App-Nopaste..
Can I have this package back? ;-)
-- 
Mit freundlichen Grüßen aus dem schönen Hainzell
Simon Wesp

The G in GNU stands for GNU
http://fedoraproject.org/wiki/SimonWesp

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: fedora 11 worst then ever release

[John Poelstra]

Ralf Corsepius said the following on 07/26/2009 11:35 AM Pacific Time:

On 07/26/2009 02:37 PM, Seth Vidal wrote:



On Sat, 25 Jul 2009, Alan Cox wrote:


"all of my system has a wrong openssl version"

all these symptoms sound like your upgrade went horribly wrong. I've 
seen

preupgrade mash up a box by half upgrading like that. It's the main
reason
I don't think preupgrade is actually safe to use yet.



Preupgrade's process is to depsolve - using the same method anaconda
does, download the pkgs it solves out. Put them in a cachedir. Download
a kernel and an initrd, Setup a ks.cfg. then reboot the machine and
allow anaconda to do the install.

Specific issues we've had with preupgrade are related to not being able
to find a mirror and/or not being able to get pkgs.

Mine were
* preupgrade running out of diskspace on / when trying to fill 
/var/cache/yum (my "/"'s tend to be minimized/small)


* anaconda failing during reboots due not being able to process fstab 
correctly (FC11's anaconda misparses fstab and is unable able to process 
bind-mounts nor nfs-mounts).


* anaconda's depsolving failed when upgrading an FC10 + FC10-updates 
system due to NEVR issues.




Are there bug numbers for these issues?

John

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: fedora 11 worst then ever release

[Björn Persson]

Ralf Corsepius wrote:
> On 07/26/2009 02:37 PM, Seth Vidal wrote:
> > On Sat, 25 Jul 2009, Alan Cox wrote:
> >> "all of my system has a wrong openssl version"
> >>
> >> all these symptoms sound like your upgrade went horribly wrong. I've
> >> seen preupgrade mash up a box by half upgrading like that. It's the main
> >> reason
> >> I don't think preupgrade is actually safe to use yet.
> >
> > Preupgrade's process is to depsolve - using the same method anaconda
> > does, download the pkgs it solves out. Put them in a cachedir. Download
> > a kernel and an initrd, Setup a ks.cfg. then reboot the machine and
> > allow anaconda to do the install.
> >
> > Specific issues we've had with preupgrade are related to not being able
> > to find a mirror and/or not being able to get pkgs.
>
> Mine were
> * preupgrade running out of diskspace on / when trying to fill
> /var/cache/yum (my "/"'s tend to be minimized/small)

You're not blaming Preupgrade for the partition being too small, are you? If 
you want a small root partition you should put /var/cache/yum on another 
partition.

Do you mean Preupgrade didn't handle the lack of disk space well?

> * anaconda failing during reboots due not being able to process fstab
> correctly (FC11's anaconda misparses fstab and is unable able to process
> bind-mounts nor nfs-mounts).
>
> * anaconda's depsolving failed when upgrading an FC10 + FC10-updates
> system due to NEVR issues.

Those would be Anaconda issues, not Preupgrade issues – which makes them all 
the more serious.

Björn Persson



signature.asc
Description: This is a digitally signed message part.
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Help needed with fedora-security-guide-en-US-1.0-16.fc12

[Richard Fearn]

Hi Eric,

> I'm having problems with a Publican package (the Security Guide).  Below you 
> will see the latest build error from Koji.  I'm not familiar with the error 
> and I can't find anything listed on the wiki pages that I'm used to finding 
> solutions to packaging errors.
>
> The SPEC file can be seen at 
> http://sparks.fedorapeople.org/Packages/security-guide/fedora-security-guide-en-US.spec.
>
> I'd appreciate any suggestions.

I just looked at your spec file in CVS (it's newer than the one you
provided a link to):

http://cvs.fedoraproject.org/viewvc/rpms/fedora-security-guide-en-US/devel/fedora-security-guide-en-US.spec?revision=1.4&view=markup

You have this in the %install section:

desktop-file-install  %{?vendoropt}
--dir=${RPM_BUILD_ROOT}%{_datadir}/applications %{name}.desktop

but you have this in the %files section:

%{_datadir}/applications/%{?vendor}%{name}.desktop

That "%{?vendor}" causes "Fedora Project" to be inserted into the
filename, resulting in these errors in build.log:

Processing files: fedora-security-guide-en-US-1.0-16.fc12.noarch
error: Two files on one line: /usr/share/applications/Fedora
error: File must begin with "/": Projectfedora-security-guide-en-US.desktop

Looks like you need to remove "%{?vendor}".

Regards,

Rich

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: fedora 11 worst then ever release

[Ralf Corsepius]

On 07/26/2009 02:37 PM, Seth Vidal wrote:



On Sat, 25 Jul 2009, Alan Cox wrote:


"all of my system has a wrong openssl version"

all these symptoms sound like your upgrade went horribly wrong. I've seen
preupgrade mash up a box by half upgrading like that. It's the main
reason
I don't think preupgrade is actually safe to use yet.



Preupgrade's process is to depsolve - using the same method anaconda
does, download the pkgs it solves out. Put them in a cachedir. Download
a kernel and an initrd, Setup a ks.cfg. then reboot the machine and
allow anaconda to do the install.

Specific issues we've had with preupgrade are related to not being able
to find a mirror and/or not being able to get pkgs.

Mine were
* preupgrade running out of diskspace on / when trying to fill 
/var/cache/yum (my "/"'s tend to be minimized/small)


* anaconda failing during reboots due not being able to process fstab 
correctly (FC11's anaconda misparses fstab and is unable able to process 
bind-mounts nor nfs-mounts).


* anaconda's depsolving failed when upgrading an FC10 + FC10-updates 
system due to NEVR issues.



Ralf

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: rawhide report: 20090726 changes

[Toshio Kuratomi]

On 07/26/2009 04:17 AM, Rawhide Report wrote:
> Compose started at Sun Jul 26 06:15:06 UTC 2009
> 
> New package python-Lightbox
> Lightbox photo display widget

Big fat warning!  The license on this package is incorrect.  It says MIT
but only the python code in the package is licensed MIT.  The Lightbox
javascript library is licensed with a Creative Commons Attribution license:
  http://creativecommons.org/licenses/by/2.5

CC licenses are incompatible with the GPL whereas the MIT license is
compatible so this is an important difference.

This was missed in the review:
  https://bugzilla.redhat.com/show_bug.cgi?id=508511

It can be a pain but (especially where sources from different upstreams
are suspected of being mixed, like including javascript files) doing a a
license audit is very important.

grep -ri license ${topdir} can help to point out files that need to be
explored further.

-Toshio



signature.asc
Description: OpenPGP digital signature
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Final Call for Fedora 12 Features

[John Poelstra]

Feature freeze for Fedora 12 is two days from now on 2009-07-28. Feature 
freeze is the last day to submit feature pages.


If you are a feature owner or expect to see a particular feature listed 
for Fedora 12, PLEASE:


1) Review this page to make sure your feature is present:
https://fedoraproject.org/wiki/Releases/12/FeatureList

2) If you do not see your feature listed on the Fedora 12 feature list 
it may be waiting for FESCo to review it (only the Feature Wrangler adds 
features to this category).  Please check:

https://fedoraproject.org/wiki/Category:FeatureReadyForFesco

If you don't see your feature page in either place, it is *NOT* being 
tracked for Fedora 12.  Send the URL of your feature page to John 
Poelstra (before 2009-07-28) and he'll help you figure out why.


Thanks,
John

___
Fedora-devel-announce mailing list
fedora-devel-annou...@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Orphaning some packages

[Simon Wesp]

Am Sonntag, 26 Juli 2009 18:02:50 schrieb Stefan Posdzich:
SP> I am orphaning this packages because i have _no_ time to maintain them...
SP> 
SP> barrage
SP> bastet
SP> biniax
SP> fbpanel
SP> xpad
SP> xqf
So long and thanks for all the fish. I will take care of them, bro!
If you want them back, I will let them go, of course.

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

The G in GNU stands for GNU
http://fedoraproject.org/wiki/SimonWesp

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Orphaning some packages

[Stefan Posdzich]

I am orphaning this packages because i have _no_ time to maintain them...

barrage
bastet
biniax
fbpanel
xpad
xqf

best regards

Stefan

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Applications install should be idiot proof

[Ben Boeckel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Seth Vidal wrote:

> 
> 
> On Sun, 26 Jul 2009, Nelson Chan wrote:
> 
>> i've just read 
>> 
http://blogs.computerworld.com/ubuntu_to_make_linux_application_
installation_idiot_proof he got
>> a pretty good idea, see the 2nd last paragraph: """
>> I may know that Amarok, Banshee, Rhythmbox, and Songbird are 
all noteworthy Linux music players,
>> but come on! Does anyone beside another Linux expert know 
that? Letting users choose a program
>> by say clicking on "music player" and then picking one makes 
all the sense in the world.
>> """
>> The idea is that newbies are likely have no idea what 
amarok,rhythmbox are, so does other
>> applications  Totem, abiword, Brasero..etc.  what they know 
are the general type of the software
>> --- Music player, movie player, office suite, CD/DVD 
burner...
>> Also i tried to search for "music player" in Add/Remove 
Software, interestingly, it gives
>> extremely odd and pointless result..(try that yourself)
>> So i can see why newbies are pull their hair off and *CAN"T 
GET THINGS DONE*, and claim *fedora
>> sucks* See this fact, i think that we should classify some 
applications under their type.
>> For instance,  have   Rhythmbox, amarok ..etc  under "Music 
Player"
>> 
>> The above is just a suggestion, hoping to help brain storming 
more better approaches.
>> But i think that the idea is kinda a must for Windows and Mac 
OS X users to get comfort with
>> Linux/fedora.
>>
> 
> something on track for Fedora 13 is tags for packages. So you 
can add
> arbitrary keywords/phrases for packages that then yum/PK can 
search on.
> 
> 
> -sv

Would these be a comps-like system? Could they replace comps 
with tags like -required and -recommended tag suffixes (my 
knowledge of the inner working of comps is limited)? Or would 
they be marked in pkgdb or the spec file? Links to information 
would be nice; I'd like such a system :) .

- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkpsVtUACgkQiPi+MRHG3qQG+wCeIQ/xTj9qEqjT7PfQ/B+VCgr+
7vgAn0NZU9WXqd1GPpLyHTlef7dMcet5
=fVUE
-END PGP SIGNATURE-


-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: fedora 11 worst then ever release

[Seth Vidal]

On Sun, 26 Jul 2009, Farkas Levente wrote:


who think about that his system will not working after doing
everything as it has to be. can you tell me any other distro
(including windows!) where the system installer not working after
upgrade?


It happens all the time on lots of systems. I've had it happen on debian
upgrades, slackware upgrades (granted that was long ago) and
many fedora and rhel upgrades.


can you tell me even one such distro+release when this happened?
it's never happened with any of the redhat, fedora, rhel releases.


fc1->fc2
fc6->fc7
rhel4->rhel5

It's not new.

-sv




--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: fedora 11 worst then ever release

[Farkas Levente]

On 07/26/2009 02:57 PM, Seth Vidal wrote:



On Sun, 26 Jul 2009, Farkas Levente wrote:



ohhh, come on!!! it's not an answer! it's just a proof that it's the
worst release ever. who dare to put a newer yum into f10-updates than
in f11 iso?



Here's what happened. I was delaying updating yum in f10-updates, on
purpose. We slipped F11 twice and there was pressure to upgrade F10's
yum to fix some bugs. So the timing worked out that F10+updates had a
newer yum than F11. It happens. We provided an easy workaround and
documented it.



who think about that his system will not working after doing
everything as it has to be. can you tell me any other distro
(including windows!) where the system installer not working after
upgrade?


It happens all the time on lots of systems. I've had it happen on debian
upgrades, slackware upgrades (granted that was long ago) and
many fedora and rhel upgrades.


can you tell me even one such distro+release when this happened?
it's never happened with any of the redhat, fedora, rhel releases.

--
  Levente   "Si vis pacem para bellum!"

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: fedora 11 worst then ever release

[Seth Vidal]

On Sun, 26 Jul 2009, Farkas Levente wrote:


On 07/26/2009 02:37 PM, Seth Vidal wrote:

when things went badly then it suggests to me that preupgrade is
probably not to blame.


the question here why yum not upgrade openssl during the dvd update process. 
it's another yum problem (and it's happened with 3 of my systems).




I'd love to know how this is a yum problem. Can you:
   a. file it in a bug
   b. describe what you were seeing and doing when this happened?
   c. include the versions of openssl you have installed before the update 
and which ones after?


Thanks,
-sv

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: fedora 11 worst then ever release

[Frank Murphy]

On 26/07/09 14:01, Farkas Levente wrote:



the question here why yum not upgrade openssl during the dvd update
process. it's another yum problem (and it's happened with 3 of my systems).




Did you have updates checked during upgrade from DVD?
--
Regards, Frank

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: fedora 11 worst then ever release

[Farkas Levente]

On 07/26/2009 02:37 PM, Seth Vidal wrote:



On Sat, 25 Jul 2009, Alan Cox wrote:


"all of my system has a wrong openssl version"

all these symptoms sound like your upgrade went horribly wrong. I've seen
preupgrade mash up a box by half upgrading like that. It's the main
reason
I don't think preupgrade is actually safe to use yet.

The case of yum being 'partially' upgraded came from us having a newer
yum in f10+updates than was in F11. This was documented here:

https://fedoraproject.org/wiki/Common_F11_bugs#Yum_doesn.27t_work_after_upgrading_from_F10


and the fix provided for it works to get you to update properly.

now, since farkas just mentioned that he didn't actually run preupgrade
when things went badly then it suggests to me that preupgrade is
probably not to blame.


the question here why yum not upgrade openssl during the dvd update 
process. it's another yum problem (and it's happened with 3 of my systems).


--
  Levente   "Si vis pacem para bellum!"

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: fedora 11 worst then ever release

[Seth Vidal]

On Sun, 26 Jul 2009, Farkas Levente wrote:



ohhh, come on!!! it's not an answer! it's just a proof that it's the worst 
release ever. who dare to put a newer yum into f10-updates than in f11 iso?



Here's what happened. I was delaying updating yum in f10-updates, on 
purpose. We slipped F11 twice and there was pressure to upgrade F10's yum 
to fix some bugs. So the timing worked out that F10+updates had a newer 
yum than F11. It happens. We provided an easy workaround and documented 
it.



who think about that his system will not working after doing everything as it 
has to be. can you tell me any other distro (including windows!) where the 
system installer not working after upgrade?


It happens all the time on lots of systems. I've had it happen on debian 
upgrades, slackware upgrades (granted that was long ago) and 
many fedora and rhel upgrades.


if it's so broken or it's require 
so broken thing like python then it should have to be replaced with something 
better tool.


I think you're being a bit melodramatic.

ok i know fedora is not intended for any serious task but can 
you images such a situation on a remote installed system. it's something like 
a toy now and not a real operation system.


I disagree.

And, frankly, if you're using fedora for such important tasks, you should 
have tested, first.



-sv

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: fedora 11 worst then ever release

[Farkas Levente]

On 07/26/2009 02:38 PM, Seth Vidal wrote:



On Sat, 25 Jul 2009, Björn Persson wrote:


Fortunately I had read in this list that upgrading breaks Yum so I did
a fresh
install instead, and only had to spend a few days getting all the
configuration
back into shape. Sound started working after I deleted ~/.pulse.


https://fedoraproject.org/wiki/Common_F11_bugs#Yum_doesn.27t_work_after_upgrading_from_F10


It's a pretty easy work around and it lasts all of however long it will
take to get the update downloaded.


ohhh, come on!!! it's not an answer! it's just a proof that it's the 
worst release ever. who dare to put a newer yum into f10-updates than in 
f11 iso? who think about that his system will not working after doing 
everything as it has to be. can you tell me any other distro (including 
windows!) where the system installer not working after upgrade? if it's 
so broken or it's require so broken thing like python then it should 
have to be replaced with something better tool. ok i know fedora is not 
intended for any serious task but can you images such a situation on a 
remote installed system. it's something like a toy now and not a real 
operation system.


--
  Levente   "Si vis pacem para bellum!"

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Applications install should be idiot proof

[Seth Vidal]

On Sun, 26 Jul 2009, Nelson Chan wrote:


i've just read  
http://blogs.computerworld.com/ubuntu_to_make_linux_application_installation_idiot_proof
he got a pretty good idea, see the 2nd last paragraph:
"""
I may know that Amarok, Banshee, Rhythmbox, and Songbird are all noteworthy 
Linux music players, but come on! Does anyone
beside another Linux expert know that? Letting users choose a program by say clicking on 
"music player" and then picking
one makes all the sense in the world.
"""
The idea is that newbies are likely have no idea what amarok,rhythmbox are, so 
does other applications  Totem, abiword,
Brasero..etc.  what they know are the general type of the software --- Music 
player, movie player, office suite, CD/DVD
burner...
Also i tried to search for "music player" in Add/Remove Software, 
interestingly, it gives extremely odd and pointless
result..(try that yourself)
So i can see why newbies are pull their hair off and *CAN"T GET THINGS DONE*, 
and claim *fedora sucks*
See this fact, i think that we should classify some applications under their 
type.
For instance,  have   Rhythmbox, amarok ..etc  under "Music Player"

The above is just a suggestion, hoping to help brain storming more better 
approaches.
But i think that the idea is kinda a must for Windows and Mac OS X users to get 
comfort with Linux/fedora.



something on track for Fedora 13 is tags for packages. So you can add 
arbitrary keywords/phrases for packages that then yum/PK can search on.



-sv
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: fedora 11 worst then ever release

[Seth Vidal]

On Sat, 25 Jul 2009, Björn Persson wrote:


Fortunately I had read in this list that upgrading breaks Yum so I did a fresh
install instead, and only had to spend a few days getting all the configuration
back into shape. Sound started working after I deleted ~/.pulse.


https://fedoraproject.org/wiki/Common_F11_bugs#Yum_doesn.27t_work_after_upgrading_from_F10

It's a pretty easy work around and it lasts all of however long it will 
take to get the update downloaded.


-sv



-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: fedora 11 worst then ever release

[Seth Vidal]

On Sat, 25 Jul 2009, Alan Cox wrote:


"all of my system has a wrong openssl version"

all these symptoms sound like your upgrade went horribly wrong. I've seen
preupgrade mash up a box by half upgrading like that. It's the main reason
I don't think preupgrade is actually safe to use yet.



Preupgrade's process is to depsolve - using the same method anaconda does, 
download the pkgs it solves out. Put them in a cachedir. Download a 
kernel and an initrd, Setup a ks.cfg. then reboot the machine and allow 
anaconda to do the install.


Specific issues we've had with preupgrade are related to not being able to 
find a mirror and/or not being able to get pkgs. However, once the pkgs 
are downloaded and the system reboots it is all in Anaconda's hands.


The case of yum being 'partially' upgraded came from us having a newer yum 
in f10+updates than was in F11. This was documented here:


https://fedoraproject.org/wiki/Common_F11_bugs#Yum_doesn.27t_work_after_upgrading_from_F10

and the fix provided for it works to get you to update properly.

now, since farkas just mentioned that he didn't actually run preupgrade 
when things went badly then it suggests to me that preupgrade is probably 
not to blame.


Alan, if you can describe the situation where preupgrade munged up a 
system, I'd like to take a look.


-sv

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: fedora 11 worst then ever release

[arvind iyer]

I too have a half-upgraded system at my workplace, tried pushing a long jump
from Fedora8 to edora11 (and i think I fell in the ditch between them). I
will sit one of this afternoons and simply reinstall afresh, the only way
out, i think.


On my laptop however , I have three partitions "Fedora n" "Fedora n+1" and
"homedisk" which has /home/ Fedora n:/home// and Fedora
n+1:/home// have symbolic links to the /homedisk//* This allows
me to have an "alomst" trouble-less installs version after version, starting
from Fedora-8


 --

Work while you are alive, you can rest later
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: fedora 11 worst then ever release

[Björn Persson]

oleksandr korneta wrote:
> on 07/25/2009 11:46 AM Chuck Anderson wrote:
> > I don't even upgrade anymore.  I just keep two partitions (Logical
> > Volumes actually)--one for Fedora N and one for Fedora N+1.
>
> interesting idea. Do you keep the same home for both?

I have two root partitions and two /boot partitions so that I can keep Fedora 
n as a fallback until I see that Fedora n+1 (or sometimes n+2) is working 
acceptably. I have a separate /home partition so I can keep it when I 
reinstall or upgrade, but I've found that logging in to Fedora n after having 
run Fedora n+1 with the same /home can be dangerous. I completely trashed my 
Kmail configuration that way. Since then I'm more careful and test Fedora n+1 
before I move the /home partition over.

Björn Persson



signature.asc
Description: This is a digitally signed message part.
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: fedora 11 worst then ever release

[Ralf Corsepius]

On 07/26/2009 10:40 AM, drago01 wrote:

On Sun, Jul 26, 2009 at 8:34 AM, Ralf Corsepius  wrote:


It may be news to you, but a single negative result invalidates a whole
series of "positive tests" ;)


No, that means that they are bugs / problems but not that the feature
is broken in general.


Well, it means that "the feature" lacks generality and raises questions 
about a feature's "readyness for prime time" - Judging whether this 
feature is sufficiently ready for "prime-time" is up to the eye of beholder.


Adam thinks it's good, I observed breakdowns on several different 
systems (5 so far). My conclusion: The FC10 preupdate/FC11 anaconda 
combo are far from being ready, even less so the version in the iso.



The worst about it: Unless rel-eng finally releases updated Fedroa 11 
isos, the shameful situation about F11 installs will not see much 
improvements, because anaconda being "FIXED UPSTREAM/RAWHIDE" doesn't 
help FC11 users.



Ralf






--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Clipboard manager by default in Fedora 12

[Julian Aloofi]

Oops, I meant Fedora 12 when I wrote this:

> I don't think that would count as a feature, and it isn't one. It's
> basically a program every system should have (in my opinion).
> The Gnome clipboard isn't working great. I often get complaints from new
> users I introduce to Fedora that their clipboard content was lost when
> they closed Firefox, or something similar. And it's true, I don't trust
> the default Gnome Copy&Paste to keep anything in it when I'm not running
> a clipboard manager and don't close any apps "just in case".
> 
> It would be really nice to have a clipboard manager by default on the
> Live CD (GNOME and XFCE, KDE already has klipper).
> When I look in the repos for available clipboard managers, I see
> glipper, parcellite and the XFCE plugin (xfce4-clipman-plugin).
> glipper is 111 k, and parcellite is 114, so it shouldn't be a difference
> of size. I personally would recommend parcellite, because it's pretty
> lightweight and works good (and I use it myself :D).
> What do you think about that? 
> I think this would improve the user experience and add functionality to
> the desktop.


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

rawhide report: 20090726 changes

[Rawhide Report]

Compose started at Sun Jul 26 06:15:06 UTC 2009

New package python-Lightbox
Lightbox photo display widget
Updated Packages:

aria2-1.5.0-1.fc12
--
* Sun Jul 26 2009 Rahul Sundaram  - 1.5.0-1
- Mostly minor bug fixes 
- WEB-Seeding support for multi-file torrent
- http://aria2.svn.sourceforge.net/viewvc/aria2/trunk/NEWS?revision=1476

* Fri Jul 24 2009 Fedora Release Engineering  
- 1.3.1-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


conspy-1.6-3.fc12
-
* Fri Jul 24 2009 Fedora Release Engineering  
- 1.6-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild

* Fri Jul 24 2009 Fabian Affolter  - 1.6-3
- Added missing BR and added auto* stuff

* Sun Jun 14 2009 Fabian Affolter  - 1.6-1
- Updated to new upstream version 1.6


dietlibc-0.32-0.fc12

* Sat Jul 25 2009 Enrico Scholz  - 
0.32-0
- updated to 0.32
- fixed stackgap/auxvec patch
- added patches to fix SMP builds and to prevent object file stripping
- moved %changelog entries from 2005 and before into ChangeLog.2005 file

* Fri Jul 24 2009 Fedora Release Engineering  
- 0.31-9.20090228
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


dracut-0.7-1.fc12
-
* Fri Jul 24 2009 Harald Hoyer  0.7-1
- version 0.7

* Wed Jul 22 2009 Harald Hoyer  0.6-1
- version 0.6


e2fsprogs-1.41.8-5.fc12
---
* Sun Jul 26 2009 Karel Zak  1.41.8-5
- disable fsck (replaced by util-linux-ng)

* Sat Jul 25 2009 Karel Zak  1.41.8-4
- disable libuuid and uuidd (replaced by util-linux-ng)

* Fri Jul 24 2009 Fedora Release Engineering  
- 1.41.8-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


f-spot-0.5.0.3-9.fc12
-
* Sat Jul 25 2009 Christian Krause  - 0.5.0.3-9
- Avoid showing f-spot twice for photo imports
- Make f-spot-import work with gvfs
- Minor indentation fix

* Fri Jul 24 2009 Fedora Release Engineering  
- 0.5.0.3-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


freenx-server-0.7.3-14.fc12
---
* Sat Jul 25 2009 Axel Thimm  - 0.7.3-14
- Use some patches from up to svn 613 (dated 2008-09-01).
- Add keymap.patch from Fedora bug #506470.
- Add cups listing patch from Fedora bug #509879.
- Add dependency for misc fonts Fedora bug #467494.
- Fix stale X11 displays from Fedora bug #492402.
- Fix authorized_keys*2* syncing, may fix Fedora bug #503822.
- Move %post parts to nxserver startup, fixes Fedora bug #474720.
- Copy ssh keys on first start, fixes Fedora bug #235592.
- Add init script with CentOS patches that ensures /tmp/.X11-unix
  always exists, fixes Fedora bug #437655.


gauche-0.8.14-3.fc12

* Sat Jul 25 2009 Gerard Milmeister  - 0.8.14-3
- patch for setting target arch

* Fri Jul 24 2009 Fedora Release Engineering  
- 0.8.14-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


gcc-4.4.1-3
---
* Sat Jul 25 2009 Jakub Jelinek  4.4.1-3
- update from gcc-4_4-branch
  - PR fortran/40727
- fix unwind info for -freorder-blocks-and-partitions
  (PR rtl-optimization/34999)
- fix Fortran MINLOC/MAXLOC/MINVAL/MAXVAL handling of infinities and NaNs,
  speed them up (PRs fortran/40643, fortran/31067)
- fix ICE with Fortran data xfer without io unit (PR fortran/40839)


globus-callout-0.7-5.fc12
-
* Thu Jul 23 2009 Mattias Ellert  - 0.7-5
- Add instruction set architecture (isa) tags
- Make doc subpackage noarch


globus-core-5.15-6.fc12
---
* Thu Jul 23 2009 Mattias Ellert  - 5.15-6
- The globus-spec-creator script now uses isa tags and noarch doc subpackages
- Replace /usr/bin/env shebangs


globus-ftp-control-2.10-3.fc12
--
* Thu Jul 23 2009 Mattias Ellert  - 2.10-3
- Add instruction set architecture (isa) tags
- Make doc subpackage noarch


globus-gass-copy-4.14-3.fc12

* Thu Jul 23 2009 Mattias Ellert  - 4.14-3
- Add instruction set architecture (isa) tags
- Make doc subpackage noarch


globus-gass-transfer-3.4-3.fc12
---
* Thu Jul 23 2009 Mattias Ellert  - 3.4-3
- Add instruction set architecture (isa) tags
- Make doc subpackage noarch


globus-gsi-callback-1.10-3.fc12
---
* Thu Jul 23 2009 Mattias Ellert  - 1.10-3
- Add instruction set architecture (isa) tags
- Make doc subpackage noarch


globus-gsi-cert-utils-5.5-3.fc12

* Thu Jul 23 2009 Mattias Ellert  - 5.5-3
- Add instruction set architecture (isa) tags
- Make doc subpackage noarch


globus-gsi-credential-2.2-3.fc12

* Thu Jul 23 2009 Mattias Ellert  - 2.2-3
- Add instruction set architecture (isa) tags
- Make doc subpackage noarch


globus-gsi-proxy-core-3.4-3.fc12

* Thu Jul 23 2009 Mattias Ellert  - 3.4-3
- Add instruction set architecture (isa) tags
- Make doc subpackage noar

Re: rpms/rubygem-rails/devel .cvsignore, 1.8, 1.9 import.log, 1.1, 1.2 rubygem-rails.spec, 1.13, 1.14 sources, 1.8, 1.9

[Mamoru Tasaka]

Hello:

Jeroen van Meeuwen wrote, at 07/26/2009 07:42 PM +9:00:

Author: kanarip

Update of /cvs/pkgs/rpms/rubygem-rails/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv28785/devel

Modified Files:
	.cvsignore import.log rubygem-rails.spec sources 
Log Message:

2.3.3-1





Index: import.log
===
RCS file: /cvs/pkgs/rpms/rubygem-rails/devel/import.log,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- import.log  16 Mar 2009 12:38:55 -  1.1
+++ import.log  26 Jul 2009 10:42:17 -  1.2
@@ -1 +1,2 @@
 rubygem-rails-2_3_2-1_fc10:HEAD:rubygem-rails-2.3.2-1.fc10.src.rpm:1237207120
+rubygem-rails-2_3_3-1_fc11:HEAD:rubygem-rails-2.3.3-1.fc11.src.rpm:1248604918


Index: rubygem-rails.spec
===





+# Delete zero-length files
+find %{buildroot}/%{geminstdir} -type f -size 0c -exec rm -rvf {} \;
+





 %changelog
-* Wed Jul 24 2009 Scott Seago  - 2.3.2-3
-- Remove the 'delete zero length files' bit, as some of these are needed.
-
-* Wed May  6 2009 David Lutterkort  - 2.3.2-2
-- Fix replacement of shebang lines; broke scripts/generate (bz 496480)
+* Sun Jul 26 2009 Jeroen van Meeuwen  - 2.3.3-1
+- New upstream version
 
 * Mon Mar 16 2009 Jeroen van Meeuwen  - 2.3.2-1

 - New upstream version


Please check out CVS module before committing your change.
You have reverted the changes by Scott Seago to fix bug 496480.

Especially please be very careful when using cvs-import.sh as using
cvs-import.sh will easily lead to this type of reverting.

Regards,
Mamoru

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: fedora 11 worst then ever release

[Farkas Levente]

On 07/26/2009 08:12 AM, Adam Williamson wrote:

On Sat, 2009-07-25 at 21:42 +0200, Farkas Levente wrote:

On 07/25/2009 08:56 PM, Björn Persson wrote:

Fortunately I had read in this list that upgrading breaks Yum so I did a fresh
install instead, and only had to spend a few days getting all the configuration
back into shape. Sound started working after I deleted ~/.pulse.

and if you is broken then the whole system is broken! so everybody have
to spenda few days to get back their config. so we only have to spend a
few days every half year. it's even worse then if i install windows.
it's a really nice release.
why is it so difficult to upgrade packages?


I upgraded my laptop from F10 to F11, with X running, via yum. It worked
flawlessly and rebooted clean.


if it's the preferred method then it's better to forget the install dvd 
upgrade method. and even forget about fedora release!



Anecdotal evidence means very little.


what do you refer to?

--
  Levente   "Si vis pacem para bellum!"

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: fedora 11 worst then ever release

[drago01]

On Sun, Jul 26, 2009 at 8:34 AM, Ralf Corsepius wrote:

> It may be news to you, but a single negative result invalidates a whole
> series of "positive tests" ;)

No, that means that they are bugs / problems but not that the feature
is broken in general.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Applications install should be idiot proof

[Thomas Janssen]

2009/7/26 Nelson Chan :
> i've just read
> http://blogs.computerworld.com/ubuntu_to_make_linux_application_installation_idiot_proof
> he got a pretty good idea, see the 2nd last paragraph:
> """
> I may know that Amarok, Banshee, Rhythmbox, and Songbird are all noteworthy
> Linux music players, but come on! Does anyone beside another Linux expert
> know that? Letting users choose a program by say clicking on "music player"
> and then picking one makes all the sense in the world.
> """

Free (part of the Fedora philosophy) means as well that *I* can choose
what application i want. The example is a bad one since we already did
choose a default player for every DE on every spin.

> The idea is that newbies are likely have no idea what amarok,rhythmbox are,
> so does other applications  Totem, abiword, Brasero..etc.  what they know
> are the general type of the software --- Music player, movie player, office
> suite, CD/DVD burner...

Works with player, office and other keywords. And there are groups who
lists apps, like "Multimedia", "Office" and others.

> Also i tried to search for "music player" in Add/Remove Software,
> interestingly, it gives extremely odd and pointless result..(try that
> yourself)
> So i can see why newbies are pull their hair off and *CAN"T GET THINGS
> DONE*, and claim *fedora sucks*
> See this fact, i think that we should classify some applications under their
> type.
> For instance,  have   Rhythmbox, amarok ..etc  under "Music Player"

The above mentioned group "Multimedia" is just for that. Having groups
for every combination of keywords might be a bit overload. But thats
just my 2Cent.

-- 
LG Thomas

Dubium sapientiae initium

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Applications install should be idiot proof

[Nelson Chan]

i've just read
http://blogs.computerworld.com/ubuntu_to_make_linux_application_installation_idiot_proof
he got a pretty good idea, see the 2nd last paragraph:
"""
I may know that Amarok ,
Banshee,
Rhythmbox , and
Songbirdare all noteworthy Linux music
players, but come on! Does anyone beside
another Linux expert know that? Letting users choose a program by say
clicking on "music player" and then picking one makes all the sense in the
world.
"""
The idea is that newbies are likely have no idea what amarok,rhythmbox are,
so does other applications  Totem, abiword, Brasero..etc.  what they know
are the general type of the software --- Music player, movie player, office
suite, CD/DVD burner...
Also i tried to search for "music player" in Add/Remove Software,
interestingly, it gives extremely odd and pointless result..(try that
yourself)
So i can see why newbies are pull their hair off and *CAN"T GET THINGS
DONE*, and claim *fedora sucks*
See this fact, i think that we should classify some applications under their
type.
For instance,  have   Rhythmbox, amarok ..etc  under "Music Player"

The above is just a suggestion, hoping to help brain storming more better
approaches.
But i think that the idea is kinda a must for Windows and Mac OS X users to
get comfort with Linux/fedora.

Cheers.

-- 
- Nelson Chan
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list