Re: Fedora 30 System-Wide Change proposal: Remove glibc-all-langpacks from buildroot
Hi Zbigniew, nice to meet you at Flock. On Thu, Aug 23, 2018 at 5:30 AM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot > > == Summary == > glibc-minimal-langpack is added to @Buildsystem group and installed > into the minimal buildroot instead of glibc-all-langpacks. Packages > which need more locales than plain C/C.UTF-8/POSIX need to pull them > in through BuildRequires. > I think not installing glibc-all-langpacks by default in the Koji buildroot makes good sense but how about replacing it in the first instance with glibc-langpack-en? A quick grep over spec files reveals: > ``` > $ rg -l 'LC_CTYPE=[^C]' *.spec | wc -l > 11 > $ rg -l 'LC_ALL=[^C]' *.spec | wc -l > 42 > ``` > Also: $ grep -l -e LANG=en *.spec | wc -l 99 Jens ___ 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
Fedora 29-20180903.n.0 compose check report
No missing expected images. Failed openQA tests: 9/132 (x86_64), 2/24 (i386), 1/2 (arm) ID: 273823 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/273823 ID: 273833 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/273833 ID: 273834 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/273834 ID: 273848 Test: i386 Workstation-live-iso install_default URL: https://openqa.fedoraproject.org/tests/273848 ID: 273859 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/273859 ID: 273865 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/273865 ID: 273868 Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/273868 ID: 273884 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/273884 ID: 273892 Test: x86_64 universal install_blivet_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/273892 ID: 273894 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/273894 ID: 273939 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/273939 ID: 273958 Test: i386 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/273958 Soft failed openQA tests: 73/132 (x86_64), 18/24 (i386) (Tests completed, but using a workaround for a known bug) ID: 273801 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/273801 ID: 273802 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/273802 ID: 273804 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/273804 ID: 273805 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/273805 ID: 273807 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/273807 ID: 273808 Test: x86_64 Server-dvd-iso server_cockpit_default URL: https://openqa.fedoraproject.org/tests/273808 ID: 273814 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/273814 ID: 273816 Test: x86_64 Server-dvd-iso server_cockpit_basic URL: https://openqa.fedoraproject.org/tests/273816 ID: 273817 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/273817 ID: 273820 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/273820 ID: 273821 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/273821 ID: 273827 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/273827 ID: 273828 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/273828 ID: 273829 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/273829 ID: 273830 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/273830 ID: 273831 Test: i386 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/273831 ID: 273852 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/273852 ID: 273864 Test: i386 KDE-live-iso install_default URL: https://openqa.fedoraproject.org/tests/273864 ID: 273869 Test: x86_64 universal install_xfs URL: https://openqa.fedoraproject.org/tests/273869 ID: 273870 Test: x86_64 universal install_lvmthin URL: https://openqa.fedoraproject.org/tests/273870 ID: 273871 Test: x86_64 universal install_no_swap URL: https://openqa.fedoraproject.org/tests/273871 ID: 273872 Test: x86_64 universal install_blivet_ext3 URL: https://openqa.fedoraproject.org/tests/273872 ID: 273873 Test: x86_64 universal install_blivet_btrfs URL: https://openqa.fedoraproject.org/tests/273873 ID: 273874 Test: x86_64 universal install_blivet_no_swap URL: https://openqa.fedoraproject.org/tests/273874 ID: 273875 Test: x86_64 universal install_blivet_xfs URL: https://openqa.fedoraproject.org/tests/273875 ID: 273876 Test: x86_64 universal install_blivet_software_raid URL: https://openqa.fedoraproject.org/tests/273876 ID: 273877 Test: x86_64 universal install_blivet_lvmthin URL: https://openqa.fedoraproject.org/tests/273877 ID: 273878 Test: x86_64 universal install_simple_free_space@uefi URL: https://openqa.fedoraproject.org/tests/273878 ID: 273879 Test: x86_64 universal install_multi_empty@uefi URL: https://openqa.fedoraproject.org/tests/273879 ID: 273880 Test: x86
Fedora Rawhide-20180903.n.0 compose check report
No missing expected images. Failed openQA tests: 31/132 (x86_64), 2/24 (i386), 1/2 (arm) New failures (same test did not fail in Rawhide-20180902.n.0): ID: 273745 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/273745 Old failures (same test failed in Rawhide-20180902.n.0): ID: 273600 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/273600 ID: 273603 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/273603 ID: 273621 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/273621 ID: 273628 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/273628 ID: 273631 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/273631 ID: 273632 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/273632 ID: 273644 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/273644 ID: 273645 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/273645 ID: 273646 Test: i386 Workstation-live-iso install_default URL: https://openqa.fedoraproject.org/tests/273646 ID: 273650 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/273650 ID: 273657 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/273657 ID: 273663 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/273663 ID: 273666 Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/273666 ID: 273676 Test: x86_64 universal install_simple_free_space@uefi URL: https://openqa.fedoraproject.org/tests/273676 ID: 273677 Test: x86_64 universal install_multi_empty@uefi URL: https://openqa.fedoraproject.org/tests/273677 ID: 273684 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/273684 ID: 273686 Test: x86_64 universal install_delete_pata@uefi URL: https://openqa.fedoraproject.org/tests/273686 ID: 273689 Test: x86_64 universal install_blivet_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/273689 ID: 273690 Test: x86_64 universal install_blivet_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/273690 ID: 273691 Test: x86_64 universal install_blivet_xfs@uefi URL: https://openqa.fedoraproject.org/tests/273691 ID: 273693 Test: x86_64 universal install_simple_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/273693 ID: 273696 Test: x86_64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/273696 ID: 273697 Test: x86_64 universal install_delete_partial@uefi URL: https://openqa.fedoraproject.org/tests/273697 ID: 273699 Test: x86_64 universal install_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/273699 ID: 273709 Test: x86_64 universal install_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/273709 ID: 273710 Test: x86_64 universal install_blivet_ext3@uefi URL: https://openqa.fedoraproject.org/tests/273710 ID: 273711 Test: x86_64 universal install_blivet_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/273711 ID: 273712 Test: x86_64 universal install_blivet_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/273712 ID: 273715 Test: x86_64 universal install_ext3@uefi URL: https://openqa.fedoraproject.org/tests/273715 ID: 273716 Test: x86_64 universal install_xfs@uefi URL: https://openqa.fedoraproject.org/tests/273716 ID: 273717 Test: x86_64 universal install_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/273717 ID: 273731 Test: x86_64 universal install_sata@uefi URL: https://openqa.fedoraproject.org/tests/273731 ID: 273733 Test: x86_64 universal install_multi@uefi URL: https://openqa.fedoraproject.org/tests/273733 Soft failed openQA tests: 7/132 (x86_64), 3/24 (i386) (Tests completed, but using a workaround for a known bug) New soft failures (same test did not soft fail in Rawhide-20180902.n.0): ID: 273649 Test: x86_64 KDE-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/273649 ID: 273688 Test: x86_64 universal upgrade_minimal_64bit URL: https://openqa.fedoraproject.org/tests/273688 ID: 273702 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/273702 ID: 273724 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/273724 ID: 273725 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/273725 ID: 273735 Test: x86_64 u
Re: upgrade tinyproxy for f29?
On Mon, Sep 3, 2018 at 11:10 PM, Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:
> On Mon, Sep 03, 2018 at 09:38:44PM +0200, Michael Adam wrote:
> > On Mon, Sep 3, 2018 at 7:07 PM, Zbigniew Jędrzejewski-Szmek <
> > zbys...@in.waw.pl> wrote:
> >
> > > On Mon, Sep 03, 2018 at 06:29:34PM +0200, Michael Adam wrote:
> > > > On Mon, Sep 3, 2018 at 5:23 PM, Peter Robinson >
> > > wrote:
> > > >
> > > > > On Mon, Sep 3, 2018 at 4:07 PM Michael Adam
> wrote:
> > > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > Tinyproxy just released a new version 1.10 which is has been
> overdue
> > > > > > and containes 2 CVE fixes apart from several enhancements.
> > > > > >
> > > > > > I created builds for rawhide already.
> > > > > >
> > > > > > I was wondering if it is still possible to get tinyproxy to this
> > > > > important
> > > > > > update in f29, since no other packages depend on it, afaict.
> > > > > >
> > > > > > If so, what do I do? Just update the scm branch and bring it in
> > > through
> > > > > Bodhi?
> > > > >
> > > >
> > > > Thanks for the swift response!
> > > >
> > > > (And apologies for any cluelessness about newer aspects of the fedora
> > > > process - it's been a while since i did these things, and it worked a
> > > little
> > > > differently then...)
> > > >
> > > >
> > > > > Sounds like a reasonable course of action. Is it backward
> compatible
> > > > > in terms of any interface people might use?
> > > >
> > > >
> > > > There are a few config file additions.
> > > > The location of the binary has changed from /usr/sbin
> > > > to /usr/bin . Otherwise no Interfaces i'm aware of.
> > >
> > > You should create a compat symlink from the old location to the new
> > > location, at least in the stable releases, in case somebody calls the
> > > binary by path.
> > >
> >
> > Good point.
> >
> > - Is there an established way to create such a "compat symlink"?
>
> ln -s ../bin/NAME %{buildroot}/usr/sbin/NAME
>
> would be the standard way.
>
> > - What do you mean by "stable releases"?
> > Does F29 (which is not released yet) qualify as that?
> I meant F28 and F27, but since this costs so little, I'd do the same
> for F29 too.
>
Hmm, ok. I guess it is not a problem at this point
if f29 thereby goes one build ahead of master.
If needed later, we can still bump master's release number..
Thanks - Michael
> Zbyszek
> ___
> 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
>
___
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: upgrade tinyproxy for f29?
On Mon, Sep 03, 2018 at 09:38:44PM +0200, Michael Adam wrote:
> On Mon, Sep 3, 2018 at 7:07 PM, Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl> wrote:
>
> > On Mon, Sep 03, 2018 at 06:29:34PM +0200, Michael Adam wrote:
> > > On Mon, Sep 3, 2018 at 5:23 PM, Peter Robinson
> > wrote:
> > >
> > > > On Mon, Sep 3, 2018 at 4:07 PM Michael Adam wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > Tinyproxy just released a new version 1.10 which is has been overdue
> > > > > and containes 2 CVE fixes apart from several enhancements.
> > > > >
> > > > > I created builds for rawhide already.
> > > > >
> > > > > I was wondering if it is still possible to get tinyproxy to this
> > > > important
> > > > > update in f29, since no other packages depend on it, afaict.
> > > > >
> > > > > If so, what do I do? Just update the scm branch and bring it in
> > through
> > > > Bodhi?
> > > >
> > >
> > > Thanks for the swift response!
> > >
> > > (And apologies for any cluelessness about newer aspects of the fedora
> > > process - it's been a while since i did these things, and it worked a
> > little
> > > differently then...)
> > >
> > >
> > > > Sounds like a reasonable course of action. Is it backward compatible
> > > > in terms of any interface people might use?
> > >
> > >
> > > There are a few config file additions.
> > > The location of the binary has changed from /usr/sbin
> > > to /usr/bin . Otherwise no Interfaces i'm aware of.
> >
> > You should create a compat symlink from the old location to the new
> > location, at least in the stable releases, in case somebody calls the
> > binary by path.
> >
>
> Good point.
>
> - Is there an established way to create such a "compat symlink"?
ln -s ../bin/NAME %{buildroot}/usr/sbin/NAME
would be the standard way.
> - What do you mean by "stable releases"?
> Does F29 (which is not released yet) qualify as that?
I meant F28 and F27, but since this costs so little, I'd do the same
for F29 too.
Zbyszek
___
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: upgrade tinyproxy for f29?
On Mon, Sep 3, 2018 at 7:07 PM, Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Mon, Sep 03, 2018 at 06:29:34PM +0200, Michael Adam wrote: > > On Mon, Sep 3, 2018 at 5:23 PM, Peter Robinson > wrote: > > > > > On Mon, Sep 3, 2018 at 4:07 PM Michael Adam wrote: > > > > > > > > Hi all, > > > > > > > > Tinyproxy just released a new version 1.10 which is has been overdue > > > > and containes 2 CVE fixes apart from several enhancements. > > > > > > > > I created builds for rawhide already. > > > > > > > > I was wondering if it is still possible to get tinyproxy to this > > > important > > > > update in f29, since no other packages depend on it, afaict. > > > > > > > > If so, what do I do? Just update the scm branch and bring it in > through > > > Bodhi? > > > > > > > Thanks for the swift response! > > > > (And apologies for any cluelessness about newer aspects of the fedora > > process - it's been a while since i did these things, and it worked a > little > > differently then...) > > > > > > > Sounds like a reasonable course of action. Is it backward compatible > > > in terms of any interface people might use? > > > > > > There are a few config file additions. > > The location of the binary has changed from /usr/sbin > > to /usr/bin . Otherwise no Interfaces i'm aware of. > > You should create a compat symlink from the old location to the new > location, at least in the stable releases, in case somebody calls the > binary by path. > Good point. - Is there an established way to create such a "compat symlink"? - What do you mean by "stable releases"? Does F29 (which is not released yet) qualify as that? > > > If so once it's baked in > > > f29 for a bit, we're in freeze atm any so it won't progress from > > > updates-testing -> stable until Beta gets signed off, you might want > > > to consider pushing to stable releases too due to CVEs > > > > > > > Ok, so can you or s/o confirm next steps: > > > > - bring it to the f29 scm > > - build > > - add it to bodhi and wait for a while > > - possibly push to stable after some time > > > > correct? > Yes, this looks correct.\ > Thanks - Michael > Zbyszek > ___ > 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 > ___ 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
Fedora 29 compose report: 20180903.n.0 changes
OLD: Fedora-29-20180902.n.0 NEW: Fedora-29-20180903.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = ___ 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: Headsup: dbus 1.12.10-1.fc29 is missing systemd dbus.service file, breaking almost everything
Den mån 3 sep. 2018 kl 12:56 skrev Fabio Valentini : > > On Mon, Sep 3, 2018, 09:13 Ron Yorston wrote: >> >> Adam Williamson wrote: >> >On Sun, 2018-09-02 at 08:58 -0700, stan wrote: >> >> On Sun, 2 Sep 2018 09:33:39 +0200 >> >> Andreas Tunek wrote: >> >> >> >> > There is no root acoount on a default F29 installation. Also, you >> >> > can't see the boot menu and I haven't been able to trigger it. >> >> >> >> Whoa! I'm not sure what that buys, but I'll change that as soon as >> >> possible when I install it. That's crazy! Maybe someone wants to >> >> imitate a Mac or something. >> > >> >It's a Change that was properly announced and extensively discussed on >> >this list. >> >> Since some Fedora users may not read this list, I hope that these >> changes will be prominently mentioned in the release documentation. >> >> Preferably for F30 as well as F29 so that users who only update to every >> other release will also receive notification. >> >> Ron > > > Well, one might argue that users who really want to run pre-beta releases of > fedora are also expected to follow the discussions and announcements here. > fedora 29 really isn't ready for end users yet (as witnessed by this thread) > - it's not even in beta after all - so if you don't (or can't) keep up with > the news and development discussions, you really shouldn't be running fedora > 29 yet IMO. > > I know that doesn't help rescue the borked systems, but running alpha-quality > code is bound to lead to problems, and users are expected to be able to deal > with them - otherwise they should stick to stable releases. > > Fabio > The thing is, if people do not test releases they will never be stable. And even if I don't know how to access my F29 installation from a chroot sometimes my testing is valuable to the project. Also, I think that my testing has shown that a lack of root account and boot menu has lead to a much worser user experience in certain cases. /Andreas >> ___ >> 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 > > ___ > 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 ___ 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: Headsup: dbus 1.12.10-1.fc29 is missing systemd dbus.service file, breaking almost everything
Den mån 3 sep. 2018 kl 14:07 skrev Hans de Goede : > > Hi, > > On 02-09-18 09:33, Andreas Tunek wrote: > > Den lör 1 sep. 2018 kl 15:50 skrev stan : > >> > >> On Sat, 1 Sep 2018 13:44:56 +0200 > >> Andreas Tunek wrote: > >> > >>> I can't get a commandline, everything seems stuck in the boot > >>> process Is there anyway to get a commandline and update the system > >>> when it is in this state? > >> > >> You could try getting to single user mode, putting a 1 after the boot > >> line during boot by editing the menu entry before booting. That should > >> put you into the root account, where you can run a dnf update. > >> > > > > There is no root acoount on a default F29 installation. Also, you > > can't see the boot menu and I haven't been able to trigger it. > > The boot menu should show if the previous boot is considered > unsuccessful I guess that you have left the gnome-initial-setup > gnome-shell session sit around for more then 2 minutes and then > the boot is considered successful if you press "ctrl + alt + F4" > and then "ctrl + alt + del" as soon as you get the broken > gnome-initial-setup screen, it should reboot into the menu > (this worked for me when I hit the same issue). > F29 worked before this update so I have already done the gnome initial setup. > If that fails you should be able to get the boot menu by one of: > > a) Keeping shift pressed during boot, note you typically need to > press it a bit after the vendor logo / bios post shows otherwise > it might not register > > b) Pressing Esc during boot (needs to be done at the right time, > so press it repeatedly during boot) > > c) Pressing F8 during boot (needs to be done at the right time, > so press it repeatedly during boot) > Will I be able to log in to the user account? And will I have network access? > Regards, > > Hans > ___ 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: upgrade tinyproxy for f29?
On Mon, Sep 03, 2018 at 06:29:34PM +0200, Michael Adam wrote: > On Mon, Sep 3, 2018 at 5:23 PM, Peter Robinson wrote: > > > On Mon, Sep 3, 2018 at 4:07 PM Michael Adam wrote: > > > > > > Hi all, > > > > > > Tinyproxy just released a new version 1.10 which is has been overdue > > > and containes 2 CVE fixes apart from several enhancements. > > > > > > I created builds for rawhide already. > > > > > > I was wondering if it is still possible to get tinyproxy to this > > important > > > update in f29, since no other packages depend on it, afaict. > > > > > > If so, what do I do? Just update the scm branch and bring it in through > > Bodhi? > > > > Thanks for the swift response! > > (And apologies for any cluelessness about newer aspects of the fedora > process - it's been a while since i did these things, and it worked a little > differently then...) > > > > Sounds like a reasonable course of action. Is it backward compatible > > in terms of any interface people might use? > > > There are a few config file additions. > The location of the binary has changed from /usr/sbin > to /usr/bin . Otherwise no Interfaces i'm aware of. You should create a compat symlink from the old location to the new location, at least in the stable releases, in case somebody calls the binary by path. > > If so once it's baked in > > f29 for a bit, we're in freeze atm any so it won't progress from > > updates-testing -> stable until Beta gets signed off, you might want > > to consider pushing to stable releases too due to CVEs > > > > Ok, so can you or s/o confirm next steps: > > - bring it to the f29 scm > - build > - add it to bodhi and wait for a while > - possibly push to stable after some time > > correct? Yes, this looks correct. Zbyszek ___ 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: upgrade tinyproxy for f29?
On Mon, Sep 3, 2018 at 5:23 PM, Peter Robinson wrote: > On Mon, Sep 3, 2018 at 4:07 PM Michael Adam wrote: > > > > Hi all, > > > > Tinyproxy just released a new version 1.10 which is has been overdue > > and containes 2 CVE fixes apart from several enhancements. > > > > I created builds for rawhide already. > > > > I was wondering if it is still possible to get tinyproxy to this > important > > update in f29, since no other packages depend on it, afaict. > > > > If so, what do I do? Just update the scm branch and bring it in through > Bodhi? > Thanks for the swift response! (And apologies for any cluelessness about newer aspects of the fedora process - it's been a while since i did these things, and it worked a little differently then...) > Sounds like a reasonable course of action. Is it backward compatible > in terms of any interface people might use? There are a few config file additions. The location of the binary has changed from /usr/sbin to /usr/bin . Otherwise no Interfaces i'm aware of. > If so once it's baked in > f29 for a bit, we're in freeze atm any so it won't progress from > updates-testing -> stable until Beta gets signed off, you might want > to consider pushing to stable releases too due to CVEs > Ok, so can you or s/o confirm next steps: - bring it to the f29 scm - build - add it to bodhi and wait for a while - possibly push to stable after some time correct? Thanks - Michael ___ > 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 > ___ 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: upgrade tinyproxy for f29?
On Mon, Sep 3, 2018 at 4:07 PM Michael Adam wrote: > > Hi all, > > Tinyproxy just released a new version 1.10 which is has been overdue > and containes 2 CVE fixes apart from several enhancements. > > I created builds for rawhide already. > > I was wondering if it is still possible to get tinyproxy to this important > update in f29, since no other packages depend on it, afaict. > > If so, what do I do? Just update the scm branch and bring it in through Bodhi? Sounds like a reasonable course of action. Is it backward compatible in terms of any interface people might use? If so once it's baked in f29 for a bit, we're in freeze atm any so it won't progress from updates-testing -> stable until Beta gets signed off, you might want to consider pushing to stable releases too due to CVEs ___ 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
upgrade tinyproxy for f29?
Hi all, Tinyproxy just released a new version 1.10 which is has been overdue and containes 2 CVE fixes apart from several enhancements. I created builds for rawhide already. I was wondering if it is still possible to get tinyproxy to this important update in f29, since no other packages depend on it, afaict. If so, what do I do? Just update the scm branch and bring it in through Bodhi? Thanks - Michael ___ 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
Fedora rawhide compose report: 20180903.n.0 changes
OLD: Fedora-Rawhide-20180902.n.0 NEW: Fedora-Rawhide-20180903.n.0 = SUMMARY = Added images:0 Dropped images: 1 Added packages: 1 Dropped packages:1 Upgraded packages: 64 Downgraded packages: 0 Size of added packages: 956.63 KiB Size of dropped packages:1.65 MiB Size of upgraded packages: 579.98 MiB Size of downgraded packages: 0 B Size change of upgraded packages: -35.17 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: Scientific_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Scientific_KDE-Live-x86_64-Rawhide-20180902.n.0.iso = ADDED PACKAGES = Package: rust-varlink_generator-5.0.0-1.fc30 Summary: Rust code generator for the varlink protocol RPMs:rust-varlink_generator rust-varlink_generator-devel Size:956.63 KiB = DROPPED PACKAGES = Package: matrix-structs-0.1.0-8.20180808git56b5b58.fc29 Summary: De/Serializable types for events, requests/responses and identifiers RPMs:matrix-structs matrix-structs-devel Size:1.65 MiB = UPGRADED PACKAGES = Package: cgnslib-3.3.1-8.fc30 Old package: cgnslib-3.3.1-7.fc30 Summary: Computational Fluid Dynamics General Notation System RPMs: cgnslib cgnslib-devel Size: 4.44 MiB Size change: 5.09 KiB Changelog: * Sun Sep 02 2018 Antonio Trande - 3.3.1-8 - Disable wl,--as-needed on fedora 30+ - Use CMake3 on epel Package: git-fame-1.5.0-1.fc30 Old package: git-fame-1.4.2-4.fc29 Summary: Pretty-print git repository collaborators sorted by contributions RPMs: git-fame Size: 15.69 KiB Size change: 308 B Changelog: * Sun Sep 02 2018 Igor Gnatenko - 1.5.0-1 - Update to 1.5.0 Package: glib-networking-2.58.0-1.fc30 Old package: glib-networking-2.57.90-1.fc29 Summary: Networking support for GLib RPMs: glib-networking glib-networking-tests Size: 1.25 MiB Size change: 21.14 KiB Changelog: * Sun Sep 02 2018 Michael Catanzaro - 2.58.0-1 - Update to 2.58.0 Package: globus-authz-3.16-1.fc30 Old package: globus-authz-3.15-7.fc29 Summary: Globus Toolkit - Globus authz library RPMs: globus-authz globus-authz-devel globus-authz-doc Size: 284.18 KiB Size change: -5.05 KiB Changelog: * Sat Sep 01 2018 Mattias Ellert - 3.16-1 - GT6 update: Use 2048 bit keys to support openssl 1.1.1 Package: globus-ftp-client-8.37-1.fc30 Old package: globus-ftp-client-8.36-5.fc29 Summary: Globus Toolkit - GridFTP Client Library RPMs: globus-ftp-client globus-ftp-client-devel globus-ftp-client-doc Size: 1.01 MiB Size change: -14.21 KiB Changelog: * Sat Sep 01 2018 Mattias Ellert - 8.37-1 - GT6 update: Use 2048 bit keys to support openssl 1.1.1 Package: globus-ftp-control-8.6-1.fc30 Old package: globus-ftp-control-8.5-1.fc29 Summary: Globus Toolkit - GridFTP Control Library RPMs: globus-ftp-control globus-ftp-control-devel globus-ftp-control-doc Size: 773.73 KiB Size change: -8.86 KiB Changelog: * Sat Sep 01 2018 Mattias Ellert - 8.6-1 - GT6 update: Use 2048 bit keys to support openssl 1.1.1 Package: globus-gass-copy-9.29-1.fc30 Old package: globus-gass-copy-9.28-3.fc29 Summary: Globus Toolkit - Globus Gass Copy RPMs: globus-gass-copy globus-gass-copy-devel globus-gass-copy-doc globus-gass-copy-progs Size: 749.89 KiB Size change: -15.13 KiB Changelog: * Sat Sep 01 2018 Mattias Ellert - 9.29-1 - GT6 update: Use 2048 bit keys to support openssl 1.1.1 Package: globus-gram-client-13.20-1.fc30 Old package: globus-gram-client-13.19-4.fc29 Summary: Globus Toolkit - GRAM Client Library RPMs: globus-gram-client globus-gram-client-devel globus-gram-client-doc Size: 370.30 KiB Size change: -5.90 KiB Changelog: * Sat Sep 01 2018 Mattias Ellert - 13.20-1 - GT6 update: Use 2048 bit keys to support openssl 1.1.1 Package: globus-gram-job-manager-14.37-1.fc30 Old package: globus-gram-job-manager-14.36-5.fc29 Summary: Globus Toolkit - GRAM Jobmanager RPMs: globus-gram-job-manager Size: 1.00 MiB Size change: -67.75 KiB Changelog: * Sat Sep 01 2018 Mattias Ellert - 14.37-1 - GT6 update: Use 2048 bit keys to support openssl 1.1.1 Package: globus-gram-protocol-12.16-1.fc30 Old package: globus-gram-protocol-12.15-10.fc29 Summary: Globus Toolkit - GRAM Protocol Library RPMs: globus-gram-protocol globus-gram-protocol-devel globus-gram-protocol-doc Size: 519.10 KiB Size change: -7.11 KiB Changelog: * Sat Sep 01 2018 Mattias Ellert - 12.16-1 - GT6 update: Use 2048 bit keys to support openssl 1.1.1 Package: globus-gridftp-server-12.12-1.fc30 Old package: globus-gridftp-server-12.9-1.fc30 Summary: Globus Toolkit - Globus GridFTP Server RPMs: globus-gridftp-server globus-gridftp-server-devel globus-gridftp-server-progs Size
Re: Building multiple version of a package from same dist-git repo
Neal Gompa píše v Po 03. 09. 2018 v 09:01 -0400: > On Mon, Sep 3, 2018 at 8:02 AM Adam Samalik > wrote: > > > > > > > > On Mon, Sep 3, 2018 at 1:57 PM Richard Shaw > > wrote: > > > > > > On Mon, Sep 3, 2018 at 1:32 AM Adam Samalik > > > wrote: > > > > > > > > > > > > I thought that Arbitrary Branching (now referred to as Stream > > > > Branching) was initially developed for Modularity only. > > > > > > > > Were there any plans to use it for standalone packages as well? > > > > > > > > > Thank you for bringing this up... I re-read the Wiki including > > > the Factory2 link and I'm still confused. I like the idea at a > > > high level but I still don't understand how to use it. > > > > > > One example is that I maintain the package OpenImageIO which has > > > a very disciplined upstream that's careful about not making > > > API/ABI breaking changes within a minor release. I would like to > > > get branches for each minor release that's currently supported, > > > 1.8 for rawhide through F28, 1.8 for F27 and 1.5 for EPEL. > > > > > > Like I said, at a high level it makes since, but I still don't > > > understand exactly how to do it or if the process/tools are > > > mature enough to actually use yet. > > > > > > The original idea was to use it for modules [1]. You would > > reference the branches in your module definition [2]. > > > > There's no particular reason it couldn't be used for regular > packages. The only reason it's not done is because of convention. > It's certainly workable, but as fedpkg doesn't yet support that > workflow, it's a bit more manual. Well, this should be fedpkg 1.35 (in updates-testing now): https://pagure.io/fedpkg/c/bcbb337e5076f8edad332067a64b7d4e6da279b6?branch=master Basically: create a config file in the repo and then fedpkg build should be able to submit builds for multiple versions of Fedora. https://docs.pagure.org/fedpkg/releases/1.35.html#submit-builds-from-stream-branch > > > -- > 真実はいつも一つ！/ 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 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 ___ 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: Building multiple version of a package from same dist-git repo
On 09/02/2018 05:51 PM, Igor Gnatenko wrote:
> Hello,
>
> is it possible to build packages like foo0.6 from dist-git repo with name
> foo and not foo0.6?
>
> Since in Rust ecosystem from time to time we need to build multiple
> versions of a same package, it is much easier if it would be one repo with
> branches 0.6, 0.7 instead of multiple separate git repos.
>
> If not, what are the limitations?
There are no technical limitations for building packages like that in
Koji, but you won't be able to tag them unless %{name} is added to
appropriate tag.
--
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
___
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: Building multiple version of a package from same dist-git repo
On Mon, Sep 3, 2018 at 3:02 PM Neal Gompa wrote: > On Mon, Sep 3, 2018 at 8:02 AM Adam Samalik wrote: > > > > > > > > On Mon, Sep 3, 2018 at 1:57 PM Richard Shaw > wrote: > >> > >> On Mon, Sep 3, 2018 at 1:32 AM Adam Samalik > wrote: > >>> > >>> > >>> I thought that Arbitrary Branching (now referred to as Stream > Branching) was initially developed for Modularity only. > >>> > >>> Were there any plans to use it for standalone packages as well? > >> > >> > >> Thank you for bringing this up... I re-read the Wiki including the > Factory2 link and I'm still confused. I like the idea at a high level but I > still don't understand how to use it. > >> > >> One example is that I maintain the package OpenImageIO which has a very > disciplined upstream that's careful about not making API/ABI breaking > changes within a minor release. I would like to get branches for each minor > release that's currently supported, 1.8 for rawhide through F28, 1.8 for > F27 and 1.5 for EPEL. > >> > >> Like I said, at a high level it makes since, but I still don't > understand exactly how to do it or if the process/tools are mature enough > to actually use yet. > > > > > > The original idea was to use it for modules [1]. You would reference the > branches in your module definition [2]. > > > > There's no particular reason it couldn't be used for regular packages. > The only reason it's not done is because of convention. It's certainly > workable, but as fedpkg doesn't yet support that workflow, it's a bit > more manual. > Ah, please don't take me wrong, I'm not opposing that. Just hinting why the wiki page might look confusing. I think I saw a way to submit a traditional RPM build from a different branch by specifying the target manually. > > > -- > 真実はいつも一つ！/ 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 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 > -- Adam Šamalík --- Software Engineer Red Hat ___ 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
Managing stream (arbitrary) branch and module lifecycles
This is a summary of a recent thread [1]. Traditional branches (such as "f29") have their EOL (end of life) encoded in the name. But what about stream branches [2] (such as "2.4" or "latest")? Stream branches of RPM packages would always have an EOL associated with them. The format would be on of the following: a) A date — mostly tied to an upstream version and its EOL. b) A specific Fedora release — for release-specific packages. c) Forever — rolling forward with upstream, latest development versions, etc. Module streams would inherit their EOL from the packages they include — the earliest EOL would win. This could be optionally overridden on the module stream level by specifying one of the following: a) A date. b) A specific Fedora release. There would be a policy that a module can reach its EOL in the middle of a Fedora release to prevent madness. We need a way to specify the EOL value and to manage it over time, because it might change. For RPM stream branches, there is currently a way to specify an EOL value when requesting the branch [3] — the actual format might change based on this discussion. However, I'm not aware of a way to change the value if necessary nor a process associated with that. Also, there is currently no way to specify an EOL for modules. After we figure this out, we also need to make sure the build system takes that into account (some recent progress [4]) and that the client tooling (mostly DNF) presents that to the user. So... any comments to the concept? Any ideas about workflows or processes of managing the EOL values? [1] Previous thread: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/K4FUOQHQSRAAI3PUUGXAC6CXEN27Y2JH/ [2] Now "stream branches", formerly "arbitrary branches": https://fedoraproject.org/wiki/Changes/ArbitraryBranching [3] Requesting a stream branch + specifying its EOL: https://docs.fedoraproject.org/en-US/modularity/making-modules/adding-new-modules/#_repositories_and_stream_branches_existing_packages [4] https://pagure.io/modularity/issue/102 -- Adam Šamalík --- Software Engineer Red Hat ___ 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
New policy for orphaning/retiring packages with open security bugs
FESCo accepted [1] a new policy to handle packages with long-standing known security bugs in a way similar to FTBFS bugs: AGREED: If a CRITICAL or IMPORTANT security issue is currently open against a package, or a security issue of lower severity has been open for at least 6 months, four weeks before the branch point a procedure similar to long-standing FTBFS will be triggered immediately, with 8 weeks of weekly notifications to maintainers and subsequent orphaning and then subsequent removal from distribution. This applies to all packages, not just leaf. This policy will apply to F30 and later. The branch point is on 2019/02/19, so somewhere around January 22 the procedure should start with notifications being sent out. Maintainers are of course encouraged to fix any security issues immediately. See [2] for a list of currently open security bugs. [1] https://pagure.io/fesco/issue/1935#comment-528180 [2] https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Fedora&keywords=SecurityTracking%2C%20&keywords_type=allwords&list_id=9337195&order=changeddate%2Cpriority%2Cbug_id&product=Fedora&query_format=advanced Zbyszek, on behalf of FESCo ___ 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: Intent to retire or orphan keybinder - python2 version
The rpath/libtool issue is fixed https://bodhi.fedoraproject.org/updates/FEDORA-2018-4ddd5fcd1f ___ 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: Building multiple version of a package from same dist-git repo
On Mon, Sep 3, 2018 at 8:02 AM Adam Samalik wrote: > > > > On Mon, Sep 3, 2018 at 1:57 PM Richard Shaw wrote: >> >> On Mon, Sep 3, 2018 at 1:32 AM Adam Samalik wrote: >>> >>> >>> I thought that Arbitrary Branching (now referred to as Stream Branching) >>> was initially developed for Modularity only. >>> >>> Were there any plans to use it for standalone packages as well? >> >> >> Thank you for bringing this up... I re-read the Wiki including the Factory2 >> link and I'm still confused. I like the idea at a high level but I still >> don't understand how to use it. >> >> One example is that I maintain the package OpenImageIO which has a very >> disciplined upstream that's careful about not making API/ABI breaking >> changes within a minor release. I would like to get branches for each minor >> release that's currently supported, 1.8 for rawhide through F28, 1.8 for F27 >> and 1.5 for EPEL. >> >> Like I said, at a high level it makes since, but I still don't understand >> exactly how to do it or if the process/tools are mature enough to actually >> use yet. > > > The original idea was to use it for modules [1]. You would reference the > branches in your module definition [2]. > There's no particular reason it couldn't be used for regular packages. The only reason it's not done is because of convention. It's certainly workable, but as fedpkg doesn't yet support that workflow, it's a bit more manual. -- 真実はいつも一つ！/ 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 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
libevent License tags corrected
Hi, I reviewed the licensing of libevent and found the License tags to be incorrect. The License tag of libevent was changed from "BSD" to "BSD and ISC". The License tag of libevent-doc was changed from "BSD" to "BSD and MIT". Best regards Ondřej Lysoněk ___ 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: Headsup: dbus 1.12.10-1.fc29 is missing systemd dbus.service file, breaking almost everything
Hi, On 02-09-18 09:33, Andreas Tunek wrote: Den lör 1 sep. 2018 kl 15:50 skrev stan : On Sat, 1 Sep 2018 13:44:56 +0200 Andreas Tunek wrote: I can't get a commandline, everything seems stuck in the boot process Is there anyway to get a commandline and update the system when it is in this state? You could try getting to single user mode, putting a 1 after the boot line during boot by editing the menu entry before booting. That should put you into the root account, where you can run a dnf update. There is no root acoount on a default F29 installation. Also, you can't see the boot menu and I haven't been able to trigger it. The boot menu should show if the previous boot is considered unsuccessful I guess that you have left the gnome-initial-setup gnome-shell session sit around for more then 2 minutes and then the boot is considered successful if you press "ctrl + alt + F4" and then "ctrl + alt + del" as soon as you get the broken gnome-initial-setup screen, it should reboot into the menu (this worked for me when I hit the same issue). If that fails you should be able to get the boot menu by one of: a) Keeping shift pressed during boot, note you typically need to press it a bit after the vendor logo / bios post shows otherwise it might not register b) Pressing Esc during boot (needs to be done at the right time, so press it repeatedly during boot) c) Pressing F8 during boot (needs to be done at the right time, so press it repeatedly during boot) Regards, Hans ___ 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: Building multiple version of a package from same dist-git repo
On Mon, Sep 3, 2018 at 1:57 PM Richard Shaw wrote: > On Mon, Sep 3, 2018 at 1:32 AM Adam Samalik wrote: > >> >> I thought that Arbitrary Branching (now referred to as Stream Branching) >> was initially developed for Modularity only. >> >> Were there any plans to use it for standalone packages as well? >> > > Thank you for bringing this up... I re-read the Wiki including the > Factory2 link and I'm still confused. I like the idea at a high level but I > still don't understand how to use it. > > One example is that I maintain the package OpenImageIO which has a very > disciplined upstream that's careful about not making API/ABI breaking > changes within a minor release. I would like to get branches for each minor > release that's currently supported, 1.8 for rawhide through F28, 1.8 for > F27 and 1.5 for EPEL. > > Like I said, at a high level it makes since, but I still don't understand > exactly how to do it or if the process/tools are mature enough to actually > use yet. > The original idea was to use it for modules [1]. You would reference the branches in your module definition [2]. [1] https://docs.fedoraproject.org/en-US/modularity/making-modules/adding-new-modules/ [2] https://docs.fedoraproject.org/en-US/modularity/making-modules/defining-modules/ > Thanks, > Richard > ___ > 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 > -- Adam Šamalík --- Software Engineer Red Hat ___ 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: Building multiple version of a package from same dist-git repo
On Mon, Sep 3, 2018 at 6:56 AM Richard Shaw wrote: > One example is that I maintain the package OpenImageIO which has a very > disciplined upstream that's careful about not making API/ABI breaking > changes within a minor release. I would like to get branches for each minor > release that's currently supported, 1.8 for rawhide through F28, 1.8 for > F27 and 1.5 for EPEL. > That was supposed to be 1.7 for F27... Need more coffee. ___ 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: Building multiple version of a package from same dist-git repo
On Mon, Sep 3, 2018 at 1:32 AM Adam Samalik wrote: > > I thought that Arbitrary Branching (now referred to as Stream Branching) > was initially developed for Modularity only. > > Were there any plans to use it for standalone packages as well? > Thank you for bringing this up... I re-read the Wiki including the Factory2 link and I'm still confused. I like the idea at a high level but I still don't understand how to use it. One example is that I maintain the package OpenImageIO which has a very disciplined upstream that's careful about not making API/ABI breaking changes within a minor release. I would like to get branches for each minor release that's currently supported, 1.8 for rawhide through F28, 1.8 for F27 and 1.5 for EPEL. Like I said, at a high level it makes since, but I still don't understand exactly how to do it or if the process/tools are mature enough to actually use yet. Thanks, Richard ___ 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: Headsup: dbus 1.12.10-1.fc29 is missing systemd dbus.service file, breaking almost everything
On Mon, Sep 3, 2018, 09:13 Ron Yorston wrote: > Adam Williamson wrote: > >On Sun, 2018-09-02 at 08:58 -0700, stan wrote: > >> On Sun, 2 Sep 2018 09:33:39 +0200 > >> Andreas Tunek wrote: > >> > >> > There is no root acoount on a default F29 installation. Also, you > >> > can't see the boot menu and I haven't been able to trigger it. > >> > >> Whoa! I'm not sure what that buys, but I'll change that as soon as > >> possible when I install it. That's crazy! Maybe someone wants to > >> imitate a Mac or something. > > > >It's a Change that was properly announced and extensively discussed on > >this list. > > Since some Fedora users may not read this list, I hope that these > changes will be prominently mentioned in the release documentation. > > Preferably for F30 as well as F29 so that users who only update to every > other release will also receive notification. > > Ron > Well, one might argue that users who really want to run pre-beta releases of fedora are also expected to follow the discussions and announcements here. fedora 29 really isn't ready for end users yet (as witnessed by this thread) - it's not even in beta after all - so if you don't (or can't) keep up with the news and development discussions, you really shouldn't be running fedora 29 yet IMO. I know that doesn't help rescue the borked systems, but running alpha-quality code is bound to lead to problems, and users are expected to be able to deal with them - otherwise they should stick to stable releases. Fabio ___ > 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 > ___ 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: Headsup: dbus 1.12.10-1.fc29 is missing systemd dbus.service file, breaking almost everything
Adam Williamson wrote: >On Sun, 2018-09-02 at 08:58 -0700, stan wrote: >> On Sun, 2 Sep 2018 09:33:39 +0200 >> Andreas Tunek wrote: >> >> > There is no root acoount on a default F29 installation. Also, you >> > can't see the boot menu and I haven't been able to trigger it. >> >> Whoa! I'm not sure what that buys, but I'll change that as soon as >> possible when I install it. That's crazy! Maybe someone wants to >> imitate a Mac or something. > >It's a Change that was properly announced and extensively discussed on >this list. Since some Fedora users may not read this list, I hope that these changes will be prominently mentioned in the release documentation. Preferably for F30 as well as F29 so that users who only update to every other release will also receive notification. Ron ___ 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
Self introduction: Alain Vigne
Hi everyone, I am Alain, a French EE engineer using Fedora 28 and EDA open source tools, for a long time now. I am part of the pcb-rnd developer upstream http://repo.hu/projects/pcb-rnd/ and was able to produce a .spec file + SRPM rpm file + COPR successful builds: https://copr.fedorainfracloud.org/coprs/avigne/pcb-rnd/ Now, I am looking for a sponsor to officially get this package into Fedora. I filled this BZ bug: https://bugzilla.redhat.com/show_bug.cgi?id=1581240 I volunteer to be the package maintainer, I have read the guidelines and acknowledge responsibilities requested for such a task. My FAS username is: avigne This package could also be part of FEL (Fedora Electronic Lab) spin, to be revived ? I am open to discussions about packaging latest versions of EE/CAD open source tools. Hoping for some positive feed-back... Best regards -- Alain V. ___ 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
