On Ter, 2016-12-20 at 11:20 -0500, Matthew Miller wrote:
> 2. I really want releases to come at a known time every year, +/- two
> weeks. Keeping to this with six month targets means that if
> (when!)
> we slip, the next release may only have five or four months to
> bake.
This is a problem
On Wednesday, December 21, 2016 12:18:47 AM CET Miro Hrončok wrote:
> Hi all,
> We've recently tried to rebuild all Python packages with Python 3.6.
> However, we currently have bunch of packages that simply fail to build.
> ...
> Everything currently happens in a side tag. I will notify you when
On Tue, Dec 20, 2016 at 10:25 PM Gerald B. Cox wrote:
>
> On Tue, Dec 20, 2016 at 7:10 PM, Rahul Sundaram wrote:
>
> I don't see any context missing in a direct quote which I responded to.
> If you believe otherwise, feel free to summarize your position and include
> any context you need to.
>
>
On Mon, 2016-12-19 at 15:46 -0800, Adam Williamson wrote:
>
> * Installs or upgrades of any package set besides minimal seem to hang
> during boot
>
> That second one is a doozy - it causes most of the failures - and I'm
> going to look into it a bit more now. But it's at least the case that
>
On Tue, Dec 20, 2016 at 7:10 PM, Rahul Sundaram wrote:
> I don't see any context missing in a direct quote which I responded to.
> If you believe otherwise, feel free to summarize your position and include
> any context you need to.
>
That's ok... I don't think you'd get the point - as I said th
On Tue, Dec 20, 2016 at 9:59 PM Gerald B. Cox wrote:
>
> " KDE folks by and large want the updates as fast as possible. If the
> GNOME folks would like
> their updates to age for six months, they can just keep them in
> updates-testing."
>
>
> Obviously you missed it. Again, you have to take tha
As of the 20th of December 2016, Fedora 23 has reached its end of life
for updates and support. No further updates, including security
updates, will be available for Fedora 23. A previous reminder was sent
on 28th of November 2016 [0]. Fedora 24 will continue to receive
updates until approximately
On Tue, Dec 20, 2016 at 6:41 PM, Rahul Sundaram wrote:
>
> " KDE folks by and large want the updates as fast as possible. If the
> GNOME folks would like
> their updates to age for six months, they can just keep them in
> updates-testing."
>
Obviously you missed it. Again, you have to take tha
On Tue, Dec 20, 2016 at 9:33 PM Gerald B. Cox wrote:
>
>
> Right. I understand that but the solution of letting things stay in
> updates-testing for a long time isn't a great way to implement that. It an
> abuse of updates-testing.
>
>
> No one is doing that. You have to read the whole thread.
On Tue, Dec 20, 2016 at 6:30 PM, Rahul Sundaram wrote:
>
> Right. I understand that but the solution of letting things stay in
> updates-testing for a long time isn't a great way to implement that. It an
> abuse of updates-testing.
>
No one is doing that. You have to read the whole thread.
__
On Tue, Dec 20, 2016 at 9:26 PM Gerald B. Cox wrote:
>
> I was just repeating what I thought was a good suggestion - which is based
> upon what has
> already been implemented using the current infrastructure. Reserve "new"
> releases only for things
> that absolutely require it and let everythin
On Tue, Dec 20, 2016 at 5:45 PM, Rahul Sundaram wrote:
> Well, it isn't some theoretical construct... it's being done now with KDE
>> and has
>> been working just fine. It stays in updates-testing until you decide to
>> push it to stable. KDE
>> folks by and large want the updates as fast as po
On Tue, Dec 20, 2016 at 1:23 PM Gerald B. Cox wrote:
> Well, it isn't some theoretical construct... it's being done now with KDE
> and has
> been working just fine. It stays in updates-testing until you decide to
> push it to stable. KDE
> folks by and large want the updates as fast as possible.
>> The only way it reduces the risk of releasing a botched update is
>> the
>> the updates somehow get more testing just by staying in the testing
>> channel longer.
>
> ...and actual QA, from the professionals and volunteers on the QA team,
> who are very good at finding bugs pre-release but curre
On Tue, Dec 20, 2016 at 6:31 PM Pádraig Brady wrote:
> On 20/12/16 22:28, Christopher wrote:
> > What's with the new sources format?
> > The old format, I could do `md5sum -c sources`
> > Why not make the new format with SHA512 follow the same pattern, so I
> could do: `shasum -c sources` or `sha
On 20/12/16 22:28, Christopher wrote:
> What's with the new sources format?
> The old format, I could do `md5sum -c sources`
> Why not make the new format with SHA512 follow the same pattern, so I could
> do: `shasum -c sources` or `sha512sum -c sources`?
>
> Is there any standard command-line to
Hi
I filed the request to unretire eigen2, but I accidentally specified
only the rhbz ticket number instead of the full URL so it got denied
with "Invalid review BZ". I now tried filing a new unretirement request
with the full ticket url, but now I'm getting
Could not save the request for br
What's with the new sources format?
The old format, I could do `md5sum -c sources`
Why not make the new format with SHA512 follow the same pattern, so I could
do: `shasum -c sources` or `sha512sum -c sources`?
Is there any standard command-line tool to parse this new format, or do I
just gotta gre
On Mon, 2016-12-19 at 12:45 +0100, Nikos Mavrogiannopoulos wrote:
> On Sun, 2016-12-11 at 18:34 -0600, Dennis Gilmore wrote:
> > Greetings.
> >
> > As previously announced, releng has made a number of changes as
> > part
> > of
> > it's 2016 "flag day".
> >
> > All package maintainers will want
On Tue, Dec 20, 2016 at 10:22:41AM -0800, Gerald B. Cox wrote:
> Well, it isn't some theoretical construct... it's being done now with
> KDE and has been working just fine. It stays in updates-testing until
> you decide to push it to stable. KDE folks by and large want the
> updates as fast as poss
On 20 December 2016 at 11:20, Matthew Miller wrote:
> On Tue, Dec 20, 2016 at 04:48:44PM +0100, Pavel Raiskup wrote:
>> I probably lost the context ... what real-world problems are trying to fix?
>> Everything which comes to my mind should be solved by better tooling for
>> updates-testing testers
On Tue, Dec 20, 2016 at 10:08 AM, Matthew Miller
wrote:
> On Tue, Dec 20, 2016 at 10:01:57AM -0800, Gerald B. Cox wrote:
> > I'll repost this because I believe Kevin had a good point:
> >
> > I don't understand why we are trying to reinvent the wheel here. The
> > infrastructure for Kevin's sugg
Maybe a bit bit off topic WRT $Subject, sorry if it is the case.
On Tuesday, December 20, 2016 8:23:12 AM CET Michael Catanzaro wrote:
> Batched updates are something I really want to do regardless.
> Of course having fixes available sooner is valuable, but you have to weigh
> that against the cos
On Tue, Dec 20, 2016 at 10:01:57AM -0800, Gerald B. Cox wrote:
> I'll repost this because I believe Kevin had a good point:
>
> I don't understand why we are trying to reinvent the wheel here. The
> infrastructure for Kevin's suggestion
> is in place now - KDE has been using it and it works.
Thi
On 12/20/2016 09:34 AM, Adam Williamson wrote:
On Tue, 2016-12-20 at 08:48 -0800, Brendan Conoboy wrote:
Batched updates are valuable when testing happens with the whole. It
sorts out complex interactions between multiple package updates by
testing them all together.
Of course, a corollary of
On Tuesday, December 20, 2016 12:11:32 PM CET Matthew Miller wrote:
> First, I very frequently hear this: "Fedora should have an LTS — or be
> a rolling release." These two things are very far apart in actual
> implication, but they have one big thing in common, and when pressed,
> it usually comes
I'll repost this because I believe Kevin had a good point:
I don't understand why we are trying to reinvent the wheel here. The
infrastructure for Kevin's suggestion
is in place now - KDE has been using it and it works.
On Thu, Dec 8, 2016 at 9:07 PM, Kevin Kofler wrote:
> However, I also do n
On 20/12/16 17:40, Adam Williamson wrote:
On Tue, 2016-12-20 at 17:15 +, Tom Hughes wrote:
I didn't think updates-testing would be, it's just I don't think many
people use it so I'm not sure having things there for longer will
actually help.
We do in fact have numbers on this. For instance
On Tue, 2016-12-20 at 09:33 -0800, Adam Williamson wrote:
> If we're talking about *weekly* batched
> updates, no, it is not at all practical to assume we'll magically be
> able to find the time to do release-validation level testing of each
> update batch every week.
Of course it wouldn't make se
On Tue, 2016-12-20 at 17:15 +, Tom Hughes wrote:
> I didn't think updates-testing would be, it's just I don't think many
> people use it so I'm not sure having things there for longer will
> actually help.
We do in fact have numbers on this. For instance, since F25 came out,
218 people have
On Tue, 2016-12-20 at 08:48 -0800, Brendan Conoboy wrote:
> Batched updates are valuable when testing happens with the whole. It
> sorts out complex interactions between multiple package updates by
> testing them all together.
Of course, a corollary of this is that you have to try and figure ou
On Tue, 2016-12-20 at 10:48 -0600, Michael Catanzaro wrote:
> On Tue, 2016-12-20 at 14:27 +, Tom Hughes wrote:
> > Surely it's more likely that it just delays the discovery of the
> > botched
> > update?
>
> I don't think updates-testing should be batched. Testers should of
> course still get
On Tue, Dec 20, 2016 at 2:32 AM, Dominik 'Rathann' Mierzejewski
wrote:
> On Thursday, 08 December 2016 at 19:26, Dennis Gilmore wrote:
> [...]
>> I would like to see us stop pushing non security updates to updates from
>> updates-testing entirely and do it in monthly batches instead. we would pus
On Tue, Dec 20, 2016 at 2:32 AM, Dominik 'Rathann' Mierzejewski
wrote:
> On Thursday, 08 December 2016 at 19:26, Dennis Gilmore wrote:
> [...]
>> I would like to see us stop pushing non security updates to updates from
>> updates-testing entirely and do it in monthly batches instead. we would pus
On 20/12/16 16:48, Michael Catanzaro wrote:
On Tue, 2016-12-20 at 14:27 +, Tom Hughes wrote:
Surely it's more likely that it just delays the discovery of the
botched
update?
I don't think updates-testing should be batched. Testers should of
course still get all test updates ASAP.
I didn'
On Tue, Dec 20, 2016 at 05:51:33PM +0100, Pavel Raiskup wrote:
> I believe in both -- and I believe Fedora could have both -- "rolling
> release" and "major releases" as a separate "products".
>
> There are people in the wild who will never use Fedora as the workstation
> system because they seek
On 12/20/2016 08:20 AM, Matthew Miller wrote:
On Tue, Dec 20, 2016 at 04:48:44PM +0100, Pavel Raiskup wrote:
I probably lost the context ... what real-world problems are trying to fix?
Everything which comes to my mind should be solved by better tooling for
updates-testing testers.
I've given
On Tuesday, December 20, 2016 11:20:49 AM CET Matthew Miller wrote:
> 1. I believe in the value of releases, for the project and for end
>users — as opposed to a "rolling release" system. But major releases
>are a lot of work across the project — not just release engineering,
>but marke
On 12/20/2016 06:27 AM, Tom Hughes wrote:
On 20/12/16 14:23, Michael Catanzaro wrote:
Batched updates are something I really want to do regardless. Of course
having fixes available sooner is valuable, but you have to weigh that
against the cost of releasing a *botched* update. The advantage of
On Tue, 2016-12-20 at 14:27 +, Tom Hughes wrote:
> Surely it's more likely that it just delays the discovery of the
> botched
> update?
I don't think updates-testing should be batched. Testers should of
course still get all test updates ASAP.
> The only way it reduces the risk of releasing a
On Tue, Dec 20, 2016, at 05:20 PM, Matthew Miller wrote:
> On Tue, Dec 20, 2016 at 04:48:44PM +0100, Pavel Raiskup wrote:
> > I probably lost the context ... what real-world problems are trying to fix?
> > Everything which comes to my mind should be solved by better tooling for
> > updates-testing
I updated python-breathe to 4.4.0 and it build successfully but it appears
that happened right after the rebuild of 4.2.0 for Python 3.6 and it keeps
retrying the failed build. Is there something I need to do to stop the
retries?
Thanks,
Dave
-- Forwarded message --
From:
Date: Tu
On 12/19/2016 12:38 PM, jfi...@fedoraproject.org wrote:
> Hi Steve,
>
> Please have a look at this email:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HQ4JFTYLPT5GRW6AD4M2MWGMRAPE7ITN/
Thanks for the pointer...
>
> systemd developers has decided to chan
On Tue, Dec 20, 2016 at 04:48:44PM +0100, Pavel Raiskup wrote:
> I probably lost the context ... what real-world problems are trying to fix?
> Everything which comes to my mind should be solved by better tooling for
> updates-testing testers.
I've given this in several ways across the thread, but
On 12/18/2016 11:56 AM, Jan Kratochvil wrote:
> On Sun, 18 Dec 2016 17:26:40 +0100, Steve Dickson wrote:
>> How do I get f25 to create cores, these days?
>
> echo >/etc/sysctl.d/foo.conf "kernel.core_pattern=core"; reboot
>
> It gets broken by:
> /usr/lib/sysctl.d/50-coredump.conf
>
> $
On Thursday, December 8, 2016 9:17:14 AM CET Matthew Miller wrote:
> Trying to make this idea a little more concrete. Here's two suggestions
> for how it might work. These are strawman ideas -- please provide
> alternates, poke holes, etc. And particularly from a QA and rel-eng
> point of view. Bot
On Tue, Dec 20, 2016 at 01:00:32PM +, James Hogarth wrote:
> I see that we just need a Dockerfile in dist-git and fedpkg
> container-build can work from the existing git repo but is this
> intended to be supported or do we need to provide a fresh review
> request and then only build from the di
Hi all,
where is documented what system/hw is used on (primary) Koji builders?
I'm interested in memory, storage, filesystem, host operating system, guest
operating system (if those are VMs), etc.
The only thing I was able to find is version of mock in the log output.
FWIW, I'd like to reproduce
On 20/12/16 14:23, Michael Catanzaro wrote:
Batched updates are something I really want to do regardless. Of course
having fixes available sooner is valuable, but you have to weigh that
against the cost of releasing a *botched* update. The advantage of
batched updates is we reduce the risk of re
On Tue, 2016-12-20 at 10:32 +0100, Dominik 'Rathann' Mierzejewski
wrote:
> You gave just one disadvantage of this proposal and no advantages at
> all. Why do you think the above is a good idea? I, for one, do not
> like
> waiting a month to get bug fixes that are not security-related. We
> are
> no
Since 0.16 libscanmem is LGPLv3+ and the rest is GPLv3+.
--
-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Hi all,
So a couple of questions I'd like clarity on surrounding this...
I see that we just need a Dockerfile in dist-git and fedpkg
container-build can work from the existing git repo but is this
intended to be supported or do we need to provide a fresh review
request and then only build from th
On Di, 2016-12-20 at 09:28 +, David Howells wrote:
> Igor Gnatenko wrote:
>
> > > Well there is gcc-arm-linux-gnu for example but that's for kernels per
> > > description
> > Didn't see it before... But looks like it doesn't work either:
> > /usr/bin/arm-linux-gnu-ld: cannot find crt1.o: No s
On 20.12.2016 13:25, Neal Gompa wrote:
> On Tue, Dec 20, 2016 at 7:20 AM, Tom Hughes wrote:
>> On 20/12/16 12:15, Till Hofmann wrote:
>>
>>> I have a package that contains a subdirectory which is changed to a
>>> symlink in the next release. When I upgrade, I get the following error:
>>>
>>> Error
On 12/20/2016 01:15 PM, Till Hofmann wrote:
Hi all,
I have a package that contains a subdirectory which is changed to a
symlink in the next release. When I upgrade, I get the following error:
Error: Transaction check error:
file /usr/share/symlinktest/dir/subdir from install of
symlinktest-1-
On 20.12.2016 13:20, Tom Hughes wrote:
> On 20/12/16 12:15, Till Hofmann wrote:
>
>> I have a package that contains a subdirectory which is changed to a
>> symlink in the next release. When I upgrade, I get the following error:
>>
>> Error: Transaction check error:
>> file /usr/share/symlinktest
On Tue, Dec 20, 2016 at 7:20 AM, Tom Hughes wrote:
> On 20/12/16 12:15, Till Hofmann wrote:
>
>> I have a package that contains a subdirectory which is changed to a
>> symlink in the next release. When I upgrade, I get the following error:
>>
>> Error: Transaction check error:
>> file /usr/share
On 20/12/16 12:15, Till Hofmann wrote:
I have a package that contains a subdirectory which is changed to a
symlink in the next release. When I upgrade, I get the following error:
Error: Transaction check error:
file /usr/share/symlinktest/dir/subdir from install of
symlinktest-1-2.fc25.x86_64
Hi all,
I have a package that contains a subdirectory which is changed to a
symlink in the next release. When I upgrade, I get the following error:
Error: Transaction check error:
file /usr/share/symlinktest/dir/subdir from install of
symlinktest-1-2.fc25.x86_64 conflicts with file from package
On 12/19/2016 11:59 PM, Igor Gnatenko wrote:
> Hi,
>
> I found only one cross-compiler in repos -- arm-none-eabi-gcc-cs
There's also two mingw cross compilers: mingw32-gcc and mingw64-gcc. Not
sure if that's what you were looking for :)
--
Kalev
___
d
On Thursday, 08 December 2016 at 19:26, Dennis Gilmore wrote:
[...]
> I would like to see us stop pushing non security updates to updates from
> updates-testing entirely and do it in monthly batches instead. we would push
> daily security fixes and updates-testing. However this would make atomi
Igor Gnatenko wrote:
> > Well there is gcc-arm-linux-gnu for example but that's for kernels per
> > description
> Didn't see it before... But looks like it doesn't work either:
> /usr/bin/arm-linux-gnu-ld: cannot find crt1.o: No such file or directory
> /usr/bin/arm-linux-gnu-ld: cannot find crti
DNF 2.0.0 and DNF-PLUGINS-CORE 1.0.0 has been released. [1]
This major version update of DNF brings many user experience
improvements and underlying code changes. This release has been focused
on improving yum compatibility and fixes over 60 bugs. Because this
release is not fully compatible with
63 matches
Mail list logo
