headers
Kay Sievers | 1 Feb 02:38

Re: Fedora 17’s unified filesystem (/usr-move)

On Tue, Jan 31, 2012 at 23:36, Adam Williamson <awilliam <at> redhat.com> wrote:
> On Tue, 2012-01-31 at 14:23 -0800, Adam Williamson wrote:
>> On Fri, 2012-01-27 at 14:10 +0100, Harald Hoyer wrote:
>> > Hello Testers and rawhide Users,
>> >
>> > Fedora 17 will locate the entire base operating system in /usr. The directories
>> > /bin, /sbin, /lib, /lib64 will only be symlinks:
>> >  /bin → /usr/bin
>> >  /sbin → /usr/sbin
>> >  /lib → /usr/lib
>> >  /lib64 → /usr/lib64
>>
>> I've just tested building a live image from the /usr move repository. It
>> boots, and the /usr move changes appear to be implemented. I'm currently
>> testing if it can be installed successfully.
>>
>> One thing I already noticed is that there seems to be a problem with the
>> ntfs-3g executables. /bin/ntfs-3g seems to be a symlink to itself - it
>> shows as "/bin/ntfs-3g -> /bin/ntfs-3g" in ls output. Trying to do 'ls
>> -l /usr/bin/ntfs-3g' results in 'cannot access /usr/bin/ntfs-3g: Too
>> many levels of symbolic links'. /bin/ntfsmount is similarly affected.
>>
>> On a pre-/usr move system it seems that these executables are actually
>> located in /bin but have symlinks in /usr/bin - /usr/bin/ntfs-3g is a
>> symlink to /bin/ntfs-3g . Perhaps the existence of these symlinks
>> in /usr/bin confused things?

Oh, for some reason, we missed to add ntfs-3g to the packages in the
f17-usrmove repo. The unconverted package contains:
  /usr/bin/ntfs-3g -> /bin/ntfs-3g
(Continue reading)

Permalink | Reply | 1 comment |
headers
Adam Williamson | 1 Feb 05:58
Picon
Favicon

Re: Fedora 17’s unified filesystem (/usr-move)

On Wed, 2012-02-01 at 02:38 +0100, Kay Sievers wrote:

> > Installation fails at partitioning stage, with udisksd hitting "Error
> > opening /etc/crypttab file: Failed to open file '/etc/crypttab': No such
> > file or directory (g-file-error-quark, 4)"
> >
> > The file /etc/crypttab indeed doesn't exist. I'm not sure if this is
> > actually specific to the /usr move stuff, but it does prevent me being
> > able to ensure that installation works from a /usr-moved live image. I
> > have a non-usr-move image also, I'll test install with that.
> 
> Sounds unlikely that this is related. But tests should show.
> 
> Unrelated: Do you know if the installer uses udisks? If, it should
> probably switch to the current udisks2, because udisks will not much
> longer be supported, and we should people give a note about that.

Confirmed that this bug is not related to /usr move. I'm working with
anaconda team now to try and get an anaconda that's actually capable of
completing a live install, with or without the /usr move stuff.

I'm not sure if anaconda uses udisks directly, or if it's something else
calling udisksd. The udisksd error may not actually have been the cause
of the anaconda crash, according to bcl.
--

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nicolas Mailhot | 1 Feb 09:36
Favicon

Re: Fedora 17’s unified filesystem (/usr-move)


Le Mar 31 janvier 2012 21:32, James Antill a écrit :

