unsigned f21 package: perl-Term-ANSIColor
I get this when I try to install vim via yum on my f21 candidate cloud image: Package perl-Term-ANSIColor-4.03-2.fc21.noarch.rpm is not signed Is this on anyones radar already? Dusty -- 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: unsigned f21 package: perl-Term-ANSIColor
On Tue, Aug 19, 2014 at 07:37:13AM -0400, Josh Boyer wrote: > On Tue, Aug 19, 2014 at 7:29 AM, Dusty Mabe wrote: > > I get this when I try to install vim via yum on my f21 candidate cloud > > image: > > > > Package perl-Term-ANSIColor-4.03-2.fc21.noarch.rpm is not signed > > > > Is this on anyones radar already? > > http://rawhidewatch.wordpress.com/2014/07/29/fedora-21-package-signing-no-its-not-just-you/ Thanks Josh. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Circular dependencies in RPM
I know I have probably been hiding under a Rock but can anyone help me understand Fedora's stance on circular dependencies within RPMs? At least in the past I think circular dependencies have been kept to a minimum as it can cause issues with rpm sorting: i.e. for two rpms A,B with a circular dependency, in different transactions sometimes A goes before B and sometimes B goes before A. In Fedora 20 just running rpm against the 1500 or so packages I have installed on my Desktop I notice that there are 47 sets of "Strongly Connected Components"; basically 47 cases of a circular dependency. Was there a point where this became more popular. I don't remember there being more than a few circular deps for EL6 era rpms. Thanks, Dusty -- 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: Circular dependencies in RPM
On Fri, Aug 22, 2014 at 10:11:25PM +0200, Reindl Harald wrote: > > Am 22.08.2014 um 21:53 schrieb Dusty Mabe: > > I know I have probably been hiding under a Rock but can anyone help me > > understand Fedora's stance on circular dependencies within RPMs? > > > > At least in the past I think circular dependencies have been kept to a > > minimum > > as it can cause issues with rpm sorting: i.e. for two rpms A,B with a > > circular > > dependency, in different transactions sometimes A goes before B and > > sometimes > > B goes before A. > > > > In Fedora 20 just running rpm against the 1500 or so packages I have > > installed > > on my Desktop I notice that there are 47 sets of "Strongly Connected > > Components"; > > basically 47 cases of a circular dependency. > > > > Was there a point where this became more popular. I don't remember there > > being more > > than a few circular deps for EL6 era rpms. > > how should it work otherwise? > > * each package defines it's depndencies > * each of the dependencies have their own > * no package knows the whole picture > * each package has to pull all deps it needs Sure. Each package defines all deps it needs is how it should be. > > if > * A requires B > * B requires C The scenario I am concerned with here is: if * A requires B * B requires C * C requires A This basically yields a case where ordering can't be properly done because rpm doesn't know which dependency is stronger. If all of the rpms in question just deliver files then all is well with the world but if each of them have scriptlets the ordering can definitely matter and this would be a problem. Dusty -- 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: Circular dependencies in RPM
On Fri, Aug 22, 2014 at 02:29:31PM -0600, Orion Poplawski wrote: > On 08/22/2014 02:23 PM, Dusty Mabe wrote: > >The scenario I am concerned with here is: > > > >if > > * A requires B > > * B requires C > > * C requires A > > > >This basically yields a case where ordering can't be properly done because > >rpm doesn't know which dependency is stronger. If all of the rpms in question > >just deliver files then all is well with the world but if each of them have > >scriptlets the ordering can definitely matter and this would be a problem. > > > >Dusty > > > > Scriptlet dependency ordering it specified with for example: > > Requires(post): pkg > > Are there any circular scriptlet deps? So that may be the answer. This *new to me* feature solves the case of scriptlets which is really the only place you see errors *during* the install. Thanks Orion -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Base] Terminology for docker/atomic images
Hi All, Per discussion in the #fedora-cloud meeting last Friday I would like to start a thread about the names of the Docker and Atomic deliverables for F21. I know of at least a few cases where there has been confusion regarding what deliverable has been the subject of a conversation on IRC as a result of the current terminology. I've seen the docker and atomic referred to as: Docker Image Atomic Image Docker Host Image etc... It seems like the one that sparks the most confusion is "Docker Image". Usually when I see "Image" I think a VM bootable image (i.e. virtualization, not containers/Docker). A progression from that misunderstanding could lead one to think that "Docker Image" is the VM disk image I can use to boot a host that will run the Docker daemon and thus run containers. I think it would be nice to help ourselves and our users along by separating the terminology a bit such that it is hard to confuse what is a VM disk image vs. what is an image for use with Docker. Here is a first stab at trying to make things clearer: Docker Container Image - base container image - can be used with docker Atomic Image - minimal OS, Atomic updates, aka 'Docker Host' In a nutshell, it would be great if we added "Container" to references we make to the container image (in conversation and docs). Thoughts? Dusty -- 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: [Base] Terminology for docker/atomic images
On Mon, Sep 08, 2014 at 09:29:12AM -0400, Colin Walters wrote: > On Sun, Sep 7, 2014, at 11:22 PM, Dusty Mabe wrote: > > > > In a nutshell, it would be great if we added "Container" to references we > > make to the container image (in conversation and docs). > > I tend to say "Docker Base Image" - that's the terminology upstream > Docker uses: https://docs.docker.com/articles/baseimages/ I think in the context of Docker, i.e. when you already know you are talking about the Docker daemon and Docker containers, then "Docker Base Image" is clear enough. I think when you don't have that context to begin with and you hear "Docker Base Image" then it is not so clear. I'm fine with incorporating their terminology so we can be more clear though: Docker Container Base Image ? Unfortunately we have to balance clarity with convenience. The longer it gets the more people won't like it so that is something to consider. Dusty -- 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: [Base] Terminology for docker/atomic images
On Mon, Sep 08, 2014 at 09:28:20AM -0400, Adam Young wrote: > On 09/07/2014 11:22 PM, Dusty Mabe wrote: > >Hi All, > > > >Per discussion in the #fedora-cloud meeting last Friday I would like to > >start a thread about the names of the Docker and Atomic deliverables for F21. > > > >I know of at least a few cases where there has been confusion regarding > >what deliverable has been the subject of a conversation on IRC as a result > >of the current terminology. I've seen the docker and atomic referred to as: > > > > Docker Image > > Atomic Image > > Docker Host Image > > etc... > > > >It seems like the one that sparks the most confusion is "Docker Image". > >Usually when I see "Image" I think a VM bootable image (i.e. virtualization, > >not containers/Docker). A progression from that misunderstanding could lead > >one to think that "Docker Image" is the VM disk image I can use to boot a > >host that will run the Docker daemon and thus run containers. > > > >I think it would be nice to help ourselves and our users along by separating > >the terminology a bit such that it is hard to confuse what is a VM disk > >image vs. what is an image for use with Docker. > > > >Here is a first stab at trying to make things clearer: > > > > > > Docker Container Image - base container image - can be used with docker > > Atomic Image - minimal OS, Atomic updates, aka 'Docker Host' > I've always thought container and image were two distinct things. Image and container are two distinct things. The container image is basically an image that contains a filesystem for use with containers (no kernel, etc..). A container is an isolated process that runs that uses the container image as the root filesystem. > > > Here's my take: > > > The image is the disk that is being used. The container is the > Operating System construct. The Two combinded are the instance. > > "My instance is a Fedora 21 base image running inside a KVM container." > > "My instance is a Docker image of JBoss with RHQ in it running in a > container on CentOS 7" I think you are mixing virtualization and containerization too much. Let me try to see if I can use similar statements in my own terms: "My virtual machine instance is a Fedora 21 base image running on a KVM hypervisor" "My container is running process X that is using a docker container image of JBoss with RHQ in it. The Docker daemon managing my container is running on a CentOS 7 host." Hopefully my take on this isn't wrong. Does this help at all? Dusty -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
cloud-init / dnf selinux denials
Hey all, We have a bug that affects booting cloud images (see [1]). There are denials that don't allow cloud-init to install packages. I'm not exactly where a fix needs to be applied but I have copied both the owners of dnf and the owner of selinux-policy on this email. What can we do to get this looked at and fixed? Thanks, Dusty https://bugzilla.redhat.com/show_bug.cgi?id=1227484 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
New CoreOS Assembler release v0.8.1
https://github.com/coreos/coreos-assembler/releases/tag/v0.8.1 Some highlights for this release: - Many UX improvements to `cosa run` - A lot of work around enhancing our support for GCP image uploads and manipulations. - Add support for offline installs - More multi-arch fixes and improvements - Support installed tests in `/usr/lib/coreos-assembler/kola` - There are now two new commands for making it easier to iterate faster - `cosa build-fast` and `cosa buildinitramfs-fast`. See their help output for more information. And of course many more fixes and features! Thanks to all the contributors! ``` Ben Howard (1): 2a92600a Use shutil.move over os.rename in python code. Benjamin Gilbert (1): 5a07e8a5 mantle: bump Ignition to 2.3.0 Colin Walters (47): 3d51185e qemu: Use a single temporary directory 9aa2d390 qemu: Unlink non-multipath/nbd disks dd883aa7 devshell: Print serial console as status line, dump when interrupted 8480daf5 cmdlib: Don't dump serial console to stdout 087ff23f installer: Inject stamp file /etc/coreos-legacy-installer-initramfs 42773b9c qemu: Ensure tmpdir is allocated for swtpm 3094bfbd devshell: More output validation 16f1c556 create_disk: Use ostree admin init-fs --modern e89b75d3 qemu: Propagate errors from disk attachment 5a3a4645 devshell: Don't print error on EOF from serial console 574b6bed mantle/qemu: Set a short hostname 95c3c8ea Add qemu API to stream journal, use it in devshell 6b5b86f4 installer: More code cleanup e0841351 testiso: Print which message we were waiting for if we hit EOF f2f7af8f testiso: Rename --console to --debug and skip initramfs failures d5fe653d testiso: Show which scenario failed on error 66807dfc upload-oscontainer: New command 494d99e8 kola: Write ignition-virtio-dump.txt to test dir 45807fb7 Add cosa supermin-shell 6724a4c1 installer: Refactor initramfs code 44bdfbbc installer: Use consistent variable to refer to built initramfs afeb3c3f mantle: Build binaries in parallel e1d5c2cc kola: Support distros and tags in external test metadata 0e5118e1 kola: Add option to configure RAM e54c5268 runc: New command 1fef2340 buildinitramfs-fast: New command to iterate on initramfs quickly dc13aced buildextend-live: Squash unused variable 04f94bfe Revert "mantle: Build binaries in parallel" 71518abc installer: Put rootfs on ISO 583f7f1f kola: Avoid losing "external" tag df6fa87b kola: Support loading tests from /usr/lib/coreos-assembler/tests/kola 30a93de1 qemu: IgnoreOnIsolate=true for journal streaming e3905fd2 create_disk: Add known UUIDs for /boot and /root 43c274a8 testiso: Gather logs 629a22e3 mantle: Remove setenforce 1 by default ca6cfed4 cmdlib: Don't hardcode manifest path in overrides ca3c5c3e kola: Add RHCOS LUKS upgrade test 4fbc3c7d testiso: Also capture initramfs virtio dumps e0846677 kola: Replace download code with executing coreos-installer 919bd067 cmdlib: Stop parsing rojig/license 26a1cc25 mantle: Move the FCOS stream URL from kola into mantle 419efd20 Remove dead code relating to detecting Ignition version 8003edea testiso: Fix use of global `outputDir` 4f2a1e26 kola: Add --no-net flag 021b6c8a supermin-shell: Support passing through qemu arguments ca97e50c create_disk: Ensure filesystem journal on rootfs is clean 4c8d41f3 osmet-pack: Mount RHCOS LUKS rootfs Dusty Mabe (20): 6df34a21 mantle: bump google.golang.org/api library to latest a11197f2 mantle/ore: glcoud: add --create-image option to upload.go 02653cad cosalib/gcp: remove unused argument 91297ff2 mantle/ore: gcloud: fix error detection, add some error checking d9c90cec mantle/ore: gcloud: add ability to attach license to image 74787089 mantle/ore: gcloud: fix --image arg for deprecate-image f0427bdb mantle: switch to v0.alpha for gcloud compute API 6d0ce985 mantle/ore: add ore gcloud update-image c5e108b6 cosalib/gcp: attach to image family in separate API call a1312708 mantle/ore: gcloud: fix error detection for deprecate-image 4dedce33 mantle/platform: gcloud: add new getImageAPIEndpoint func 92efaf05 mantle/platform: gcloud: use API endpoint for replacement in DeprecateImage 0cd1771c mantle/platform: gcloud: enhance api.ListImages to filter by image family d27f297f mantle/ore: gcloud: add promote-image command f7eebc17 cmd-kola: also detect --platform= a42a6b0d cosalib/gcp: Add more gcp information to meta.json b18d76a5 cosalib/gcp: shchema: make gcp image project optional 6c0c1851 kola: don't error if external tests directory doesn't exist df161488 cosalib/gcp: pass the log level to ore 560c2dc6 mantle/o
Fedora CoreOS rebasing to Fedora 32: known issues; upcoming test day
Today we’ve released the first Fedora CoreOS testing release based on Fedora 32. We expect that this release will promote to the stable channel in two weeks, on the usual schedule. New features include: Support for the Ignition 3.1.0 config specification. Use this with the FCC 1.1.0 config specification. For more on the new features, see here. It’s now easier to enable SSH password authentication. There are a few quirks that may affect you: New releases are signed with the Fedora 32 key. Accordingly, bare metal installations require coreos-installer 0.2.1 or greater. If you’re installing from media that matches the release you’re installing, you’ll already have the correct installer version. Ignition currently fails to set SELinux labels on absolute symlinks. For more info and a workaround, see #512. AWS instances may produce a kernel warning on shutdown. For more info, see #507. On Monday, June 8, we’ll be joining the Fedora QA team for a Fedora CoreOS test day. Join us in #fedora-coreos on Freenode to test Fedora CoreOS based on Fedora 32! For more information, see the mailing list post. Thanks for helping us make Fedora CoreOS awesome! Dusty Mabe, for the Fedora CoreOS team ___ 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
rust-ipnetwork license change
The license for rust-ipnetwork changed to "MIT or Apache-2.0" upstream [1]. This is reflected in the PR to distgit [2] to update to the latest version. Dusty [1] https://github.com/achanda/ipnetwork/commit/fa128680b51fbcf9c37db99f011c91204c4a3b0d [2] https://src.fedoraproject.org/rpms/rust-ipnetwork/pull-request/1 ___ 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
TermRecord software in Fedora/EPEL
Hi Everyone, I have been using TermRecord recently to archive terminal sessions and share them or play them back using a web browser. It is simple and provides one click access for a colleague to view a recording. Currently this software is available on github [1] as well as in the python package index [2]. I have written a small blog post on how to use it with old timing and log files created with scriptreplay as well [3]. I would like to package this software for Fedora and possible EPEL if others think it would be useful. I have reviewed the Fedora package review process [4] and will follow those steps if this is well received. Thanks, Dusty Mabe [1] https://github.com/theonewolf/TermRecord [2] https://pypi.python.org/pypi/TermRecord [3] http://dustymabe.com/2014/05/19/termrecord-terminal-screencast-in-a-self-contained-html-file/ [4] http://fedoraproject.org/wiki/Package_Review_Process -- 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: TermRecord software in Fedora/EPEL
On Mon, May 19, 2014 at 12:53:31PM +0800, Christopher Meng wrote: > You can try asciinema which is already packaged in Fedora: > > yum install asciinema Hi, Thanks for the suggestion. What I like about TermRecord is that it produces a self-contatined html file as output and that it doesn't require any external service. From what I understand asciinema does require the service and doesn't create a self-contained html file. Is that correct? Dusty -- 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: TermRecord software in Fedora/EPEL
On Mon, May 19, 2014 at 09:25:51AM -0400, Matthew Miller wrote: > On Mon, May 19, 2014 at 12:39:55AM -0400, Dusty Mabe wrote: > > I would like to package this software for Fedora and possible > > EPEL if others think it would be useful. I have reviewed the > > Fedora package review process [4] and will follow those steps > > if this is well received. > > > It does sound useful -- go for it! Thanks everyone for the encouragement. I'll continue with this and submit a request soon (and hopefully get sponsored at some point). Dusty -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
ansible in Fedora 23+ (python3)
Hey all, Just wondering if anyone has started to feel any pain from trying to use ansible with F23 systems. As part of the Fedora Cloud working group it would be nice to ship a system that could be targeted by ansible out of the box. Unfortunately, since ansible uses python 2.X vs python 3 it doesn't really work. A simple answer would be to "just install python", but I actually hit several roadblocks because of python packages that are usually there but have been replaced by their python 3 counterparts. As an example for one ansible playbook like [1] I had to install these rpms in order to get it to work: python libselinux-python python-dnf python-docker-py Unfortunately there isn't a catchall that is a workaround for this problem because the libraries you need on the system depend on the modules you will use. Does anyone have a good solution for this? Obviously it would be nice if ansible went to python3 but I think they have stated clearly that they are sticking with python2 for backwards compat with systems that still need 2.4. -Dusty [1] - https://github.com/dustymabe/vagrantdirs/blob/master/f22/playbook.yml -- 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: ansible in Fedora 23+ (python3)
On 10/14/2015 09:40 AM, Pete Travis wrote: On 10/14/2015 07:47 AM, Matthew Miller wrote: On Tue, Oct 13, 2015 at 08:57:57PM -0700, Adam Williamson wrote: Beyond that, though, why not just have your ansible play ensure its own deps are installed? If you're dealing with docker, make sure the package you need is installed before you run any docker steps... So, in other words, it seems acceptible to make this a documentation problem? We should at least definitely make sure to have that documentation. I haven't poked at this yet, but can add it to the release notes. Can someone confirm that at least the dnf module works out of the box? Define "out of the box". For the fedora cloud image you have to install python and python-dnf first. The dnf module will then work, but not until you do that. -- 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: ansible in Fedora 23+ (python3)
On Wed, Oct 14, 2015 at 11:07:42AM -0400, Colin Walters wrote: > On Tue, Oct 13, 2015, at 10:21 PM, Dusty Mabe wrote: > > > Just wondering if anyone has started to feel any pain from trying to > > use ansible with F23 systems. As part of the Fedora Cloud working > > group it would be nice to ship a system that could be targeted by > > ansible out of the box. > > Sounds like you're talking about the Cloud Base; this is not > an issue for the Atomic Host; see: > > https://lists.fedoraproject.org/pipermail/devel/2015-June/211310.html I am talking about cloud base, but don't be so fast to assume Atomic is OK because it has python2. Arguably Atomic is in a worse position. Part of this email chain is to explain how just installing python2 isn't going to solve the problem.. For example, if I simply want to place a file on the host: tasks: - name: write .bashrc template: src=/home/dustymabe/.bashrc dest=/root/.bashrc I end up with: msg: Aborting, target uses selinux but python bindings (libselinux-python) aren't installed! Another example: I want to start a docker container: tasks: - name: start skydns docker: name: skydns net: host image: gcr.io/google_containers/skydns:2015-03-11-001 docker_api_version: 1.18 # Not sure why this is needed state: started restart_policy: always env: ETCD_MACHINES: "http://127.0.0.1:2379"; SKYDNS_DOMAIN: "kubernetes.local" SKYDNS_ADDR:"0.0.0.0:53" SKYDNS_NAMESERVERS: "8.8.8.8:53,8.8.4.4:53" I end up with: msg: `docker-py` doesn't seem to be installed, but is required for the Ansible Docker module. Even though the python3 versions of those libraries are in the system it doesn't work. For atomic there is no way to workaround this either. Dusty -- 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: ansible in Fedora 23+ (python3)
On 10/14/2015 12:42 PM, Matthew Miller wrote: On Wed, Oct 14, 2015 at 11:07:42AM -0400, Colin Walters wrote: Just wondering if anyone has started to feel any pain from trying to use ansible with F23 systems. As part of the Fedora Cloud working group it would be nice to ship a system that could be targeted by ansible out of the box. Sounds like you're talking about the Cloud Base; this is not an issue for the Atomic Host; see: https://lists.fedoraproject.org/pipermail/devel/2015-June/211310.html If we assume many or most Atomic Host users will be using Ansible, I think that's a good batteries-included call. Interestingly, CoreOS has _no_ version of Python, and I've seen two approaches for dealing with this: using ansible 'raw' mode to pull down a python interpreter into /home/core/bin, or else to use the toolbox-container — which, awesomely, is Fedora-based and contains Python. Cool. I didn't know about 'raw' mode. That could provide us with some workarounds that we could document. The toolbox container might be something we could use on Atomic. -- 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: [Test-Announce] Fedora 23 Final Test Compose 10 (TC10) and Test Compose 11 (TC11) Available Now!
On 10/16/2015 12:21 PM, Adam Williamson wrote: As scheduled [1], Fedora 23 Final Test Compose 10 (TC10) and TC11 are now available for testing. Please help us complete all the validation testing! Hey Adam/Cloud list, Does anyone know what happened between TC9 / TC10 / TC11 with regards to the Fedora cloud base image? Here is what I notice: - TC9 boots fine but is affected by https://fedorahosted.org/cloud/ticket/128 - TC10 does not boot. It is using syslinux!!! This is a big change that should not have happened. - TC11 boots fine but the kbd rpm is missing so the systemd-vconsole-setup.service systemd unit fails on boot. Any insight here? Dusty -- 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: [Test-Announce] Fedora 23 Final Test Compose 10 (TC10) and Test Compose 11 (TC11) Available Now!
On 10/16/2015 02:24 PM, Orion Poplawski wrote: On 10/16/2015 11:40 AM, Dusty Mabe wrote: On 10/16/2015 12:21 PM, Adam Williamson wrote: As scheduled [1], Fedora 23 Final Test Compose 10 (TC10) and TC11 are now available for testing. Please help us complete all the validation testing! Hey Adam/Cloud list, Does anyone know what happened between TC9 / TC10 / TC11 with regards to the Fedora cloud base image? Here is what I notice: - TC9 boots fine but is affected by https://fedorahosted.org/cloud/ticket/128 - TC10 does not boot. It is using syslinux!!! This is a big change that should not have happened. - TC11 boots fine but the kbd rpm is missing so the systemd-vconsole-setup.service systemd unit fails on boot. Any insight here? Perhaps affected by dnf change for https://bugzilla.redhat.com/show_bug.cgi?id=1199868 ? Indeed. That looks like the reason stopped being there. Thanks, Dusty -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora Rel-Eng builder boxes can't run qemu-kvm on F23
Basically this means we can't build any images (rawhide/Fedora23/etc) because the builder hosts have been moved to Fedora 23. The following BZ has more info. Please discuss in the bug if you have comments about the technicals. Please discuss here otherwise. https://bugzilla.redhat.com/show_bug.cgi?id=1283666 -- 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 Rel-Eng builder boxes can't run qemu-kvm on F23
On 11/19/2015 09:41 AM, Cole Robinson wrote: On 11/19/2015 09:35 AM, Dusty Mabe wrote: Basically this means we can't build any images (rawhide/Fedora23/etc) because the builder hosts have been moved to Fedora 23. The following BZ has more info. Please discuss in the bug if you have comments about the technicals. Please discuss here otherwise. https://bugzilla.redhat.com/show_bug.cgi?id=1283666 Possible this KVM kernel regression, fixed upstream but not in f23 yet: https://bugzilla.redhat.com/show_bug.cgi?id=1278688 Looks the same to me. Dusty -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Disabling predictable interface names
According to [1] predictable interface naming can be disabled with a symlink to /dev/null or by providing net.ifnames=0 on the kernel command line. It seems like symlinking to /dev/null isn't working any more. Is symlinking to /dev/null supposed to still work? We are seeing this on Atomic Cloud images where the symlink is in place but net.ifnames=0 isn't on the cmd line so we are getting ens* interface names. [1] - http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ -- 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: Disabling predictable interface names
On 11/20/2015 05:10 AM, wheelz wrote: You need to run dracut to rebuild initramfs, or you wait for the next kernel > update. Thanks wheelz. I'll have to look into that. -- 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: Who owns the Fedora Atlas account?
On 01/08/2016 01:09 PM, Daniel Farrell wrote: > Hello Fedora devs, > > Who owns this account? > > https://atlas.hashicorp.com/fedora > > My initial hope was to get the F22 boxes[0] hosted there, in addition to > the current F23 ones[1]. Digging into that on #fedora-devel, dgilmore told > me that the account isn't official and the owner is unknown. Dave_o then > pointed out that the account may have been created by Hashicorp, not Fedora > devs. > > [0]: > https://dl.fedoraproject.org/pub/fedora/linux/releases/22/Cloud/x86_64/Images/ > [1]: https://atlas.hashicorp.com/fedora/ > > Obviously it'd be nice to get the facts, and likely it'd be nice to have > the account under community control. > > Thanks for the help, > Hi, It is owned by a few of us from Fedora Cloud Sig. It is not under the normal release engineering process right now but we hope for it to be in Fedora 24. I have opened a ticket to track this, but haven't made much progress on it since I opened it: https://fedorahosted.org/cloud/ticket/133 As for Fedora 22. There were some issues in those images that were fixed by F23. I think we decided not to release them in Atlas because of those issues. Dusty -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
iphone mount in nautilus on Fedora 24
In older Fedora (at least Fedora 22) I could easily mount my ihphone in Nautilus. I could click on it in the left hand side of the File Manager and it would mount. I am having trouble getting this same behavior in Fedora 24. Can someone verify this works or does not work for them? You should be able to verify this with Fedora 24 + Gnome + iphone + iphone cable. Thanks, Dusty -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: iphone mount in nautilus on Fedora 24
On 07/09/2016 12:04 AM, Peter Robinson wrote: >> In older Fedora (at least Fedora 22) I could easily mount my ihphone >> in Nautilus. I could click on it in the left hand side of the File >> Manager and it would mount. >> >> I am having trouble getting this same behavior in Fedora 24. Can >> someone verify this works or does not work for them? You should be >> able to verify this with Fedora 24 + Gnome + iphone + iphone cable. > > Support is provided by gvfs-afc through the libimobiledevice stack, > the later hasn't really changed since F-22 when the 1.2.0 version > fixed up support for the new iOS devices, upstream have confirmed that > iOS 10 works with that version too [1], so not sure what might have > broken. Hey Peter, thanks for responding. So things "work" just not as they used to. I can still mount the files from the iphone if I use idevicepair and ifuse as described at http://www.dedoimedo.com/computers/fedora-22-iphone.html The problem is when I'm using nautilus I used to just be able to click on the iphone in the left hand side menu and it would mount the files and I could browse around. Now I see a similar item in the menu but all I see are "Documents on Dusty's iPhone" and it lists out a few apps that are installed on my phone, but it doesn't give me any option to mount and browse files. > > There's some utils in the libimobiledevice-utils package that might > help with debug, possibly also try in selinux permissive mode to see > if something has changed there that might be affecting it. Tried disabling selinux but that didn't help. Dusty -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: iphone mount in nautilus on Fedora 24
On 07/11/2016 07:33 AM, Bastien Nocera wrote: > > > - Original Message - >>> On 07/09/2016 12:04 AM, Peter Robinson wrote: > In older Fedora (at least Fedora 22) I could easily mount my ihphone > in Nautilus. I could click on it in the left hand side of the File > Manager and it would mount. > > I am having trouble getting this same behavior in Fedora 24. Can > someone verify this works or does not work for them? You should be > able to verify this with Fedora 24 + Gnome + iphone + iphone cable. Support is provided by gvfs-afc through the libimobiledevice stack, the later hasn't really changed since F-22 when the 1.2.0 version fixed up support for the new iOS devices, upstream have confirmed that iOS 10 works with that version too [1], so not sure what might have broken. >>> >>> Hey Peter, thanks for responding. >>> >>> So things "work" just not as they used to. I can still mount the >>> files from the iphone if I use idevicepair and ifuse as described >>> at http://www.dedoimedo.com/computers/fedora-22-iphone.html >>> >>> The problem is when I'm using nautilus I used to just be able to click >>> on the iphone in the left hand side menu and it would mount the files >>> and I could browse around. Now I see a similar item in the menu but >>> all I see are "Documents on Dusty's iPhone" and it lists out a few apps >>> that are installed on my phone, but it doesn't give me any option to >>> mount and browse files. >>> >> >> Well there's been no change lower down the stack since F-22 and the >> core functionality seems to be working. That indicates it's either 1) >> a change in iOS version that has impacted this (I've no idea about >> this) or a change in the way gvfs deals with iOS/afc which looking at >> changelogs for 1.28 could be the case [1]. The one of interest seems >> to be commit 0b68656 >> >> [1] https://download.gnome.org/sources/gvfs/1.28/gvfs-1.28.0.changes Thanks Peter > > Yup. The "normal" mount contains nothing that normal users should access. > Accessing the photos will leave ghosts on the device, and there have been no > ways to update the music database in Linux for a few iOS releases. > > You can still access the device by editing the URL in the "Documents on..." > location. Just remove the ":3" at the end. > > If you have use cases that aren't the 2 mentioned above, or using your iDevice > as a thumb drive, please file bugs against gvfs in the upstream GNOME > Bugzilla. > Thanks Bastien. My use case is that I want to be able to copy pictures off of my phone and onto the computer. I simply copy them off of the phone, then eject phone from computer and then I delete them on the phone using the phones interface.. This is my method of recovering space on the phone. I used to be able to just double click the icon in Nautilus and drag/drop the pictures where I wanted them to go. Now I have to use the CLI to get the same functionality. Dusty -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: iphone mount in nautilus on Fedora 24
On 07/12/2016 05:01 AM, Bastien Nocera wrote: > > > Huh, the phone should still be getting mounted, but as a camera, and just as > a camera, and you can remove photos there without botching the phone's > internal > photo database. > > That definitely works here. > -- Yeah All I see are "documents on dusty's iphone" and it shows 4 apps that I have installed on my phone. The apps are random and have nothing to do with my pictures. Maybe I have a bad setup. Dusty -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: iphone mount in nautilus on Fedora 24
On 07/13/2016 08:49 AM, Bastien Nocera wrote: > > > - Original Message - >> >> >> On 07/12/2016 05:01 AM, Bastien Nocera wrote: >>> >>> >>> Huh, the phone should still be getting mounted, but as a camera, and just >>> as >>> a camera, and you can remove photos there without botching the phone's >>> internal >>> photo database. >>> >>> That definitely works here. >>> -- >> >> Yeah All I see are "documents on dusty's iphone" and it shows 4 apps >> that I have installed on my phone. The apps are random and have >> nothing to do with my pictures. >> >> Maybe I have a bad setup. > > It should be a separate mount. Make sure you have gvfs-gphoto2 installed as > well. > I did not have gvfs-gphoto2 installed. After installing it I now see the separate mount. Thanks for your help! Let me try to summarize. Can you please correct me if I'm wrong: - Before (Fedora 22) I didn't need this because a "generic mount" of the phone was supported. - Now (Fedora 24) I need gvfs-gphoto2 installed to access pictures on the iphone. I have a custom install so I don't know the answer to this question: - Is gvfs-gphoto2 get installed by default? Thanks again for the help Dusty -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
T460s + latest kernel doesn't boot
kernel-4.6.4-301.fc24.x86_64 Once I select the latest kernel in grub it then pops up and says Probing EDD (edd=off to disable)... OK and then nothing else and stays there. Anyone else having this problem? If i boot the original kernel from f24 (kernel-4.5.5-300.fc24.x86_64) then the system boots fine. Any tips? Thanks, Dusty -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: T460s + latest kernel doesn't boot
On 07/22/2016 09:00 AM, Fabio Alessandro Locati wrote: > On Fri, Jul 22, 2016 at 08:40:16AM -0400, Dusty Mabe wrote: >> >> >> kernel-4.6.4-301.fc24.x86_64 >> >> >> Once I select the latest kernel in grub it then pops up and says >> >> Probing EDD (edd=off to disable)... OK >> >> and then nothing else and stays there. >> >> Anyone else having this problem? If i boot the original kernel from f24 >> (kernel-4.5.5-300.fc24.x86_64) then the system boots fine. >> >> Any tips? > > It's a known bug and you got to update the BIOS. > > https://bugzilla.redhat.com/show_bug.cgi?id=1351943 > https://bugzilla.redhat.com/show_bug.cgi?id=1353103 > Thanks Fabio! My google fu did not lead me there. I appreciate it. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
iwl8000 driver in Fedora 24
I have the Lenovo T460s with the Intel Wireless AC 8260 chip in it. According to the page at [1], that chip is supported by the iwlwifi-8000 firmware. I don't see that package as an option in the Fedora 24 repos [2]. The newest I see is the 7260. Googling around hasn't led me to a solution. Anybody else having this same problem? Thanks, Dusty [1] http://www.intel.com/content/www/us/en/support/network-and-i-o/wireless-networking/05511.html [2] http://mirrors.rit.edu/fedora/fedora/linux/updates/24/x86_64/i/ -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: iwl8000 driver in Fedora 24
On 07/22/2016 09:40 AM, Josh Boyer wrote: > On Fri, Jul 22, 2016 at 9:30 AM, Dusty Mabe wrote: >> I have the Lenovo T460s with the Intel Wireless AC 8260 chip in it. >> According to the page at [1], that chip is supported by the >> iwlwifi-8000 firmware. I don't see that package as an option in the >> Fedora 24 repos [2]. The newest I see is the 7260. Googling around >> hasn't led me to a solution. Anybody else having this same problem? > > [jwboyer@x1 ~]$ rpm -ql iwl7260-firmware | grep 8000 > /usr/lib/firmware/iwlwifi-8000C-13.ucode > /usr/lib/firmware/iwlwifi-8000C-16.ucode > /usr/lib/firmware/iwlwifi-8000C-21.ucode > > It's packaged in the iwl7260-firmware package. > Thanks for the info. Could we have the info for the package updated to indicate that? [dustymabe@media ~]$ sudo dnf repoquery -i iwl7260-firmware Last metadata expiration check: 2:39:18 ago on Fri Jul 22 07:17:27 2016. Name: iwl7260-firmware Version : 25.30.13.0 Release : 65.fc24 Architecture: noarch Size: 3192506 License : Redistributable, no modification permitted Source RPM : linux-firmware-20160526-65.git80d463be.fc24.src.rpm Build Date : 2016-05-26 12:56 Packager: Fedora Project URL : http://www.kernel.org/ Summary : Firmware for Intel(R) Wireless WiFi Link 7260 Series Adapters Description : This package contains the firmware required by the Intel wireless drivers for Linux. Usage of the firmware is subject to the terms and conditions contained inside the provided LICENSE file. Please read it carefully. From the description/summary it seems that packaged is pretty focused and doesn't indicate it would work for anything else. If it would have read (and supports 8260) then I would have installed and use that from the beginning. Thanks again, Dusty -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: iwl8000 driver in Fedora 24
On 07/22/2016 10:22 AM, Josh Boyer wrote: > On Fri, Jul 22, 2016 at 9:59 AM, Dusty Mabe wrote: >> >> >> On 07/22/2016 09:40 AM, Josh Boyer wrote: >>> On Fri, Jul 22, 2016 at 9:30 AM, Dusty Mabe wrote: >>>> I have the Lenovo T460s with the Intel Wireless AC 8260 chip in it. >>>> According to the page at [1], that chip is supported by the >>>> iwlwifi-8000 firmware. I don't see that package as an option in the >>>> Fedora 24 repos [2]. The newest I see is the 7260. Googling around >>>> hasn't led me to a solution. Anybody else having this same problem? >>> >>> [jwboyer@x1 ~]$ rpm -ql iwl7260-firmware | grep 8000 >>> /usr/lib/firmware/iwlwifi-8000C-13.ucode >>> /usr/lib/firmware/iwlwifi-8000C-16.ucode >>> /usr/lib/firmware/iwlwifi-8000C-21.ucode >>> >>> It's packaged in the iwl7260-firmware package. >>> >> >> Thanks for the info. Could we have the info for the package updated to >> indicate that? > >> From the description/summary it seems that packaged is pretty focused >> and doesn't indicate it would work for anything else. >> >> If it would have read (and supports 8260) then I would have installed >> and use that from the beginning. > > Seems like a good suggestion. Care to send a patch? I'll look into it. Hopefully I'll have something by the end of today. > > FWIW, packaging the iwl firmware as split out subpackages has proven > to be a royal pain. > > josh > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Broken: Firefox 48 + Private Tab + Kerberos SSO
I can't seem to get firefox-48.0-5.fc24.x86_64 to work with kerberos single sign on in a private window. It works fine when using a non-private window. Any ideas on why this would have broken? Anyone else seeing this? Dusty -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
t460s fedora 24 - display freeze
Several times over the past month my t460s has just blank screens when I come back to it after some time. I don't know if the thing froze up completely or if it is just the display not working. I lock my screens (laptop + 2 external monitors) and then leave for an hour or so. When I come back no attempt at input will get the lockscreen to appear. I have to power down and then back up. After boot I look at the journal and I always tend to see some of these: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe C (start=167156 end=167157) time 146 us, min 1073, max 1079, scanline start 1072, end 1082 [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=488827 end=488828) time 107 us, min 1073, max 1079, scanline start 1072, end 1080 I'm not saying these are what is causing the issue but are at least something I noticed. I'll continue to monitor this problem. It only happens like once every two weeks so it is hard to prepare for it by knowing the IP address so that I can try to ssh in to see if the system is frozen or if it is just the screen. Has anyone else seen some behavior like this? I am using i3wm and my system is updated approximately once a week, so I should have close to the latest software installed. Thanks, Dusty ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: t460s fedora 24 - display freeze
On 09/20/2016 05:08 PM, Keith Keith wrote: > > I ran in to a problem that involved an unresponsive screen a few months ago > and also had a FIFO underrun. I think your problem is somewhere in the intel > graphics stack. Here's the bug I had: > https://bugzilla.redhat.com/show_bug.cgi?id=1339855 > https://bugs.freedesktop.org/show_bug.cgi?id=96284 Thanks > > I was able to determine the system wasn't frozen because I made a unit file > that ran a bash script that saved a file on shut down and then pressed my > power button. Systemd ran the script and I was able to see the file had been > updated. The fact that it was able to shutdown without me forcing it was > also a good sign that this was the case. Cool - I'll set up my system so I can determine if the bug is freezing the entire system or just the display. > > Some info about reporting these bugs is here: > https://01.org/linuxgraphics/documentation/how-report-bugs > > If you want to try some drivers that are close to the developer version > upstream you can try my copr repo: > https://copr.fedorainfracloud.org/coprs/bollocks/intelblood/packages/ > > It hasn't been updated in a month. I'm going to get on that today. I try > for once a week but since I no longer have any bugs I don't run it on my > machine and so I forget easily. Note that running these is probably crazy > experimental and the package maintainer(me) is far from an expert. Thanks! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: t460s fedora 24 - display freeze
On 09/20/2016 06:28 PM, Jonny Heggheim wrote: > I have not run into this issue on my T460s, using the latest BIOS on > Fedora 25. I can try to reproduce the error if you are able to give me > a more detailed walk-through. > > Jonny Heggheim Thanks Jonny, Are you in IRC? I may try to find you there and describe my system a little more. Dusty ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: t460s fedora 24 - display freeze
On 09/20/2016 07:22 PM, Andrew Lutomirski wrote: > On Sep 20, 2016 7:31 AM, "Dusty Mabe" <mailto:du...@dustymabe.com>> wrote: >> >> >> Several times over the past month my t460s has just blank screens >> when I come back to it after some time. I don't know if the thing >> froze up completely or if it is just the display not working. I lock >> my screens (laptop + 2 external monitors) and then leave for an hour >> or so. When I come back no attempt at input will get the lockscreen >> to appear. I have to power down and then back up. >> >> After boot I look at the journal and I always tend to see some of >> these: >> >> [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO >> underrun > > Sadly, i915 has had issues on and off with Skylake. :( > >> [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe C >> (start=167156 end=167157) time 146 us, min 1073, max 1079, scanline start >> 1072, end 1082 > > This smells like a bug that was fixed in the 4.8 series a bit late IIRC. > Search for i915 SAGV. Ok, I'll browse through the commit log. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: t460s fedora 24 - display freeze
On 09/21/2016 08:41 AM, Dusty Mabe wrote: > > > On 09/20/2016 07:22 PM, Andrew Lutomirski wrote: >> On Sep 20, 2016 7:31 AM, "Dusty Mabe" > <mailto:du...@dustymabe.com>> wrote: >>> >>> >>> Several times over the past month my t460s has just blank screens >>> when I come back to it after some time. I don't know if the thing >>> froze up completely or if it is just the display not working. I lock >>> my screens (laptop + 2 external monitors) and then leave for an hour >>> or so. When I come back no attempt at input will get the lockscreen >>> to appear. I have to power down and then back up. >>> >>> After boot I look at the journal and I always tend to see some of >>> these: >>> >>> [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO >>> underrun >> >> Sadly, i915 has had issues on and off with Skylake. > > :( > >> >>> [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe C >>> (start=167156 end=167157) time 146 us, min 1073, max 1079, scanline start >>> 1072, end 1082 >> >> This smells like a bug that was fixed in the 4.8 series a bit late IIRC. >> Search for i915 SAGV. > > Ok, I'll browse through the commit log. > I think this commit is probably the one that you were referring to: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f403372 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: t460s fedora 24 - display freeze
On 09/21/2016 09:05 AM, Dusty Mabe wrote: > > > On 09/21/2016 08:41 AM, Dusty Mabe wrote: >> >> >> On 09/20/2016 07:22 PM, Andrew Lutomirski wrote: >>> On Sep 20, 2016 7:31 AM, "Dusty Mabe" >> <mailto:du...@dustymabe.com>> wrote: >>>> >>>> >>>> Several times over the past month my t460s has just blank screens >>>> when I come back to it after some time. I don't know if the thing >>>> froze up completely or if it is just the display not working. I lock >>>> my screens (laptop + 2 external monitors) and then leave for an hour >>>> or so. When I come back no attempt at input will get the lockscreen >>>> to appear. I have to power down and then back up. >>>> >>>> After boot I look at the journal and I always tend to see some of >>>> these: >>>> >>>> [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO >>>> underrun >>> >>> Sadly, i915 has had issues on and off with Skylake. >> >> :( >> >>> >>>> [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe C >>>> (start=167156 end=167157) time 146 us, min 1073, max 1079, scanline start >>>> 1072, end 1082 >>> >>> This smells like a bug that was fixed in the 4.8 series a bit late IIRC. >>> Search for i915 SAGV. >> >> Ok, I'll browse through the commit log. >> > > I think this commit is probably the one that you were referring to: > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f403372 > This happened to me again today so I decided to grab the latest F25 kernel to see if that causes the problem to go away. kernel-4.8.0-0.rc6.git0.1.fc25.x86_64 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
unretire kompose package
I am trying to package [1] in fedora and there is a name conflict with an old/retired package [2] that no longer has an upstream. I have talked with the old maintainer (cc'd) and we would like to unretire the package and allow for the new project to assume the name in rpm. I'm attempting to follow the process described at [3]. I will request for the package to be unretired and file a ticket for releng to unblock the package. I have already had the new package spec file reviewed in Fedora [4]. Dusty [1] https://github.com/skippbox/kompose [2] https://admin.fedoraproject.org/pkgdb/package/rpms/kompose/ [3] https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package [4] https://bugzilla.redhat.com/show_bug.cgi?id=1379460 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: unretire kompose package
The package has been un-retired and I have started the process of putting the new kompose into place. Thanks! On 09/29/2016 03:48 PM, Dusty Mabe wrote: > > I am trying to package [1] in fedora and there is a name conflict with an > old/retired > package [2] that no longer has an upstream. I have talked with the old > maintainer (cc'd) > and we would like to unretire the package and allow for the new project to > assume the name > in rpm. > > I'm attempting to follow the process described at [3]. I will request for the > package > to be unretired and file a ticket for releng to unblock the package. > > I have already had the new package spec file reviewed in Fedora [4]. > > Dusty > > [1] https://github.com/skippbox/kompose > [2] https://admin.fedoraproject.org/pkgdb/package/rpms/kompose/ > [3] > https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package > [4] https://bugzilla.redhat.com/show_bug.cgi?id=1379460 > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20170227.n.0 compose check report
On 02/27/2017 09:41 PM, Adam Williamson wrote:
> On Mon, 2017-02-27 at 17:25 +, Fedora compose checker wrote:
>> Missing expected images:
>>
>> Atomic qcow2 x86_64
>
> There seems to be some sort of problem in pungi-make-ostree:
> https://kojipkgs.fedoraproject.org//work/tasks/1386/18091386/root.log
>
> DEBUG util.py:435: + pungi-make-ostree tree
> --repo=/mnt/koji/compose/atomic/rawhide/
> --log-dir=/mnt/koji/compose/rawhide/Fedora-Rawhide-20170227.n.0/logs/x86_64/Atomic/ostree-2
>
> --treefile=/mnt/koji/compose/rawhide/Fedora-Rawhide-20170227.n.0/work/ostree-2/config_repo/fedora-atomic-docker-host.json
>
> --extra-config=/mnt/koji/compose/rawhide/Fedora-Rawhide-20170227.n.0/work/ostree-2/extra_config.json
> DEBUG util.py:435: Traceback (most recent call last):
> DEBUG util.py:435:File "/usr/bin/pungi-make-ostree", line 15, in
> DEBUG util.py:435: ostree.main()
> DEBUG util.py:435:File
> "/usr/lib/python2.7/site-packages/pungi/ostree/__init__.py", line 85, in main
> DEBUG util.py:435: func()
> DEBUG util.py:435:File
> "/usr/lib/python2.7/site-packages/pungi/ostree/tree.py", line 95, in run
> DEBUG util.py:435: repos = extra_source_repos + [{'name':
> 'source_repo_from', 'baseurl': source_repo_from}]
> DEBUG util.py:435: TypeError: unsupported operand type(s) for +: 'NoneType'
> and 'list'
>
I'll try to track this down tomorrow when I'm not AFK, unless someone
else gets to it first. If you open an issue to track this then please link
me to it.
Dusty
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora 26-20170309.n.0 compose check report
On 03/09/2017 05:21 PM, Adam Williamson wrote: > On Thu, 2017-03-09 at 20:10 +, Fedora compose checker wrote: >> Missing expected images: >> >> Atomic qcow2 x86_64 >> Server dvd i386 >> Workstation live i386 >> Server boot i386 >> Atomic raw-xz x86_64 >> Workstation live x86_64 > > Atomic image builds seem to be failing in anaconda, with a blank screenshot: > https://koji.fedoraproject.org/koji/taskinfo?taskID=18277586 > https://koji.fedoraproject.org/koji/taskinfo?taskID=18277589 *note* I'm replying all - but some of my emails get rejected. I'll try to look at this weekend. Let me know if anyone else is looking at this or already knows what the issue is. Dusty ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: whatever happened to yum + btrfs snapshotting?
On 02/17/2015 07:53 AM, Neal Becker wrote: > Some time back there was discussion of being able to rollback yum updates via > btrfs snapshotting. As I recall, it turned out that the default btrfs > install > was not setup correctly to make this feasible (I had briefly tested it on my > machine). I haven't heard anything since - this seems like a great idea. > I've been using it for years. It takes a special setup, but works pretty well. http://dustymabe.com/2017/02/12/fedora-btrfssnapper-the-fedora-25-edition/ I do use some patches in grub from suse to take advantage of everything I need which is documented here: https://github.com/dustymabe/fedora-grub-boot-btrfs-default-subvolume/tree/master/fedora25 Dusty ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Default permissions on /dev/kvm
On 03/14/2017 04:29 PM, Daniel P. Berrange wrote: > > I'm fuzzy about the issue faced with containers. Containers will usually > have a separate /dev that is populated by the container mgmt engine (whether > docker, libvirt, lxc or something else). That mgmt engine is responsible for > setting permissions of /dev/kvm in the container's /dev if the user asked for > /dev/kvm to be made available. udev should never run inside a container - it > is only supposed to run in host context. So any udev rules that manipulate > /dev/kvm permissions will only ever be used in host context and never have > any effect on containers. > > The bug listed above doesn't actually describe any real problem with > containers & /dev/kvm - my reading is that the bug is just thinking > about a hypothetical future problem, but since udev isn't involved > in containers' /dev mgmt, I don't think there's a bug that needs fixing > here. $user here. The problem was real, but I don't know how legitimate the need for change is. I opened the bug so that we could have a discussion about it. Basically as a user that wants to run libvirt inside a container I was facing issues (permission denied). I noticed randomly that if I had installed qemu on the host before I tried to run libvirt inside of a container everything was fine. If I started from a fresh system (no qemu ever installed on the host) and tried to run that same container, I could not do it. Cole Robinson helped me track down that it was a permissions issue on /dev/kvm itself. Then I found the permission fixup code in the qemu rpm, which led me to think it might be better to open up the permissions even if qemu is not installed so that containerized libvirt use cases could succeed without having to workaround it. To workaround the person starting the container would need to change perms on /dev/kvm or have the container do that itself before running libvirt. I'm just saying that if we put this "hack" in qemu, then it seems like we might as well have it outside of qemu so that the 'qemu is delivered by a container' use case can work. Dusty ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Default permissions on /dev/kvm
On 03/14/2017 04:56 PM, Daniel J Walsh wrote: > > > On 03/14/2017 04:29 PM, Daniel P. Berrange wrote: > I guess if you volume/bind mount the device into the container you could > see an issue, > but most containers that deal with /dev/kvm are going to be run as root, > anyways. I was running with --privileged, still got permission denied until I changed permissions of /dev/kvm to 666. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Default permissions on /dev/kvm
On 03/14/2017 05:15 PM, Daniel J Walsh wrote: > > > On 03/14/2017 05:02 PM, Dusty Mabe wrote: >> >> On 03/14/2017 04:56 PM, Daniel J Walsh wrote: >>> >>> On 03/14/2017 04:29 PM, Daniel P. Berrange wrote: >>> I guess if you volume/bind mount the device into the container you could >>> see an issue, >>> but most containers that deal with /dev/kvm are going to be run as root, >>> anyways. >> I was running with --privileged, still got permission denied until I >> changed permissions of /dev/kvm to 666. >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > # docker run -ti --device /dev/kvm fedora ls -lZ /dev/kvm > crw-rw-rw-. 1 root 36 system_u:object_r:container_file_t:s0:c303,c737 10, 232 > Mar 14 21:12 /dev/kvm > # chmod 600 /dev/kvm > # docker run -ti --device /dev/kvm fedora ls -lZ /dev/kvm > crw---. 1 root 36 system_u:object_r:container_file_t:s0:c281,c442 10, 232 > Mar 14 21:13 /dev/kvm > > So using --device to add the device to the container just maintains the > permission of the host > for the device you added. Whether it is volume mounted in or specified via > --device, at least > from dockers point of view. I'm not sure of your point. I was just trying to say that whether i was root or not did not seem to matter. I still got permission denied if perms were 600 and not 666. I'm working off of memory here, so it's possible somebody will prove me wrong. Dusty ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Default permissions on /dev/kvm
On 03/15/2017 05:17 AM, Daniel P. Berrange wrote: > > Sure, if udev maintainers are willing to ship the kvm rule by default, > that's fine with me for reason you suggest. I simply don't think it'll > have any effect on usage of /dev/kvm inside containers > Does that mean you assume my scenario I outlined is incorrect? The only reason we are having this discussion is because i found that changing the permissions of /dev/kvm on the host from 600 to 666 made it so that I could run libvirt inside a container, which would mean that if does have an effect on usage of /dev/kvm inside a container. I could be "using it wrong", but would like for you to tell me why what I'm doing is invalid. Dusty ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Default permissions on /dev/kvm
On 03/15/2017 11:49 AM, Daniel P. Berrange wrote: > On Wed, Mar 15, 2017 at 11:32:35AM -0400, Dusty Mabe wrote: >> >> >> On 03/15/2017 05:17 AM, Daniel P. Berrange wrote: >>> >>> Sure, if udev maintainers are willing to ship the kvm rule by default, >>> that's fine with me for reason you suggest. I simply don't think it'll >>> have any effect on usage of /dev/kvm inside containers >>> >> >> Does that mean you assume my scenario I outlined is incorrect? The >> only reason we are having this discussion is because i found that >> changing the permissions of /dev/kvm on the host from 600 to 666 made >> it so that I could run libvirt inside a container, which would mean >> that if does have an effect on usage of /dev/kvm inside a container. > > Oh, wait I think I see - you don't have qemu installed in the host > at all - you only installed it inside a docker image, but docker > is just copying the host permissions, and thus see the default > permissions from the kernel. right >> I could be "using it wrong", but would like for you to tell me why >> what I'm doing is invalid. > > While Docker copies the permissions from host devices, I don't think > that is something it is nice to rely on. Different operating systems > have different views on what default permissions are. So if you build > a Docker image that relies on the host OS having given /dev/kvm > particular permissions, your Docker image is going to be non-portable. > > IOW while moving the udev rule out of the QEMU rpm into the udev RPM > would fix it for future Fedora, your docker image is going to be > unable to reliably run on other OS distros (whether older Fedora or > Debian which has restrictive /dev/kvm by default). > > I don't see any way to force docker to give the device different > permissions when using the --device flag to launch a container. > In absence of that the only other option is to use an entrypoint > script to chmod the file when your container starts, but that > requires the container to run privileged which is bad. I think > ideally Docker would provide some way to give explicit permissions > so your container is isolated from decisions OS distros make about > default permissions in the host. > Thanks for the explanation. Maybe we should just leave things like they are in Fedora then and not worry with changing systemd since it looks like we won't be able to get them to change it to 666 by default anyway. Should we just cancel our request? I think any change other than 666 perms would probably cause more problems than it would solve. Dusty ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Self Introduction: Olzhas Rakhimov
On 03/19/2017 07:17 PM, Olzhas Rakhimov wrote: > Hello everybody, > > My name is Olzhas Rakhimov. I am an open-source enthusiast > (https://github.com/rakhimov). > I'd like to package https://github.com/rakhimov/scram > The review request: https://bugzilla.redhat.com/show_bug.cgi?id=1433686 > > SCRAM is a Command-line Risk Analysis Multi-tool. > It can perform static fault tree analysis, > analysis with common cause failure models, > probability calculations with importance analysis, > and uncertainty analysis with Monte Carlo simulations. > This project supports the Open-PSA Model Exchange Format open standard: > https://open-psa.github.io/mef/ > > It is already packaged in Debian Science > (https://blends.debian.org/science/tasks/engineering), > so I hope this project be packaged in SciTech SIG in Fedora. > The tool is relevant to reliability, industrial, mechanical, > and other engineering. > > I love hacking on C++ and Python. Checkout my other project: > cppdep - C/C++ Dependency Analyzer (https://github.com/rakhimov/cppdep). > > Regards, > Olzhas Rakhimov Hi Olzhas, Welcome to the community! Dusty ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: pagure notification outage
Adding in fedora-devel
On 04/05/2017 10:23 AM, Dusty Mabe wrote:
>
> I've identified that we have not been getting notifications from
> pagure for the past few days. I'm working with pingou to resolve this.
We were not getting pagure notifications to our cloud mailing list.
It turns out this is related to a global "ban rule" on our mailing
lists that matches ^.*\+.*\d{3,}@ against address or messageID.
One example message id from a message that was discarded is:
DISCARD:
Re: pagure notification outage
On 04/05/2017 11:06 AM, Dusty Mabe wrote:
>
> Adding in fedora-devel
>
> On 04/05/2017 10:23 AM, Dusty Mabe wrote:
>>
>> I've identified that we have not been getting notifications from
>> pagure for the past few days. I'm working with pingou to resolve this.
>
> We were not getting pagure notifications to our cloud mailing list.
>
> It turns out this is related to a global "ban rule" on our mailing
> lists that matches ^.*\+.*\d{3,}@ against address or messageID.
>
> One example message id from a message that was discarded is:
> DISCARD: rule_hits': ['banned-address']
>
> Most emails get through because they don't contain 3 consecutive
> digits, but some get banned because they do. This means we have been
> missing some notifications randomly over time. For this list we just
> happened to have been unlucky enough over the past few days for it to
> happen to us many times and for us to notice.
>
> Patrick is tracking this down now.
Patrick is done with his investigation/fix:
The summary is that some of the Pagure reply-to headers were matching an
antispam filter that was added to a limited set of lists. Patrick has put
in a fix and all email notifications from pagure should now all be making
it to the lists.
Dusty
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: switching libcurl back to OpenSSL and providing the libcurl-minimal subpackage
On 04/05/2017 12:17 PM, Kamil Dudka wrote: > On Wednesday, April 05, 2017 11:38:35 Colin Walters wrote: >> >> libostree does that - >> https://github.com/ostreedev/ostree/blob/c937305c0e7f5609273e25753912c294b0 >> 40a6ac/src/libostree/ostree-fetcher-curl.c >> >> In the exploded archive case, I get quite a lot of speedup. >> >> librepo is not quite as good at this yet, but it matters less for RPMs. > > I cannot see CURLOPT_PIPEWAIT or CURLMOPT_PIPELINING options in your code. > They are needed if you want to take advantage of the core HTTP/2 features. > Otherwise you can slightly benefit from the compressed HTTP headers but you > are not using the HTTP/2 pipelining/multiplexing. I would suggest to have a > look at the http2-download.c example: > > https://github.com/curl/curl/blob/curl-7_53_0/docs/examples/http2-download.c FYI: https://github.com/ostreedev/ostree/pull/780 Thanks for your suggestion! Dusty ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora CI effort/Interest Group
On 04/12/2017 10:49 AM, Neal Gompa wrote: > On Wed, Apr 12, 2017 at 10:46 AM, Pierre-Yves Chibon > wrote: >> On Wed, Apr 12, 2017 at 10:18:33AM -0400, Neal Gompa wrote: >>> On Wed, Apr 12, 2017 at 10:14 AM, Matthew Miller >>> wrote: On Wed, Apr 12, 2017 at 12:37:47PM +0200, Pierre-Yves Chibon wrote: > I have put together a wiki page making this a change proposal: > https://fedoraproject.org/wiki/Changes/FedoraAtomicCI I'd actually like to escalate this from a Change proposal (which generally fit into Fedora releases) to a Council-level project Objective. That basically means rename to https://fedoraproject.org/wiki/Objective/FedoraAtomicCI and file a council ticket. :) >>> >>> Why call this "Atomic CI"? Can't we call this something better that >>> reflects that it would be beneficial for the entire distribution, >>> rather than a small subset of Fedorans working in Project Atomic? >> >> The idea is to start with something that has a limited impact, I believe the >> idea is to build up the pipeline in such a way that it can scale to the >> entire >> distribution, but we need to start somewhere and Atomic Host is a >> deliverable in >> itself and as a small set of packages making it easier to control and >> experiment >> with. >> Does that make sense? >> > > Sure, it does, but if this becomes an actual aspect of Fedora, as > Matthew Miller wants (and it makes sense), then it makes little > sense to call the thing Atomic CI. Instead CI for Atomic would > be the first goal, but the overall aim is for the whole distribution. > +1 - The overall effort should be called something more generic, where the first stage is to implement for atomic host. Dusty ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Self Introduction: Thanos Apostolou
On 05/18/2017 11:42 AM, Thanos Apostolou wrote: > Hi, my name is Thanos Apostolou and I am from Greece. I am studying > Electrical and Computer Engineering in the National Technical University of > Athens. Hi Thanos, Big welcome to you! > > > > My linux experience, so far, is this: > > I was using Ubuntu since 2012 and I was active in the askubuntu.com, where I > was trying to help people solving problems, while expanding my knowledge at > the same time. > > Then I moved to arch based distros at 2016 where I settled with Manjaro. I > learned there how to create PKGBUILDs. > I've been active on the Manjaro forum, I have been doing a few Pull Requests > to Manjaro Github Repositories in order to improve/update certain packages. > I also maintain the Manjaro Lxde Community Edition. > > Recently I decided to move to Fedora as it feels more "Professional" and > higher quality distribution. Glad to have you on board :) > So, I believe that Fedora provides a better user experience. > Additionally, I will be able to improve my knowledge by learning Fedora's > infrastructure. > However Fedora doesn't have the AUR and it's missing a lot of packages that I > needed, so I learned how to create simple RPM packages and how to use COPR. > > > > I've seen many users (especially youtubers) avoiding Fedora because of some > missing packages and because it's not so user friendly. > So, my goal is to contribute to Fedora by creating some simple packages which > I've seen many people ask for. Amazing! Packagers are the unsung heroes of open source. > Because of my University's workload, I don't have much time in order to do > more complex tasks, so in the beginning I want to make packages for some > themes and some simple software (like compton). > When I get enough experience, in the future, I might get involved with some > more difficult tasks. > If you're interested at all in cloud or containers feel free to join me and others in #fedora-cloud on freenode. > > > > > For start, I have created this Review Request for vertex-theme which works > good with the latest gtk versions and looks awesome with gtk Fedora spins: > https://bugzilla.redhat.com/show_bug.cgi?id=1451298 > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: retiring git-annex
On 05/28/2017 12:39 PM, Richard W.M. Jones wrote: > On Sat, May 27, 2017 at 04:00:32PM +0200, Björn 'besser82' Esser wrote: >> Am 27.05.2017 um 15:13 schrieb Jens-Ulrik Petersen: >>> Hi, >>> >>> I think we need to retire git-annex from Fedora (the current >>> version is very old and has security issues), since to build >>> current versions needs adding a lot of new Haskell dependencies to >>> Fedora. >>> >>> Currently noone has expressed interested in doing this... I plan >>> to make a copr repo later at some point. So unless someone wants >>> to help do a lot of package reviews, I think it is better just to >>> retire git-annex from Fedora for now. >>> >>> I will do that next week unless someone volunteers to do all the >>> work to update. >>> >>> I am writing on behalf of Ben who is on away and the Haskell SIG. >>> >>> Thanks, Jens >> >> Well, if someone would file the needed dependencies for review, I'd >> be happy to review them; just drop me a mail with all links to rhbz… > > I can help reviews too. I also need git-annex! > > Rich. > I use it quite a bit for personal use. Would hate to see it go. Unfortunately I know nothing about haskell :( Dusty ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: retiring git-annex
On 05/29/2017 09:16 AM, Jens-Ulrik Petersen wrote: > Okay thanks for all the offers of help! > > I will post more details tomorrow then. > I saw a link to a copr come through, but not much on how to get git-annex fixed in Fedora proper. Any info for that? Unfortunately /me knows nothing about haskell, but I might be able to help in other ways. Dusty ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: Graphical Applications as Flatpaks
On 07/14/2017 05:04 PM, Richard Hughes wrote: > On 14 July 2017 at 20:28, Andreas Tunek wrote: >> Is this really more reliable than using dnf (for graphical packages >> like Recepies and Builder)? > > It's hugely more reliable. You can't actually trust rpm to do anything > atomically, and this is the main reason we force upgrade to be offline > in the workstation product. Just doing this one step reduced the > number of people experiencing the dead-system-after-upgrading bugs by > two order of magnitude, but it SUCKS to have to reboot to apply > application updates. Doing live updates with rpm is a bit like doing > maintenance on your car engine while driving down the freeway. Most of > the time it's fine, and you feel awesome. 0.001% of the time you die > in a huge fireball. I'm sure some people are aware but for those who aren't it is worth noting that we have an entire edition (atomic host) that is built around atomic updates for rpm content. We are starting to make progress with a workstation variant that is built on the same technology. [1] https://getfedora.org/atomic/download/ [2] https://download.fedoraproject.org/pub/fedora/linux/releases/26/Workstation/x86_64/iso/Fedora-Workstation-ostree-x86_64-26-1.5.iso ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Making mailman3/hyperkitty send my emails to me
I have played with all of the settings in hyperkitty and I still am failing to get the emails that I compose and send to a mailing list also sent back to me. The reason I want this is because of the "archived-at" email header. Once I compose an email and get it sent to me from mailman it will have that header in the email and I'll be able to copy/paste a permalink to it easily (see [1]). Anyone experiencing the same issue? Thanks, Dusty [1] http://dustymabe.com/2016/01/10/archived-at-email-header-from-mailman-3-lists/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Making mailman3/hyperkitty send my emails to me
On 02/10/2016 01:05 PM, Kevin Fenzi wrote: > On Wed, 10 Feb 2016 12:39:51 -0500 > Dusty Mabe wrote: > >> I have played with all of the settings in hyperkitty and I still am >> failing to get the emails that I compose and send to a mailing list >> also sent back to me. >> >> The reason I want this is because of the "archived-at" email header. >> Once I compose an email and get it sent to me from mailman it will >> have that header in the email and I'll be able to copy/paste a >> permalink to it easily (see [1]). > > Well, there's 3 places in postorius that could be in play... > > Under subscriptions settings: > Under Global settings -> Receive own postings > Under Address-based settings -> Receive own postings (for the address > you are sending/subscribed with). > Under Subscription based settings -> Receive own postings (for the > list). > > Obviously the subscription settings override the address based/global > ones, and address based override global, etc. > > So, if the setting is set in the right place there, I can only think it > might be a bug, and ask you to file a ticket on it? Thanks Kevin. I'm playing around with settings now to see if I can get it. I can file a bug if needed. Is this the right place: https://gitlab.com/mailman/hyperkitty/issues It would be nice if I can get anyone to speak up and say "it works for me" so that I can further investigate my settings before I open an issue. - Dusty -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Making mailman3/hyperkitty send my emails to me
On 02/10/2016 02:38 PM, Kevin Fenzi wrote: > On Wed, 10 Feb 2016 14:03:48 -0500 > Dusty Mabe wrote: > >> Thanks Kevin. I'm playing around with settings now to see if I can get >> it. I can file a bug if needed. Is this the right place: >> >> https://gitlab.com/mailman/hyperkitty/issues > > Actually this is either postorius (the admin interface) or mailman3 > itself. Hyperkitty is just the archiver/web forum part. > >> It would be nice if I can get anyone to speak up and say "it works for >> me" so that I can further investigate my settings before I open an >> issue. > > Well, I just updated mine, lets see what happens on this post. :) > Oh the suspense!! -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Making mailman3/hyperkitty send my emails to me
On 02/10/2016 02:51 PM, Kevin Fenzi wrote: > On Wed, 10 Feb 2016 14:47:56 -0500 > Dusty Mabe wrote: > >> On 02/10/2016 02:38 PM, Kevin Fenzi wrote: >>> On Wed, 10 Feb 2016 14:03:48 -0500 >>> Dusty Mabe wrote: >>> >>>> Thanks Kevin. I'm playing around with settings now to see if I can >>>> get it. I can file a bug if needed. Is this the right place: >>>> >>>> https://gitlab.com/mailman/hyperkitty/issues >>> >>> Actually this is either postorius (the admin interface) or mailman3 >>> itself. Hyperkitty is just the archiver/web forum part. >>> >>>> It would be nice if I can get anyone to speak up and say "it works >>>> for me" so that I can further investigate my settings before I >>>> open an issue. >>> >>> Well, I just updated mine, lets see what happens on this post. :) >>> >> >> Oh the suspense!! > > It mailed me a copy of my post just fine. :) > Yeah. I'm aggregating my email through gmail hence you get stuff that doesn't work like it should. See below summary of the problem: http://wiki.list.org/DOC/I%20use%20Gmail-Googlemail%2C%20but%20I%20can't%20tell%20if%20any%20of%20my%20messages%20have%20been%20posted%20to%20the%20list -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
fc24 packages when running dnf on f25
Is it normal to have fc24 packages get installed when I install a package on F25? This system started as an F25 cloud instance based on the cloud image. $ rpm -qa | grep fc24 | wc -l 116 $ cat /etc/redhat-release Fedora release 25 (Twenty Five) - Dusty ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: fc24 packages when running dnf on f25
On 11/07/2016 11:03 PM, Orion Poplawski wrote: > On 11/07/2016 08:52 PM, Dusty Mabe wrote: >> Is it normal to have fc24 packages get installed when I install a package on >> F25? >> This system started as an F25 cloud instance based on the cloud image. >> >> $ rpm -qa | grep fc24 | wc -l >> 116 >> $ cat /etc/redhat-release >> Fedora release 25 (Twenty Five) >> >> - Dusty > > We didn't have a mass rebuild for F25, so yes. > > Thanks for the info. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
new gemspec behavior in rawhide
Hey all, In my vagrant-sshfs rpm i call `gem spec` here [0]. In rawhide vs f25 I get differing outputs. Basically in rawhide I get a bunch of `.freeze` added to my strings like: s.authors = ["Dusty Mabe".freeze] See the full diff at [1]. This is causing pain for me because I actually patch the gemspec file. Was this a desired change? Thanks, Dusty [0] http://pkgs.fedoraproject.org/cgit/rpms/vagrant-sshfs.git/tree/vagrant-sshfs.spec?h=f25#n43 [1] https://gist.github.com/dustymabe/b8a467581c9b5ee4473c1649e6c6aacc/revisions ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: new gemspec behavior in rawhide
On 11/26/2016 12:31 PM, Mamoru TASAKA wrote: > Dusty Mabe wrote on 11/27/2016 01:35 AM: >> >> Hey all, >> >> In my vagrant-sshfs rpm i call `gem spec` here [0]. In rawhide vs f25 I get >> differing >> outputs. Basically in rawhide I get a bunch of `.freeze` added to my strings >> like: >> >> s.authors = ["Dusty Mabe".freeze] >> >> See the full diff at [1]. This is causing pain for me because I actually >> patch the >> gemspec file. Was this a desired change? >> >> Thanks, >> Dusty >> >> [0] >> http://pkgs.fedoraproject.org/cgit/rpms/vagrant-sshfs.git/tree/vagrant-sshfs.spec?h=f25#n43 >> [1] >> https://gist.github.com/dustymabe/b8a467581c9b5ee4473c1649e6c6aacc/revisions > > This change was introduced in ruby 2.3.2 . See ruby-sig discussion: > https://lists.fedoraproject.org/archives/list/ruby-...@lists.fedoraproject.org/thread/PP6SA43POR5OL34BCQMIORTTMPB3NWIN/ Thanks for the pointer. Dusty ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
bex represents pagure emails in hyperkitty
The atomic working group has configured pagure to send notifications to the cloud mailing list. These notifications come through as normal emails but for some reason in hyperkitty the emails from pagure show up as coming from Brian Exelbierd (bex). Anyone know why that is? You can see that he has the most posts on the summary page: https://lists.fedoraproject.org/archives/list/cl...@lists.fedoraproject.org/ Here is an example of a single email that looks like it is coming from him: https://lists.fedoraproject.org/archives/list/cl...@lists.fedoraproject.org/thread/EI6QCHLZSM3UDEPM6OWQPJCQ4R7DA5WC/ Dusty ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Changing default "docker" storage to to Overlay2 in Fedora 26
On 01/18/2017 03:50 PM, Igor Gnatenko wrote: > On Wed, Jan 18, 2017 at 9:48 PM, Dusty Mabe wrote: >> >> >> On 01/06/2017 03:29 PM, Daniel J Walsh wrote: >>> https://fedoraproject.org/wiki/Changes/DockerOverlay2 >> >> Can we get this onto the "official looking" page for F26 changes [1]? > Change initiator should add it to category ReadyForWrangler and this > change will be discussed on next (or after next) FESCo meeting. I see this on that page already: Category:ChangeReadyForWrangler Does that work? Dusty ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Changing default "docker" storage to to Overlay2 in Fedora 26
On 01/06/2017 03:29 PM, Daniel J Walsh wrote: > https://fedoraproject.org/wiki/Changes/DockerOverlay2 Can we get this onto the "official looking" page for F26 changes [1]? Do we also need to document in here the different configurations for the different variants? Atomic Host vs Server vs Workstation? Dusty [1] https://fedoraproject.org/wiki/Releases/26/ChangeSet ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 Self Contained Change: Container Minimal Image
On 01/31/2017 10:35 AM, Peter Robinson wrote: > On Tue, Jan 31, 2017 at 8:00 AM, Jan Kurik wrote: >> = Proposed Self Contained Change: Container Minimal Image = >> https://fedoraproject.org/wiki/Changes/ContainerMinimalImage >> >> Change owner(s): >> * Dusty Mabe >> >> >> Produce a new container image that contains as little as possible, but >> also still provides the ability to install packages from dnf >> repositories. > > How's this different to the minimal container we currently ship? The goal is to get it smaller that what we currently ship. Part of this is being done by removing dnf (and thus python) from the image by using microdnf instead. The goal really is to rip out most anything that doesn't make sense and/or is bloated for a container use case. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 Self Contained Change: Container Minimal Image
On 01/31/2017 09:54 AM, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Jan 31, 2017 at 09:00:01AM +0100, Jan Kurik wrote: >> = Proposed Self Contained Change: Container Minimal Image = >> https://fedoraproject.org/wiki/Changes/ContainerMinimalImage >> >> Change owner(s): >> * Dusty Mabe >> >> >> Produce a new container image that contains as little as possible, but >> also still provides the ability to install packages from dnf >> repositories. > > Would this be an official image or just a "contrib" kickstart? > If the first, shouldn't it be added to the list of deliverables, and > who's going to test it, etc. > I would hope that this would be an official image. I imagine testing would be a joint effort between the atomic WG and the QA team. This is my first go-round on this front so I welcome guidance on the appropriate process to take. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Atomic Host Two Week Release Announcement: 29.20191001.0
On 10/2/19 5:25 PM, nore...@fedoraproject.org wrote: > > A new Fedora Atomic Host update is available via an OSTree update: > > Version: 29.20191001.0 > Commit(x86_64): > 15b8a10f8b587c2a037a592806dc04e9cdf6ab1c73c6e49fdaacab1b1174b9ab > Commit(aarch64): > 2b83282e976249b8e1910a7292379753b006851078e9bcea279ff3b6483ee602 > Commit(ppc64le): > 7ed4f0395e22000ffe372132c791a8dded291063d5c184e2470dde13c0eb3ba2 > > > We are releasing images from multiple architectures but please note > that x86_64 architecture is the only one that undergoes automated > testing at this time. > > Existing systems can be upgraded in place via e.g. `atomic host upgrade`. > > Corresponding image media for new installations can be downloaded from: > > https://getfedora.org/en/atomic/download/ > > Alternatively, image artifacts can be found at the following links: > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20191001.0.aarch64.qcow2 > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20191001.0.aarch64.raw.xz > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-29-20191001.0.iso > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20191001.0.ppc64le.qcow2 > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20191001.0.ppc64le.raw.xz > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-29-20191001.0.iso > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20191001.0.x86_64.qcow2 > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20191001.0.x86_64.raw.xz > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20191001.0.x86_64.vagrant-libvirt.box > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20191001.0.x86_64.vagrant-virtualbox.box > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-29-20191001.0.iso > > Respective signed CHECKSUM files can be found here: > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20191001.0-aarch64-CHECKSUM > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-29-20191001.0-aarch64-CHECKSUM > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20191001.0-ppc64le-CHECKSUM > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-29-20191001.0-ppc64le-CHECKSUM > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20191001.0-x86_64-CHECKSUM > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-29-20191001.0-x86_64-CHECKSUM > > For direct download, the "latest" targets are always available here: > x86_64: > https://getfedora.org/atomic_qcow2_x86_64_latest > https://getfedora.org/atomic_raw_x86_64_latest > https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest > https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest > https://getfedora.org/atomic_dvd_ostree_x86_64_latest > > aarch64: > https://getfedora.org/atomic_qcow2_aarch64_latest > https://getfedora.org/atomic_raw_aarch64_latest > https://getfedora.org/atomic_dvd_ostree_aarch64_latest > > ppc64le: > https://getfedora.org/atomic_qcow2_ppc64le_latest > https://getfedora.org/atomic_raw_ppc64le_latest > https://getfedora.org/atomic_dvd_ostree_ppc64le_latest > > Filename fetching URLs are available here: > x86_64: > https://getfedora.org/atomic_qcow2_x86_64_latest_filename > https://getfedora.org/atomic_raw_x86_64_latest_filename > https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest_filename > https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest_filename > https://getfedora.org/atomic_dvd_ostree_x86_64_latest_filename > > aarch64: > https://getfedora.org/atomic_qcow2_aarch64_latest_filename > https://getfedora.org/atomic_raw_aarch64_latest_filename > https://getfedora.org/atomic_dvd_ostree_aarch64_latest_filename >
Fedora Atomic Host Nearing End Of Life
This content also exists at: https://www.projectatomic.io/blog/2019/11/fedora-atomic-host-nearing-eol/ Last year we [introduced the plans for Fedora CoreOS] [1] including that Fedora CoreOS would be the successor to Fedora Atomic Host and Container Linux (from CoreOS Inc.). As part of that succession plan we decided that Fedora 29 Atomic Host would be the last stream of Fedora Atomic Host to be released. Fedora 29 Atomic Host has served us well, but with Fedora 29 End of Life coming soon [2], so will the last release of Fedora 29 Atomic Host. The next release of Fedora 29 Atomic Host (in the next few weeks) will be the last two-week release. It will contain all of the latest content from Fedora 29. After that release, Fedora 29, and Fedora 29 Atomic Host will no longer receive any updates. Please try out the Fedora CoreOS preview to help us get it towards stable. Documentation and download links can be found at https://getfedora.org/coreos/ The Atomic Host Team [1] https://fedoramagazine.org/announcing-fedora-coreos/ [2] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VUK3CJ5LO4ROUH3JTCDVHYAVVYAOCU62/ ___ 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: Fedora Atomic Host Nearing End Of Life
On 11/25/19 11:41 AM, Normand wrote: > > > On 11/21/19 11:33 PM, Dusty Mabe wrote: >> This content also exists at: >> https://www.projectatomic.io/blog/2019/11/fedora-atomic-host-nearing-eol/ >> >> Last year we [introduced the plans for Fedora CoreOS] [1] including that >> Fedora CoreOS would be the successor to Fedora Atomic Host and Container >> Linux (from CoreOS Inc.). As part of that succession plan we decided that >> Fedora 29 Atomic Host would be the last stream of Fedora Atomic Host to be >> released. >> >> Fedora 29 Atomic Host has served us well, but with Fedora 29 End of >> Life coming soon [2], so will the last release of Fedora 29 Atomic Host. >> The next release of Fedora 29 Atomic Host (in the next few weeks) will be >> the last two-week release. It will contain all of the latest content >> from Fedora 29. After that release, Fedora 29, and Fedora 29 Atomic >> Host will no longer receive any updates. >> >> Please try out the Fedora CoreOS preview to help us get it towards >> stable. Documentation and download links can be found at >> https://getfedora.org/coreos/ >> >> The Atomic Host Team >> >> [1] https://fedoramagazine.org/announcing-fedora-coreos/ >> [2] >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VUK3CJ5LO4ROUH3JTCDVHYAVVYAOCU62/ >> ___ >> 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 >> > > > Thanks for the info, > > But what about arches that are not x86_64 ? > Where could we found for exemple the ppc64le coreos replacement of > Atomic Host ? Is there already a web page to retrieve them ? > Hi Normand, Thank you for bringing this up. You have indeed pointed out a gap in what we're currently delivering with Fedora CoreOS preview and what we were delivering with Atomic Host. The good news is that we have done enablement work to allow for Fedora CoreOS to be run on other platforms. The bad news is that we don't currently run our build infrastructure in an environment that has other architectures available. So while you can build it yourself today, there is currently no where to download it from the Fedora website. I have added Jakub Cajka who was working on getting some space to host unofficial builds of Fedora CoreOS for other architectures for now. I'll also link you to our open issues where we're working through our strategy for delivering multi-arch FCOS: - https://github.com/coreos/fedora-coreos-tracker/issues/262 - https://pagure.io/fedora-infrastructure/issue/8370 - Dusty ___ 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: Xen / EC2 release criteria proposal
On 8/9/19 8:56 PM, Adam Williamson wrote: > Hey folks! I'm starting a new thread for this to trim the recipient > list a bit and include devel@ and coreos@. Hey Adam! > > The Story So Far: there is a Fedora release criterion which requires > Fedora to boot on Xen: > > "The release must boot successfully as Xen DomU with releases providing > a functional, supported Xen Dom0 and widely used cloud providers > utilizing Xen." > > We (QA group) had a discussion about removing this criterion entirely. > That has now morphed into the idea that we should tweak it to be > focused exclusively on the "widely used cloud providers utilizing > Xen"...by which we mean EC2. At the time this criterion was invented, > all EC2 instance types used Xen; now, some still use Xen, and some use > KVM. > > So it seems like this would also be a good opportunity to revisit and > nail down more specifically exactly what our cloud requirements are. > bcotton suggested that we require two sample instance types to be > tested, c5.large (KVM) and t3.large (Xen). (I've also mailed Thomas > Cameron, ex-of Red Hat, now of Amazon, for his opinion, as it seemed > like it might be worthwhile - he's promised to get back to me). > > So, for now, let me propose this as a trial balloon: we rewrite the > above criterion to say: > > "Release-blocking cloud disk images must be published to Amazon EC2 as > AMIs, and these must boot successfully and meet other relevant release > criteria on c5.large and t3.large instance types." Sounds good to me if we trim it down to a few instance types that we think will cover Xen and KVM based booting in EC2. For Fedora CoreOS we'll be doing some automated testing in EC2. I don't know if we have a certain set of instance types we'll be using for that, but the information that Matt provided should help us decide. Dusty ___ 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: Orphaning cloud-init, python-boto
On 8/10/19 9:06 PM, Garrett Holmstrom wrote: > Hi, > > My time to work on Fedora cloud-related things has diminished in > recent months, so I have not been able to give the cloud-init and > python-boto packages the care they deserve. They are free to a good > home. > Maybe larks (cc) would be interested. Dusty ___ 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: Orphaning cloud-init, python-boto
On 8/10/19 9:06 PM, Garrett Holmstrom wrote: > Hi, > > My time to work on Fedora cloud-related things has diminished in > recent months, so I have not been able to give the cloud-init and > python-boto packages the care they deserve. They are free to a good > home. > Can you give cloud-init to me and major hayden (@mhayden) for now? Dusty ___ 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: Fedora-29-updates-testing-20190819.0 compose check report
On 8/19/19 1:18 AM, Sinny Kumari wrote: > From the build logs [1] [2] , it looks like disk got full which could be > builder specific. We can dig in more if it happens again. > > [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=37134473 > [2] > https://kojipkgs.fedoraproject.org//work/tasks/4473/37134473/screenshot.ppm > > Thanks for looking Sinny! ___ 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: fedora-gpg-keys not updated yet again
On 8/19/19 6:59 AM, Pavel Raiskup wrote: > On Monday, August 19, 2019 10:50:52 AM CEST Zbigniew Jędrzejewski-Szmek wrote: >> Can we *please* send out the FN+1 and FN+2 keys a month before branching, >> to *all* releases of Fedora, so we can avoid this pointless scramble? > > What about to have F33 keys right now, when the fresh F31 branch is out? > +1. Go ahead and make the f33 keys when we branch for f31. ___ 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: Fedora Atomic Host Two Week Release Announcement: 29.20190820.0
On 8/21/19 5:46 AM, Normand wrote: > > > On 8/20/19 7:56 PM, nore...@fedoraproject.org wrote: >> We are releasing images from multiple architectures but please note >> that x86_64 architecture is the only one that undergoes automated >> testing at this time. > > Is there wiki pages that describe what are those automated tests, and > how/where they have been run ? > We run tests in openqa and autocloud. The links are listed in the release doc that we follow: https://pagure.io/atomic-wg/blob/master/f/docs/two-week-release-steps.md For Fedora CoreOS we'll be using kola for automated tests in clouds. Dusty ___ 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: fedora-gpg-keys not updated yet again
On 8/22/19 12:58 PM, Kevin Fenzi wrote: > On 8/21/19 9:27 AM, Dusty Mabe wrote: >> >> >> On 8/19/19 6:59 AM, Pavel Raiskup wrote: >>> On Monday, August 19, 2019 10:50:52 AM CEST Zbigniew Jędrzejewski-Szmek >>> wrote: >>>> Can we *please* send out the FN+1 and FN+2 keys a month before branching, >>>> to *all* releases of Fedora, so we can avoid this pointless scramble? >>> >>> What about to have F33 keys right now, when the fresh F31 branch is out? >>> >> >> +1. Go ahead and make the f33 keys when we branch for f31. > > I don't see how this helps any. I agree we should push out the f33 keys > before next branching, but why now? > For me it solves any "timing" issues. We often get into a state where we're trying to upgrade to something that is signed with a key we don't have yet. With ostree we hit this every time we branch. Here is where a user hit it this time: https://discussion.fedoraproject.org/t/unable-to-update-gpg-signatures-found-but-none-are-in-trusted-keyring/2703/3?u=dustymabe There could be other problems that won't be solved but if we get the key out now for the next release we'll at least solve any races and problems like this. Dusty ___ 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: 'showme' RPM dependency visualizer (was: Minimization Objective report)
On 8/23/19 6:35 AM, Dominik 'Rathann' Mierzejewski wrote: > Hi, Adam. > > On Wednesday, 21 August 2019 at 15:41, Adam Samalik wrote: > [...] >> == Toolbox == >> >> The 'showme' tool [3] for visualising and inspecting RPM dependencies >> now supports weak dependencies and a package list output. > > I didn't have a chance to tell you this at Flock, but could you rename > the binary to something like rpm-showme? Plain showme is very generic > and unsuitable for such a specific tool. > I agree. It also means people are less likely to "discover" the tool and must be told about it or otherwise find it through indirect searches. Dusty ___ 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: Help update Hugo
On 8/22/19 12:46 AM, Robert-André Mauchin wrote: > Hello, > > Feel free to help review these packages needed to update Hugo: > Thanks for the effort here Robert-André. I might be able to help with a few of these since I use Hugo. Will let you know next week. Dusty ___ 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: fedora-gpg-keys not updated yet again
On 8/23/19 12:21 PM, Kevin Fenzi wrote: > On 8/23/19 4:12 AM, Dusty Mabe wrote: >> >> >> On 8/22/19 12:58 PM, Kevin Fenzi wrote: >>> On 8/21/19 9:27 AM, Dusty Mabe wrote: >>>> >>>> >>>> On 8/19/19 6:59 AM, Pavel Raiskup wrote: >>>>> On Monday, August 19, 2019 10:50:52 AM CEST Zbigniew Jędrzejewski-Szmek >>>>> wrote: >>>>>> Can we *please* send out the FN+1 and FN+2 keys a month before branching, >>>>>> to *all* releases of Fedora, so we can avoid this pointless scramble? >>>>> >>>>> What about to have F33 keys right now, when the fresh F31 branch is out? >>>>> >>>> >>>> +1. Go ahead and make the f33 keys when we branch for f31. >>> >>> I don't see how this helps any. I agree we should push out the f33 keys >>> before next branching, but why now? >>> >> >> For me it solves any "timing" issues. We often get into a state where we're >> trying to upgrade to something that is signed with a key we don't have yet. > > Yes, but it would also be solved by pushing the F33 key out a few weeks > or a month or so before branching next time right? > It depends on how often people update. If they wait a month to do an update we still get into a situation like this where fedora-gpg-keys doesn't have the key but they are trying to update to a system that has content signed by it. Creating the key for the next next rawhide at time of branching would also mean that we make minimal changes to our existing SOPs. The ONLY change is that now we're creating the key for the next next rawhide instead. Dusty ___ 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: [atomic-announce] Fedora Atomic 29 EOL date?
On 8/24/19 6:27 AM, Feilong Wang wrote: > Hi team, > Hi Feilong! I'm adding in Spyros who has worked with us in the past on Atomic Host and Magnum. > Could you please help me understand when will be the EOL date for Fedora > Atomic 29? I understand generally it takes 13 months. But given Fedora Atomic > 29 -> Fedora CoreOS 30 is a big jump, is there any special considering for > this case? Fedora 29 Atomic Host will follow the EOL schedule for Fedora 29. It will EOL approximately a month after Fedora 31 is released. Fedora 31 is scheduled to be released at the end of October, so the EOL for Fedora 29 will probably be around the end of November. > > The background is OpenStack Magnum is using Fedora Atomic as the base > operating system to deploy Kubernetes cluster, but because of the big change > from FA29 to FCOS 30, we haven't got enough resources on this work. So it > would be really helpful if the Fedora Atomic/CorOS community can help me > understand the roadmap and plan. Thank you very much. > The Fedora CoreOS preview release is out now. We're hoping to bring that to stable ASAP but we've got some things we'd like to finish before we make that declaration. The best thing that can be done is to get some experience trying out OpenStack Magnum on Fedora CoreOS so that we can get in fixes now before we declare stable. We'd like to work with you more closely to make sure the transition is smooth for the Magnum project. Can you all share some time/resources to work with us to make sure we smooth out any wrinkles? Dusty ___ 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: [atomic-announce] Fedora Atomic 29 EOL date?
On 9/10/19 10:18 PM, Feilong Wang wrote: > Hi Dusty, > > Now Spyros and I are trying to ask for support in Ignition for multi part > MIME, see https://github.com/coreos/ignition/issues/849 It would be nice if > we can get your review and support. Thanks. Any chance you could drop by #fedora-coreos on freenode IRC and we can discuss? We do have a meeting today in #fedora-meeting-1 at 16:30 UTC. We could discuss with the broader group then. Dusty ___ 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: CPE Team Weekly Update
On 9/27/19 9:18 AM, Aoife Moloney wrote: > Hi everyone, > > > I’d like to introduce myself first, my name is Aoife Moloney and I recently > started with the Community Platform Engineering (CPE) team. My role within > this team is going to be a hybrid role of a Product Owner / Project Manager. > > As part of that, I want to send a weekly update to the lists to give an > insight into what the CPE team have worked on over the past week or so. This > will also be mirrored as a higher level blog to give maximum visibility. > > We, as a team, welcome your input and comments and please do let us know how > we can improve this community facing information segment! > > As you know, the CPE team looks after interests in both Fedora and CentOS, so > this update is also going to include work done on areas that are not your > Community, but for transparency, we are including it :) Hi Aoife, Great to virtually meet you! I think this report is great! Thank you so much for sending it and for committing to doing so in the future! Dusty ___ 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 1/20/20 7:57 PM, Matthew Garrett wrote: > > 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: For what it's worth, this is what is done for OSTree based systems (Fedora Atomic Host, Fedora CoreOS, Fedora Silverblue). There is an option for the user to generate an initramfs client side, but I don't think it's used very much at all. I know in the case of OSTree based systems you are shipping more of an image than a case like Fedora Server where you are assembling a new system from a set of defined RPMs, but it's at least a data point. Dusty ___ 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
new maintainer for tmuxinator
It was orphaned recently. Anybody care to pick it up? :) https://src.fedoraproject.org/rpms/tmuxinator Dusty ___ 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: What to do with simple-koji-ci?
On 2/7/20 9:30 AM, Pierre-Yves Chibon wrote: > Good Morning Everyone, > > I while back I wrote a small service named simple-koji-ci, which reacts to > every pull-request opened on dist-git and fires a (scratch) build of the > package > with the proposed changes merged, and report the outcome as a "flag" to the > pull-request. > This is a very simple service, so simple that it has some issues, including > the > fact that it uses the default mock configuration to build the SRPM for the > scratch build. This can break the SRPM generation in a few cases. > > This is the very first service we have had triggering of PRs on dist-git and > giving some CI feeling/taste to our workflow. > Since then, the CI pipeline managed by the Fedora CI SIG folks has appeared, > is > running and is also doing a scratch build like simple-koji-ci and then some > more > testing. > > simple-koji-ci has been running in the openstack instance hosted by the Fedora > Infrastructure. However, this openstack is being decommissioned and > applications > running there are being asked to find another place to run, an option being > openshift. > > I'd like to ask for your input about this service. Is it worth keeping? Is it > duplicating what the CI pipeline does? > Is someone interested in working on it? I like having it. It's a direct link to a koji scratch build. I think the CI pipeline does a koji scratch build too but you have to dig through logs to find the links. Also, does the CI pipeline run if you don't have any tests defined? > > If this service is deemed important enough, I don't mind moving it to > openshift > but in all honestly, what I would prefer would be to help someone move it to > openshift. > > > Looking forward to read your thoughts, > > Thanks, > Pierre ___ 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
co-maintainer wanted for fuse-sshfs in EPEL8
The current maintainer of fuse-sshfs is looking for a co-maintainer for it in epel8. It's currently not in EPEL 8 so if you go from RHEL or CentOS 7->8 you'll lose it. I have users of vagrant-sshfs who would like to have it there. https://bugzilla.redhat.com/show_bug.cgi?id=1758884#c4 Anybody interested? Dusty ___ 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: co-maintainer wanted for fuse-sshfs in EPEL8
Thanks Vascom, I'm not the maintainer so I can't add you, but I'll copy the maintainer here as well, just to see if he'll see it. In case he doesn't can you reply to the comment over in the BZ as well? See https://bugzilla.redhat.com/show_bug.cgi?id=1758884#c4 When we get you added as a co-maintainer we'll then need to add a epel8 branch and build against it. Thanks so much! Dusty On 3/8/20 12:33 PM, Vascom wrote: > You can add me as comaintainer. > FAS name: vascom > > вс, 8 мар. 2020 г., 19:32 Dusty Mabe <mailto:du...@dustymabe.com>>: > > The current maintainer of fuse-sshfs is looking for a co-maintainer for it > in epel8. It's currently not in EPEL 8 so if you go from RHEL or CentOS > 7->8 > you'll lose it. I have users of vagrant-sshfs who would like to have it > there. > > https://bugzilla.redhat.com/show_bug.cgi?id=1758884#c4 > > Anybody interested? > > Dusty > ___ > devel mailing list -- devel@lists.fedoraproject.org > <mailto:devel@lists.fedoraproject.org> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > <mailto: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 > > > ___ > 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 > ___ 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: Emerging editions, Fedora 32 Beta, and bureaucracy
On 3/17/20 2:01 PM, Adam Williamson wrote: Hey Adam, > > 3) CoreOS - CoreOS is just a *whole* other thing. It is not built like > the rest of Fedora at all. It's not built as Pungi composes, whatever > compose process it does have doesn't run alongside our other compose > processes or output to the same locations, it's like a whole other > product. It also doesn't seem to be terribly well documented (I can't > find any detail on the wiki, docs sites, or any of the git repos I > happen to know of) or even introspectable - for instance, ISO locations > look like > https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/31.20200223.3.0/x86_64/fedora-coreos-31.20200223.3.0-live.x86_64.iso > , but if you try and browse around that tree by visiting URLs like > https://builds.coreos.fedoraproject.org/prod/streams/ , you just > get 'Access Denied'. So if the process appears to have broken down and > some poor monkey like me is left trying to help people figure out where > they can get a 'Fedora CoreOS 32' image to try - it isn't very easy. > Right now I simply have no clue if there is something you could > reasonably call 'Fedora CoreOS 32 Beta' or a decent analogue of it. You have reasonable points here. I do agree that the current state of integration between Fedora CoreOS and the rest of Fedora is not quite complete. Part of the reason for this is that we've been working hard on building Fedora CoreOS from the ground up and getting it out the door. There are two things here worth being explicit about: 1. Fedora CoreOS is today not composed by pungi on Fedora infra. It is composed using coreos-assembler[1] in CentOS CI. I think this fundamental difference is the root to a lot of the mystery here surrounding FCOS. People integrated into Fedora processes are familiar with pungi and how it works. OTOH, I'm sure not many of us are familiar with coreos-assembler. 2. Fedora CoreOS follows a rolling release model, where by design, we don't want people to care about whether they're on f31 or f32 (at least in principle). For FCOS, the f32 update just goes out like any other update when we're ready to do the cutover. Thus, sentences like "Fedora CoreOS 32" don't have quite the same meaning as for e.g. Workstation or Server. That said, Fedora CoreOS does have more streams than just stable and testing, and one of those streams should be $((N+1))-based. So we definitely could have some marketing/banners/whatever to point people at. Right now there is not yet a F32 based coreos, but there will be soon as part of our `next` stream [2]. That said, we know there is work to do to make things better understood and more predictable from the rest of Fedora's point of view. Note that there was a lot of hard work to integrate and participate in more Fedora processes as Fedora Atomic Host matured. Know that this work will come as we finish building out the more foundational pieces of Fedora CoreOS. We have opened a discussion ticket [3] for this in our issue tracker, which is where our meeting topics get sourced from and our discussions generally take place. [1] https://github.com/coreos/coreos-assembler [2] https://github.com/coreos/fedora-coreos-tracker/issues/283 [3] https://github.com/coreos/fedora-coreos-tracker/issues/426. ___ 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: Should logrotate timer be enabled by default on all installations?
On 3/18/20 8:04 AM, Kamil Dudka wrote: > logrotate is a utility designed to simplify the administration of log files > on > a system which generates a lot of log files. It used to be triggered by > cron. > The cron hook was unconditionally installed with logrotate but it took effect > only if a cron daemon was installed. > > Starting with Fedora 30, logrotate is triggered by a systemd timer instead. > In order to make updates smoother, the timer was enabled on updates in case > a cron daemon was configured on the system. > > The timer is currently not enabled on fresh installs to avoid surprises (such > as data lost) on systems where logrotate is installed but not actually used. > logrotate can also be triggered independently of systemd/cron and can be even > run by non-privileged users to rotate logs they have access to. > > Some people think that the logrotate timer should be enabled by default on > all > systems where the logrotate package is installed: > > https://bugzilla.redhat.com/1655153#c4 > > Do you think it would be a good idea? I chimed in in the ticket too, but +1 from me. I guess it would be worth analyzing the problem space a bit: - in the past how many people do we think had logrotate installed and not cron? - what are the worst case scenarios if logrotate.timer defaults to off? - what are the worst case scenarios if logrotate.time defaults to on? Dusty ___ 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
Any plans to support .heic files in Fedora?
Seems like Apple converted their phones over to using a new file format to store pictures. I was copying some pictures from a phone and noticed my linux box couldn't read them and they had an interesting extension .heic. Looks like there is a new image format in town and we need the libheif and libde265 libraries in order to read it according to the gimp plugin [1]. The plugin docs say it should be included by default now in gimp but the gimp on my f29 system says it can't read the file. This is probably because we don't have the underlying libraries in Fedora. Anybody been down this road? Is it as simple as getting the libraries in or is there much more pain involved that I haven't discovered yet? Thanks, Dusty [1] https://github.com/strukturag/heif-gimp-plugin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Any plans to support .heic files in Fedora?
On 11/30/18 5:20 AM, Leigh Scott wrote: > Reviewers welcome. > > https://bugzilla.rpmfusion.org/show_bug.cgi?id=5089 > https://bugzilla.rpmfusion.org/show_bug.cgi?id=5090 Thanks Leigh. I see those have already made progress in code review. +1000 Is there a definitive reason why those are necessary to go in RPM fusion? Was Tom Hughes right? Dusty ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
