Re: Fedora/EPEL GitHub Badges
On 12/15/2017 04:56 PM, Avram Lubkin wrote: > Anyone have a better way to generate dynamic badges? Should badge > generation be a part of the Fedora infrastructure? > > For an alternative approach, would it be better to show the latest stable > version in the latest Fedora. Something like this, but dynamic: > > https://img.shields.io/badge/Fedora_27-1.0.7-lightgrey.svg Dynamic version of this badge: https://img.shields.io/badge/dynamic/json.svg?uri=https://apps.fedoraproject.org/mdapi/f27/pkg/python3-enlighten&query=$.version&label=Fedora+27 Some apps already implement their own badges, like Copr, or Koschei, which tells you whether your package builds in Fedora or not: https://apps.fedoraproject.org/koschei/badge/f27/python-enlighten.svg -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora/EPEL GitHub Badges
On Fri, Dec 15, 2017 at 11:04 AM Avram Lubkin wrote: > Badges are pretty popular in GitHub though there don't seem to be many > that provide information on distros that have packages for a project. This > would be very useful because, at least for me, the first thing I do when I > want to try a new project is see if a package is available for the distro > I'm working with, usually Fedora or CentOS. > > I searched around, but couldn't find anything that existed already (please > let me know if I missed it), so I made static badges for one of my > projects, python-enlighten[1], but this requires remembering to update them > when a new version of Fedora comes out. > > I tried to create a dynamic one, but it isn't exactly what I want. It's > based on if a branch exists and starts with 'f' or 'e', not if there is a > stable package for that branch. Also, the branch names are not consistent > between EPEL 6 and EPEL 7, so it would be better to just get the number. > Might as well just use the number for Fedora too for consistency. > > Static Fedora: > https://img.shields.io/badge/Fedora-26,_27-lightgrey.svg > > Static EPEL: > https://img.shields.io/badge/EPEL-6,_7-lightgrey.svg > > > Dynamic Fedora: > > https://img.shields.io/badge/dynamic/json.svg?uri=https://pdc.fedoraproject.org/rest_api/v1/component-branches/?global_component=python-enlighten;fields=name;active=true;type=rpm&query=$.results[?(@.name.startsWith( > "f"))].name&label=Fedora > > Dynamic EPEL: > > https://img.shields.io/badge/dynamic/json.svg?uri=https://pdc.fedoraproject.org/rest_api/v1/component-branches/?global_component=python-enlighten;fields=name;active=true;type=rpm&query=$.results[?(@.name.startsWith( > "e"))].name&label=EPEL > > I'm also not sure the best place to point them to. shields.io does let > you set a target for both the left and the right sides, but I just set the > target within readme.rst and pointed both badges to the Bodhi updates page > for the package. > > Anyone have a better way to generate dynamic badges? Should badge > generation be a part of the Fedora infrastructure? > > For an alternative approach, would it be better to show the latest stable > version in the latest Fedora. Something like this, but dynamic: > > https://img.shields.io/badge/Fedora_27-1.0.7-lightgrey.svg > > > [1] https://github.com/Rockhopper-Technologies/enlighten > > I would be very interested in this if it were dynamic. My preference would be for a dynamic badge service which shows the latest stable `nevr` for either a specific Fedora/EPEL, with the option to use keywords like "latest" and "rawhide" in addition to specific releases like "F27". Upstream users could choose to add a Fedora 26 badge, a Fedora 27 badge, and a Fedora Rawhide badge to advertise the available versions in each of those, or they could just advertise the latest stable with a badge for the latest released Fedora version. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
wrong selinux label on user-1000.journal, AVC denials
Fedora 27 workstation. I'm getting selinux AVC denial messages in the journal as a result of user-1000.journal having label system_u:object_r:unlabeled_t:s0. It's the only log file with that label, the other files and the directory its in have system_u:object_r:var_log_t:s0. The AVC message of course go away if I relabel /var/log/journal but then maybe two weeks later the problem starts happening again when the log gets rotated. For whatever reason this is not happening with the system.journal. Dec 15 15:54:47 f27h.localdomain audit[640]: AVC avc: denied { read write } for pid=640 comm="systemd-journal" name="user-1000.journal" dev="nvme0n1p9" ino=1174 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0 Is this a systemd or selinux-policy bug? Or other? -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Missing deltarpms?
I may have missed something, but I think there might be a problem with deltarpms in all the current Fedora releases. Looking at http://mirrors.kernel.org/fedora/updates/27/x86_64/drpms, there are eight available deltarpms for F27, and if you go to F26, there are two. At a guess, new deltarpms are being generated for each push, but the old ones aren't being copied in anymore. Jonathan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora/EPEL GitHub Badges
On Fri, Dec 15, 2017 at 10:56:10AM -0500, Avram Lubkin wrote: > I'm also not sure the best place to point them to. shields.io does let you > set a target for both the left and the right sides, but I just set the > target within readme.rst and pointed both badges to the Bodhi updates page > for the package. > > Anyone have a better way to generate dynamic badges? Should badge > generation be a part of the Fedora infrastructure? I'm for us serving them. Full transparency: shields.io says "no tracking" but that doesn't mean they don't do _counting_. I also have no interest in tracking, but a lot of interest in counting. (How many distinct projects use this? How many people look at them? Super-interesting!) It seems like they don't really need to be dynamic and _could_ just be static content we serve from https://getfedora.org/static/, right? That way, we wouldn't need to stand up a new service or anything ongoing except an update when we put out a new release. That wouldn't allow per-project linking though. If you are doing something dynamic, I'd suggest https://src.fedoraproject.org/ as a target, and then include a README.md with instructions on how to dnf install your package. Anyway: can you file an infrastructure ticket for this? I doubt it will be high priority, but on the other hand, it seems like something an infrastructure apprentice could tackle. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Schedule for Friday's FESCo Meeting (2017-12-15)
Following is the list of topics that will be discussed in the FESCo meeting Friday at 16:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2017-12-15 16:00 UTC' Links to all issues below can be found at: https://pagure.io/fesco/report/meeting_agenda = Followups = #topic #1767 F28 Self Contained Changes .fesco 1767 https://pagure.io/fesco/issue/1767 #topic #1799 The ProvenPackager rubric needs more formality .fesco 1799 https://pagure.io/fesco/issue/1799 = New business = #topic #1805 Election Interview Questions .fesco 1805 https://pagure.io/fesco/issue/1805 #topic #1804 Election Process Clarifications .fesco 1804 https://pagure.io/fesco/issue/1804 #topic #1803 F28 System Wide Change: Reduce Initial Setup Redundancy .fesco 1803 https://pagure.io/fesco/issue/1803 #topic #1802 F28 System Wide Change: Switch libcurl to use libssh instead of libssh2 .fesco 1802 https://pagure.io/fesco/issue/1802 #topic #1800 Election Planning discussion .fesco 1800 https://pagure.io/fesco/issue/1800 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora/EPEL GitHub Badges
Badges are pretty popular in GitHub though there don't seem to be many that provide information on distros that have packages for a project. This would be very useful because, at least for me, the first thing I do when I want to try a new project is see if a package is available for the distro I'm working with, usually Fedora or CentOS. I searched around, but couldn't find anything that existed already (please let me know if I missed it), so I made static badges for one of my projects, python-enlighten[1], but this requires remembering to update them when a new version of Fedora comes out. I tried to create a dynamic one, but it isn't exactly what I want. It's based on if a branch exists and starts with 'f' or 'e', not if there is a stable package for that branch. Also, the branch names are not consistent between EPEL 6 and EPEL 7, so it would be better to just get the number. Might as well just use the number for Fedora too for consistency. Static Fedora: https://img.shields.io/badge/Fedora-26,_27-lightgrey.svg Static EPEL: https://img.shields.io/badge/EPEL-6,_7-lightgrey.svg Dynamic Fedora: https://img.shields.io/badge/dynamic/json.svg?uri=https://pdc.fedoraproject.org/rest_api/v1/component-branches/?global_component=python-enlighten;fields=name;active=true;type=rpm&query=$.results[?(@.name.startsWith( "f"))].name&label=Fedora Dynamic EPEL: https://img.shields.io/badge/dynamic/json.svg?uri=https://pdc.fedoraproject.org/rest_api/v1/component-branches/?global_component=python-enlighten;fields=name;active=true;type=rpm&query=$.results[?(@.name.startsWith( "e"))].name&label=EPEL I'm also not sure the best place to point them to. shields.io does let you set a target for both the left and the right sides, but I just set the target within readme.rst and pointed both badges to the Bodhi updates page for the package. Anyone have a better way to generate dynamic badges? Should badge generation be a part of the Fedora infrastructure? For an alternative approach, would it be better to show the latest stable version in the latest Fedora. Something like this, but dynamic: https://img.shields.io/badge/Fedora_27-1.0.7-lightgrey.svg [1] https://github.com/Rockhopper-Technologies/enlighten ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Review requests: mingw-qt5-qtserialport, mingw-qt5-qtcharts, mingw-twaindsm
Hi Another bunch of mingw packages: * mingw-qt5-qtserialport: https://bugzilla.redhat.com/show_bug.cgi?id=1526479 * mingw-qt5-qtcharts: https://bugzilla.redhat.com/show_bug.cgi?id=1526480 * mingw-twaindsm: https://bugzilla.redhat.com/show_bug.cgi?id=1526481 Should be pretty straight forward. Happy to review in exchange. Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Elections in January 2018 to FESCo, Council, Mindshare - the schedule
Hi, I have published schedule for elections in January 2018 on the Elections [1] wiki page. The schedule is as follows: * Dec 15 - Jan 02: Selection of questions from Questionnaire * Jan 03 - Jan 10: Nomination period * Jan 11 - Jan 15: Interviews * Jan 16 - Jan 16: Voting Setup & Validation & Publishing of interviews * Jan 17 - Jan 24: Voting period * Jan 25: Result Announcement Please check the Election page [1] for more details on how the Elections (and interviews) are going to be organized. I am going to be on vacations, mostly off-grid, until January 4th, so if you need any help, please contact Bex [2] (and CC me, please). [1] https://fedoraproject.org/wiki/Elections [2] https://fedoraproject.org/wiki/User:Bex Regards, Jan -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
systemd 236 in rawhide
Hi, systemd 236 was released [1] and is building for rawhide. As always, there's a bunch of new functionality, in particular cgroups v2 support is updated and improved for the recent kernel changes [2], various systemd internal services now run under DynamicUser=yes, support for formatting and resizing file systems on the fly has been added, systemd-nspawn can join pre-defined network namespaces, ..., and many many small fixes and improvements. The way that the Fedora rpms are put together (or rather split apart) has been redone: we now use a set of regexp patterns [3] to divvy the files found in %buildroot between all the binary rpms. The advantage is that it's much easier to move a certain binary and all its ancillary files (the man page, service unit, symlinks). In particular we don't need to add %exclude patterns to the main binary rpm's %files section. This change fixed a number of misplaced manpages and service files and various files being assigned to multiple binary rpms. Nevertheless, it's possible that I messed something up, so please keep an eye out. [1] https://lists.freedesktop.org/archives/systemd-devel/2017-December/039996.html [2] Essentially, with linux-4.15 and systemd-236 full unified hierarchy is functional and almost feature complete. Cpuset controller is planned for 4.16, so that's missing, and moving scopes between the user session and user systemd manager still doesn't work (systemd-run --scope --user screen is broken ;( ). Also, although kernel and systemd support is almost there, other utilities that use cgroups might not have support for the unified hierarchy or threaded mode. Use systemd.unified-cgroup-hierarchy on the kernel command line to test this mode. [3] https://src.fedoraproject.org/rpms/systemd/blob/master/f/split-files.py Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org