Re: Broken dnf from 06-30-2018

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2018-07-06 at 11:57 +0100, Russel Winder wrote:
> On Thu, 2018-07-05 at 12:49 -0700, Adam Williamson wrote:
> […]
> > 
> > But the new dnf doesn't break everywhere; I updated to it and didn't
> > hit any of the reported issues. I'm sure the DNF developers *do* test
> > it on their local machines, but this is not some sort of cast-iron
> > guarantee that it will never fail anywhere else.
> 
> Can I suggest that the DNF people ought to be interested in the fact that two
> people prepared to say something on this list have a real problem that they
> have no idea how to fix without doing a reinstall from scratch. 

Sure they are. So far as I'm aware, no-one claimed that the bugs
*aren't* a problem, did they?

> It sounds like there is a set up for which there is no problem and that is
> good. It implies there is hope!
> 
> If given direction I can create a list of all packages installed, George I
> suspect can do likewise. This then might be able to allow people to ascertain
> what went wrong, why the tests didn't find it, and (the most important thing) 
> how to get out of this situation.

It wouldn't hurt (it's easy to do: rpm -qa | sort -u >
packagelist.txt), but it may not necessarily help either. The problem
may not be down to some specific combination of packages, but some
other factor to do with exactly how your repositories are set up or
something like that.

> I did an "strace dnf check-update" and got:
> 
> …
> pwrite64(24, "\305\33\10\3\2\3\7s\2\305\34\10\3\2\3\7s\2\305\35\10\3\2\3\7s\2\305\36\10\3\2"..., 1024, 1595392) = 1024
> pwrite64(24, "s\2\305\215\10\3\2\3\7s\2\305\216\10\3\2\3\7s\2\305\217\10\3\2\3\7s\2\305\220\10"..., 1024, 1596416) = 1024
> pwrite64(24, "\3\7s\2\305\377\10\3\2\3\7s\2\306\0\10\3\2\3\7s\2\306\1\10\3\2\3\7s\2\306"..., 609, 1597440) = 609
> munmap(0x7f95ff0c8000, 1598055)         = 0
> close(24)                               = 0
> --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x40} ---
> +++ killed by SIGSEGV (core dumped) +++
> Segmentation fault (core dumped)
> 
> but that isn't entirely helpful on its own I guess.

No, generally speaking, when you get a core dump, the backtrace of the
core dump (as generated by abrt, if you're lucky) is the most useful
thing you can provide. strace is only helpful in some specific
situations.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx/message/RHB5YH6QHXENCLK6IZ7XOLLNCQ4VXMJG/




[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]

  Powered by Linux