Adam Williamson wrote:
> I think I've proposed at least once that we make Obsoletes: for retired
> packages mandatory. My last proposal currently seems to be assigned to
> tibbs.
IMHO, forcefully removing packages that still work is a major disservice to
our users and should never be done.
On 18/11/16 19:53, Chris Murphy wrote:
On Fri, Nov 18, 2016 at 3:13 AM, Ms Sanchez wrote:
Hello Peter!
I tried to do this but it recorded nothing. Maybe I did something wrong?
Worked for me. But I did make modifications, I used tmux, because I'm
familiar with it, though that shouldn't matte
protobuf 3.1.0 is currently building. When the arm build finally completes
I'll start rebuilding the dependent packages. This bumps the soname, add
python3 support (in the -4 build), and adds java-nano and java-util. Thanks
to Gil Cattaneo for much help.
Deps appear to be:
clementine-1.3.1-3.f
On Fri, 18 Nov 2016 15:59:29 +0100
Florian Weimer wrote:
> On 11/18/2016 03:51 PM, Richard Fearn wrote:
> >> I also checked that mail to my fedoraproject.org address (to which
> >> the wiki defaults) is forwarded to me. Changes/Fedora26CFlags is
> >> on my watchlist, but I did not receive any ch
2016-11-18 15:53 GMT+01:00 Stephen John Smoogen :
> On 18 November 2016 at 02:39, Gerd Hoffmann wrote:
>> Hi,
>>
>>> > Apples and oranges. There's no installer on ARM. There's no need to wipe
>>> > all your data on a desktop system that you have one unit of.
>>>
>>> Yes, there is, we support ana
2016-11-18 19:37 GMT+01:00 Chris Murphy :
> Options:
> 1. Keep the mactel-boot stuff (pretty but weird), and write up test
> cases specifically to account for the weirdness in particular how to
> reset the state of the computer so it's possible to do clean installs.
> There are a couple of ways to
On 2016-11-18 10:13 AM, Kalev Lember wrote:
I don't think it would make upgrades less problematic because
both dnf and gnome-software can already remove problematic packages
without needing obsoletes.
This isn't entirely true. It's true in straightforward cases, but there
are complex cases whe
On Fri, Nov 18, 2016 at 07:58:14PM +0100, Kalev Lember wrote:
> As for (2), I guess we should do the same as (1) but just allow the user
> to choose the N+1 release as well in addition to N+2.
I'd rather just always show the latest and tell people who have a
special need to just go up one release
On 11/17/2016 07:26 PM, Adam Williamson wrote:
> Hi, folks!
>
> While looking into an issue with how GNOME Software decides which
> release to offer an upgrade to when there's more than one plausible
> candidate, I noticed something interesting: we do not actually have a
> policy on what we 'recom
On Fri, Nov 18, 2016 at 3:13 AM, Ms Sanchez wrote:
>
> Hello Peter!
>
> I tried to do this but it recorded nothing. Maybe I did something wrong?
Worked for me. But I did make modifications, I used tmux, because I'm
familiar with it, though that shouldn't matter, and I didn't literally
do this ste
Missing expected images:
Cloud_base qcow2 x86_64
Atomic qcow2 x86_64
Workstation live i386
Kde live x86_64
Cloud_base raw-xz x86_64
Atomic raw-xz x86_64
Workstation live x86_64
Kde live i386
Failed openQA tests: 55/79 (x86_64), 14/15 (i386), 1/2 (arm)
New failures (same test did not fail in Rawh
Options:
1. Keep the mactel-boot stuff (pretty but weird), and write up test
cases specifically to account for the weirdness in particular how to
reset the state of the computer so it's possible to do clean installs.
There are a couple of ways to do this. Burden is on Mac testers.
2. Explore treat
On Fri, Nov 18, 2016 at 07:19:20PM +0100, Kalev Lember wrote:
> There's a plan, but I don't think anyone is currently actively working
> on this. I may look into this for F26, but not promising anything right now.
I would really appreciate it if you can prioritize this.
--
Matthew Miller
Fedora
On 11/18/2016 06:03 PM, Adam Williamson wrote:
> On 2016-11-18 08:30 AM, Ralf Corsepius wrote:
>> Actually, I am inclined to believe only packages which are replaced by
>> others within Fedora or are definitely dead can be obsoleted. Package
>> which a just being retired for current/temporary lack
On 11/18/2016 02:50 PM, Stephen Gallagher wrote:
> On 11/18/2016 07:07 AM, Marcin Juszkiewicz wrote:
>> W dniu 18.11.2016 o 12:49, Michael Catanzaro pisze:
>>> On Fri, 2016-11-18 at 05:37 +, Sérgio Basto wrote:
but GNOME Software use dnf-plugin-system-upgrade ? if yes , since
then
>>>
On 2016-11-18 09:33 AM, Ralf Corsepius wrote:
On 11/18/2016 06:08 PM, Adam Williamson wrote:
On 2016-11-18 09:03 AM, Adam Williamson wrote:
In fact, now I think about it for two seconds, the
'fedora-obsolete-packages' package can fulfill this role perfectly well.
If we make it a policy that a
On 11/18/2016 06:08 PM, Adam Williamson wrote:
On 2016-11-18 09:03 AM, Adam Williamson wrote:
In fact, now I think about it for two seconds, the
'fedora-obsolete-packages' package can fulfill this role perfectly well.
If we make it a policy that all packages which are retired but not
specifica
> "AW" == Adam Williamson writes:
AW> Meh, I disagree.
It a reasonable point, but there were strong opinions against forced
removal of packages in the manner you propose. This did go through
FESCo as well.
AW> Personally, though, I think any non-maintained package should be
AW> retired.
R
On Fri, Nov 18, 2016 at 08:48:20AM -0500, Stephen Gallagher wrote:
> On 11/18/2016 01:02 AM, Sérgio Basto wrote:
> > On Qui, 2016-11-17 at 21:04 +0100, Christian Dersch wrote:
> >>
> >> On 11/17/2016 09:01 PM, Luya Tshimbalanga wrote:
> >>> Why not using a similar scheme from Libre Office [1] where
On 2016-11-18 09:03 AM, Adam Williamson wrote:
I guess one tweak I would be okay with would be a sort of
weaker-Obsoletes mechanism: some kind of field that provides a hint to
package managers that by default it's OK for the packaging system to
remove a given package if it's blocking another tran
On 2016-11-18 08:30 AM, Ralf Corsepius wrote:
Actually, I am inclined to believe only packages which are replaced by
others within Fedora or are definitely dead can be obsoleted. Package
which a just being retired for current/temporary lack
interest/maintainer should not be obsoleted.
I disagre
On 2016-11-18 08:38 AM, Jason L Tibbitts III wrote:
I don't recall anything about _forcing_ retired packages to be
obsoleted. The current rules just say that you must do so if allowing
the package to continue to exist would cause dependency issues. Forcing
the removal of packages from systems w
> "AW" == Adam Williamson writes:
AW> (Interestingly, there is actually a way to solve this
AW> *retroactively*: the other week I was kicking around the idea of
AW> setting up a third-party repo containing a single package named
AW> fedora-obsoletes which just contains a bunch of obsoletes fo
On 11/18/2016 05:16 PM, Adam Williamson wrote:
(Interestingly, there is actually a way to solve this *retroactively*:
the other week I was kicking around the idea of setting up a third-party
repo containing a single package named fedora-obsoletes which just
contains a bunch of obsoletes for know
On 2016-11-18 01:03 AM, Miroslav Suchý wrote:
Fedora N has:
xorg-drivers-7.5 which requires xorg-drivers-foo, xorg-drivers-bar
xorg-drivers-foo requires xorg-drivers = 7.5
xorg-drivers-bar requires xorg-drivers = 7.5
Fedora N+1 has:
xorg-drivers-7.7 which requires xorg-drivers-foo
xorg
On 18/11/16 15:31, Sérgio Basto wrote:
hum, so use udevadm control --reload is deprecated ?
I review udev rules recently in one of my packages and systemd have 2
services: systemd-udevd.service and systemd-udev-trigger.service
trigger.service have this command:
ExecStart=/usr/bin/udevadm trig
> "SB" == Sérgio Basto writes:
SB> Anyway we should add some instructions in guidelines about this
SB> matter, even if we don't need add nothing in %post etc
That would be great, but someone who knows all of the details would need
to actually provide a draft. Or at least be willing to rev
On Sex, 2016-11-18 at 16:08 +0100, Igor Gnatenko wrote:
> On Fri, Nov 18, 2016 at 2:46 PM, Igor Gnatenko
> wrote:
> >
> > Hello @all,
> >
> > unfortunately I was not able to find updated information how to do
> > that.
> >
> > %{_udevrulesdir}/foo.rules is fine in %files and BuildRequires:
> >
On Fri, Nov 18, 2016 at 2:46 PM, Igor Gnatenko wrote:
> Hello @all,
>
> unfortunately I was not able to find updated information how to do that.
>
> %{_udevrulesdir}/foo.rules is fine in %files and BuildRequires:
> systemd, but there are more questions:
>
> * Should %udev_rules_update be put into
On Fri, Nov 18, 2016 at 9:36 AM, Matthew Miller
wrote:
> On Tue, Nov 15, 2016 at 09:01:52AM -0800, Adam Williamson wrote:
>> I would not be at all surprised to see a response to 1) be an effort to
>> define some specific hardware configurations that Workstation targets.
>
> Not completely by coinc
On 11/18/2016 03:51 PM, Richard Fearn wrote:
I also checked that mail to my fedoraproject.org address (to which the wiki
defaults) is forwarded to me. Changes/Fedora26CFlags is on my watchlist,
but I did not receive any change notification for it. The last change was
not even flagged as minor.
On 18/11/16 05:50, Stephen Gallagher wrote:
GNOME Software uses PackageKit and both PackageKit and DNF these days
use the same underlying dependency resolvers. So they're a lot closer
than they used to be.
Thanks.
___
devel mailing list -- devel@lists
On 18 November 2016 at 02:39, Gerd Hoffmann wrote:
> Hi,
>
>> > Apples and oranges. There's no installer on ARM. There's no need to wipe
>> > all your data on a desktop system that you have one unit of.
>>
>> Yes, there is, we support anaconda just like on all the other arches.
>> It's not as wi
> I also checked that mail to my fedoraproject.org address (to which the wiki
> defaults) is forwarded to me. Changes/Fedora26CFlags is on my watchlist,
> but I did not receive any change notification for it. The last change was
> not even flagged as minor.
Could it be because you haven't visite
On Tue, Nov 15, 2016 at 09:01:52AM -0800, Adam Williamson wrote:
> I would not be at all surprised to see a response to 1) be an effort to
> define some specific hardware configurations that Workstation targets.
Not completely by coincidence, I raised this at a Red Hat meeting this
week. Since Red
On Wed, Nov 16, 2016 at 9:00 PM, Florian Weimer wrote:
> On 11/16/2016 04:05 PM, Kevin Fenzi wrote:
>>
>> On Wed, 16 Nov 2016 12:03:42 +0100
>> Florian Weimer wrote:
>>
>>> On the Fedora wiki, I can subscribe to certain pages. I did that,
>>> but I did not receive any notifications when they wer
On 11/18/2016 07:07 AM, Marcin Juszkiewicz wrote:
> W dniu 18.11.2016 o 12:49, Michael Catanzaro pisze:
>> On Fri, 2016-11-18 at 05:37 +, Sérgio Basto wrote:
>>> but GNOME Software use dnf-plugin-system-upgrade ? if yes , since
>>> then
>>> we have dnf-plugin-system-upgrade should be safe offer
On 11/18/2016 01:02 AM, Sérgio Basto wrote:
> On Qui, 2016-11-17 at 21:04 +0100, Christian Dersch wrote:
>>
>> On 11/17/2016 09:01 PM, Luya Tshimbalanga wrote:
>>> Why not using a similar scheme from Libre Office [1] where Fedora
>>> 25 is
>>> the more recent version while Fedora 24 is more stable?
Hello @all,
unfortunately I was not able to find updated information how to do that.
%{_udevrulesdir}/foo.rules is fine in %files and BuildRequires:
systemd, but there are more questions:
* Should %udev_rules_update be put into %post?
* Should %{?systemd_requires} be presented in spec? probably
On Wed, Nov 09, 2016 at 08:13:16AM +0100, Adrian Reber wrote:
> Recently libcdio upstream released a new version of libcdio. I will
> update rawhide to this latest libcdio version and rebuild all
> dependencies.
libcdio and all dependencies have been rebuilt.
Adrian
signature.as
On 11/16/2016 05:09 PM, Adam Williamson wrote:
On Wed, 2016-11-16 at 17:02 +0100, Florian Weimer wrote:
On 11/16/2016 04:45 PM, Vít Ondruch wrote:
Dne 16.11.2016 v 16:30 Florian Weimer napsal(a):
On 11/16/2016 04:05 PM, Kevin Fenzi wrote:
On Wed, 16 Nov 2016 12:03:42 +0100
Florian Weimer w
No as long as the storage is modified before the first start of the
docker daemon and the first execution of docker-storage-setup, it should
be fine.
On 11/17/2016 07:54 PM, Subhendu Ghosh wrote:
>
> Assuming cloud-init can also select the storage or is that too late in
> the process?
>
>
> On No
I think N+2 updates are barely done pre release by users out there, so issues
will rarely be noted before final (F25 final in this case) lands. N+1 updates
happen quite often during N+1 alpha and beta phase, thus they'll probably see
more testing and should be recommended. OpenQA is fine, but it
W dniu 18.11.2016 o 12:49, Michael Catanzaro pisze:
> On Fri, 2016-11-18 at 05:37 +, Sérgio Basto wrote:
>> but GNOME Software use dnf-plugin-system-upgrade ? if yes , since
>> then
>> we have dnf-plugin-system-upgrade should be safe offer ii
>
> No, GNOME Software does not use dnf and never
On Fri, 2016-11-18 at 10:03 +0100, Miroslav Suchý wrote:
> The example of this issue:
>
> Fedora N has:
> xorg-drivers-7.5 which requires xorg-drivers-foo, xorg-drivers-bar
> xorg-drivers-foo requires xorg-drivers = 7.5
> xorg-drivers-bar requires xorg-drivers = 7.5
>
> Fedora N+1 has:
>
On Fri, 2016-11-18 at 05:37 +, Sérgio Basto wrote:
> but GNOME Software use dnf-plugin-system-upgrade ? if yes , since
> then
> we have dnf-plugin-system-upgrade should be safe offer ii
No, GNOME Software does not use dnf and never will.
Michael
__
Hello Peter!
I tried to do this but it recorded nothing. Maybe I did something wrong?
Cheers, Sylvia
On 14/11/16 04:20, Peter Hutterer wrote:
[Disclaimer: sorry if you've seen this one before, I posted it to desktop@
but I only got one recording. That's not quite enough to call it a dataset,
perl-Module-ScanDeps-1.23-1.fc26 changes license from
((GPL+ or Artistic) and Artistic 2.0) to (GPL+ or Artistic).
-- Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Dne 17.11.2016 v 19:26 Adam Williamson napsal(a):
You'll notice we don't explicitly specify *how* you should do this. That
is, if you're currently running Fedora 23, and you want to upgrade to
Fedora 25 next week, are you supposed to:
i) Upgrade to Fedora 24 first, then from Fedora 24 to Fedora
49 matches
Mail list logo