For the release of F25, has nobody run the upgrade path violations checker
to warn packagers about any downgrades the dist update would perform?
A missing zero day update [only available in updates-testing] for Claws
Mail has hit users. Not great. And I hear there are other packages that
get downgraded when upgrading to F25.
On Mon, Nov 21, 2016 at 4:42 AM, Piotr Ozarowski <piotr(a)debian.org> wrote:
> [Germano Massullo, 2016-11-20]
>> We often deal with upstream developers that bundle libraries in their
>> code, so to make a package we have to debundle them, etc.
>> This time, an upstream dev. asked me what he could do to make easier
>> the work of packagers.
>> In this case the software is python-netjsongraph  that bundles
>> I think it would be nice to make a discussion even for non Python
>> packages, so we can elaborate a sort of vademecum that a packager
>> could show to upstreams when there is a collaboration between them.
> In Debian we have https://wiki.debian.org/UpstreamGuide
> I guess more official, cross-distro document that we all point upstream
> authors to would be a nice idea as well.
It would be a great idea if there were principles that all
distributions could agree on and have a document codify that so that
all distributions can reference it to upstream.
真実はいつも一つ！/ Always, there's only one truth!
>>>17:10:26 <adamw> i can't really vote -1 on this under the current criteria unless someone tries on a newer mac and it works. but given https://www.happyassassin.net/testcase_stats/25/Installation/QA_Testcase_... , i am entirely open to dropping the criterion on the basis of failure to test.
I think it's specious to drop the criterion on this basis. There are
plenty of other things that don't get tested and their criterion don't
get dropped. It's always a last minute rush to test things like active
directory, Free IPA, iSCSI, you know the list way better than I do, so
I don't know why you're picking on this one in contrast to others.
>>>17:12:02 <sgallagh> I've never understood why we would block on failures to run on hardware that actively tries to make it difficult to run Linux on.
Please elaborate on what this means. Specifically I have no idea what
the word "actively" is referring to.
>>>17:20:03 <adamw> oh that's right, Apple decided to have HFS+ formatted 'ESP'. because they're assholes.
No, Macs have a FAT32 ESP just like other hardware does. And it can
use a bootloader on that ESP just like other hardware does. It's how
Ubuntu and openSUSE work on Macs.
It's Anaconda and mactel-boot that make an hfsplus ESP, in order to
trick the firmware into thinking the Fedora bootloaders are a macOS
instance, so that the Mac's bootloader and startup panel will show
Fedora as a boot option. openSUSE and Ubuntu aren't as pretty but
things still work in a more standardized fashion.
So feel free to drop the pretty UI/Ux going forward if maintaining
that is going to cause problems, but I don't see how Fedora meets its
goals by claiming Macs make things difficult for Linux, when in this
Go No Go meeting is a pre-plan to actively make Fedora more difficult
to use on Macs.
Dennis Gilmore wrote:
> koji authentication will be switching to Kerberos. Koji supports multiple
> authentication mechanisms. Fedora infrastructure has set up a freeipa
> instance internally that has credential syncing to fas. We are working on
> ensuring that gssapi caching is supported so that you can have multiple
> TGT's and the ability to work in multiple reams at once. you can get
> started today by doing kinit <fas username>@FEDORAPROJECT.ORG if you move
> your ~/.fedora.cert file out of the way authentication will still work.
Maybe a crazy idea, but couldn't Koji just use our SSH keys for
authenticating somehow? Those just work without any extra setup, they never
expire, and unlocking passphrase-protected keys is also an already solved
problem (ssh-askpass including GNOME and KDE versions, ssh-agent). All that
would have to happen is to tunnel the Koji CLI's communication through SSH
to koji.fedoraproject.org or to some trusted tunnel server that you can
delegate authentication to.
The root.log of F25 build jobs prints this late:
DEBUG util.py:421: Running transaction
DEBUG util.py:421: /var/tmp/rpm-tmp.W2zvnF: line 1: udevadm: command not found
DEBUG util.py:421: /var/tmp/rpm-tmp.W2zvnF: line 2: udevadm: command not found
DEBUG util.py:421: Running in chroot, ignoring request.
Haven't done anything to examine it, but mention it in case somebody recognises
which scriptlet it comes from.