On 01/05/2017 11:36 PM, Lukas Slebodnik wrote:
On 01/05/2017 08:19 PM, Lukas Slebodnik wrote:
Even if we had this capability, I'm not sure if we would use it in
rawhide. It could considerably increase the size of the dependency
information.
You would remove "temporary versions" with official
> On 01/05/2017 08:19 PM, Lukas Slebodnik wrote:
>
> Even if we had this capability, I'm not sure if we would use it in
> rawhide. It could considerably increase the size of the dependency
> information.
>
You would remove "temporary versions" with official release.
I know it's not ideal and
On 01/05/2017 08:19 PM, Lukas Slebodnik wrote:
I think that we need to wait for
https://bugzilla.redhat.com/show_bug.cgi?id=1320954
Even if we had this capability, I'm not sure if we would use it in
rawhide. It could considerably increase the size of the dependency
information.
But I
I think that we need to wait for
https://bugzilla.redhat.com/show_bug.cgi?id=1320954
But I think it still would be good to to at least rebuild images.
LS
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
On Tue, Jan 03, 2017 at 09:22:52AM -0800, Adam Williamson wrote:
> Sure - but you talked about cherry-picking "an update", not "a
> package". Cherry picking *packages* from updates-testing is not
> required to work (or fail 'correctly' due to a dependency), no, but
> cherry-picking *updates* more
On Tue, 2017-01-03 at 08:46 -0500, Matthew Miller wrote:
> On Mon, Jan 02, 2017 at 08:43:37PM -0800, Adam Williamson wrote:
> > > I think officially, we don't "support" anything but all-or-nothing
> > > upgrades in *all* branches. That is, if you cherry-pick an update from
> > > updates (or even
On Mon, Jan 02, 2017 at 08:43:37PM -0800, Adam Williamson wrote:
> > I think officially, we don't "support" anything but all-or-nothing
> > upgrades in *all* branches. That is, if you cherry-pick an update from
> > updates (or even updates-testing) and it also needs some other package
> > to be
> On Tue, Jan 03, 2017 at 08:08:32AM -, Lukas Slebodnik wrote:
>
> But there is nothing that can be done about it. The symbol versions come
> from upstream, every release that adds new symbols adds new symbol version,
> and we do want to test glibc before it is released, we can't just wait
> It has nothing to do with rawhide. It is a best practice how to use
> map symbols/version script and to have stable API/ABI
> https://www.akkadia.org/drepper/dsohowto.pdf
>
> quote:
>
> I know it is not a high critical issue and therefore I suggested (in BZ) to
> to automatically rebuild
On Tue, Jan 03, 2017 at 08:08:32AM -, Lukas Slebodnik wrote:
> > On Mon, 2017-01-02 at 20:43 -0800, Adam Williamson wrote:
> >
> > ...but to expand on that, that's for stable releases. So far as Rawhide
> > is concerned, historically my understanding has been the same as
> > Florian's, we
> On Mon, 2017-01-02 at 20:43 -0800, Adam Williamson wrote:
>
> ...but to expand on that, that's for stable releases. So far as Rawhide
> is concerned, historically my understanding has been the same as
> Florian's, we haven't ever claimed that dependencies will be so
> comprehensive that you can
On Mon, 2017-01-02 at 20:43 -0800, Adam Williamson wrote:
> On Mon, 2017-01-02 at 09:37 -0500, Matthew Miller wrote:
> > On Mon, Jan 02, 2017 at 02:29:47PM +0100, Florian Weimer wrote:
> > > We received a bug report that generated RPM dependencies are too
> > > coarse in rawhide (#1409557).
> > >
On Mon, 2017-01-02 at 09:37 -0500, Matthew Miller wrote:
> On Mon, Jan 02, 2017 at 02:29:47PM +0100, Florian Weimer wrote:
> > We received a bug report that generated RPM dependencies are too
> > coarse in rawhide (#1409557).
> >
> > The bug report is correct at a technical level. But I assumed
> On Mon, Jan 02, 2017 at 02:29:47PM +0100, Florian Weimer wrote:
>
> I think officially, we don't "support" anything but all-or-nothing
> upgrades in *all* branches. That is, if you cherry-pick an update from
> updates (or even updates-testing) and it also needs some other package
> to be
> On 01/02/2017 05:22 PM, Lukas Slebodnik wrote:
> The bug is in the user-supplied container build scripts. Recommended
> practice is to run “dnf update” (or “yum update”) as part of the build
> process.
Could you provide some link where it is recommended?
Because most of pages say exactly
On 01/02/2017 05:22 PM, Lukas Slebodnik wrote:
I know it is not a high critical issue and therefore I suggested (in BZ) to
to automatically rebuild docker base image for such change in glibc in rawhide.
It would not fix the problem but it would reduce potential bugs. And in future
we might
> On Mon, Jan 02, 2017 at 02:29:47PM +0100, Florian Weimer wrote:
>
> This is rawhide, if it breaks, people should keep the pieces.
> We shouldn't
> change what we do with symbol versions just because of it.
>
It has nothing to do with rawhide. It is a best practice how to use
map
On Mon, Jan 02, 2017 at 09:37:01AM -0500, Matthew Miller wrote:
> On Mon, Jan 02, 2017 at 02:29:47PM +0100, Florian Weimer wrote:
> > We received a bug report that generated RPM dependencies are too
> > coarse in rawhide (#1409557).
> >
> > The bug report is correct at a technical level. But I
On Mon, Jan 02, 2017 at 02:29:47PM +0100, Florian Weimer wrote:
> We received a bug report that generated RPM dependencies are too
> coarse in rawhide (#1409557).
>
> The bug report is correct at a technical level. But I assumed that
> it was not a problem because partial upgrades are in rawhide
On Mon, Jan 02, 2017 at 02:29:47PM +0100, Florian Weimer wrote:
> We received a bug report that generated RPM dependencies are too coarse in
> rawhide (#1409557).
>
> The bug report is correct at a technical level. But I assumed that it was
> not a problem because partial upgrades are in rawhide
We received a bug report that generated RPM dependencies are too coarse
in rawhide (#1409557).
The bug report is correct at a technical level. But I assumed that it
was not a problem because partial upgrades are in rawhide are not
supported—it's always all-or-nothing.
Comments?
Thanks,
21 matches
Mail list logo