>  Also, even if someone could fix rpm to work this out, making this work
> at the yum layer is _much_ harder ... because the repodata does not
> currently specify that /path/to/blah is a regular file or a symlink (and
> if it's a symlink, what it points to).

This, BTW, is a PITA whenever you need to check repo compliance with any
packaging guideline that specifies file location or ownership.

It's not possible to do a simple repoquery to find problem packages, you have
to download every single package with a file name in the wrong location, just
in case it's not actually wrong but contains a compat symlink pointing to the
right file (that may or may not be installed by the same package).

That makes simple repo checks astonishingly long and bandwidth-expensive.

-- 
Nicolas Mailhot

--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Permalink | Reply | 0 comments |
headers
Bastien Nocera | 1 Feb 13:01
Picon
Favicon

Re: Unity For Fedora (As in OpenSUSE or Arch)

On Sat, 2012-01-28 at 00:03 +0100, Kevin Kofler wrote:
> Adam Williamson wrote:
> > As far as I'm aware, Canonical were reasonably good about proposing the
> > libindicator patches for upstream inclusion, but many upstream projects
> > - especially those that are part of GNOME - weren't exactly rushing to
> > adopt the patches. I think Canonical did try to implement libindicator
> > support as a plugin for apps with sufficently sophisticated plugin
> > frameworks, which obviously helps.
> 
> That's really GNOME's fault. :-( Canonical explicitly designed 
> libappindicator (which is the library applications are expected to use, it 
> uses libindicator behind the scenes; there's also libindicate which is for 
> communication apps to notify new messages and such, confusing, isn't it?) to 
> be interoperable with KDE's status notifier spec, and thus applications 
> supporting libappindicator will also integrate better into the KDE Plasma 
> workspaces than applications still stuck on the legacy XEmbed-based system 
> tray protocol and/or using a GNOME-only gnome-shell extension. But GNOME is 
> giving the finger to cross-desktop protocols and refusing to implement them.

GNOME never gave an opinion on the spec, we gave an opinion on the
library, which was really just a huge pile of bugs (I know, they patched
a bunch of the applications I maintain, and I get to receive a large
number of crashers because of it).

> It's too bad that our maintainers for the affected packages are often one 
> and the same as the GNOME maintainers and thus Fedora is mostly siding with 
> GNOME on this and refusing to carry those patches, hurting all non-GNOME 
> desktops, not just Unity.

I refuse to carry the patches because libappindicator is far too buggy
(Continue reading)

Permalink | Reply | 54 comments |
headers
Rawhide Report | 1 Feb 13:29
Favicon

rawhide report: 20120201 changes

Compose started at Wed Feb  1 08:15:07 UTC 2012

Broken deps for x86_64
----------------------------------------------------------
[aunit]
	aunit-2010-3.fc16.i686 requires libgnat-4.6.so
	aunit-2010-3.fc16.x86_64 requires libgnat-4.6.so()(64bit)
[banshee]
	banshee-meego-2.2.1-3.fc17.x86_64 requires mutter-meego
[blender]
	1:blender-2.61-1.fc17.x86_64 requires libOpenCOLLADAStreamWriter.so.svn863()(64bit)
	1:blender-2.61-1.fc17.x86_64 requires libOpenCOLLADASaxFrameworkLoader.so.svn863()(64bit)
	1:blender-2.61-1.fc17.x86_64 requires libOpenCOLLADAFramework.so.svn863()(64bit)
	1:blender-2.61-1.fc17.x86_64 requires libOpenCOLLADABaseUtils.so.svn863()(64bit)
	1:blender-2.61-1.fc17.x86_64 requires libMathMLSolver.so.svn863()(64bit)
	1:blender-2.61-1.fc17.x86_64 requires libGeneratedSaxParser.so.svn863()(64bit)
	1:blenderplayer-2.61-1.fc17.x86_64 requires libOpenCOLLADAStreamWriter.so.svn863()(64bit)
	1:blenderplayer-2.61-1.fc17.x86_64 requires libOpenCOLLADASaxFrameworkLoader.so.svn863()(64bit)
	1:blenderplayer-2.61-1.fc17.x86_64 requires libOpenCOLLADAFramework.so.svn863()(64bit)
	1:blenderplayer-2.61-1.fc17.x86_64 requires libOpenCOLLADABaseUtils.so.svn863()(64bit)
	1:blenderplayer-2.61-1.fc17.x86_64 requires libMathMLSolver.so.svn863()(64bit)
	1:blenderplayer-2.61-1.fc17.x86_64 requires libGeneratedSaxParser.so.svn863()(64bit)
[cluster]
	clusterlib-3.1.8-2.fc17.i686 requires libconfdb.so.4(COROSYNC_CONFDB_1.0)
	clusterlib-3.1.8-2.fc17.i686 requires libconfdb.so.4
	clusterlib-3.1.8-2.fc17.x86_64 requires libconfdb.so.4(COROSYNC_CONFDB_1.0)(64bit)
	clusterlib-3.1.8-2.fc17.x86_64 requires libconfdb.so.4()(64bit)
	cman-3.1.8-2.fc17.x86_64 requires libconfdb.so.4(COROSYNC_CONFDB_1.0)(64bit)
	cman-3.1.8-2.fc17.x86_64 requires libconfdb.so.4()(64bit)
[comoonics-cdsl-py]
(Continue reading)

Permalink | Reply | 0 comments |
headers
Panu Matilainen | 1 Feb 13:32

Re: [Rpm-maint] Fedora 17’s unified filesystem (/usr-move)

On 01/31/2012 11:30 PM, James Antill wrote:
> On Tue, 2012-01-31 at 15:58 -0500, Bill Nottingham wrote:
>> James Antill (james <at> fedoraproject.org) said:
>>>> [root <at> nostromo ~]# mv /bin /cow
>>>> [root <at> nostromo ~]# /cow/ln -s /cow /bin
>>>> [root <at> nostromo ~]# rpm -qf /cow/bash
>>>> bash-4.2.20-1.fc16.x86_64
>>>> [root <at> nostromo ~]# rpm -qf /bin/bash
>>>> bash-4.2.20-1.fc16.x86_64
>>>>
>>>> rpm should already handle this, no need for the provides.
>>>
>>>   Good to see everyone still doesn't read what I write.
>>>
>>>   As I said, rpm _does something_ to make the above work for -qf (the
>>> above even works if you inside /cow ... as long as the /bin symlink
>>> exists!).
>>>   However, it _does not_ work, if you put the above in package
>>> provides/requires and try to install them. Eg.
>>
>> It does, in some cases. Which makes it even more fun.
>>
>> Take a system with /usr/bin/sdiff.
>>
>> ...
>> Name: cow
>> Summary: cow
>> Version: 1.0
>> Release: 1
>> URL: http://redhat.com/
(Continue reading)

Permalink | Reply | 7 comments |
headers
Florian Müllner | 1 Feb 14:05
Picon
Gravatar

Re: Unity For Fedora (As in OpenSUSE or Arch)

On mié, 2012-02-01 at 12:01 +0000, Bastien Nocera wrote:
> GNOME never gave an opinion on the spec, we gave an opinion on the
> library, which was really just a huge pile of bugs (I know, they patched
> a bunch of the applications I maintain, and I get to receive a large
> number of crashers because of it).

I can not comment on the quality of the library, but GNOME did comment
on the spec[0] (or rather: several gnomers did) - there were a couple of
objections, none of which have been addressed in the spec as far as I
can tell.

Florian

[0] http://lists.freedesktop.org/archives/xdg/2010-January/011228.html

--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Permalink | Reply | 47 comments |
headers
Emanuel Rietveld | 1 Feb 14:49
Picon
Gravatar

Re: Fedora 17’s unified filesystem (/usr-move)

On 02/01/2012 01:32 PM, Panu Matilainen wrote:
> To-be-installed files obviously have no on-disk fingerprints, so it 
> wont work for initial installation. So yes, those "fake" compatibility 
> provides are needed. Strictly speaking, compatibility provides would 
> be needed for ALL the moved files, not just /bin, as it's technically 
> perfectly legal for a package to depend on an arbitrary path in 
> /lib[64], not just /[s]bin.
>
>     - Panu -

Would it be possible to leave out these provides and fix each individual 
package to require in the new path instead?
--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Permalink | Reply | 6 comments |
headers
Chris Adams | 1 Feb 15:41
Favicon

Re: Fedora 17’s unified filesystem (/usr-move)

Once upon a time, Emanuel Rietveld <codehotter <at> gmail.com> said:
> On 02/01/2012 01:32 PM, Panu Matilainen wrote:
> >To-be-installed files obviously have no on-disk fingerprints, so it 
> >wont work for initial installation. So yes, those "fake" compatibility 
> >provides are needed. Strictly speaking, compatibility provides would 
> >be needed for ALL the moved files, not just /bin, as it's technically 
> >perfectly legal for a package to depend on an arbitrary path in 
> >/lib[64], not just /[s]bin.
> >
> >    - Panu -
> 
> Would it be possible to leave out these provides and fix each individual 
> package to require in the new path instead?

It isn't practical to "fix" every package that requires /bin/sh.

There sure seems to be a lot of uncertainty for a "feature" that is
supposedly ready to land.
-- 
Chris Adams <cmadams <at> hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Permalink | Reply | 5 comments |
headers
Genes MailLists | 1 Feb 15:48
Favicon

Re: Fedora 17’s unified filesystem (/usr-move)

On 02/01/2012 09:41 AM, Chris Adams wrote:
> Once upon a time, Emanuel Rietveld <codehotter <at> gmail.com> said:
>> On 02/01/2012 01:32 PM, Panu Matilainen wrote:
>>> To-be-installed files obviously have no on-disk fingerprints, so it 
>>> wont work for initial installation. So yes, those "fake" compatibility 
>>> provides are needed. Strictly speaking, compatibility provides would 
>>> be needed for ALL the moved files, not just /bin, as it's technically 
>>> perfectly legal for a package to depend on an arbitrary path in 
>>> /lib[64], not just /[s]bin.
>>>
>>>    - Panu -
>>
>> Would it be possible to leave out these provides and fix each individual 
>> package to require in the new path instead?
> 
> It isn't practical to "fix" every package that requires /bin/sh.
> 
> There sure seems to be a lot of uncertainty for a "feature" that is
> supposedly ready to land.

 Just asking - does a bind mount of /bin instead of a soft link help?
--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Permalink | Reply | 1 comment |

Gmane