FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 03-16-2010, 01:24 PM
Thorsten Leemhuis
 
Default Conflicts in latest update

Ankur Sinha wrote on 16.03.2010 14:33:
> On Tue, 2010-03-16 at 13:45 +0100, Thorsten Leemhuis wrote:
>> Jon Masters wrote on 16.03.2010 13:04:
>> > On Tue, 2010-03-16 at 11:16 +0100, Matěj Cepl wrote:
>> >> Dne 16.3.2010 09:50, Ankur Sinha napsal(a):
>> >> > I did notice that. I wasn't sure why a package from rpmfusion would
>> >> > conflict with one from fedora repos. (It's in rpmfusion for a reason)
>> >> > Is it being obsoleted by a fedora package (license been cleared or
>> >> > something)?
>> >> There are constantly modules moving between -good, -bad, -ugly packages
>> >> of gstreamer, and sometimes rpmfusion packages are not in sync with
>> >> Fedora ones. Give rpmfusion packagers some time to fix it (or join them
>> >> and help to fix it on your own).
>> > I'd just add those gstreamer packages to my exclude config in yum for
>> > the moment, if you don't want to deal with the breakage each time. Then
>> > you can remove those excludes when the repos catch up with each other.
>> > /etc/yum.conf:
>> > exclude=gstreamer-plugins-bad-free gstreamer-plugins-good
>> There are so many developers around on this list that know: reporting
>> bugs is the right way to get problems fixed and fixing things is way
>> better than posting workarounds to public places for various reasons --
>> nevertheless nobody filed a bug yet afaics :-/
> [...]
> I'm really grateful for the info.

np

> I didn't have enough knowledge on the transitions going on wrt gst packages

In case you got it wrong: my "There are so many developers around on
this list that know..." rant was not sent in your direction ;-)

> which is why I hadn't reported a bug yet. The intention of the thread
> here was to get more info on what was going on.

That's fine, but OTOH: A lot of people seem to think like that and that
afaics often leads to a situation where nobody reports the bug :-/ Note
that this is not specific to RPM Fusion, it's a general problem that
just worse when it comes to RPM Fusion, as it only has a quite small
number of contributors...

CU
knurd
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-16-2010, 01:34 PM
Bastien Nocera
 
Default Conflicts in latest update

On Tue, 2010-03-16 at 13:45 +0100, Alexander Kahl wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Thorsten Leemhuis from RPMFusion said why this is the case at the FUDCon
> 09 in Berlin and it will continue to be the case if nothing changes: No
> collaboration and total underappreciation of RPMFusion's work. We cannot
> legally endorse RPMFusion but we could very well collaborate with them
> "under the hood", which doesn't happen at all - at least not to my
> knowledge.

Except that that's not the case here, as Benjamin and I have been in
contact with Hans who takes care of the RPMFusion packages from the
start.

And top-posting FTL.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-16-2010, 01:37 PM
Alexander Kahl
 
Default Conflicts in latest update

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/16/2010 03:34 PM, Bastien Nocera wrote:
> Except that that's not the case here, as Benjamin and I have been in
> contact with Hans who takes care of the RPMFusion packages from the
> start.
Thanks for the insight, didn't know this has changed in the meantime.

- --
Alexander Kahl
GNU/Linux Software Developer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkufl6sACgkQVTRddCFHw12H2QCglNDY3SzP3N fVuKsbH8V7qtUa
KgEAnRbZR0awwBYFeYqKYx4O+mw7+U1k
=Pmtu
-----END PGP SIGNATURE-----
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-16-2010, 03:42 PM
Till Maas
 
Default Conflicts in latest update

On Tue, Mar 16, 2010 at 01:45:33PM +0100, Thorsten Leemhuis wrote:

> There are so many developers around on this list that know: reporting
> bugs is the right way to get problems fixed and fixing things is way
> better than posting workarounds to public places for various reasons --
> nevertheless nobody filed a bug yet afaics :-/

Imho it was not that obvious that there is a bug present, because these
kind of delays are usual with RPMFusion, because the repos are not
directly synced. E.g. I just expected it to work within some days and if
it did not, then I would have thought there might be something wrong.

Regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-16-2010, 06:09 PM
Thorsten Leemhuis
 
Default Conflicts in latest update

On 16.03.2010 17:42, Till Maas wrote:
> On Tue, Mar 16, 2010 at 01:45:33PM +0100, Thorsten Leemhuis wrote:
>> There are so many developers around on this list that know: reporting
>> bugs is the right way to get problems fixed and fixing things is way
>> better than posting workarounds to public places for various reasons --
>> nevertheless nobody filed a bug yet afaics :-/
> Imho it was not that obvious that there is a bug present, because these
> kind of delays are usual with RPMFusion, because the repos are not
> directly synced.

That IMHO something that needs fixing on the Fedora side (e.g. in yum)
http://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html
But I lost energy driving a solution forward.

> E.g. I just expected it to work within some days and if
> it did not, then I would have thought there might be something wrong.

Well, there were a few cases in the past where problems like this one
persisted for a few days because everybody thought like you outline :-/
But I have no solution for that apart from "if in a doubt file a bug" :-(

CU
knurd
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-16-2010, 06:46 PM
James Antill
 
Default Conflicts in latest update

On Tue, 2010-03-16 at 20:09 +0100, Thorsten Leemhuis wrote:
> On 16.03.2010 17:42, Till Maas wrote:
> > On Tue, Mar 16, 2010 at 01:45:33PM +0100, Thorsten Leemhuis wrote:
> >> There are so many developers around on this list that know: reporting
> >> bugs is the right way to get problems fixed and fixing things is way
> >> better than posting workarounds to public places for various reasons --
> >> nevertheless nobody filed a bug yet afaics :-/
> > Imho it was not that obvious that there is a bug present, because these
> > kind of delays are usual with RPMFusion, because the repos are not
> > directly synced.
>
> That IMHO something that needs fixing on the Fedora side (e.g. in yum)
> http://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html
> But I lost energy driving a solution forward.

I'm not sure what you want us to do, the main problem is that splitting
a DB of packages and then stitching it back together doesn't work 100%
of the time ... this isn't us being stupid:

http://en.wikipedia.org/wiki/CAP_Theorem

...yum repo DBs are AP and not C.
Skip-broken helps in all cases apart from file conflicts, which is a
packaging bug. Your idea of "timed skip-broken by default" doesn't work
because we don't have a "date package was released" ... although PK
currently does skip-broken by default, all the time.

> > E.g. I just expected it to work within some days and if
> > it did not, then I would have thought there might be something wrong.
>
> Well, there were a few cases in the past where problems like this one
> persisted for a few days because everybody thought like you outline :-/
> But I have no solution for that apart from "if in a doubt file a bug" :-(

Rpmfusion can run auto QA like tests on rpmfusion and Fedora (I don't
think we can legally do the same ... but I'm not sure). Finding the file
conflicts automatically is harder (you need to download all the rpms),
and it's not fast, but it's possible (Seth has a script, IIRC).

--
James Antill - james@fedoraproject.org
http://yum.baseurl.org/wiki/releases
http://yum.baseurl.org/wiki/whatsnew/3.2.27
http://yum.baseurl.org/wiki/YumMultipleMachineCaching
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-16-2010, 06:51 PM
Seth Vidal
 
Default Conflicts in latest update

On Tue, 16 Mar 2010, James Antill wrote:

>
> Rpmfusion can run auto QA like tests on rpmfusion and Fedora (I don't
> think we can legally do the same ... but I'm not sure). Finding the file
> conflicts automatically is harder (you need to download all the rpms),
> and it's not fast, but it's possible (Seth has a script, IIRC).

The script does this:

1. look up any potential conflicts in the filelists metadata
2. download the headers from those pkgs and see if the conflicts are real
or fake conflicts (ie: multilib-allowed)

it's not fast - it has to traverse a lot of data, of course.
-sv

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-16-2010, 07:02 PM
Jesse Keating
 
Default Conflicts in latest update

On Tue, 2010-03-16 at 15:46 -0400, James Antill wrote:
> but it's possible (Seth has a script, IIRC).

I do believe seth's script works purely from metadata without
downloading the rpms.

--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-16-2010, 07:43 PM
Thorsten Leemhuis
 
Default Conflicts in latest update

On 16.03.2010 20:46, James Antill wrote:
> On Tue, 2010-03-16 at 20:09 +0100, Thorsten Leemhuis wrote:
>> On 16.03.2010 17:42, Till Maas wrote:
>>> On Tue, Mar 16, 2010 at 01:45:33PM +0100, Thorsten Leemhuis wrote:
>>>> There are so many developers around on this list that know: reporting
>>>> bugs is the right way to get problems fixed and fixing things is way
>>>> better than posting workarounds to public places for various reasons --
>>>> nevertheless nobody filed a bug yet afaics :-/
>>> Imho it was not that obvious that there is a bug present, because these
>>> kind of delays are usual with RPMFusion, because the repos are not
>>> directly synced.
>> That IMHO something that needs fixing on the Fedora side (e.g. in yum)
>> http://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html
>> But I lost energy driving a solution forward.
> I'm not sure what you want us to do,

Actually I'm not sure myself what to do and haven't put much thought
into it lately...

> the main problem is that splitting
> a DB of packages and then stitching it back together doesn't work 100%
> of the time ... this isn't us being stupid:
> http://en.wikipedia.org/wiki/CAP_Theorem
> ...yum repo DBs are AP and not C.

Well, the big hammer solution to make it work 100% of the time then
would be: RPM Fusion should disable the Fedora repos and provide the
matching repodata for Fedora itself.

But that solution would be over designed, complicated and inflexible, so
don't take that suggestion seriously ;-)

But I don't think 100% of the time is needed, but maybe it could be made
a lot whole lot better with some fine tuning. The simple solution that
would fix most of the problems afaics: an additional config value flag
in (say) rpmfusion-free-updates.repo that expresses "if repo
fedora-updates gets updated repodata then check for updated
rpmfusion-free-repodata not only on the mirrors of this configured repo,
but also on server download1.rpmfusion.org (master repo for RPM
Fusion)". Then everything should just work for people as long as RPM
Fusion pushed matching updates in parallel. Note that the stuff needs to
work vice versa as -- e.g. if yum sees updated repo data for RPM Fusion
then check for new fedora-updates repodata as well.

> Skip-broken helps in all cases apart from file conflicts, which is a
> packaging bug.

Or a mirror lag and cache problems, like it would have happened with
gst-plugins-bad if we had pushed it at the right time, as in some cases
a freshly updated fedora-updates repo will get combined with a outdated
rpmfusion updates repo from a not-yet-updated mirror (or vice versa).

> Your idea of "timed skip-broken by default" doesn't work

That was just me thinking out loud ;-) and it's not my preferred
solution for the problem at hand these days...

> because we don't have a "date package was released" ...

And would that be needed at all? The timer could simply start locally
then yum sees the problem seen for the first time.

But as I said: Not sure if that worth investigating, but it might, as
yum bailing out when a problem happens seems to confuse quite a lot of
people (a colleague of mine for example always gets annoyed by that and
asks for help). Sure, those that don't know how to deal with it might
better be using PK, but we can't force them to do that and those
problems make us look bad :-/


Anyway: the "timed skip-broken by default" has a big downside in any
case: you might lose features temporary. Let's assume new gstreamer
packages where a plugin was moved from -bad to -good. Let's further
assume Fedora and RPM Fusion would have shipped the new matching and
updated packages in parallel. Then yum on some systems will install the
new -bad package from rpmfusion (which lacks the plugin now) but not the
new -good package from Fedora, if the mirror yum chose was not updated
yet (or updated a few hours earlied and was not checked for updated
repodata due to caching). Than the user temporary looses a feature --
bad :-/

>>> E.g. I just expected it to work within some days and if
>>> it did not, then I would have thought there might be something wrong.
>> Well, there were a few cases in the past where problems like this one
>> persisted for a few days because everybody thought like you outline :-/
>> But I have no solution for that apart from "if in a doubt file a bug" :-(
> Rpmfusion can run auto QA like tests on rpmfusion and Fedora (I don't
> think we can legally do the same ... but I'm not sure). Finding the file
> conflicts automatically is harder (you need to download all the rpms),
> and it's not fast, but it's possible (Seth has a script, IIRC).

Yeah, sure, that's right, but there were other information that made be
write the above:

RPM Fusion has just a few contributors and so little man-power, it
didn't even manage to get the repo closure scripts running on their own
hosts regularly -- there were some attempts over the years, but nothing
came out of it :-/

I fear that the lack of man power and contributors will result in RPM
Fusion falling apart sooner or later, but I really hope I'm wrong with that.

CU
knurd
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-16-2010, 07:46 PM
Michael Schwendt
 
Default Conflicts in latest update

On Tue, 16 Mar 2010 15:46:16 -0400, James wrote:

> Rpmfusion can run auto QA like tests on rpmfusion and Fedora (I don't
> think we can legally do the same ... but I'm not sure). Finding the file
> conflicts automatically is harder (you need to download all the rpms),
> and it's not fast, but it's possible (Seth has a script, IIRC).

I've created and published a proof-of-concept script a couple of times
before. It's the one I've used to file all those bugs about conflicts
in Rawhide.
http://mschwendt.fedorapeople.org/confcheck-remote-split2.py
(that's a more experimental version that tries to work with just 1GB of RAM)
It does not download all packages, but just the headers. For packages
stored in a local mirror, the speed isn't too bad. It ran approx. 11 minutes
with remote Rawhide, though, on an average dual core machine.

Will Woods/autoqa features a conflicts checker, too,
https://fedorahosted.org/pipermail/autoqa-results/2010-March/date.html
which is why I haven't continued with filing further tickets or with
enhancing my script.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 12:06 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org