[HEADS UP] mercurial v4.7 in rawhide
by Petr Stodulka
Hi guys,
mercurial has been rebased to v4.7 which would be incompatible
with RPMs mentioned below. As F30 will be released in winter,
there is a lot of time to find any issues and make other RPMs
working again.
Here is the list of components that depends on mercurial:
- git-cinnabar
- gitifyhg
- git-remote-hg
- golang
- gwsmhg
- hg-git
- hgsubversion
- hgsvn
- hgview
- python-anyvc
- python-hgapi
- python-hghooks
- python-vcstools
- python-wstool
- pyvcs
- qct
- rabbitvcs
- rbm
- tortoisehg
- trac-mercurial-plugin
Cheers,
Petr
5 years, 8 months
mingw-qt5-qtwebkit FTBFS: C++ struct size question
by Sandro Mani
Hi
I've spent some time debugging mingw-qt5-qtwebkit being FTBFS since the
last mass rebuild, and I've narrowed it down to this:
struct Foo {
unsigned u1 : 5;
unsigned u2 : 5;
unsigned u3 : 3;
unsigned u4 : 3;
unsigned u5 : 4;
unsigned u6 : 2;
unsigned u7 : 3;
unsigned u8 : 2;
unsigned u9 : 1;
unsigned u10 : 3;
// 31 bits
unsigned u11 : 2;
unsigned u12 : 2;
unsigned u13 : 2;
unsigned u14 : 6;
unsigned u15 : 7;
unsigned u16 : 1;
unsigned u17 : 1;
unsigned u18 : 1;
unsigned u19 : 1;
unsigned u20 : 1;
bool bar() const { return false; }
private:
unsigned u21 : 1;
unsigned u22 : 1;
unsigned u23 : 1;
unsigned u24 : 1;
// 59 bits
};
COMPILE_ASSERT((sizeof(Foo) <= 8), Foo_does_not_grow);
The COMPILE_ASSERT fails, since apparently sizeof(Foo) = 12. But without
the bool bar() member function, sizeof(Foo) = 8, which is what I would
expect regardless of the presence of (non-virtual) member functions - as
far as my C/C++ knowledge goes, non-virtual functions should not take up
any space. Am I missing something, or is this a compiler issue?
(Coincidentally, the failed build used mingw-gcc-8.1.0 which landed
before the mass rebuild, but previous (successful) builds were performed
with mingw-gcc-7.3.0).
Thanks
Sandro
5 years, 8 months
ideas about logging during the initramfs
by Dusty Mabe
I'd love to make logging during early boot not require everyone
to happen to get the `console=` entries ordered correctly on the
kernel command line. Inevitably we always get it wrong or the ordering
of the `console=` lines on a pre-baked works great for some people
but not for others. What if there was a way to get those early startup
systemd unit messages on all `console=` entries? Maybe there is.
I've got some code that I think could help with this. We basically configure
the journal in the initramfs to log all messages at 'info' level and above
to kmsg. We also have to make the kernel not ratelimit messages during this
time. Check out the proposed change and see what you think:
https://github.com/dracutdevs/dracut/pull/445
5 years, 8 months