Re: State of Sparkeshare in Fedora
On 07/10/17 08:28 AM, Robert-André Mauchin wrote: > > Hello Luya, > > I've worked on this issue this afternoon, you can find the resulting SPEC, > SRPM and patches here: https://eclipseo.fedorapeople.org/sparkleshare/ > > The main patch backports the changes made in 2.0 for WebkitGTK 2.0 > compatibility. > > It builds in Mock and Koji but I haven't attempted to run the program itself. > > Best regards, > > Robert-André Hello Robert-André, Thank you for porting the change to 1.5. The only issue is the panel setting to add repositories missing and a traceback when starting it: tacktrace: at <0x> at (wrapper managed-to-native) Gtk.Label.gtk_label_new_with_mnemonic (intptr) [0x2] in :0 at Gtk.Label..ctor (string) [0x00062] in :0 at Gtk.Label..ctor () [0x0] in :0 at SparkleShare.SparkleUI..ctor () [0x0003c] in :0 at SparkleShare.Program.Main (string[]) [0x00133] in :0 at (wrapper runtime-invoke) .runtime_invoke_void_object (object,intptr,intptr,intptr) [0x0004e] in :0 /proc/self/maps: 41393000-4143c000 rwxp 00:00 0 [mpx] 41503000-41513000 rwxp 00:00 0 [mpx] 55d5da816000-55d5dad17000 r-xp 08:08 2535114 /usr/bin/mono-sgen 55d5daf17000-55d5daf2e000 r--p 00501000 08:08 2535114 /usr/bin/mono-sgen 55d5daf2e000-55d5daf39000 rw-p 00518000 08:08 2535114 /usr/bin/mono-sgen 55d5daf39000-55d5daf6d000 rw-p 00:00 0 [mpx] 55d5db68a000-55d5dbc8f000 rw-p 00:00 0 [mpx] 7ffae800-7ffae8021000 rw-p 00:00 0 [mpx] 7ffae8021000-7ffaec00 ---p 00:00 0 [mpx] 7ffaf000-7ffaf0021000 rw-p 00:00 0 [mpx] 7ffaf0021000-7ffaf400 ---p 00:00 0 [mpx] 7ffaf6d96000-7ffaf6d97000 ---p 00:00 0 [mpx] 7ffaf6d97000-7ffaf7597000 rw-p 00:00 0 [mpx] 7ffaf7597000-7ffaf7598000 ---p 00:00 0 [mpx] 7ffaf7598000-7ffaf7d98000 rw-p 00:00 0 [mpx] 7ffaf7d98000-7ffaf7dac000 r-xp 08:08 2497942 /usr/lib64/libgpg-error.so.0.22.0 7ffaf7dac000-7ffaf7fab000 ---p 00014000 08:08 2497942 /usr/lib64/libgpg-error.so.0.22.0 7ffaf7fab000-7ffaf7fac000 r--p 00013000 08:08 2497942 /usr/lib64/libgpg-error.so.0.22.0 7ffaf7fac000-7ffaf7fad000 rw-p 00014000 08:08 2497942 /usr/lib64/libgpg-error.so.0.22.0 7ffaf7fb-7ffaf7fc3000 r-xp 08:08 2500440 /usr/lib64/liblz4.so.1.8.0 7ffaf7fc3000-7ffaf81c3000 ---p 00013000 08:08 2500440 /usr/lib64/liblz4.so.1.8.0 7ffaf81c3000-7ffaf81c4000 r--p 00013000 08:08 2500440 /usr/lib64/liblz4.so.1.8.0 7ffaf81c4000-7ffaf81c5000 rw-p 00:00 0 [mpx] 7ffaf81c8000-7ffaf81ed000 r-xp 08:08 2501211 /usr/lib64/liblzma.so.5.2.3 7ffaf81ed000-7ffaf83ec000 ---p 00025000 08:08 2501211 /usr/lib64/liblzma.so.5.2.3 7ffaf83ec000-7ffaf83ed000 r--p 00024000 08:08 2501211 /usr/lib64/liblzma.so.5.2.3 7ffaf83ed000-7ffaf83ee000 rw-p 00:00 0 [mpx] Not sure where to start. -- Luya Tshimbalanga Graphic & Web Designer E: l...@fedoraproject.org W: http://www.coolest-storm.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: plan to update F27 to systemd-235
On Fri, Oct 6, 2017 at 11:04 AM, Zbigniew Jędrzejewski-Szmek wrote: > Hi, > > systemd 235 was released today. A large number of issues was closed > upstream, including many bug fixes, documentation updates, and > long-standing RFEs. There are some new features, but relatively few > entirely new features or changes in behaviour that impact other > services. There also are no (intentional) breaking changes. Systemd doesn't "intend" to break working software. But it has repeatedly demanded, without advance notice, that working software be rewritten to support a new and unexpected violation of working standards by systemd. The symlink replacment of /etc/resolv.conf was one. The killing of logged out user processes, without record and with no option to disable it after compilation in release 230 was another one. Do not get me *started* on the "systemd knows better than you do or than syslinux how many active connections MySQL should support, we'll just reset that behind your back" that I encountered recently. Systemd version updates need regression testing and burn-in. I'd like to very strongly discourage activating it this late in the Fedora 17 release process. > The update is building for rawhide. If nothing major pops up, I'd like > to release the update for F27 too. (The updates policy says that > "major version updates should be avoided", but systemd does not use > semantic versioning, so there's no distinction between major and minor > releases. A number of patches was backported previously, and are > already present in F27, but there are other fixes that are too > numerous to backport, and which would be desirable to have in F27.) > > Zbyszek Systemd's unwillingness to use major/minor revision numbering is just another of the reasons I don't have high confidence in the safety of its updates. If the updates and feature additions are too numerous to describe, then that multiplies my concern that it will break otherwise stable software unexpectedly. Are there any particular features you consider a "must-have" for Fedora 27? Is there anything that justifies the risk of a late update? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Removing ghostscript-fonts package
On Fri, Oct 6, 2017 at 8:49 AM, Zdenek Dohnal wrote: > Hi, > > I am going to retire ghostscript-fonts package in F27 because its fonts > are deprecated and replaced by urw-base35-fonts package. Only package > which depends on ghostscript-fonts seems to be hylafax+ package, I > created bugzilla for it > https://bugzilla.redhat.com/show_bug.cgi?id=1499240 . Does anyone have > any objections on its retirement? > > If there isn't any objections, I'll retire it next Monday. > > Zdenek May I request respectfully that you orphan it first? Hylafax++ is one of those *extremely* stable, robust packages that has needed very few architectural updates in its lifetime. It is used commercially, at last check, by the Efax company. It was originally written by Sam Leffler, the inventor of TIFF and one of the authors of the original BSD: I'm one of the first people to package it as an RPM, and wrote the first public ports to Linux and to SunOS. The maintainers probably hadn't kept track of the ghostscript-fonts becoming obsolete in Fedora, because it "just worked(tm)". I can try to reach out to the current maintainers. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: is anybody using fedora-loadmodules.service and fedora-readonly.service?
Hi, /*Zbigniew Jędrzejewski-szmek*/ wrote on Sat, 7 Oct 2017 07:18:59 +: Two boot-time services provided by the venerable initscripts package: <...> - fedora-readonly.service: this is used to mount parts of the filesystem rw in case the system is using read-only root filesystem. To do anything this service checks if READONLY=yes is set in /etc/sysconfig/readonly-root. Is anybody using this? If yes, would it be OK if the service was not enabled by default anymore and would require an explicit 'systemctl enable fedora-readonly.service' or creating a custom preset (in addition to setting READONLY=yes) to be active? I do! Yes, I don't care if it should be explicitly enabled, but I really hope that it won't vanish. I even don't care if you do not need to specify READONLY=yes if it is enabled explicitly (enabling it can mean that you really want READONLY=yes). See https://bugzilla.redhat.com/show_bug.cgi?id=1493479 and https://pagure.io/fesco/issue/1779 for some more info. <...> fedora-readonly.service is based on mounting tmpfs dirs, copying files around, doing selinux fixups, manually mounting rpcfs and nfs, etc. I have never seen fedora-readonly.service actually used, but that doesn't mean much. If people are using them I'd love to hear about their use cases, and think if we can provide the same functionality using more modern mechanisms. Without breaking existing setups, I'd like to disable this by default to simplify the boot process and not encourage the use in new installations. ] fedora-readonly.service is actually an advanced utility to let you configure the system to be used with fully or partly read-only root filesystem. I've used it, and are very likely to use it again and again in future, to deploy 'reliable' Fedora instances, which are either fully read-only, or let you write in a very specific locations and make sure that your / partition will never be corrupted for any reason. It is a great feature for using Fedora in embedded devices. Anyway, I don't see why it can't be disabled by default, but I hope it is not removed... at least not until there is a replacement with 100% of its features. Regards, Hedayat Zbyszek ___ 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: Giving us the ability to go backwards [was Re: plan to update F27 to systemd-235]
On 7 October 2017 at 12:31, Matthew Miller wrote:
> On Sat, Oct 07, 2017 at 10:33:38AM -0400, Colin Walters wrote:
>> I'm personally very in favor of this; of course my usual refrain
>> here is that we should *try* new things and have the ability
>> to back them out if they don't work (the latter bit is what the
>> current system doesn't support).
>
> You know, we could easily _start_ supporting the thing you want if we
> switched from "Epoch is a horrible confusing hack that should never get
> used" to "We increment Epoch every time instead of Release (and don't
> reset back to 1 on new versions)".
>
> We could even define Release to %{epoch} and remove it from spec files,
> giving a user-visible indicator, even if that's not what the tools sort
> on. Or, I guess, we could to the other way around and define Epoch to
> equal release.
>
> We could also change the tools to increment with every build rather
> than manually — then, things like git-revert-and-build- would work. The
> ability to revert to previously-existing binaries *without* rebuilding
> would take more invasive tooling changes, of course.
>
>
If there is one thing I have learned in 20 years of dealing with
RPMS... DON'T PLAY AROUND WITH EPOCH. It is a hack which should only
be used as a last resort and a lot of tools are built around that
assumption.. even if they don't know it. Every time we have done
things with Epoch we have regretted it because of this.
At a certain point, if you want/need to do these things, it is better
to burn it from the ground and come up with a new packaging system
(and relearn all the second system problems involved with that).
--
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Giving us the ability to go backwards [was Re: plan to update F27 to systemd-235]
On Sat, Oct 7, 2017 at 1:10 PM, Pierre-Yves Chibon wrote:
> On Sat, Oct 07, 2017 at 12:45:14PM -0400, Neal Gompa wrote:
>> On Sat, Oct 7, 2017 at 12:31 PM, Matthew Miller
>> wrote:
>> > On Sat, Oct 07, 2017 at 10:33:38AM -0400, Colin Walters wrote:
>> >> I'm personally very in favor of this; of course my usual refrain
>> >> here is that we should *try* new things and have the ability
>> >> to back them out if they don't work (the latter bit is what the
>> >> current system doesn't support).
>> >
>> > You know, we could easily _start_ supporting the thing you want if we
>> > switched from "Epoch is a horrible confusing hack that should never get
>> > used" to "We increment Epoch every time instead of Release (and don't
>> > reset back to 1 on new versions)".
>> >
>> > We could even define Release to %{epoch} and remove it from spec files,
>> > giving a user-visible indicator, even if that's not what the tools sort
>> > on. Or, I guess, we could to the other way around and define Epoch to
>> > equal release.
>> >
>>
>> No. Please don't do this. If anything, I want Epoch to be a thing that
>> we reset on new distribution releases, since our tooling does support
>> this and the distribution upgrade procedures have long since been
>> adapted to handle it. Epochs shouldn't be permanent. :(
>>
>> > We could also change the tools to increment with every build rather
>> > than manually — then, things like git-revert-and-build- would work. The
>> > ability to revert to previously-existing binaries *without* rebuilding
>> > would take more invasive tooling changes, of course.
>> >
>>
>> We could do this now with the Release field. I've mentioned it
>> numerous times in the past that this is a well-proven idea. SUSE does
>> this now with OBS, which is why their release field is set to the
>> following format:
>>
>> Release: .
>>
>> The values above are automatically written by OBS, ignoring whatever
>> Release is set to. When the version is bumped, is
>> reset to 1. Whenever a rebuild occurs for whatever reason, the
>> is bumped, but it resets to 1 on a new commit+submit
>> build.
>>
>> So, for example:
>>
>> 1. foo v1 => Release: 1.1
>> 2. adjust spec => Release: 2.1
>> 3. auto-rebuild due to dependency change => Release: 2.2
>> 4. adjust spec => Release: 3.1
>> 5. foo v2 => Release: 1.1
>>
>> Since we don't have nice things like auto-rebuild of reverse
>> dependencies for packages, we could probably simplify the scheme to
>> be:
>>
>> Release: %{?dist}
>
> But the version is evaluated before the release no? So how would rollback work
> if we're only touching the release field (ie the last one evaluated)?
>
I was addressing the increment on every build thing with my
suggestion, not the rollback bit. Rollback would require a temporary
(i.e. for the distro release that it applies to ONLY) Epoch to bump it
back down. Epochs should go away after they're no longer necessary.
Though, technically, as Florian mentioned, distro-sync also works
without having to do Epochs.
--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Rawhide-20171007.n.0 compose check report
Missing expected images: Server dvd i386 Workstation live i386 Server boot i386 Kde live i386 Failed openQA tests: 79/126 (x86_64), 1/2 (arm) New failures (same test did not fail in Rawhide-20171006.n.0): ID: 153296 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/153296 ID: 153300 Test: x86_64 Workstation-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/153300 ID: 153310 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/153310 ID: 153317 Test: x86_64 KDE-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/153317 Old failures (same test failed in Rawhide-20171006.n.0): ID: 153265 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/153265 ID: 153266 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/153266 ID: 153268 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/153268 ID: 153269 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/153269 ID: 153271 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/153271 ID: 153275 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/153275 ID: 153276 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/153276 ID: 153287 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/153287 ID: 153288 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/153288 ID: 153302 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/153302 ID: 153303 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/153303 ID: 153304 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/153304 ID: 153305 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/153305 ID: 153307 Test: x86_64 KDE-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/153307 ID: 153319 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/153319 ID: 153321 Test: x86_64 universal install_multi_empty URL: https://openqa.fedoraproject.org/tests/153321 ID: 153322 Test: x86_64 universal install_btrfs URL: https://openqa.fedoraproject.org/tests/153322 ID: 153324 Test: x86_64 universal install_blivet_xfs@uefi URL: https://openqa.fedoraproject.org/tests/153324 ID: 153325 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/153325 ID: 153326 Test: x86_64 universal install_simple_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/153326 ID: 153327 Test: x86_64 universal install_simple_free_space@uefi URL: https://openqa.fedoraproject.org/tests/153327 ID: 153328 Test: x86_64 universal install_multi_empty@uefi URL: https://openqa.fedoraproject.org/tests/153328 ID: 153329 Test: x86_64 universal install_delete_partial@uefi URL: https://openqa.fedoraproject.org/tests/153329 ID: 153330 Test: x86_64 universal install_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/153330 ID: 153331 Test: x86_64 universal install_ext3@uefi URL: https://openqa.fedoraproject.org/tests/153331 ID: 153332 Test: x86_64 universal install_xfs@uefi URL: https://openqa.fedoraproject.org/tests/153332 ID: 15 Test: x86_64 universal install_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/15 ID: 153334 Test: x86_64 universal install_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/153334 ID: 153335 Test: x86_64 universal install_kickstart_hdd URL: https://openqa.fedoraproject.org/tests/153335 ID: 153336 Test: x86_64 universal upgrade_minimal_64bit URL: https://openqa.fedoraproject.org/tests/153336 ID: 153337 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/153337 ID: 153338 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/153338 ID: 153339 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/153339 ID: 153341 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/153341 ID: 153342 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/153342 ID: 153348 Test: x86_64 universal install_updates_img_local URL: https://openqa.fedoraproject.org/tests/153348 ID: 153349 Test: x86_64 universal install_shrink_ext4 URL: https://openqa
Re: Giving us the ability to go backwards [was Re: plan to update F27 to systemd-235]
On Sat, Oct 07, 2017 at 12:45:14PM -0400, Neal Gompa wrote:
> On Sat, Oct 7, 2017 at 12:31 PM, Matthew Miller
> wrote:
> > On Sat, Oct 07, 2017 at 10:33:38AM -0400, Colin Walters wrote:
> >> I'm personally very in favor of this; of course my usual refrain
> >> here is that we should *try* new things and have the ability
> >> to back them out if they don't work (the latter bit is what the
> >> current system doesn't support).
> >
> > You know, we could easily _start_ supporting the thing you want if we
> > switched from "Epoch is a horrible confusing hack that should never get
> > used" to "We increment Epoch every time instead of Release (and don't
> > reset back to 1 on new versions)".
> >
> > We could even define Release to %{epoch} and remove it from spec files,
> > giving a user-visible indicator, even if that's not what the tools sort
> > on. Or, I guess, we could to the other way around and define Epoch to
> > equal release.
> >
>
> No. Please don't do this. If anything, I want Epoch to be a thing that
> we reset on new distribution releases, since our tooling does support
> this and the distribution upgrade procedures have long since been
> adapted to handle it. Epochs shouldn't be permanent. :(
>
> > We could also change the tools to increment with every build rather
> > than manually — then, things like git-revert-and-build- would work. The
> > ability to revert to previously-existing binaries *without* rebuilding
> > would take more invasive tooling changes, of course.
> >
>
> We could do this now with the Release field. I've mentioned it
> numerous times in the past that this is a well-proven idea. SUSE does
> this now with OBS, which is why their release field is set to the
> following format:
>
> Release: .
>
> The values above are automatically written by OBS, ignoring whatever
> Release is set to. When the version is bumped, is
> reset to 1. Whenever a rebuild occurs for whatever reason, the
> is bumped, but it resets to 1 on a new commit+submit
> build.
>
> So, for example:
>
> 1. foo v1 => Release: 1.1
> 2. adjust spec => Release: 2.1
> 3. auto-rebuild due to dependency change => Release: 2.2
> 4. adjust spec => Release: 3.1
> 5. foo v2 => Release: 1.1
>
> Since we don't have nice things like auto-rebuild of reverse
> dependencies for packages, we could probably simplify the scheme to
> be:
>
> Release: %{?dist}
But the version is evaluated before the release no? So how would rollback work
if we're only touching the release field (ie the last one evaluated)?
Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 27-20171007.n.0 compose check report
Missing expected images: Server dvd i386 Workstation live i386 Server boot i386 Kde live i386 Failed openQA tests: 17/128 (x86_64), 1/2 (arm) New failures (same test did not fail in 27-20171006.n.0): ID: 153431 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/153431 ID: 153432 Test: x86_64 Server-dvd-iso server_cockpit_basic URL: https://openqa.fedoraproject.org/tests/153432 ID: 153438 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/153438 ID: 153517 Test: x86_64 universal install_blivet_lvmthin URL: https://openqa.fedoraproject.org/tests/153517 ID: 153535 Test: x86_64 universal install_blivet_xfs URL: https://openqa.fedoraproject.org/tests/153535 Old failures (same test failed in 27-20171006.n.0): ID: 153427 Test: x86_64 Server-dvd-iso base_services_start URL: https://openqa.fedoraproject.org/tests/153427 ID: 153447 Test: x86_64 Workstation-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/153447 ID: 153457 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/153457 ID: 153464 Test: x86_64 KDE-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/153464 ID: 153467 Test: arm Minimal-raw_xz-raw.xz base_services_start_arm URL: https://openqa.fedoraproject.org/tests/153467 ID: 153486 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/153486 ID: 153488 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/153488 ID: 153491 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/153491 ID: 153501 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/153501 ID: 153502 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/153502 ID: 153508 Test: x86_64 universal install_rescue_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/153508 ID: 153523 Test: x86_64 universal install_mirrorlist_graphical URL: https://openqa.fedoraproject.org/tests/153523 ID: 153540 Test: x86_64 universal install_rescue_encrypted URL: https://openqa.fedoraproject.org/tests/153540 Soft failed openQA tests: 2/128 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in 27-20171006.n.0): ID: 153485 Test: x86_64 universal upgrade_minimal_64bit URL: https://openqa.fedoraproject.org/tests/153485 ID: 153487 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/153487 Passed openQA tests: 108/128 (x86_64), 1/2 (arm) Installed system changes in test x86_64 Server-boot-iso install_default@uefi: System load changed from 0.27 to 0.12 Previous test data: https://openqa.fedoraproject.org/tests/153092#downloads Current test data: https://openqa.fedoraproject.org/tests/153412#downloads Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 2 packages(s) added since previous compose: amiri-fonts, amiri-fonts-common 1 packages(s) removed since previous compose: alef-fonts System load changed from 0.03 to 0.21 Previous test data: https://openqa.fedoraproject.org/tests/153095#downloads Current test data: https://openqa.fedoraproject.org/tests/153415#downloads Installed system changes in test x86_64 Server-dvd-iso install_default_upload: 2 packages(s) added since previous compose: amiri-fonts, amiri-fonts-common 1 packages(s) removed since previous compose: alef-fonts Previous test data: https://openqa.fedoraproject.org/tests/153096#downloads Current test data: https://openqa.fedoraproject.org/tests/153416#downloads Installed system changes in test x86_64 Workstation-live-iso install_default_upload: System load changed from 0.31 to 0.66 Average CPU usage changed from 1.99047619 to 30.08571429 Previous test data: https://openqa.fedoraproject.org/tests/153119#downloads Current test data: https://openqa.fedoraproject.org/tests/153439#downloads Installed system changes in test x86_64 Workstation-boot-iso install_default: System load changed from 0.36 to 0.73 Average CPU usage changed from 6.78095238 to 18.27619048 Used mem changed from 855 MiB to 979 MiB Previous test data: https://openqa.fedoraproject.org/tests/153132#downloads Current test data: https://openqa.fedoraproject.org/tests/153452#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 3 packages(s) removed since previous compose: kaccessible, kaccessible-libs, qaccessibilityclient System load changed from 0.88 to 1.18 Previous test data: https://openqa.fedoraproject.org/tests/153135#downloads Current test data: https://openqa.fedoraproject.org/tests/153455#downloads Installed system changes in test x86
Re: Giving us the ability to go backwards [was Re: plan to update F27 to systemd-235]
On Sat, Oct 7, 2017 at 12:47 PM, Igor Gnatenko
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Sat, 2017-10-07 at 12:31 -0400, Matthew Miller wrote:
>> On Sat, Oct 07, 2017 at 10:33:38AM -0400, Colin Walters wrote:
>> > I'm personally very in favor of this; of course my usual refrain
>> > here is that we should *try* new things and have the ability
>> > to back them out if they don't work (the latter bit is what the
>> > current system doesn't support).
>>
>> You know, we could easily _start_ supporting the thing you want if we
>> switched from "Epoch is a horrible confusing hack that should never
>> get
>> used" to "We increment Epoch every time instead of Release (and don't
>> reset back to 1 on new versions)".
> Please, don't.
>
> Epoch is horrible hack and breaks Requires / any other dependencies in
> unpredictable ways.
>
> Imagine, you have systemd which would have Epoch: 1 and Version: 234..
> Now you do Requires: systemd >= 235 and the dependency is satisfied
> because 1:234 > 235.
>>
>> We could even define Release to %{epoch} and remove it from spec
>> files,
>> giving a user-visible indicator, even if that's not what the tools
>> sort
>> on. Or, I guess, we could to the other way around and define Epoch to
>> equal release.
> openSUSE uses distepoch, so any version of next release of distribution
> "upgrades" old ones (even if version is lower). So far we use yet
> another hack called %{?dist} in Release and assuming that packagers
> will make sure that their builds for new distro are higher.
>
That's OpenMandriva that uses it, but libsolv does support handling it
for upgrade calculations. We'd need to complete support for DistTag
and implement support for DistEpoch in rpm, but it's a much cleaner
way to handle that if you care for the "always go up on upgrade"
thing.
I experimented a bit with it and it seems nicer than what we do now,
and it cleans up the Release tag, which is always nice. :D
> I am strongly against using Epoch for purpose like this, but we could
> reuse distepoch. But probably just making assumption like
> update==distro-sync would do this trick as well.
Yep. distro-sync also now has the alias of dist-upgrade, which makes
it clear what purpose it's for.
>>
>> We could also change the tools to increment with every build rather
>> than manually — then, things like git-revert-and-build- would work.
>> The
>> ability to revert to previously-existing binaries *without*
>> rebuilding
>> would take more invasive tooling changes, of course.
> I don't see how this could work at all.
Well, we're bad at automating stuff like this in Fedora, so I doubt we
could pull that off. :(
--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Giving us the ability to go backwards [was Re: plan to update F27 to systemd-235]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sat, 2017-10-07 at 12:31 -0400, Matthew Miller wrote:
> On Sat, Oct 07, 2017 at 10:33:38AM -0400, Colin Walters wrote:
> > I'm personally very in favor of this; of course my usual refrain
> > here is that we should *try* new things and have the ability
> > to back them out if they don't work (the latter bit is what the
> > current system doesn't support).
>
> You know, we could easily _start_ supporting the thing you want if we
> switched from "Epoch is a horrible confusing hack that should never
> get
> used" to "We increment Epoch every time instead of Release (and don't
> reset back to 1 on new versions)".
Please, don't.
Epoch is horrible hack and breaks Requires / any other dependencies in
unpredictable ways.
Imagine, you have systemd which would have Epoch: 1 and Version: 234..
Now you do Requires: systemd >= 235 and the dependency is satisfied
because 1:234 > 235.
>
> We could even define Release to %{epoch} and remove it from spec
> files,
> giving a user-visible indicator, even if that's not what the tools
> sort
> on. Or, I guess, we could to the other way around and define Epoch to
> equal release.
openSUSE uses distepoch, so any version of next release of distribution
"upgrades" old ones (even if version is lower). So far we use yet
another hack called %{?dist} in Release and assuming that packagers
will make sure that their builds for new distro are higher.
I am strongly against using Epoch for purpose like this, but we could
reuse distepoch. But probably just making assumption like
update==distro-sync would do this trick as well.
>
> We could also change the tools to increment with every build rather
> than manually — then, things like git-revert-and-build- would work.
> The
> ability to revert to previously-existing binaries *without*
> rebuilding
> would take more invasive tooling changes, of course.
I don't see how this could work at all.
>
>
> --
> Matthew Miller
>
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
- --
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-
iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlnZBTkACgkQaVcUvRu8
X0y4UQ/9GBqUQZrcj92eA4icLk6N64STpZRRm6HZM4mFrZwh4lop0h9pXUKQ7rjG
CryZnaMgtN3VPQkzpPkgwfQq510etlda9qIIFihS/HQI2Uxyx5ZOhhEIKHd2VH48
3N2TOOht1InePM7AOFxk3nM26TBSzFjSka33gfkS0/GarSe3E97+LmXc3qEfN5FY
zpHAbH9TW8nTqqXxYAH15MtHJr8Hv/KGxyGSbIyFXrSM+UmFNhDT2xNcC7L/JgzK
Vp6L+G42Ss4GKbgU1/rV5JQhhdxm8tHaaGnnjauz3URtNqmJ3VAHKnmn8HDht7IY
gIGt/6yCev7HdumVifyiyovuiaXh50JV2G9syApBokjHvXFFZpnY0WybMHeuEK0o
I5sVkT0shvsqs4lZIbFw9NertHBR2DopYeJy7GNxfObhbgbZsiJvNwoHLQHEWvpv
yrBAx+Nuply51+fgSs41FsNjrCDLsz7pkLZqPBeDfd11AfxkKe4H9fQecOU1vNqm
axRjCfRNEwyLdVXwEU3O/Z0os/QY7yKKqQCJA+mMDyzEjiY9rm+yGFYjGixWbp+w
nN5+ZRvFqxTiCBYHm5yhLezKLo3yUcgJ+6IrJgNzVpq4Amx2luzh+b/NVV/jn3Lm
SLNJ5lvwdEIUC+dh6fAInnWiHlpPLCTWh5miPBsE91LJi+pLUTQ=
=GzSG
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Giving us the ability to go backwards [was Re: plan to update F27 to systemd-235]
On Sat, Oct 7, 2017 at 12:31 PM, Matthew Miller
wrote:
> On Sat, Oct 07, 2017 at 10:33:38AM -0400, Colin Walters wrote:
>> I'm personally very in favor of this; of course my usual refrain
>> here is that we should *try* new things and have the ability
>> to back them out if they don't work (the latter bit is what the
>> current system doesn't support).
>
> You know, we could easily _start_ supporting the thing you want if we
> switched from "Epoch is a horrible confusing hack that should never get
> used" to "We increment Epoch every time instead of Release (and don't
> reset back to 1 on new versions)".
>
> We could even define Release to %{epoch} and remove it from spec files,
> giving a user-visible indicator, even if that's not what the tools sort
> on. Or, I guess, we could to the other way around and define Epoch to
> equal release.
>
No. Please don't do this. If anything, I want Epoch to be a thing that
we reset on new distribution releases, since our tooling does support
this and the distribution upgrade procedures have long since been
adapted to handle it. Epochs shouldn't be permanent. :(
> We could also change the tools to increment with every build rather
> than manually — then, things like git-revert-and-build- would work. The
> ability to revert to previously-existing binaries *without* rebuilding
> would take more invasive tooling changes, of course.
>
We could do this now with the Release field. I've mentioned it
numerous times in the past that this is a well-proven idea. SUSE does
this now with OBS, which is why their release field is set to the
following format:
Release: .
The values above are automatically written by OBS, ignoring whatever
Release is set to. When the version is bumped, is
reset to 1. Whenever a rebuild occurs for whatever reason, the
is bumped, but it resets to 1 on a new commit+submit
build.
So, for example:
1. foo v1 => Release: 1.1
2. adjust spec => Release: 2.1
3. auto-rebuild due to dependency change => Release: 2.2
4. adjust spec => Release: 3.1
5. foo v2 => Release: 1.1
Since we don't have nice things like auto-rebuild of reverse
dependencies for packages, we could probably simplify the scheme to
be:
Release: %{?dist}
Though I would love to see us be able to do auto-rebuild of reverse
deps on submit and auto-bundling with an update, as that would
alleviate a huge burden, I don't think that will ever happen. :(
--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Giving us the ability to go backwards [was Re: plan to update F27 to systemd-235]
On 10/07/2017 06:31 PM, Matthew Miller wrote:
On Sat, Oct 07, 2017 at 10:33:38AM -0400, Colin Walters wrote:
I'm personally very in favor of this; of course my usual refrain
here is that we should *try* new things and have the ability
to back them out if they don't work (the latter bit is what the
current system doesn't support).
You know, we could easily _start_ supporting the thing you want if we
switched from "Epoch is a horrible confusing hack that should never get
used" to "We increment Epoch every time instead of Release (and don't
reset back to 1 on new versions)".
We could even define Release to %{epoch} and remove it from spec files,
giving a user-visible indicator, even if that's not what the tools sort
on. Or, I guess, we could to the other way around and define Epoch to
equal release.
This will break updates across Fedora releases (or any kind of
branches). It would boil down to “always use distro-sync after
switching branches”. That's not far from “always use distro-sync”, at
which point we don't really need ordered version numbers anymore (except
maybe for checks in RPM scriptlets, but those would like not work
correctly with the epoch change as well).
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Giving us the ability to go backwards [was Re: plan to update F27 to systemd-235]
On Sat, Oct 07, 2017 at 10:33:38AM -0400, Colin Walters wrote:
> I'm personally very in favor of this; of course my usual refrain
> here is that we should *try* new things and have the ability
> to back them out if they don't work (the latter bit is what the
> current system doesn't support).
You know, we could easily _start_ supporting the thing you want if we
switched from "Epoch is a horrible confusing hack that should never get
used" to "We increment Epoch every time instead of Release (and don't
reset back to 1 on new versions)".
We could even define Release to %{epoch} and remove it from spec files,
giving a user-visible indicator, even if that's not what the tools sort
on. Or, I guess, we could to the other way around and define Epoch to
equal release.
We could also change the tools to increment with every build rather
than manually — then, things like git-revert-and-build- would work. The
ability to revert to previously-existing binaries *without* rebuilding
would take more invasive tooling changes, of course.
--
Matthew Miller
Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: plan to update F27 to systemd-235
On Sat, Oct 7, 2017 at 12:02 PM, Richard W.M. Jones wrote: > On Fri, Oct 06, 2017 at 03:04:12PM +, Zbigniew Jędrzejewski-Szmek wrote: >> Hi, >> >> systemd 235 was released today. A large number of issues was closed >> upstream, including many bug fixes, documentation updates, and >> long-standing RFEs. There are some new features, but relatively few >> entirely new features or changes in behaviour that impact other >> services. There also are no (intentional) breaking changes. > > What happened to systemd stable > (https://github.com/systemd/systemd-stable)? The last commit is in > 2013. > > I think it'd be better if systemd had a stable branch and that's what > we used for anything (except Rawhide of course). > There's already a v235 branch: https://github.com/systemd/systemd-stable/tree/v235-stable My understanding is that it's used to maintain backports from systemd development for distributions to use, and Fedora leverages that already. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: plan to update F27 to systemd-235
On Fri, Oct 06, 2017 at 03:04:12PM +, Zbigniew Jędrzejewski-Szmek wrote: > Hi, > > systemd 235 was released today. A large number of issues was closed > upstream, including many bug fixes, documentation updates, and > long-standing RFEs. There are some new features, but relatively few > entirely new features or changes in behaviour that impact other > services. There also are no (intentional) breaking changes. What happened to systemd stable (https://github.com/systemd/systemd-stable)? The last commit is in 2013. I think it'd be better if systemd had a stable branch and that's what we used for anything (except Rawhide of course). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: SELinux policy contibutions
On Thu, Mar 23, 2017 at 6:53 AM, Lukas Vrabec wrote: > On 03/23/2017 01:12 PM, Robert Marcano wrote: >> >> Greetings. Is https://github.com/fedora-selinux/selinux-policy-contrib >> the right place to contribute to the Fedora SELinux policy? >> >> I added a pull request for a small update needed for a new release of >> cups-pdf, but I am not sure someone is monitoring that. There is another >> one from rhatdan there so I presume is the right place. > > > Yes, It's right place. I'll check tour PR ASAP. I don't believe that anybody looks at those pull requests on a regular basis. Should somebody be doing so? There are 8 pull requests, dating back to about the time of the above conversation. Five of those don't contain a single comment. I opened one for gcl on July 29, and added a comment a month later asking if somebody was going to look at it. No response. This is a bit annoying, considering that I opened a bugzilla request asking for the same thing 4 years ago, and no action has ever been taken on it. I thought maybe a PR would finally get something to happen. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: State of Sparkeshare in Fedora
On vendredi 6 octobre 2017 22:24:01 CEST Luya Tshimbalanga wrote: > On 24/09/17 11:47 AM, James Hogarth wrote: > > On 24 September 2017 at 16:29, Michael Catanzaro > > > > mailto:mike.catanz...@gmail.com>> wrote: > > On Fri, Sep 22, 2017 at 2:09 AM, James Hogarth > > > > mailto:james.hoga...@gmail.com>> wrote: > > Based on the fedora update policy and the acknowledged > > breaking changes in 2.0 we should only really update to the > > most recent 1.x in F27 and below at this time. > > > > The latest version should be a self contained change in F28. > > > > I haven't been following this closely, but my understanding is > > that if it's not updated, there won't be any Sparkleshare in F27, > > since one of the current version's dependencies (WebKitGTK+ 2.4) > > is gone. So the update should go into F27 as well (which has not > > even reached beta yet, despite the freeze). The updates policy is > > very important, but it doesn't trump common sense. :) > > > > The Sparkeshare 1.5 release removes that dependency fixing the issue > > and keeping it in Fedora. > > > > Having that in F27 and 2.0 in F28 would be most keeping in spirit with > > our policies I'd suggest. > > I attempt to build Sparkleshare 1.5 on master but the main issue is the > webkitgitk dependency. Suggestion welcome to fix that: > > https://src.fedoraproject.org/fork/luya/rpms/sparkleshare/blob/master/f/spar > kleshare.spec Hello Luya, I've worked on this issue this afternoon, you can find the resulting SPEC, SRPM and patches here: https://eclipseo.fedorapeople.org/sparkleshare/ The main patch backports the changes made in 2.0 for WebkitGTK 2.0 compatibility. It builds in Mock and Koji but I haven't attempted to run the program itself. Best regards, Robert-André ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: plan to update F27 to systemd-235
On Sat, Oct 7, 2017, at 08:14 AM, Zbigniew Jędrzejewski-Szmek wrote: > Well, my point is that in this case there aren't any big changes, only> some > relatively minor feature additions. According to the policy, > "minor" upgrades are OK after beta. The only difference for critical > path packages is some additional karma requirements. I'm personally very in favor of this; of course my usual refrain here is that we should *try* new things and have the ability to back them out if they don't work (the latter bit is what the current system doesn't support). > The formal side is pretty clear. Instead, I'm giving the heads up in > case any technical issues or regressions crop up. I'm especially > interested in feedback from people who run rawhide, especially if they> use > various container technologies, namespaces, and such, which is > probably the area most like to regress. Yes that said...things like the systemd-nspawn changing to a syscall whitelist seems highly likely to aggravate the current problems with mock: https://pagure.io/releng/issue/6967 See also https://pagure.io/releng/issue/6602#comment-71214 >From a while ago. We go to quite a bit of effort in the rpm-ostree side to work around oddities from running in nspawn. https://github.com/projectatomic/bubblewrap/issues/171#issuecomment-27773181[1]Was also really fun. Basically nspawn isn’t very focused on the privileged/recursive container case. And while nspawn is OK for building RPMs, other cases like Lorax and rpm-ostree need more privileges. Links: 1. https://github.com/projectatomic/bubblewrap/issues/171#issuecomment-277731811 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: plan to update F27 to systemd-235
On 7 October 2017 at 13:14, Zbigniew Jędrzejewski-Szmek wrote: > On Sat, Oct 07, 2017 at 09:19:17AM +0100, James Hogarth wrote: > > Although personally I have no specific objections and indeed plan to use > > the IP accounting stuff on a bunch of units... since we're already past > > beta, this is a critical component of the system and it's not got a > Change > > on the wiki for F27 I'd suggest that you need to raise your case with > FESCo > > for approval of doing this. > > Well, my point is that in this case there aren't any big changes, only > some relatively minor feature additions. According to the policy, > "minor" upgrades are OK after beta. The only difference for critical > path packages is some additional karma requirements. > > The formal side is pretty clear. Instead, I'm giving the heads up in > case any technical issues or regressions crop up. I'm especially > interested in feedback from people who run rawhide, especially if they > use various container technologies, namespaces, and such, which is > probably the area most like to regress. In addition, it's possible that > the fixes that are present in v235 could break some use cases. AFAIK, > we didn't change documented behaviour, but rather clarified various gray > areas, but I'm well aware that upstream developers test systemd only in > narrow fraction of ways it is used in the wild. Hence this thread. > Sorry, I should have made that clearer in my original e-mail. > > Zbyszek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Ah gotcha .. I'm looking forward to DynamicUser ... I'll probably update lldpd and sslh to make use of that later on in the weekend to give it a test. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: plan to update F27 to systemd-235
On Sat, Oct 07, 2017 at 09:19:17AM +0100, James Hogarth wrote: > Although personally I have no specific objections and indeed plan to use > the IP accounting stuff on a bunch of units... since we're already past > beta, this is a critical component of the system and it's not got a Change > on the wiki for F27 I'd suggest that you need to raise your case with FESCo > for approval of doing this. Well, my point is that in this case there aren't any big changes, only some relatively minor feature additions. According to the policy, "minor" upgrades are OK after beta. The only difference for critical path packages is some additional karma requirements. The formal side is pretty clear. Instead, I'm giving the heads up in case any technical issues or regressions crop up. I'm especially interested in feedback from people who run rawhide, especially if they use various container technologies, namespaces, and such, which is probably the area most like to regress. In addition, it's possible that the fixes that are present in v235 could break some use cases. AFAIK, we didn't change documented behaviour, but rather clarified various gray areas, but I'm well aware that upstream developers test systemd only in narrow fraction of ways it is used in the wild. Hence this thread. Sorry, I should have made that clearer in my original e-mail. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
orphaning OpenStego
Dear Developpers, I'm sorry to inform you I orphaned OpenStego package, I can't maintain it anymore. The software doesn't work in fedora since two updates, upstream is not able to fix the problem (first report was in 2012 IIRC). It is a very old package and should be retired in six weeks. Best regards, Casper -- GPG Key ID: 83288189 @ hkp://keys.fedoraproject.org Empreinte: CC26 692F 5205 AC8F 7912 7783 D7A7 F4C5 8328 8189 x509 C.A.: https://dl.casperlefantom.net/pub/root.pem Empreinte: 0975 864A 2036 0F94 A139 114A D32E 8EBE 30F2 2429 signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Removing ghostscript-fonts package
On Fri, Oct 6, 2017 at 9:51 PM, R P Herrold wrote: > On Fri, 6 Oct 2017, Xose Vazquez Perez wrote: > >> Zdenek Dohnal wrote: >> >> > I am going to retire ghostscript-fonts package in F27 because its fonts >> > are deprecated and replaced by urw-base35-fonts package. > > > I don't see a urw-base35-fonts SRPM in my RawHide ... has it > been packaged? https://koji.fedoraproject.org/koji/packageinfo?packageID=24486 If you're just doing a dnf query you probably need to do urw-base35* > My mirror only fires weekly, but it seens ... hasty to retire > a package before its successor has 'aged' a bit to let > possible bugs appear. In checking the CTAN site, it seems > pretty likely that font metrics will have changed and so the > appearance of documents will be affected > > -- Russ herrold > ___ > 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: Removing ghostscript-fonts package
On Fri, Oct 6, 2017 at 10:54 PM, Samuel Sieb wrote: > On 10/06/2017 05:49 AM, Zdenek Dohnal wrote: >> >> I am going to retire ghostscript-fonts package in F27 because its fonts >> are deprecated and replaced by urw-base35-fonts package. Only package >> which depends on ghostscript-fonts seems to be hylafax+ package, I >> created bugzilla for it >> https://bugzilla.redhat.com/show_bug.cgi?id=1499240 . Does anyone have >> any objections on its retirement? >> >> If there isn't any objections, I'll retire it next Monday. > > > Isn't it too late to retire it for F27? And unless there's a pressing > reason to retire it, the usual procedure is for you to orphan it and if no > one else wants it, it will get retired automatically. No, that's not necessarily the case, if it's dead upstream and the maintainer knows that there's reason to just retire it they can do exactly that. The orphan first tends to be for packages where it's not necessarily dead and someone might be interested in it. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: plan to update F27 to systemd-235
On 6 Oct 2017 16:08, "Zbigniew Jędrzejewski-Szmek" wrote: Hi, systemd 235 was released today. A large number of issues was closed upstream, including many bug fixes, documentation updates, and long-standing RFEs. There are some new features, but relatively few entirely new features or changes in behaviour that impact other services. There also are no (intentional) breaking changes. The update is building for rawhide. If nothing major pops up, I'd like to release the update for F27 too. (The updates policy says that "major version updates should be avoided", but systemd does not use semantic versioning, so there's no distinction between major and minor releases. A number of patches was backported previously, and are already present in F27, but there are other fixes that are too numerous to backport, and which would be desirable to have in F27.) Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Although personally I have no specific objections and indeed plan to use the IP accounting stuff on a bunch of units... since we're already past beta, this is a critical component of the system and it's not got a Change on the wiki for F27 I'd suggest that you need to raise your case with FESCo for approval of doing this. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Removing ghostscript-fonts package
Hi, Thank you both for starting to clean up the awful mess that URW fonts had become over time. It had come to the point they were totally unusable by anything but a few apps that hardcoded them. They were tripping many many users (countless why *awful things* happen as soon as I try to use one of the urw fonts in my app, it's time proven right ?) The next step of course is to replace Postscript fonts with Opentype CFF versions (.otf), since that's what most apps expect. The few apps that used to work with Postscript fonts are getting sick of them (LibreOffice is filtering legacy font formats now for example). Since OpenType .otf versions ship CFF outlines like Postscript there is no risk of breaking metric compatibility. Nitpick: Fedora packages are supposed to group fonts by family. As Microsoft noted in its WPF font model whitepaper, the CSS model and apps only know to manage weight, width or slant qualifiers. So anything which is a weight, width or slant qualifier is a font face name (in the same Fedora package), and anything else a different font family. Therefore urw-base35-nimbus-sans-fonts and urw-base35-nimbus-sans-narrow-fonts should be merged (narrow is a width qualifier). But even though splitting those what a mistake, over-spitting is much better for users than under-splitting! (the 4 faces only thing is actually another Postscript legacy limitation IIRC). Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
is anybody using fedora-loadmodules.service and fedora-readonly.service?
Two boot-time services provided by the venerable initscripts package: – fedora-loadmodules.service: this loads kernel modules based on configuration in /etc/rc.modules. Identical functionality is provided by systemd-modules-load.service. (systemd-modules-load.service reads modules-load.d directories and the kernel command line, not /etc/rc.modules). Is anybody still using /etc/rc.modules? It'd be nice to just drop support for /etc/rc.modules by not enabling fedora-loadmodules.service by default, and then drop it completely. - fedora-readonly.service: this is used to mount parts of the filesystem rw in case the system is using read-only root filesystem. To do anything this service checks if READONLY=yes is set in /etc/sysconfig/readonly-root. Is anybody using this? If yes, would it be OK if the service was not enabled by default anymore and would require an explicit 'systemctl enable fedora-readonly.service' or creating a custom preset (in addition to setting READONLY=yes) to be active? See https://bugzilla.redhat.com/show_bug.cgi?id=1493479 and https://pagure.io/fesco/issue/1779 for some more info. [ Why disable those services by default? The most obvious reason is that this is additional stuff the runs during boot, making things a tiny bit slower and the logs slightly more verbose. But this is very weak reason. More important is that the way those services are implemented is largely obsolete. fedora-loadmodules.service is completely duplicated by systemd-modules-load.service, so it'd make sense to drop the Fedora-specific service. fedora-readonly.service is based on mounting tmpfs dirs, copying files around, doing selinux fixups, manually mounting rpcfs and nfs, etc. I have never seen fedora-readonly.service actually used, but that doesn't mean much. If people are using them I'd love to hear about their use cases, and think if we can provide the same functionality using more modern mechanisms. Without breaking existing setups, I'd like to disable this by default to simplify the boot process and not encourage the use in new installations. ] Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
