Re: Potential (security) issue for beginners/non-experts when release is End Of Life: Fedora doesn’t consider the behavior of beginners/non-experts sufficiently
On Sat, Aug 12, 2023 at 12:07:05PM +0200, Leon Fauster via devel wrote: > Please do not clutter the user experience with such _additional_ > informations. The user on such workstations are not always the > administrator and such informations would not help/change the > situation either. I actually do a lot of config work to disable > such UI "features". For my case the user does not even understands > or notice it when a major upgrade was done (albeit some UI improvments). > Of course the active usage of Gnome software or dnf could and should > provide such information in a prominent way ... I think it's reasonable that this should be something under admin control, but for the common default scenario where the single uesr is also the admin it seems reasonable to let the user know that they'll no longer receive security updates? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Restricting automounting of uncommon filesystems?
On Sat, Jul 22, 2023 at 10:32:01AM +0200, drago01 wrote: > Which file systems are considered uncommon in that context? And aren't most > attacks based on file systems used by windows, which makes them "common" ? > (Extfat, NTFS, VFAT) Any attack here is going to be OS-specific - a vulnerability in a filesystem used by Windows is massively unlikely to be present in Linux. If your goal is to compromise a Linux device then the attack surface available to you (right now) is everything that's present in Linux. For removable devices I'd argue that anything other than exfat and vfat are probably uncommon, but could be convinced that ext4 and xfs made sense as well (and maybe ntfs since I assume some people do want to transfer data on USB hard drives) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Restricting automounting of uncommon filesystems?
On Sat, Jul 22, 2023 at 10:12:33AM -0400, Neal Gompa wrote: > Several years ago, SUSE distributions moved to disabling the modules > by default for a number of filesystems, but making it pretty easy to > turn them back on: > https://github.com/openSUSE/suse-module-tools/pull/5 The problem there is that if you install a module you need for a static mount, you open yourself up to attack via automounts. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Restricting automounting of uncommon filesystems?
A discussion within Debian again brought up the problem that:
1) Automounting of removable media exposes the kernel to a lot of
untrusted input
2) Kernel upstream are not terribly concerned with ensuring that kernel
filesystems are resilient against deliberately malformed filesystems so
are mostly not proactively looking for bugs there
3) Uncommonly used filesystems are less likely to be tested against
adverse input in the real world and so are more likely to contain
exploitable bugs
There are various cases where people do need to make use of uncommon
filesystems, but the majority of them aren't related to removable media.
udisks2 supports setting the UDISKS_AUTO variable to 0 on devices that
shouldn't be automounted, which means something like:
SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"
ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
# repeat as necessary for anything else that shouldn't be automounted
LABEL="udisks_insecure_fs_end"
ought to be enough. So:
a) Does this seem like a good idea?
b) If so, is dealing with it via udev rules the right approach? This way
seems desktop-agnostic
c) Where should it ship, and what should the process be for disabling it
for people who need this functionality?
Long-term I'd love to see more work put into having FUSE support for
these and leaving the in-kernel fs to stuff we know is trustworthy, but
that's rather more work.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Vague proposal: ship prebuilt initramfs images
On Tue, Jan 21, 2020 at 12:43:47PM +, Matthew Garrett wrote: > configinitrd file1 file2 file3 > initrd initramfs1.img initramfs2.img CONFIG Huh - it seems like grub may already support this? It looks like: initrd initramfs.img newc:/etc/crypttab:/boot/crypttab will add /boot/crypttab to the initramfs as /etc/crypttab. Haven't tested this yet, though, and it's entirely undocumented. -- Matthew Garrett | mj...@srcf.ucam.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Vague proposal: ship prebuilt initramfs images
On Tue, Jan 21, 2020 at 11:25:29AM +0100, Hans de Goede wrote: > For the size problem one approach which I think is worthwhile at least > for the x86/workstation case is making one initrd with the most common > stuff in there (say i915,nouveau and amd GPU drivers + NVME and AHCI > disk support, maybe some eMMC support) and another which contains > "everything" and then rework the dracut host-only code so that we can > leverage it to figure out which variant we want. Yeah, the important thing is that we have known values - there's no real problem with there being a large number of known values, so shipping multiple images (potentially to be combined if necessary) is entirely reasonable from that perspective. > So b it is, I actually suggested b. on a discussion about how to set > the keyboard map for the initrd (for full disk encryption) which currently > is a problem for rpm-ostree / SilverBlue which uses pre-generated > initrds with no custom config in there. Ok. I'll look into adding support to grub for reading some files and assembling them into an image. My rough idea here would be something like: configinitrd file1 file2 file3 initrd initramfs1.img initramfs2.img CONFIG where the first command generates the image and the second command causes it to be placed at the end of the final cpio blob? -- Matthew Garrett | mj...@srcf.ucam.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Vague proposal: ship prebuilt initramfs images
On Tue, Jan 21, 2020 at 09:09:16AM +0100, Petr Pisar wrote: > On Tue, Jan 21, 2020 at 12:57:50AM +0000, Matthew Garrett wrote: > > Any thoughts on this? > > > Properly measured system must measure all inputs. If you move the varying > bits from initramfs to another file, a boot loader will have to measure that > another file. At the end that's exactly what GRUB2 does. It measures any > loaded file. Yes, I wrote that code. The point of measurements is to be able to make a policy determination. If the contents of a file aren't security relevant then you don't care about its contents, but you do want to ensure that it ends up in a position where it can't interfere with any other security relevant codepath. In that scenario you want to measure the path, not the contents (or, rather, you can measure both and the policy agent can ignore the contents) > In my opinon, your proposal does not solve the problem. It actually makes > things worse because the booted code would become bigger and probably slower. I'm not clear how that follows. -- Matthew Garrett | mj...@srcf.ucam.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Vague proposal: ship prebuilt initramfs images
On Tue, Jan 21, 2020 at 12:29:13AM -0700, Chris Murphy wrote: > What about the on-going cost: downloading ~80M initramfs for each kernel > update; systemd-analyze on NVMe says initrd time is 2.5s for a host-only > ~25M initramfs. No-host-only initramfs is about 3x bigger. If the size to > time relationship is linear, that's a chunk of extra time. Maybe there's a > way to improve the read performance in the bootloader to compensate? I don't see this as an obligatory choice - users should still be free to generate images locally instead. I'm certainly willing to do the work on performance calculations if there's no absolute objection to the idea. > Any expected hardware with TPM2 but without UEFI? Not on x86 - the PC client spec for TPM2 only covers UEFI. > If the first initramfs contains systemd, could systemd start things in > parallel while unpacking a second initramfs? The straightforward implementation involves the kernel unpacking all the initramfs archives before it starts init. In theory we could add functionality to the kernel to expose additional archives to userland rather than have the kernel unpack them, but that's not currently achievable - and it's one of those situations where we'd need to be very careful about ensuring there's no potential for races. > I take it you've found some liability with measuring a locally produced > initramfs? You'd need a trusted mechanism for passing the new initramfs measurements to whatever's verifying the measurements. That's not easy. -- Matthew Garrett | mj...@srcf.ucam.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Vague proposal: ship prebuilt initramfs images
Measured boot involves generating cryptographic measurements of boot components and configuration and using that to either control access to a local secret (in the case of sealing secrets to a TPM) or proving to another device (eg, a remote server or a local phone) what was booted. We're shipping most of the infrastructure to do this, but we're still left with a pretty fundamental problem - we need to know what the expected values are in order to know whether something's been tampered with or not. For many components this isn't a huge problem (we build and distribute the files - users can extract them and calculate the appropriate measurements, and maybe long term we'll be able to ship the measurements in a digestable way), but our initramfs images are generated on the user system and include system-specific data. This makes it impractical to know the expected measurements in advance. I've been thinking about ways to solve this for a while, and I'm coming to the conclusion that the best plan is probably to just ship pre-built initramfs images. I can think of three main reasons to want to use system-specific images: 1) They're smaller. By default we're already generating a generic image for rescue purposes, so disk space isn't the concern here - we're largely looking at losing boot speed. As machines have got faster this is probably not a huge deal. 2) They contain machine-specific configuration. Some of this can be passed on the kernel command line instead (eg, the machine ID), but we'd need answers for the rest. I can think of a couple of solutions: a) Stick the config in UEFI variables. It's small enough that we wouldn't run out. b) Extend grub to read some config files and synthesise an initramfs image for them. If we measure the paths that those images use then we don't need to worry about the contents as long as the tools that read the config can't be subverted via that configuration. 3) User customisation, such as including extra tooling. grub supports loading multiple initramfs images. Packages that right now install stuff in the initramfs could instead ship a prebuilt image that grub could append to the main initramfs. This would allow for things like overriding Plymouth themes, and we could ship the measurements for these pre-built images in order to allow them to be validated. Any thoughts on this? -- Matthew Garrett | mj...@srcf.ucam.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: TPMs, measured boot and remote attestation in Fedora
On Sat, Apr 23, 2016 at 02:57:55PM +0200, Kevin Kofler wrote: > Matthew Garrett wrote: > > Measured boot is a process whereby each component in the boot chain > > "measures" the next component. In the TPM 1.x world (which is where most > > of us still are), that measurement is in the form of a SHA1 hash of the > > next component. So, on a BIOS system, the firmware measures itself, the > > firmware measures its configuration, the firmware measures any option > > ROMs on plugin cards, the firmware measures the MBR of the disk, the MBR > > measures the grub stage 1, the grub stage 1 measures the grub stage 2, > > the grub stage 2 measures the kernel and so on. > > Yet another Treacherous Computing "feature" that nobody needs! I need to know if somebody has modified my firmware. > > Remote attestation is a mechanism by which a remote machine can request > > (but not compel) another machine to provide evidence of the PCR state. > > The TPM provides a signed bundle of information including the PCR values > > and the event log, and the remote machine verifies that the signature > > corresponds to the key it expected to see. > > How does the remote machine know that what is answering is a physical TPM > and not a software emulation? Does it need to have the individual TPM's > public key in advance? Three ways: 1) If you only care that it's *a* TPM, you validate the certificate chain from the endorsement key and ensure that it chains back to an intermediate certificate corresponding to a TPM vendor 2) If you care that it's a specific TPM, yes, you need to know the public key in advance 3) If you fall into (1) but it's socially unacceptable for you to demand a specific TPM key because that's a uniquely identifiable piece of data about the machine, you use a trusted privacy CA that validates (1) and then issues a new certificate In the general case, (1) is unacceptable for privacy reasons. (3) is impractical because nobody has actually built the privacy CA infrastructure. As a result, remote attestation is only practical in constrained corporate environments, not those where there's a risk to individual freedom. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: TPMs, measured boot and remote attestation in Fedora
On Thu, Apr 21, 2016 at 02:35:21PM +0200, Harald Hoyer wrote: > On 08.04.2016 18:56, Matthew Garrett wrote: > > initrd is certainly a more difficult one. One thing we can do is work on > > making dracut builds reproducible - that way they should be consistent > > across identical machines in a cluster. > > > > dracut already supports reproducible builds: > $ man dracut > […] >--reproducible >Create reproducible images. > > needs cpio with "--reproducible" support though Oh, wonderful! Is there a reason that isn't default in Fedora? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: TPMs, measured boot and remote attestation in Fedora
On Fri, Apr 08, 2016 at 11:36:33AM +0200, Florian Weimer wrote: > On 04/08/2016 10:28 AM, Matthew Garrett wrote: > > With what we now know about malicious actors targeting the system boot > > chain (even down to the firmware), this kind of TPM-based work is a > > vital part of helping keep our users secure. > > On the other hand, it can easily be abused to restrict user freedom. > For example, video streaming sites might not be willing to serve content > to users who cannot cryptographically prove they are running an approved > operating system with an approved browser. The practical issues around enforcing this kind of remote attestation have proven to be sufficiently intractable that literally nobody has ever ended up doing it (I thought Netflix had for ChromeOS devices - it turned out I was wrong). > Remote attestation only works with a trusted counterpart who rejects > access once a breach is detected. Who do you expect to be the > counterpart for Fedora users? Is there anyone who offers such a service > without also requiring to use their own operating system? Openstack has some support for this, although I wouldn't recommend using it. The setup I'm envisaging is for server deployments within a single administrative domain - this way it's entirely under the control of whoever controls the machines anyway. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: TPMs, measured boot and remote attestation in Fedora
On Fri, Apr 08, 2016 at 09:23:07AM +, Petr Pisar wrote: > I'm curious how you would predict hash of initramfs because it is > generated on the host and depends on dracut configuration and presence > of various optionally installed packages. initrd is certainly a more difficult one. One thing we can do is work on making dracut builds reproducible - that way they should be consistent across identical machines in a cluster. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: TPMs, measured boot and remote attestation in Fedora
On Fri, Apr 08, 2016 at 09:09:23AM +, Gregory Maxwell wrote: > The TPM style of remote attest is quite unfriendly to free software. > It puts basically the entire operating system in the trusted domain, > and you cannot change even a bit of it without "breaking the seal". > So if you want any use of remote attest at all, there is a huge swath > of your system which are are "compelled" under threat of loss of > access to whatever functionality remote-attest was providing to make > no modification-- or even, potentially, no upgrade to a very new or > less common version. Remote attestation is primarily useful within a single administrative domain. Outside that case it's far too easy to subvert (easiest approach: simply add a second TPM to your system and program whatever PCRs you want), and the privacy concerns remain sufficiently problematic that I don't see anybody pushing for it in the near future. > I think any time invested to make remote attest of any kind work would > better be spent on support for Intel SGX, which creates limited > remote-attestable sandboxes which (assuming Intel made no mistakes :) > ) have strong security and confidentiality regardless of what else is > running on the system. These sandboxes also have no outside access > except via limited channels, so (again assuming no mistakes/backdoors > on Intel's part); and the published security model is stronger (e.g. > encrypted ram) and more suitable for user-friendly uses (for example, > it would be straight-forward to use SGX to implement a bitcoin wallet > that could enforce user specified transfer limits, even against a > total security compromise of the host-- and if the RA part is as > usuable as it could be, even prove to third party auditors that your > keys have these security properties (the RA functionality for SGX is > not yet documented in public, AFAIK)). SGX has some interesting properties, but it's unhelpful in the rather more common case of "I'm running a bunch of servers and I want to know that they're trustworthy before I give them access to resources". Rearchitecting a large number of apps into a more SGXy world is a far from trivial task. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
TPMs, measured boot and remote attestation in Fedora
ware-level security. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?
On Tue, Apr 14, 2015 at 12:39:04AM +, Zbigniew Jędrzejewski-Szmek wrote: Yeah, hibernation is automatically invoked when battery runs low Is this actually the default behaviour? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Half-OT: Secure boot and thirdy party kernel modules
On Sun, Jul 06, 2014 at 02:10:45PM -0300, Sergio Belkin wrote: I've found that Oracle VirtualBox kernel module are not signed so I have to disable secure boot. Oracle says that is not a VirtualBox bug. And Fedora cannot sign it because of license, can it? Correct. You can generate your own key, enroll it with mokutil and then sign the modules with that key. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: libgcrypt soname bump in rawhide
On Thu, Jul 03, 2014 at 12:35:26AM +0800, Christopher Meng wrote: It's a burden for downstream to ship such a compat- package for chrome only, and chrome is not a part of Fedora. Maintaining software in general is a burden, but we do it for the benefit of our users anyway. The best case scenario would certainly be for Google to update their packages, but if they don't then how does rendering the package uninstallable benefit our users who want to install it? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: libgcrypt soname bump in rawhide
On Thu, Jul 03, 2014 at 01:20:26AM +0800, Christopher Meng wrote: On Thu, Jul 3, 2014 at 1:11 AM, Matthew Garrett mj...@srcf.ucam.org wrote: Maintaining software in general is a burden, but we do it for the benefit of our users anyway. The best case scenario would certainly be for Google to update their packages, but if they don't then how does rendering the package uninstallable benefit our users who want to install it? I don't think they don't if you could give google-chrome-unstable a try. I don't follow. My understanding was that all the Chrome builds were generic RPMs rather than tracking a specific branch of Fedora, so how does the rate of development releases do anything to help us get them to update their packages to build against a more recent gcrypt? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
On Thu, Jun 12, 2014 at 11:39:00AM +0100, Richard W.M. Jones wrote: grub2 ARM (32 bit) boots using u-boot. Aarch64 machines will boot using grub2 (or is that grub2-efi? - you know better than I do :-) This one's purely excluded from 32-bit ARM. The source package is grub2 regardless of the firmware interface used. (3) Out of 15000 packages, only about 100 don't build on ARM, and there are at most 50 missing bugs to fully comply with policy. I didn't go through the list of FTBFS to figure out whether there are other cases, but yeah, the situation certainly isn't dreadful. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Fri, Jun 13, 2014 at 01:50:32AM +0200, Kevin Kofler wrote: Matthew Miller wrote: Kevin, I disagree. A positive tone to discussion is important even when speaking the truth. There was no negative tone in Matthew Garrett's original message: If the Fedora/ARM community don't care about feature parity with x86, then we should just drop them back to secondary status. There was nothing impolite or insulting in there. It might be impopular with the ARM people, but it's still a valid point that had to be made, and shouldn't have been retracted. In context, there was absolutely an impolite tone - it confounded there being no interest in making a single package work on ARM with the Fedora ARM community having no interest in feature parity. These are not actually the same thing, and the fact that I equated them was inappropriate. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
On Wed, Jun 11, 2014 at 09:14:24AM +0100, Richard W.M. Jones wrote: This ought to improve greatly with 64 bit ARM, where Red Hat are pushing for everything to support UEFI booting and ACPI for hardware description. A single upstream open source kernel should [eventually] be able to boot on every aarch64 machine, even ones that have not been seen before. UEFI should be an improvement in this respect, but there's really no fundamental benefit to using ACPI rather than DTB for hardware description. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
On Tue, Jun 10, 2014 at 11:29:41PM +0100, Matthew Garrett wrote:
Ok, I was entirely unaware of that, and it does change things. Thanks
for letting me know. I'll look into whether it's practical to generate a
list of all the existing ExcludeArch packages and automatically check
whether they have tracker bugs filed - does that seem helpful? It
*would* be good to have meaningful metrics on this, but I don't want
there to be excessive process overhead.
I pulled git and have the following for ExclusiveArch: %{arm}:
gda
Agda-stdlib
amplab-tachyon
avgtime
avogadro
avro
clpeak
compat-gcc-32
compat-gcc-34
cqrlog
derelict
dustmite
dyninst
elk
floppy-support
ghc-ForSyDe
gl3n
glusterfs-hadoop
grub2
grub-customizer
gtkd
hadoop
hbase
hfsplus-tools
hive
hledger
jogl
joystick-support
keepass
ldc
liveusb-creator
Macaulay2
mcollective-qpid-plugin
numactl
numad
numatop
nwchem
ocaml-cil
ocaml-gsl
patchelf
perftest
perl-Alien-ROOT
perl-qpid
perl-SOOT
pig
pure
pure-glpk
pyode
qt-creator
root
rootplot
sbt
scilab
seamonkey
solr
sparkleshare
sys_basher
tango
urjtag
wine-mono
zfs-fuse
That's 60. In addition, the following packages are ExclusiveArch: in
such a way that ARM is left out but PPC support is claimed:
gprolog
mono-bouncycastle
nant
pvs-sbcl
xsupplicant
for a total of 65. Of those:
compat-gcc32
compat-gcc34
floppy-support
grub
grub-customizer
joystick-support
liveusb-creator
numactl
numad
numatop
seem entirely legitimate. That's 55 packages, several of which can be
blamed on a small number of missing dependencies.
That's git master. In F20 the number is about the same, which I'm going
to assume means that there were some fixes and around the same number of
excludes added.
(This ignores packages that are ExclusiveArch: %ix86 x86_64 because
that's probably unfair - if the maintainer genuinely believes that it
makes sense for the package to be x86 only then that's fair)
So, two conclusions from this:
1) People are very bad at following policy here. The majority of the
packages that are marked ExcludeArch: arm are not in the tracker bug,
and most of those don't appear to have a bug filed at all.
2) The rate at which things are being fixed appears to be uninfluenced
by (1) - the number of bugs on the tracker may have increased, but the
number of packages actually excluded on ARM hasn't. This means that I
was grossly overestimating how many packages were broken. I made an
assertion without collecting accurate data first, and came to the wrong
conclusion. I apologise for that.
I'll look at filing bugs against packages that don't appear to have bugs
filed, and I'll attempt to add them to the tracker where they exist but
aren't listed.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Tue, Jun 10, 2014 at 07:54:26AM +0100, Richard W.M. Jones wrote:
On Mon, Jun 09, 2014 at 10:20:46PM +0100, Matthew Garrett wrote:
On Mon, Jun 09, 2014 at 08:43:07PM +0100, Richard W.M. Jones wrote:
Can we excludearch %{arm} for this one?
Why? It's a bug that it doesn't build on ARM. Refusing to build it
doesn't fix the bug, and then someone else will crash into the same
issue when they dare to build something that needs llvm.
It seems the alternative is hfsplus-tools doesn't work at all for
anyone.
Eh. We're constrained by our own policies here, not by anything
fundamental - LLVM being broken on ARM ought to mean that our ARM
product is worse, not that everything else is dragged down to the same
level.
BTW this package is also affected by the -fstack-protector-strong LLVM
bug, but that is simple to work around.
Yeah that complaint is completely fair.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Tue, Jun 10, 2014 at 05:23:01PM +0100, Richard W.M. Jones wrote:
On Tue, Jun 10, 2014 at 03:45:57PM +0100, Matthew Garrett wrote:
Eh. We're constrained by our own policies here, not by anything
fundamental - LLVM being broken on ARM ought to mean that our ARM
product is worse, not that everything else is dragged down to the same
level.
So .. ExcludeArch %{arm} should be added? I'm not clear what you're
saying here.
ExcludeArch implies that it's acceptable that it doesn't build on ARM
and removes the incentive for anyone to fix it. It's not.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Tue, Jun 10, 2014 at 06:14:03PM +0100, Richard W.M. Jones wrote: On Tue, Jun 10, 2014 at 06:00:05PM +0100, Matthew Garrett wrote: ExcludeArch implies that it's acceptable that it doesn't build on ARM and removes the incentive for anyone to fix it. It's not. There's a process for handling this, which is to create (if required) a Fedora bug for the package, and then attach it to this tracker: https://bugzilla.redhat.com/show_bug.cgi?id=F-ExcludeArch-ARM Then add ExcludeArch to the package, mentioning the particular bug. I've never seen this actually result in the bug being fixed in leaf packages. I'm going to go ahead and do this now, since otherwise we won't have hfsplus-tools at all for any user. This is inappropriate. The bug is in LLVM, not hfsplus-tools. Quoting from the guidelines: ExcludeArch should only be set when the architecture is not relevant for the package, the package is non-functional on the architecture, or the code does not compile cleanly for the architecture. The code compiles fine, LLVM then fucks up linking. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Tue, Jun 10, 2014 at 06:34:31PM +0100, Richard W.M. Jones wrote: The bug that I'm actually fixing is that we haven't had a successful hfsplus-tools build in nearly a year. Ok. Once the build's done let's remove the ExcludeArch so it continues to show up as a failure in mass builds. It can be restored if we actually need to make any code changes. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Tue, Jun 10, 2014 at 06:44:06PM +0100, Richard W.M. Jones wrote: On Tue, Jun 10, 2014 at 06:39:52PM +0100, Matthew Garrett wrote: Ok. Once the build's done let's remove the ExcludeArch so it continues to show up as a failure in mass builds. It can be restored if we actually need to make any code changes. Where is the Fedora policy that we should break builds so that we can collectively remember there is a bug in a particular architecture? That's what Bugzilla is for. Having it show up on the FTBFS list sparked a discussion that noted upstream movement on this. If it hadn't been there we wouldn't have noticed, and even once LLVM is fixed this would probably have remained ExcludeArch: arm. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Tue, Jun 10, 2014 at 07:05:56PM +0100, Richard W.M. Jones wrote:
In this case however I don't think much productive came from this
discussion we had about hfsplus-tools. Obviously no one wants
hfsplus-tools and/or clang enough on Fedora/ARM that they are prepared
to fix it. So I think we should just drop it on ARM, and let anyone
who wants it, fix it later (or reenable %{arm} if clang gets fixed).
If the Fedora/ARM community don't care about feature parity with x86,
then we should just drop them back to secondary status.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
ExcludeArch tracker doesn't appear to be effective
https://bugzilla.redhat.com/show_bug.cgi?id=485251 is depressing. Nine bugs have been closed - of these, one is a review request that was dropped, two were incorrectly closed after an ExcludeArch was added and one was closed as a duplicate. Further, one bug was just unsubscribed from the tracker after tests were disabled. We've correctly fixed *five* packages that have been flagged as FTBFS on ARM. At this rate of fixing, and given the rate at which new bugs are added, ARM will never build the entire archive. Fedora is supposed to provide a consistent experience across primary architectures. Having a subset of our packages fail to build on ARM means that's not true, and the current state of affairs clearly violates point 8 of the architecture promotion requirements. How can we fix this? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Tue, Jun 10, 2014 at 07:11:53PM +0100, Matthew Garrett wrote:
On Tue, Jun 10, 2014 at 07:05:56PM +0100, Richard W.M. Jones wrote:
In this case however I don't think much productive came from this
discussion we had about hfsplus-tools. Obviously no one wants
hfsplus-tools and/or clang enough on Fedora/ARM that they are prepared
to fix it. So I think we should just drop it on ARM, and let anyone
who wants it, fix it later (or reenable %{arm} if clang gets fixed).
If the Fedora/ARM community don't care about feature parity with x86,
then we should just drop them back to secondary status.
That was overly critical of me and did nothing to actually further the
discussion. I apologise.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Improving the state of ARM
On Tue, Jun 10, 2014 at 07:05:56PM +0100, Richard W.M. Jones wrote:
In this case however I don't think much productive came from this
discussion we had about hfsplus-tools. Obviously no one wants
hfsplus-tools and/or clang enough on Fedora/ARM that they are prepared
to fix it. So I think we should just drop it on ARM, and let anyone
who wants it, fix it later (or reenable %{arm} if clang gets fixed).
Let me try this again. The aim is for Fedora to provide an experience
that's consistent across primary architectures to the extent that is
reasonably possible. If people don't care about that, we have a problem.
The nature of that problem depends on who is failing to do the caring:
1) If the ARM maintainers don't care about ARM being equivalent to x86,
that's a serious problem that is (with luck) easily fixable. On the
other hand, if they care but don't have sufficient resources to fix
things, that's a smaller problem but probably less easily fixed,
because:
2) If individual package maintainers don't care about ARM, there's
really not a lot we can do. They weren't involved in the decision to
make ARM primary. They probably don't plan on installing Fedora on any
ARM systems, so they gain no personal benefit from fixing it. What kind
of incentives can we provide? Threaten to drop their packages? That
would provide consistency, but it ends up being a rather limiting
strategy.
Honestly the most practical solution would seem to be a concerted effort
from the ARM team to fix these up - the assumption that individual
package maintainers will take care of things isn't realistic. But given
that they're busy getting arm64 into a good state, I don't know how
reasonable that is given the available resources.
I think there's a real problem if ARM continues to languish behind x86's
feature set, and I think it's realistic to ask whether that problem is
sufficiently serious for demoting it. But that's clearly not the most
desirable outcome, and so I'd really prefer us to figure out a way to
fix things. Improving code portability benefits us, our users and the
ecosystem as a whole.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
On Tue, Jun 10, 2014 at 09:12:35PM +0100, Peter Robinson wrote: So at the moment there's around 15,000 source packages in Fedora mainline and you're getting depressed over exactly 24 of them? I'm not sure how 24 packages is providing a inconsistent experience. In some cases the maintainer of the package hasn't bothered to close the bug when support was added, in some cases ARM was added incorrectly. For example just before mass rebuild we added Ada support which closed out around 2 dozen other packages we didn't build prior. What's depressing is the trend, not the absolute count. I'd expected it to head rapidly towards zero after the first release, but instead it's still growing. Ultimately I fail to see how missing 20 odd packages out of 15,000 odd fails to provide a consistent experience across primary architectures so if there's something more specific and constructive you'd like to provide it would be useful or is this just a random rant because your bored? Anyone who has a usecase that relies on one of those packages will have an inconsistent experience if they attempt to reproduce it on ARM. That's harmful. It makes us look bad. It gives the appearance that we're willing to release a worse product simply in order to claim ARM support. Ultimately we've been working hard to provide as consistent environment on ARM as possible and improving all the time and all you seem to do is randomly come in Magpie style and shit on something without any other visible involvement in the ARM process or community or any context and pick on something of random like a bully. If you've got constructive criticism feel free to engage properly to assist us in improving and coming up to your exacting standards but this means of bullying tactics isn't the way to do it. I don't think the current state of the ARM port is good enough. That's not a reflection on the people involved. That's not a criticism of the amount of effort that's been made. I just want to know how we can get from where we currently are to where we want to be. Individual package maintainers seem happy to just add an ExcludeArch, maybe file a bug against upstream and then forget about the issue. Given a lack of direct incentive for them to care about ARM, that's not terribly surprising. What can we do about that? Is the only realistic answer to find the resources to have a team to hunt down and fix portability issues that are sufficiently far from the core that the existing ARM community can't justify the time? And if so, is there any way we can make that happen? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
On Tue, Jun 10, 2014 at 09:49:58PM +0100, Peter Robinson wrote: What's depressing is the trend, not the absolute count. I'd expected it to head rapidly towards zero after the first release, but instead it's still growing. Is it? Where's your proof? From the patches and dealings with it personally that's not my understanding and if it is the case it's not due to the ARM team but because packagers aren't following the packaging process and in this case we actively fix them when we're made aware of the incident. In the past 6 months, 6 bugs added, 2 bugs closed - https://bugzilla.redhat.com/show_activity.cgi?id=485251 . Anyone who has a usecase that relies on one of those packages will have an inconsistent experience if they attempt to reproduce it on ARM. That's harmful. It makes us look bad. It gives the appearance that we're willing to release a worse product simply in order to claim ARM support. And if they engage with us about that experience we do our best to deal with them where possible. There's a few cases where I'm aware of that we don't package because the HW is actively not supported on ARM or similar style cases. In those cases I would argue that it's better not to build the packages as arguably no experience is better experience than a bad experience especially if there's potential of issues that offer a worse experience, hardware breakage or data corruption. The fact is that the x86 and ARM use cases don't match up 100% and I don't see the point in trying to glue those together 100% for the sake of a check box. Where there's reliance on specific hardware functionality that's absent then yes, absolutely, there's no benefit in building the packages. Figuring out how to communicate that to users isn't an entirely solved problem, but with luck nobody's actually buying ARM hardware with unrealistic expectations of its functionality. But I can't find any examples of those in the tracker. They all seem to be cases where packages are either missing dependencies, take too long to build or are just missing support. They're code. We can fix them. I don't think the current state of the ARM port is good enough. That's not a reflection on the people involved. That's not a criticism of the amount of effort that's been made. I just want to know how we can get from where we currently are to where we want to be. Well why didn't you say that from the start rather than coming in and bullying the people actively involved and make them feel like the massive effort myself and many others have been putting in is useless and a waste of time. Don't be a Magpie Board Member and fly in and shit over everything and than fly awau with no concept of what's happening below. Every time you've had any attempt at opinion that's the way you've done it and all you do is get all our backs up and make the problem worse rather than better. I'm genuinely sorry if I gave the impression of bullying here. I want to feel comfortable pointing at the ARM port as an equal to the x86_64 one. I don't feel entirely comfortable doing so at the moment, and the current process doesn't seem to be getting us to the point where I would be. Individual package maintainers seem happy to just add an ExcludeArch, maybe file a bug against upstream and then forget about the issue. Given a lack of direct incentive for them to care about ARM, that's not terribly surprising. What can we do about that? Is the only realistic answer to find the resources to have a team to hunt down and fix portability issues that are sufficiently far from the core that the existing ARM community can't justify the time? And if so, is there any way we can make that happen? I'm not sure I agree with your outline here, you've given no real concrete examples here. I agree there's no real incentive but there's over 15,000 source packages in Fedora and there's less than 100 (last time I looked, unfortunately there's no easy way off checking this without downloading the entire src.rpms or checking out all 15K git repos) or so excluded from ARM and the vast majority of those are due to HW support. There's some like D where upstream has yet to port the stack. I'm sure there's others I'm unaware of but it's not because of the ARM team but rather the packager following procedures or engaging us for assistance. The quantity of the archive that's built and working on ARM so far is a testament to the amount of effort that the ARM community have put into this port. The question is how to finish that. All I'm saying here is that the current approach of filing bugs doesn't appear to be resulting in people actually fixing their packages. It's unreasonable to expect you to do all of it. So what do we do? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
On Tue, Jun 10, 2014 at 10:52:19PM +0100, Peter Robinson wrote: On Tue, Jun 10, 2014 at 10:20 PM, Matthew Garrett mj...@srcf.ucam.org wrote: In the past 6 months, 6 bugs added, 2 bugs closed - https://bugzilla.redhat.com/show_activity.cgi?id=485251 . If you're going on just the bug tracker possibly but there's a lot of stuff we fix and enhance that doesn't even make the that tracker, the Ada stuff I mentioned earlier is but one example. Rightly or wrongly it's not the canonical source of information. For example if I discover an exclude arch I'll generally just go and fix it rather than spending the time to open a bug, fix it myself and then close it myself. Just go and read the rawhide reports. If that's what you want us to do to give a warm fuzzy feeling of progress I don't see it as a time effective agile way of necessarily dealing with it. Feel free to suggest alternatives :-) Ok, I was entirely unaware of that, and it does change things. Thanks for letting me know. I'll look into whether it's practical to generate a list of all the existing ExcludeArch packages and automatically check whether they have tracker bugs filed - does that seem helpful? It *would* be good to have meaningful metrics on this, but I don't want there to be excessive process overhead. Where there's reliance on specific hardware functionality that's absent then yes, absolutely, there's no benefit in building the packages. Figuring out how to communicate that to users isn't an entirely solved problem, but with luck nobody's actually buying ARM hardware with unrealistic expectations of its functionality. But I can't find any examples of those in the tracker. They all seem to be cases where packages are either missing dependencies, take too long to build or are just missing support. They're code. We can fix them. Are you offering to do so? For example some time ago I approached one of the root maintainers (comes out of CERN I believe) and they said they didn't see the point nor have the time to maintain anything other than x86 at this time. Should we fork it and support it just to say we're feature complete with x86 just because it's code? Well maybe, but I'm not sure in that case it would add value to the distro for the expenditure of time and we've had exactly zero enquires about it (and it's 3 dependencies in the tracker). In the case of Hadoop there might possibly be value (and in later releases the issues might even have been fixed) but again we've had no queries and so we've focused on things people want. In the case of Ada we had some requests for support since F-20 was released so we've added that for F-21. Yeah, I think where it's practical for us to maintain feature compatibility we should do so even if upstream disagree. We make modifications to upstream code all the time in order to meet Fedora policy. As for who should be doing that work - well, yeah. That's kind of my point. Responsibility for this kind of thing is really something we should have figured out prior to promotion, and I'm sorry that I didn't think about it in a more timely manner. I'm looking for answers here, not insisting that anyone take on more work. I'm genuinely sorry if I gave the impression of bullying here. I want to feel comfortable pointing at the ARM port as an equal to the x86_64 one. I don't feel entirely comfortable doing so at the moment, and the current process doesn't seem to be getting us to the point where I would be. Well you need to engage with us better. Every time you make an appearance it appears to us all it's just to bully us. People genuinely shudder when your nick appears on on the channel and I've had 3 people thank me for replying so they don't have to. That's unfortunate. I'm sorry. I'll try to ensure that I'm interacting in a more productive way. So moving on from that why don't you feel comfortable pointing to the ARM port? I'm aware we're still not perfect but it was always going to be a road to improvement. Basically that you're still not perfect, to the extent that anything in Fedora is. I'd have been significantly happier if more time had been spent on, for instance, Anaconda before ARM was promoted. But realistically there's obviously a tension between perfectionism and maintaining enthusiasm - especially with the longer F21 cycle, I suspect the right decisions were made at the time. We're supporting massively more hardware now than we were at F-20 release time and the types of HW are getting better with the likes of the Tegra K1 supporting full desktop equivalent graphics and we might even have the support for that upstream in time for F-21 release, the open graphics drivers are improving that they might be usable in that timeframe too. Those were problems that were well known when we went to primary and the path is basically what was agreed and mapped out in that regards. The work that's been done
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Wed, Jun 11, 2014 at 01:53:12AM +0200, Kevin Kofler wrote: Matthew Garrett wrote: Eh. We're constrained by our own policies here, not by anything fundamental - LLVM being broken on ARM ought to mean that our ARM product is worse, not that everything else is dragged down to the same level. Didn't YOU vote for ARM as a primary architecture, and even actively lobby for it? Now you get to pick the (poisoned) fruit… Er. No? I think you're confusing me with someone else. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Mon, Jun 09, 2014 at 05:07:14PM +0100, Richard W.M. Jones wrote: On Sun, Jun 01, 2014 at 11:24:09AM +0200, Till Maas wrote: hfsplus-toolsajax, ajax Just to be clear, is hfsplus-tools still at risk of being removed or not? It's required in order to build x86 install images, so not really. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Mon, Jun 09, 2014 at 08:43:07PM +0100, Richard W.M. Jones wrote:
Can we excludearch %{arm} for this one?
Why? It's a bug that it doesn't build on ARM. Refusing to build it
doesn't fix the bug, and then someone else will crash into the same
issue when they dare to build something that needs llvm.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Considering GNOME 3.12 as an F20 update
On Thu, Apr 03, 2014 at 10:20:30AM -0400, Matthias Clasen wrote: Did any of your gnome-shell extensions break ? Isn't this inevitable? If any extensions only claim to support 3.10 then they'll stop working until updated. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Considering GNOME 3.12 as an F20 update
On Thu, Apr 03, 2014 at 04:57:10PM +0200, Miloslav Trmač wrote: 2014-04-03 16:52 GMT+02:00 Matthew Garrett mj...@srcf.ucam.org: Isn't this inevitable? If any extensions only claim to support 3.10 then they'll stop working until updated. One, at least theoretical, way to resolve this would be to update all extensions hosted at extensions.gnome.org to support 3.12. Don't the extensions end up in the user's home directory? How can we forcibly update them? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Considering GNOME 3.12 as an F20 update
On Thu, Apr 03, 2014 at 11:11:58AM -0400, Stephen Gallagher wrote: One option we could look into would be for GNOME to set this option on by default for a month or so to give extension authors time to catch up while not breaking any user extension that works unmodified. My understanding was that there was no mechanism for automatically updating extensions at present. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: lbzip2 as default bzip2 implementation
On Wed, Apr 02, 2014 at 05:14:53PM -0400, Al Dunsmuir wrote: This implementation has been built and extensively tested using the current release of the real bzip2 library. Substituting a completely different library implementation without going through extensive and explicit validating and testing is risky and unreasonable. At best, it would complicate problem reporting, reproduction, analysis and correction. The suggestion is to replace the tool, not the library. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Help understanding Anaconda source - walk through needed.
On Mon, Mar 24, 2014 at 07:21:51PM +, Aaron Gray wrote: The HP Dl140 G3 has MCA based graphics. F20 seems to be mainly fixed apart from MCA based Anaconda, which gets the resolution wrong, the screen being too small for the Anaconda graphics. VESA setup mode works fine however. Ah. You mean MGA, not MCA. It's entirely possible that there's a bug in the mgag200 driver that's resulting in a failure to get the correct EDID, but that's a kernel bug rather than an anaconda one. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Fri, Mar 14, 2014 at 06:25:03AM -0400, Jan Lieskovsky wrote: One hypothetical [*] scenario coming to my mind being the users might be willing to provide customized policy content to Fedora installation. Let's suppose the case there is a SCAP content for vulnerability checking (and ensuring some restrictions) for Fedora systems. Something like is done for Red Hat Enterprise Linux case: https://www.redhat.com/security/data/metrics/ This seems pretty niche. The cost associated with it is UI that makes no sense to most users but is presented to them by default anyway. I think we should concentrate on finding a way to make this possible without compromising the common case. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Fri, Mar 14, 2014 at 09:25:16AM -0400, Eric H. Christensen wrote: I disagree with this assessment. The workstation is exactly where much of these hardening needs to take place. I can't see an installation that wouldn't benefit from this feature. If there's a default policy that would make sense for most workstation users, we should just make that the default. If there isn't, how are we going to educate users as to which choice they should be making? *I* don't understand the terms used in the proposed UI, so I'd be willing to put money on the number of potential users who do being pretty close to statistically indistinguishable from 0. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Fri, Mar 14, 2014 at 12:38:59PM -0400, Jan Lieskovsky wrote: I am afraid there isn't a default policy that would suit every possible use case Fedora OS can be used at. Yes, there's something like common understanding / agreement which technologies can be considered safe at current level of (security) knowledge (i.e. that certain cryptographic algorithms should be preferred for usage before the others etc.) selinux doesn't suit every possible use case that Fedora supports either. But we still default to it being enabled with a targeted policy and provide no installer UI to let people change that. But the current Fedora defaults approach has one limitation - even when we set up the defaults reasonable enough, there is possibility users can return back to the use of less secure ways (example how many users are still using telnet or rsh today?) Well, yes. If you're deploying in an environment where you want to make it impossible for users to disable security features, you shouldn't be allowing those users to choose their own security policy. That's not an argument for putting it in the installer UI. If there isn't, how are we going to educate users as to which choice they should be making? We can do the following (three alternatives comes to mind): * use sane defaults, allow the less secure ones (if I am not wrong this is the current approach), Yes, a user can edit /etc/selinux/config to disable selinux. They can also modify the mmap_min_addr sysctl. But we don't offer those choices in the installer, because there's no way that most users are going to be able to make an informed decision about what these values should be set to or what the associated compromises are. *I* don't understand the terms used in the proposed UI, Can you be more concrete which term(s) you don't understand? Maybe you are right and the concept needs to be better explained / presented differently prior wider adoption [**]. What is a Data stream? What is a Checklist? How do I know which ones to pick? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Fri, Mar 14, 2014 at 02:51:10PM -0400, Steve Grubb wrote: On Friday, March 14, 2014 03:00:20 PM Matthew Garrett wrote: If there's a default policy that would make sense for most workstation users, we should just make that the default. Right now there is just one policy. In there future there could be several. I could see a server specific, workstation specific, virt specific, PCI, USGCB, STIG, common criteria, etc. Having separate server, workstation and cloud products means we can apply separate defaults without requiring user interaction. Beyond that, why would an end user want to choose common criteria during an interactive install? Isn't that something that should be imposed on them by their local admin? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Fri, Mar 14, 2014 at 02:57:33PM -0400, Steve Grubb wrote: On Friday, March 14, 2014 06:53:42 PM Matthew Garrett wrote: Having separate server, workstation and cloud products means we can apply separate defaults without requiring user interaction. Beyond that, why would an end user want to choose common criteria during an interactive install? Isn't that something that should be imposed on them by their local admin? Yes, and I believe the kick start would do that. I would also even see a case where an admin takes the base policy and tailors it with site specific settings and puts that into effect instead of the default one we provide. I like the idea of choice. Exactly, this is functionality that makes sense for enterprise and automated deployments. I don't see it making sense for an interactive install. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Fri, Mar 14, 2014 at 02:39:51PM -0400, Eric H. Christensen wrote: On Fri, Mar 14, 2014 at 03:00:20PM +, Matthew Garrett wrote: If there's a default policy that would make sense for most workstation users, we should just make that the default. If there isn't, how are we going to educate users as to which choice they should be making? *I* don't understand the terms used in the proposed UI, so I'd be willing to put money on the number of potential users who do being pretty close to statistically indistinguishable from 0. I'm all for creating a recommended hardening policy that users can opt into at install time. This feature would allow us to provide that kind of data to the end user. If the user decides to not implement a policy that would simply yield the same outcome as we have today. How does the average user make an informed decision about whether an available security policy is appropriate for them? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Fri, Mar 14, 2014 at 03:06:06PM -0400, Eric H. Christensen wrote: You're making an assumption that I wouldn't want my personal box to be hardened at install or that the enterprise has an automated way of doing a deployments. Why make it harder to use the operating system when a simpler way of configuration has been suggested? I'm making the assumption that you, as someone with sufficient knowledge of the field to make an informed choice, are capable of performing additional steps in order to ensure that your system meets additional security criteria. The feature isn't going to be a massive change to the UI and only adds to the awareness that users have a choice on how hardened their system is at install time. Whether you chose to use it is your business. It's not going to be a massive change? It's an entire additional spoke in the UI. That *is* a massive change. Users will click on it. Users will be confused by it. They'll choose inappropriate options and then complain that their software doesn't work, and then they'll either take resources from our limited support pool or give up and install something else instead. The job of the installer is to make it as easy as possible for the user to end up with a working system. Adding options that make it straightforward for the user to end up with a non-working system is a backwards step. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Fri, Mar 14, 2014 at 03:41:30PM -0400, Eric H. Christensen wrote: On Fri, Mar 14, 2014 at 07:31:55PM +, Matthew Garrett wrote: How does the average user make an informed decision about whether an available security policy is appropriate for them? I guess we'll have to describe the different policies and provide approprate documentation/education. You know, pretty much how we get users to understand whether or not they should encrypt their hard drives or assign the first user as an administrator or anything else they do with their computer. The failure mode of making the wrong choice regarding an encrypted partition or the default user being an administrator involves the system *continuing to work*. The failure mode of making the wrong choice regarding security policy is that things you expect to work mysteriously don't. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Fri, Mar 14, 2014 at 03:56:47PM -0400, Eric H. Christensen wrote: On Fri, Mar 14, 2014 at 07:45:53PM +, Matthew Garrett wrote: The failure mode of making the wrong choice regarding an encrypted partition or the default user being an administrator involves the system *continuing to work*. The failure mode of making the wrong choice regarding security policy is that things you expect to work mysteriously don't. What exactly do you think would be done with one of these policies? You seem to think that an incorrect choice will brick a system. If an incorrect choice means that the software the user wants to run won't run, that's going to be a problem for the user. And we presumably expect that some software won't run, because otherwise we'd be enabling that security feature by default? A user who accidentally installs a profile that enables FIPS compliance is going to have a bad time, for instance. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Fri, Mar 14, 2014 at 06:24:36PM -0400, Eric H. Christensen wrote: On Fri, Mar 14, 2014 at 08:01:53PM +, Matthew Garrett wrote: If an incorrect choice means that the software the user wants to run won't run, that's going to be a problem for the user. And we presumably expect that some software won't run, because otherwise we'd be enabling that security feature by default? A user who accidentally installs a profile that enables FIPS compliance is going to have a bad time, for instance. No, that's not exactly it. I've pointed out reasons why defaults usually suck (security-wise). I've yet to see a hardened system make software fail. I'd love some examples of your concerns. I also don't understand why FIPS compliance will make a user have a bad time since I've been on systems that were fully FIPS compliant and didn't have any problems. You don't think it would upset users to have their kernel panic if they accidentally tried to load an inappropriately signed module? What happens if I ssh to a server that doesn't implement any of the FIPS-approved algorithms? Why is Firefox suddenly asking for a password before I can visit https sites? Why won't Firefox speak https to a bunch of sites? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
How would this alter the default user installation experience? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Thu, Mar 13, 2014 at 01:40:53PM -0400, Jan Lieskovsky wrote: Of course, in the case they wouldn't like to configure any security policy and use just vanilla Fedora installation, the can ignore the security section, configure just those sections as configured (required to be configured) now (e.g. INSTALLATION SOURCE, SOFTWARE SELECTION etc.), and click the Begin Installation button. In that case no security profile would be applied. The demos seem to cover the case where there's already data provided from the Kickstart file. What options are presented to the user if there's no oscap entry in Kickstart? Is the user expected to provide a path to download a policy? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Thu, Mar 13, 2014 at 02:45:58PM -0400, Jan Lieskovsky wrote: The demos seem to cover the case where there's already data provided from the Kickstart file. What options are presented to the user if there's no oscap entry in Kickstart? Is the user expected to provide a path to download a policy? Yes, there are two ways how to provide the policy - either via kickstart or via GUI by entering the HTTP / FTP URI [*] of the policy (in RPM package format) and clicking the Fetch data button. Ok. I'm kind of struggling to imagine the scenario where a user actually wants to do that. What's the use-case for providing UI rather than limiting deployment to Kickstart? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Out of virtual memory on ARM builder
On Fri, Feb 14, 2014 at 04:00:09PM -0600, Mátyás Selmeci wrote: This may be a stupid question, but can you solve this by putting more swap on those builders? It depends. If the system is sufficiently resource constrained that malloc() is actually telling you that you're not going to the moon, more RAM will help. But what's more likely is that it's running out of process address space - a 32 bit process can only address 3GB of address space (which isn't necessarily all RAM), no matter how much RAM is available[1]. Adding more RAM isn't going to help there. Getting rid of 32-bit build systems is. [1] On x86, anyway. I don't know what the ARM VM split is. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: f20, anaconda, net install and video out of range ....
On Fri, Feb 07, 2014 at 11:19:38AM -0500, Paul Wouters wrote: On Thu, 6 Feb 2014, Adam Williamson wrote: painstakingly hand-weeding something like M*a's ldetect-lst you can get some minor benefits, like doing this kind of distinction where we want to load the native driver for a real card but not qemu's emulated cirrus. You are telling me it is hard to detect the real physical card versus the emulated card? Come on! You can even make that decision by looking at the cpu type. If your cpu is QEMU Virtual CPU, how about using the virtual cirrus driver Oh, that's not difficult - it'd be possible to make the cirrus driver bail on virtualised hardware (easy to detect, just check whether there's a KMS driver bound). But that would still require someone to care about maintaining the cirrus driver, which nobody does. Taking out everyone who tries to run fedora or rhel7 using a physical cirrus card IMHO is just sloppy and lazy. Yes, people still run P-III servers with SCSI disks and cirrus cards. In fact, I think you will see it more within the enterprise then outside it. As Adam points out, nobody's running RHEL7 on a physical cirrus card. However, we'd still expect the vesa driver to work, and the fact that it doesn't is a bug[1]. Nobody ever added exa support to Cirrus, so it's not like you'd see any meaningful difference in performance. [1] I mean plausibly it's a bug in this particular Cirrus video BIOS, but it'd be nice to actually figure that out. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, Feb 04, 2014 at 04:18:27PM -0700, Chris Murphy wrote: Does anyone know why the convention is to create the ESP as the first partition? Because that's the only configuration anyone's likely to have tested. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, Feb 04, 2014 at 02:45:29PM -0800, Andrew Lutomirski wrote: On Tue, Feb 4, 2014 at 2:41 PM, Adam Williamson awill...@redhat.com wrote: You're making a fatal mistake: assuming some kind of sense on the part of firmware authors. ;) Not really -- I figure that either the firmware is only parsing the protective MBR (in which case the existence of an ESP won't even be detectable) or that the firmware actually supports UEFI, in which case I'd be fairly impressed if it matters. You're missing the not uncommon case of UEFI firmware with CSM forcibly enabled and no UEFI boot option which was much of the market between 2009 and 2011. These implementations will frequently understand GPT well enough to decide that a disk isn't BIOS bootable, but won't let you perform a UEFI boot instead. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, Feb 04, 2014 at 04:42:23PM +0100, Jochen Schmitt wrote: On Mon, Feb 03, 2014 at 08:14:06PM -0800, Andrew Lutomirski wrote: (This is a particular pain point for me -- my main development box was originally installed as BIOS, and I switched it to UEFI, and I'm sure I did it wrong because the boot process is impressively finicky.) If your hard disc is GPT partition the movement from BIOS to UEFI boot shoot be very easy. You have to install grub2-efi and create the configuration file on /boot/efi/EFI/fedora/grub.cfg. …and configure the UEFI boot options, which you can't do because you're not running under UEFI and so have no access to UEFI runtime services. The workarounds required for this will tend to be vendor specific, although ensuring that you have the fallback loader supplied by shim may work in many cases. 3.) On my MacBoot Pro (late 2013) I required the usage of the linux16/initrd16 commands instead of linux/initrd commands for the BIOS-mode boot. Yeah it's really a mistake for us to be using the linux/initrd commands under any circumstances. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, Feb 04, 2014 at 10:30:58AM -0800, Andrew Lutomirski wrote: On Tue, Feb 4, 2014 at 10:19 AM, Chris Murphy li...@colorremedies.com wrote: On Feb 4, 2014, at 10:42 AM, Andrew Lutomirski l...@mit.edu wrote: I think that half the difficulty here is that UEFI is annoying and the other half is that both GRUB2 and efibootmgr are miserable. For single OS installs, you shouldn't have to interact with any of those things. shim.efi, or shim via fallback.efi (?) will even do a fallback boot of Fedora if NVRAM has somehow been vanquished. How does firmware find shim.efi? Is it installed as bootx64.efi? IIRC that approach used to be frowned upon. It installs a fallback loader as bootx64.efi which then creates new boot entries for any installed operating systems it can find. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, Feb 04, 2014 at 11:49:06AM -0800, Andrew Lutomirski wrote: What failed? I'm guessing that userspace improvements since then have mostly fixed this. I've never seen any problem on F18 (IIRC) and up with GPT partition tables being BIOS-booted. It seems to Just Work (tm). Some firmware sees a GPT label and refuses to even attempt a BIOS boot. We tried this back in F16, tried further by violating the spec as it stood at the time and marking the protective MBR bootable and discovered that there are still systems where this just doesn't work. Also, isn't this already sort of necessary on large disks? There's not really anything else we can do in that case, so we make a best effort and if it doesn't work then, well. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: I want to turn on a part of the kernel to make SELinux checking more stringent.
On Sun, Jan 26, 2014 at 08:38:25PM +, Richard W.M. Jones wrote: JONESFORTH, a public domain FORTH I wrote, is written in x86 assembler and prefers to put its threaded interpreter at address 0. Can you change its preference? Permitting the mapping of executable code at address 0 makes it much easier to exploit null pointer vulnerabilities in the kernel. Recent (within the past few years…) kernels will refuse to let you mmap stuff below 64K or so regardless of selinux policy, so this may break on other distributions as well. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Mon, Jan 20, 2014 at 10:08:01AM +0100, Hans de Goede wrote: So now it is time to start looking into some of the corner cases, or rather at the elephant in the room. What about non-kms drivers. We still have the vesa driver around as most prominent example, and this is useful for some oddball cards and for cards which are too new. -mga is probably also still relevant in some small number of cases. We can probably kill -cirrus. That would leave -openchrome, which I think is probably only really relevant for OLPC? What's the situation with the binary nvidia and amd drivers? I would like to not break the vesa driver, while still killing the suid bit on the X server. It's probably worth considering whether porting uvesafb to kms would be worthwhile, and then just using -modesetting. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Mon, Jan 20, 2014 at 04:48:55PM +0100, Hans de Goede wrote: Hi, On 01/20/2014 03:18 PM, Matthew Garrett wrote: -mga is probably also still relevant in some small number of cases. Don't we've a kms driver for those? Or you mean for mga cards not supported by the kms driver? The KMS driver only supports the g200 cores embedded in some server chipsets, it doesn't handle real hardware. We've already dropped 3D support for those chips, though, so it's arguably not of great importance. The only real difference in functionality by dropping -mga would be losing multihead support, and I don't think anyone ever made that work on the UMS driver without the HAL blob. We can probably kill -cirrus. That would leave -openchrome, which I think is probably only really relevant for OLPC? What's the situation with the binary nvidia and amd drivers? Oh, I completely did not think about the binary drivers yet. Ugh. AFAIK those are not compatible with kms, so the helper for other ums drivers would just do the right thing there since there would be no kms capable card to be found in /dev. The binary drivers don't need iopl(), so the only real question is whether they need root for anything else. It may just be permissions on device nodes, in which case we can probably just special-case them? It's probably worth considering whether porting uvesafb to kms would be worthwhile, and then just using -modesetting. Yes that is something I was thinking about too, that would be an interesting approach, it would make it somewhat harder for people to use binary drivers, but not impossible. I don't see it being any harder than the blacklisting of nouveau/radeon that's already required. And then we could simply forget about supporting ums at all I guess. That would be certainly be a glorious flying-car future. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Mon, Jan 20, 2014 at 03:58:23PM +, Richard W.M. Jones wrote: On Mon, Jan 20, 2014 at 02:18:22PM +, Matthew Garrett wrote: We can probably kill -cirrus. qemu? (I know that people should be using QXL, but cirrus is still the default in plain qemu, and IMHO simpler and more secure.) We have KMS support for the qemu cirrus, so you can just use -modesetting. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Mon, Jan 20, 2014 at 10:19:30AM -0800, Andrew Lutomirski wrote: Does uvesafb actually work? I submitted a patch to the uvesafb kernel driver a few months back, and not only is the upstream link [1][2] to the v86d helper dead, but no one on the dri-devel list answered my request to see if anyone had a copy. Fedora does not appear to package a copy (at least yum whatprovides '*/v86d' doesn't come up with anything). This means that I got a patch into upstream drm and that it's quite possible that no one (or maybe a grand total of one person) has ever tested. It'd be pretty straightforward to re-implement the helper if it's vanished entirely - we haven't retired libx86, and the rest is pretty trivial. Or do you mean the older pre-uvesafb driver? That's problematic from the You have to provide a fixed resolution on the kernel command line perspective. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Mon, Jan 20, 2014 at 04:50:09PM +, Peter Robinson wrote: Isn't -cirrus still used by virt in a number of cases? I know -mga is used as a gpu chipset on a number of relatively new server platforms. What about -vmware? Virt can use the cirrus kms driver, the server matrox is supported by mgag200 and doesn't the vmwgfx driver cover vmware? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Mon, Jan 20, 2014 at 10:54:22AM -0800, Andrew Lutomirski wrote: On Mon, Jan 20, 2014 at 10:40 AM, Matthew Garrett mj...@srcf.ucam.org wrote: It'd be pretty straightforward to re-implement the helper if it's vanished entirely - we haven't retired libx86, and the rest is pretty trivial. OTOH, if it has indeed vanished entirely, then maybe we could argue that there can't be any users and therefore it's okay if the driver stops working in F21. People are using -vesa right now, not uvesafb. Going forward, if the simpledrm stuff ever starts being fully functional, then it should provide a working, if rather crappy, way to get fixed-resolution graphics running on any new-enough system. Non-EFI systems are still going to need some mechanism for calling out to userspace for setting a mode. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Best practice for multiple version/OS boot?
On Mon, Nov 25, 2013 at 05:27:34PM +0100, Tomasz Torcz wrote: On Mon, Nov 25, 2013 at 08:28:59AM -0700, Pete Travis wrote: Enough people have asked this sort of question that Chris Roberts and I started hacking on a Guide to address it. Suggestions, criticisms, or contributions are equally welcome. [1] https://git.fedorahosted.org/cgit/docs/multiboot-guide.git/ Maybe some GSoC task to implement Boot Loader Spec in GRUB? http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ We're not going to implement the boot loader spec as written - the EFI system partition is always going to remain at /boot/efi, not /boot. This is a situation that's already allowed by the spec, so fixing it would just be a matter of deleting the section about using the ESP as $BOOT. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaging changes for libev in Rawhide
On Sat, Nov 23, 2013 at 01:47:49PM -0500, Simo Sorce wrote: On Tue, 2013-11-19 at 15:30 +0800, Mathieu Bridon wrote: Upstream itself requires the pkgconfig file for libev. That's just a terrible idea, as it means libverto won't build on e.g Debian, or with the upstream libev. libverto should be fixed upstream here IMHO. Libverto builds against both libevent and libev being a event loop abstraction library, if you make libev and libevent conflict libeverto cannot be built anymore. But it requires patches to libev that aren't upstream in order to build? One alternative would be to package the libev headers twice, one in the upstream location and once in the Fedora-specific location. The latter package could then include the pkgconfig file. This is still a bad solution. If libverto needs to link against both then libverto upstream should really work with libev and libevent upstream to find a solution that'll work for all distributions, rather than being limited to Fedora hacks. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaing question: need some includes from kernel source
On Tue, Nov 19, 2013 at 10:47:12AM -0600, Chris Adams wrote: I'm looking at packaing mpt-status (get status info from LSI MPT SAS RAID controllers) for Fedora and EPEL. However, to build, it needs some include files from the kernel source, specifically from the drivers/message/fusion directory. I've built an RPM using an extra tarball of all the .h files under that directory (using the 3.11.7 kernel source), and it works (and it also works on an older kernel under RHEL 6). If the headers describe a stable interface that should be used by userland then it's a kernel bug that they're not being exported. If they don't, you shouldn't use them. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaing question: need some includes from kernel source
On Tue, Nov 19, 2013 at 01:31:20PM -0600, Chris Adams wrote: Once upon a time, Matthew Garrett mj...@srcf.ucam.org said: If the headers describe a stable interface that should be used by userland then it's a kernel bug that they're not being exported. If they don't, you shouldn't use them. I believe the headers describe what is intended to be a stable interface. Would that be something I should bring up on linux-kernel? Probably better to look the driver up in MAINTAINERS and contact the people there. If the interface is supposed to be stable, asking upstream kernel to change isn't going to help make a package any time soon (and likely never for EPEL). Is it permissible to carry the necessary headers in the SRPM until they are no longer needed? From a technical perspective? Sure. Better to do that than add a gratuitous additional package. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Workstation WG Governance Charter
On Wed, Oct 30, 2013 at 09:01:52AM -0400, Josh Boyer wrote: The Fedora Workstation Work Group has nine voting members, with one member selected by the Fedora Engineering Steering Committee as the liaison to FESCo. Is the FESCo appointed member one of the nine voting members? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Target Display Mode in Fedora
On Tue, Oct 15, 2013 at 09:36:32AM -0600, Chris Murphy wrote: Or maybe Intel would be forthcoming. It's their hardware. Not in this case. Target display mode is a vendor extension, and switching it will be vendor specific. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, Oct 15, 2013 at 12:42:44PM -0400, Carlos O'Donell wrote: On 10/14/2013 10:55 AM, Matthew Garrett wrote: Did the arm32 portions of this end up being completed for F20? For 32-bit ARM on f20: - Stack guard: - Existing glibc support provides stack guard value in global variable and is used by existing runtime. Regression tests are passing in glibc testsuite. Verified working. Upstream verified that global variable is the best compromise for performance across all 32-bit ARM targets (TLS will be too slow in the average case). What's the effective difference in security between this and the existing ports? - Pointer mangling: - Not supported. Do we ship it in the x86 ports? Upstream glibc 2.19 summary: - Stack guard support already present using global variable. - Will have pointer encryption support using global variable, and could be a candidate for backport to f20. Cool. This is a runtime change, right? There's no requirement for a rebuild to take advantage of it? Do we need pointer mangling? If so then we need someone to file an f20 specific bug so the glibc team can look at backporting the fix. I won't commit to it until I review exactly what might need changing. The aim was for parity of important features, but it doesn't seem like we've ever advertised pointer guard as a Fedora feature so I'm not personally that worried. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, Oct 15, 2013 at 02:16:28PM -0400, Carlos O'Donell wrote: Pointer mangling is useful, but we can roll that change into an update and it should not in my opinion block F20. I've filed: Bug 1019452 - [ARM] Backport pointer mangling support from upstream. https://bugzilla.redhat.com/show_bug.cgi?id=1019452 Great. Thanks, Carlos! -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Target Display Mode in Fedora
On Tue, Oct 15, 2013 at 11:52:41AM -0600, Chris Murphy wrote: On Oct 15, 2013, at 10:36 AM, Matthew Garrett mj...@srcf.ucam.org wrote: On Tue, Oct 15, 2013 at 09:36:32AM -0600, Chris Murphy wrote: Or maybe Intel would be forthcoming. It's their hardware. Not in this case. Target display mode is a vendor extension, and switching it will be vendor specific. Too bad. I wonder if this switching extension is being obfuscated from reverse engineering with these smart cables Apple's producing. I can't see how. It works fine without any kind of special cable. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: ARM as primary Architecture
On Thu, Jul 11, 2013 at 01:39:21AM -0400, Carlos O'Donell wrote: Next steps: - Verify libssp works correctly on 32-bit ARM. - Look at enhancing the existing support in glibc. - Add TLS stack guard. - Add TLS pointer guard. - Add pointer mangle/demangle support. - Enhance aarch64 to support the same set of features. Did the arm32 portions of this end up being completed for F20? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora Working Groups: Call for Self-Nominations
On Fri, Oct 11, 2013 at 03:58:41PM +0200, Miloslav Trmač wrote: No, the intent was very much to change what the resulting desktop prioritizes. Quite a few FESCo members would be rather disappointed if the new Workstation ended up just an unchanged GNOME[1]. ? The intent was very much for the working group to set their own priorities. I don't see any role for FESCo in making that decision. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora Working Groups: Call for Self-Nominations
On Fri, Oct 11, 2013 at 03:53:39PM +, Jóhann B. Guðmundsson wrote: Did someone even bother to reach out to the community and ask them how they would like to move forward? ( Not that I recall any thread doing just that ) It was discussed at Flock. It was discussed on this mailing list. The community representatives on FESCo and the board discussed it. All of this happened in public. Which community do you feel was given no opportunity to represent their opinions? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora Working Groups: Call for Self-Nominations
On Fri, Oct 11, 2013 at 04:19:00PM +, Jóhann B. Guðmundsson wrote: On 10/11/2013 03:59 PM, Matthew Garrett wrote: community representatives on FESCo and the board discussed it. All of this happened in public. Which community do you feel was given no opportunity to represent their opinions? For the first not everybody is subscribed to the list, secondly not everyone can and never will be able to attend flock or other events. Fedora development takes place on this list. Was there any attempt to reach out to the relevant sub-community was there a mail or discussion held on the server list even if only to see who where active on it? Given that the last mail to the server list was over 18 months ago, the answer is that there's nobody active on it. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora Working Groups: Call for Self-Nominations
On Fri, Oct 11, 2013 at 04:33:24PM +, Jóhann B. Guðmundsson wrote: On 10/11/2013 04:27 PM, Matthew Garrett wrote: Was there any attempt to reach out to the relevant sub-community was there a mail or discussion held on the server list even if only to see who where active on it? Given that the last mail to the server list was over 18 months ago, the answer is that there's nobody active on it. In other words it was not done. Because there's no active server sub-community. The people interested in server work are working within the general Fedora development community, which means devel@ is the appropriate list to reach them. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora Working Groups: Call for Self-Nominations
On Fri, Oct 11, 2013 at 04:47:34PM +, Jóhann B. Guðmundsson wrote: On 10/11/2013 04:41 PM, Matthew Garrett wrote: Because there's no active server sub-community. The people interested in server work are working within the general Fedora development community, which means devel@ is the appropriate list to reach them. That's quite the assumption and based on that I assume the next step planned is to kill the server list and just mobiles the people interested here right. shrug If people doing server development work feel that they'd be better doing so on a separate mailing list, that option's there. But given the number of server-related discussions we've had on this list, they don't seem to currently feel that. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal: AppData files in all application packages?
On Thu, Sep 12, 2013 at 05:39:29PM -0500, Dennis Gilmore wrote: I really do not think we can integrate this into our release processes right now. What work would need to be done in order to make it possible to integrate this into the release process? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: 19 (Schrödinger’s Cat)
On Fri, Sep 06, 2013 at 12:33:40AM +0200, Reindl Harald wrote: whay is Fedora starting with this crap exatly with the release having a short-minded name with special chars not properly handeled by the whole OS? You're sending email to the development mailing list, so you're presumably a developer. In which case, perhaps you'd be willing to spend the time that you're currently using to send angry mails to the list to improve grub's support for Unicode characters when using VGA text mode? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: 19 (Schrödinger’s Cat)
Maybe something like (the incredibly ugly) http://www.codon.org.uk/~mjg59/tmp/mapping.diff -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Graphics driver support in F21+
On Tue, Aug 27, 2013 at 04:30:25PM -0400, john.flor...@dart.biz wrote: From: mj...@srcf.ucam.org On Tue, Aug 27, 2013 at 02:54:46PM +, Jóhann B. Guðmundsson wrote: From this point forward only graphics driver that have kms support will be allow to be packaged and shipped in the distribution Only if you want to drop VESA support. Please don't drop that. I have a large install base of SBCs using geode and some on savage and s3virge IIRC. I need at least the VESA fallback, although I suspect that may not suffice in some cases. Yeah, I don't think anyone's planning on dropping VESA support. It's just that supporting it at the moment means that we continue to support some UMS drivers, which makes it difficult to stick to a KMS or nothing approach. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Graphics driver support in F21+
On Tue, Aug 27, 2013 at 02:54:46PM +, Jóhann B. Guðmundsson wrote: From this point forward only graphics driver that have kms support will be allow to be packaged and shipped in the distribution Only if you want to drop VESA support. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: BlueZ Status in Fedora.
On Sun, Aug 18, 2013 at 02:28:34PM -0700, Ryan Rix wrote: Basically we ship Fedora 20 in a state where one only of our major desktop environments supports bluetooth in a stable fashion? That seems kind of like a disaster waiting to happen. The current release blocking desktops are Gnome and KDE. If those are broken then F20 doesn't ship - if they're working, it ships. It'd be unfortunate to ship a release that doesn't support the non-blocking desktops, but (right now) it's fundamentally up to them to provide the development effort to ensure that they have a full feature set. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Thu, Aug 15, 2013 at 03:43:27PM -0400, Jóhann B. Guðmundsson wrote: On 08/15/2013 03:16 PM, drago01 wrote: Suddenly? They always have been supported that even dates back to the Redhat Linux days ... I should clarify what I'm talking about is the discussion of officially supporting upgrading while you probably mean it has been technically possible which has indeed been available for a long time. It's supported in that it's expected to work, and if it doesn't work it's a valid bug and should be fixed or relnoted. That's been the intention forever, and like I said, if QA aren't testing that then QA should be testing that. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Thu, Aug 15, 2013 at 09:40:01AM -0400, Paul Wouters wrote: On Thu, 15 Aug 2013, Matthew Garrett wrote: I want increased participation in the creation of Fedora, which is a product with a defined set of software shipped as default. I'm also happy with people working to make it practical to use Fedora as the basis for derived products (such as the spins and remixes), providing that they don't compromise the product that we're producing. I feel that people mostly say fedora is for testing. It is somewhat supported by responses to upgrade problems to a new version which invariable are along the lines of we don't support that upgrade path/method. What's wrong with fedup? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Thu, Aug 15, 2013 at 01:02:42PM -0400, Jóhann B. Guðmundsson wrote: Well whomever choose to decide that we support upgrades in the first place bypassed the QA community entirely in making that decision as well as to which tool is preferred,supported or recommended. If QA is testing something other than the supported upgrade mechanism, then QA should rectify that. The communication has been very clear - if fedup fails to upgrade then that's considered a bug, and if any other approach fails then it may not be. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Thu, Aug 15, 2013 at 03:02:37PM -0400, Jóhann B. Guðmundsson wrote: Our release criteria and everything we defined *after* we found out that we suddenly supported upgrades is solid which is not what I was saying or referring to. We've always supported upgrades. Before fedup, preupgrade was the supported upgrade mechanism. That's been true as long as I've been involved in Red Hat. Could you point me to the individual(s) and the discussion to support upgrades in the first place, took place so we in the QA community can finally see who made the decision to open that pandora box and why? Preupgrade was accepted into Fedora 8, so you'd probably need to go back and review the feature discussion from then. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Schedule for Wednesday's FESCo Meeting (2013-08-14)
Oh, and to clarify - upgrades were supported even before then, but required booting Anaconda from new install media. That's been true since the Red Hat Linux days, so years before Fedora even existed. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Wed, Aug 14, 2013 at 05:32:15PM -0400, Jóhann B. Guðmundsson wrote: Putting one of those at a higher level by default, by recommendation or even just by placing it on the front web page puts the others at disadvantage and will hinder growth and participation in the relevant sub-communities which will result in worse product and in turn will have negative outcome for the project in whole. At least that is how I see it. Some projects are objectively better than other projects. Some projects may not be objectively better but are more closely aligned with our release schedule and support cycles. Some projects are actively developed in Fedora and as such can be more cleanly integrated into the distribution. Making it easier for users to obtain those projects is doing our users a service. It is not our responsibility to encourage growth and development of other projects that don't make things better for our users, and so it's inappropriate to provide equivalent promotion. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Wed, Aug 14, 2013 at 06:49:17PM -0400, Jóhann B. Guðmundsson wrote: On 08/14/2013 06:04 PM, Matthew Garrett wrote: Some projects are objectively better than other projects. Some projects may not be objectively better but are more closely aligned with our release schedule and support cycles. Some projects are actively developed in Fedora and as such can be more cleanly integrated into the distribution. As soon as we slip that argument no longer stands and we always slip... We suck, so we should keep on sucking? Come on. Our inability to maintain a schedule is the result of a wide variety of factors that we can improve, not an inherent reality. Making it easier for users to obtain those projects is doing our users a service. It is not our responsibility to encourage growth and development of other projects that don't make things better for our users, and so it's inappropriate to provide equivalent promotion. You do realize that each sub community is trying to reach out to their own target users, even an single application might be reaching to a specific target audience so in that perspective there is no such thing as our users. If you visit fedoraproject.org and click on Download now, you'll get a 64-bit x86 desktop live image. Those are our de-facto target users. The proposal under discussion actually broadens that slightly by making it clearer that we offer three separate first-class products for three different user-cases. You seem to be arguing for a different scenario, one where arbitrary subsets of the Fedora package set are advertised equally. That's not the status quo, and so I think you need to follow this proposal's lead and come up with a solid argument for how your position improves Fedora and what technical and policy changes are needed to get there. So in other words what to take from your response is that you are saying that you do not want increased participation in the project as whole and or only for specific areas of the project? I want increased participation in the creation of Fedora, which is a product with a defined set of software shipped as default. I'm also happy with people working to make it practical to use Fedora as the basis for derived products (such as the spins and remixes), providing that they don't compromise the product that we're producing. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Excludearch/Exclusivearch reminder
On Wed, Aug 07, 2013 at 02:36:48PM -0600, Kevin Fenzi wrote: If you exclude arm support for now, please file a bug against your package with the information about the missing arm support and then add F-ExcludeArch-arm to the Blocks field on your bug. This will make the arm team aware of the issue, as well as FESCo to track what items are missing for full primary promotion. Did this get set on packages that had ExcludeArch added while Arm was still secondary? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary of accepted Fedora 20 Changes - week 30
On Sun, Jul 28, 2013 at 09:56:16AM +0300, Oron Peled wrote: On Saturday 27 July 2013 18:36:23 Matthew Garrett wrote: Really? I'd expect most users to be using gmail at this point. Any solution needs to account for them as well. 1. By the same logic we can ship just a browser, why bother building LibreOffice if many use just google-docs? Because not everyone uses Google Docs, and so any solution needs to account for those who don't as well. 2. People can still use gmail and other online services like twitter via desktop applications (in my case kmail and choqok respectively). But most don't, and therefore an error reporting scheme that depends on users running a local mail client is inappropriate. Last side note: helping non-expert people get used to quality local applications which have convenient defaults, is part of the push for Freedom -- if both your data and your applications are locked in vertical clouds, you aren't left with too much freedom. There are benefits in running local applications, especially when it comes to freedom. However, we are unable to force our users to run local applications. We therefore need a mechanism for providing error data to users that doesn't require them to run a local application. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
