tunnelvision attack

[Neal Becker]

I'm assuming Fedora systems are vulnerable:

https://arstechnica.com/security/2024/05/novel-attack-against-virtually-all-vpn-apps-neuters-their-entire-purpose/

I hope we can find a fix soon!
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)

[Neal Becker]

On Fri, Dec 29, 2023 at 6:43 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Thu, Dec 28, 2023 at 05:07:09PM +, Barry Scott wrote:
> >
> >
> > > On 28 Dec 2023, at 16:58, Chris Adams  wrote:
> > >
> > > Anything that depends on PATH entries is IMHO doomed to failure.
> > > There are way too many things that explicitly set PATH to "known"
> > > values (for good and bad reasons) to be able to depend on
> > > extending it. Heck, it took a long time to get sudo just to
> > > include /usr/local/{bin,sbin}.
>
> Things that reset $PATH to "known" values are usually breaking things
> and doing unnecessary work. It is OK to extend the $PATH by inserting
> something (usually at the front), but systemd sets it to something
> appropriate on a given system for _everything_ that is started, so
> resetting it is not useful.
>
> It was very common to set the $PATH via .bash_profile or other
> shell-specific mechanisms. This is flexible and convenient, but the
> problem with that approach is that it happens too late: since now the
> system may get all the way the graphical interface without going
> through a shell, if we want $PATH to be set properly for the whole
> environment including service binaries started directly by systemd,
> this needs to be done by systemd itself. And once it has done that,
> it's not helpful if the shell also plays with $PATH, affecting some
> processes but not others.
>
> But yeah, it's possible that sometimes we'll and up with an environment
> with $PATH without the additional directories. That's OK: it will
> gracefully fall back to the generic versions. Hopefully, people
> will fix those environments over time.
>
> (Sudo is a special case: it needs to reset the path to avoid being
> influenced by the calling environment. But things started through sudo
> are generally not CPU-intenstive, so using the generic versions should
> be OK.)
>
> > Indeed, how would my shell get the right micro architecture into its
> PATH?
> > Would konsole on plasma desktop picking up PATH from systemd?
>
> Yes. If should already be doing that.
>
> > The alternative would be to symlink the "right" version of a
> program/library from
> > the micro architecture dir into /usr/bin and /usr/lib maybe?
>
> The approaches with glibc-hwcaps and the proposed path-based thing for
> binaries
> have the advantage that they are dynamic. The same image can be used on
> different
> machines. It may even be read-only. In particular, in case of VMs, if we
> stop
> the VM, move it to a different host or change it's CPU settings, and
> restart it,
> it'll gracefully DTRT. It also important that the system remains functional
> even if a CPU downgrade happens for any reason.
>
> We _could_ take the approach with symlinks. Most likely, this would be
> handled
> via alternatives, i.e. the symlinks would go through /etc, i.e.
> /usr/bin/foo
> → /etc/alternatives/foo → /usr/lib-something/bin/foo. This is doable, but I
> like the dynamic approach much more.
>
> Also, glibc-hwcaps are implemented and available since glibc 2.33.
> Combining a static symlink-based system for binaries with a dynamic
> path-based system for libraries would be very strange.
>
> On a philosophical note, I once worked on Apollo workstations.  These
could switch behavior between sysv and bsd unix.  To do this, the kernel
would interpret e.g. /usr/bin/$arch, substituting the env variable arch.
At least that is my recollection of how this worked.  Elegant I think, but
some might see this as a security problem.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change Proposal: KDE Plasma 6 (System Wide)

[Neal Becker]

On Tue, Sep 19, 2023 at 10:12 AM Neal Gompa  wrote:

> On Tue, Sep 19, 2023 at 9:57 AM Neal Becker  wrote:
> >
> > Some apps that are not open source and we are required to use don't
> cooperate:  see attached
> >
>
> According to this VMware forum post, the warning is annoying, but
> harmless?
> https://communities.vmware.com/t5/Horizon-for-Linux/Anyone-know-if-they-re-working-on-Wayland-support-for-the/td-p/2953800
>
> Thanks!  That does work.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change Proposal: KDE Plasma 6 (System Wide)

[Neal Becker]

Some apps that are not open source and we are required to use don't
cooperate:  see attached

On Mon, Sep 18, 2023 at 11:58 AM Steven A. Falco 
wrote:

> On 9/18/23 11:33 AM, Neal Gompa wrote:
> > On Mon, Sep 18, 2023 at 11:12 AM Steven A. Falco 
> wrote:
> >>
> >> On 9/17/23 05:48 PM, Kevin Kofler via devel wrote:
> >>> Ian Laurie wrote:
>  I didn't think the greeter used Wayland?  So there may be something
> else
>  going on.  I cannot swear to it, but I don't think I've noticed
> problems
>  in the greeter before.
> 
>  As Adam posted, the offset problem already has a bug for it.  Wayland
> is
>  certainly unusable in VirtualBox, but now even the greeter has issues,
>  and I think that's newish.
> >>>
> >>> SDDM was switched to Wayland for F38 and newer. If you want it to use
> X11,
> >>> you have to edit /etc/sddm.conf and set:
> >>>
> >>> [General]
> >>> DisplayServer=x11
> >>>
> >>> there.
> >>>
> >>>   Kevin Kofler
> >>
> >> Yes - I had to do that because the Wayland version of the SDDM greeter
> apparently doesn't honor xrandr.
> >>
> >> I have the following in my /etc/sddm/Xsetup file:
> >>
> >>  #!/usr/bin/sh
> >>  # Xsetup - run as root before the login dialog appears
> >>  xrandr --output DisplayPort-0 --right-of DisplayPort-1
> >>
> >> If I have the greeter set to x11 that works perfectly, but if I have
> the greeter set to wayland it is ignored.
> >>
> >> I don't know if there is a way to tell wayland the desired screen
> arrangement.  If there is a way I'd like to hear about it.  If there isn't
> a way, then I guess that should be another bug.
> >>
> >
> > kwin can be configured using kscreen-doctor, as long as the kwin
> > wayland socket is up.
>
> Thanks, Neal.  I'll give that a try at some point.
>
> Steve
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
*Those who don't understand recursion are doomed to repeat it*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Test upgrades from F37 to F38 - it will take you just a minute

[Neal Becker]

If I add --allowerasing, some packages will be removed:
Removing dependent packages:
 ffmpeg-free   x86_64 5.1.3-1.fc37
@updates   2.2 M
 libavcodec-free   x86_64 5.1.3-1.fc37
@updates   9.6 M
 libavdevice-free  x86_64 5.1.3-1.fc37
@updates   228 k
 libavfilter-free  x86_64 5.1.3-1.fc37
@updates   4.4 M
 libavformat-free  x86_64 5.1.3-1.fc37
@updates   2.6 M
 libavutil-freex86_64 5.1.3-1.fc37
@updates   836 k
 libpostproc-free  x86_64 5.1.3-1.fc37
@updates   127 k
 libswresample-freex86_64 5.1.3-1.fc37
@updates   152 k
 libswscale-free   x86_64 5.1.3-1.fc37
@updates   632 k

On Tue, Apr 18, 2023 at 7:40 PM Neal Becker  wrote:

> Error:
>  Problem 1: problem with installed package ffmpeg-free-5.1.3-1.fc37.x86_64
>   - package ffmpeg-6.0-6.fc38.x86_64 conflicts with ffmpeg-free provided
> by ffmpeg-free-6.0-2.fc38.x86_64
>   - ffmpeg-free-5.1.3-1.fc37.x86_64 does not belong to a distupgrade
> repository
>   - conflicting requests
>  Problem 2: problem with installed package firefox-112.0-3.fc37.x86_64
>   - conflicting requests
>   - package ffmpeg-libs-6.0-6.fc38.i686 conflicts with libavcodec-free
> provided by libavcodec-free-6.0-2.fc38.x86_64
>   - package ffmpeg-libs-6.0-6.fc38.x86_64 conflicts with libavcodec-free
> provided by libavcodec-free-6.0-2.fc38.x86_64
>   - problem with installed package libavcodec-free-5.1.3-1.fc37.x86_64
>   - libavcodec-free-5.1.3-1.fc37.x86_64 does not belong to a distupgrade
> repository
>   - firefox-112.0-3.fc37.x86_64 does not belong to a distupgrade repository
> (try to add '--allowerasing' to command line to replace conflicting
> packages or '--skip-broken' to skip uninstallable packages)
>
> On Sun, Apr 16, 2023 at 5:49 AM Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl> wrote:
>
>> On Sat, Apr 15, 2023 at 06:30:36PM -0400, Elliott Sales de Andrade wrote:
>> > > >   - problem with installed package
>> msv-xsdlib-1:2013.6.1-19.fc33.noarch
>> > > > (try to add '--skip-broken' to skip uninstallable packages)
>> > >
>> > > I'll add this one to fedora-obsolete-packages.
>> > >
>> > >
>> > It looks like you've only added the main package msv [0]. However, that
>> > package doesn't exist as a binary rpm, the srpm only produces msv-*
>> > subpackages [1]. And obsoleting the main package won't obsolete the
>> > subpackages, so this conflict is not fixed yet. I'm not sure if any of
>> the
>> > other msv-* subpackages should also be obsoleted or just msv-xsdlib.
>>
>> I adjusted f-o-p to just list them all. I don't think we want to keep some
>> subset of the subpackages.
>>
>> Zbyszek
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
>>
>
>
> --
> *Those who don't understand recursion are doomed to repeat it*
>


-- 
*Those who don't understand recursion are doomed to repeat it*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Test upgrades from F37 to F38 - it will take you just a minute

[Neal Becker]

Error:
 Problem 1: problem with installed package ffmpeg-free-5.1.3-1.fc37.x86_64
  - package ffmpeg-6.0-6.fc38.x86_64 conflicts with ffmpeg-free provided by
ffmpeg-free-6.0-2.fc38.x86_64
  - ffmpeg-free-5.1.3-1.fc37.x86_64 does not belong to a distupgrade
repository
  - conflicting requests
 Problem 2: problem with installed package firefox-112.0-3.fc37.x86_64
  - conflicting requests
  - package ffmpeg-libs-6.0-6.fc38.i686 conflicts with libavcodec-free
provided by libavcodec-free-6.0-2.fc38.x86_64
  - package ffmpeg-libs-6.0-6.fc38.x86_64 conflicts with libavcodec-free
provided by libavcodec-free-6.0-2.fc38.x86_64
  - problem with installed package libavcodec-free-5.1.3-1.fc37.x86_64
  - libavcodec-free-5.1.3-1.fc37.x86_64 does not belong to a distupgrade
repository
  - firefox-112.0-3.fc37.x86_64 does not belong to a distupgrade repository
(try to add '--allowerasing' to command line to replace conflicting
packages or '--skip-broken' to skip uninstallable packages)

On Sun, Apr 16, 2023 at 5:49 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Sat, Apr 15, 2023 at 06:30:36PM -0400, Elliott Sales de Andrade wrote:
> > > >   - problem with installed package
> msv-xsdlib-1:2013.6.1-19.fc33.noarch
> > > > (try to add '--skip-broken' to skip uninstallable packages)
> > >
> > > I'll add this one to fedora-obsolete-packages.
> > >
> > >
> > It looks like you've only added the main package msv [0]. However, that
> > package doesn't exist as a binary rpm, the srpm only produces msv-*
> > subpackages [1]. And obsoleting the main package won't obsolete the
> > subpackages, so this conflict is not fixed yet. I'm not sure if any of
> the
> > other msv-* subpackages should also be obsoleted or just msv-xsdlib.
>
> I adjusted f-o-p to just list them all. I don't think we want to keep some
> subset of the subpackages.
>
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
*Those who don't understand recursion are doomed to repeat it*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unfiltered Flathub (System-Wide Change proposal)

[Neal Becker]

The one concern I have with this proposal is it says that flatpak version
would only be offered if it didn't duplicate a package in fedora.  The
potential problem I see is this depends on Fedora and Flathub being totally
consistent in their naming.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFI/RFC: Fedora Linux graphical recovery environment

[Neal Becker]

There are several recovery disks available that could serve as examples.
https://www.system-rescue.org/

On Mon, Apr 4, 2022 at 7:12 AM Fabio Valentini  wrote:

> On Thu, Mar 31, 2022 at 11:39 PM Neal Gompa  wrote:
> >
> > Hey all,
> >
> > Earlier this week, the Fedora Workstation WG discussed a ticket
> > brought to us asking for a GUI-based rescue/recovery environment[1].
> > While we all agreed in principle that such a thing would be a very
> > good thing to have, we don't really know how to achieve such a thing.
> > Additionally, we're not really sure what the scope of things should be
> > provided in said recovery environment and what kind of things people
> > would expect to be able to fix in there.
> >
> > So I come to y'all to ask about this and give us some feedback on the
> > idea, how to do it, and what kinds of things you expect people to need
> > a recovery environment for.
>
> This sounds interesting.
>
> The only situation in which I would really have needed a "recovery
> environment" was when after upgrading my old Fedora installs to Fedora
> 33 or something (whenever we switched GRUB to use BLS snippets, I
> think) some required GRUB modules that were split off into subpackages
> didn't get pulled in (I think it was grub2-efi-x64 ?), leaving the
> system in an unbootable state, which I was only able to fix by booting
> from a Live USB and installing the missing GRUB modules.
>
> If I didn't know what to do (or wouldn't have had a Live USB at hand),
> that would have basically bricked my system (or locked me into booting
> Windows with its own bootloader). Not sure if it would be possible
> with the "recovery environment" you would have in mind, but a basic
> "are all the components that are required to boot there" check, with
> suggestions how to fix them if they're missing, would have saved me
> tons of time recovering from the borked grub install.
>
> Fabio
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


-- 
*Those who don't understand recursion are doomed to repeat it*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Can't fedpkg new-sources (403)

[Neal Becker]

On Wed, Mar 16, 2022 at 2:40 PM Kevin Fenzi  wrote:

> On Wed, Mar 16, 2022 at 01:55:03PM -0400, Neal Becker wrote:
> > On Wed, Mar 16, 2022 at 1:45 PM Neal Becker  wrote:
> >
> > >
> > >
> > > On Wed, Mar 16, 2022 at 1:38 PM Neal Becker 
> wrote:
> > >
> > >> I believe it is failing on the line:
> > >>   File "/usr/lib/python3.10/site-packages/pyrpkg/lookaside.py", line
> 298,
> > >> in upload
> > >> if self.remote_file_exists(name, filename, hash):
> > >>   File "/usr/lib/python3.10/site-packages/pyrpkg/lookaside.py", line
> 259,
> > >> in remote_file_exists
> > >> self.raise_upload_error(status)
> > >>
> > >> So maybe the file already exists in the cache?  But then, sources has
> not
> > >> been updated, and if I try
> > >> fedpkg local it will attempt to build the old version 1.8.1, not the
> new
> > >> 1.9.0.
> > >>
> > >>
> > >>>>
> > > OK, so unuran-1.9.0.tar.gz already exists in the cache.  So I had to
> > > manually update sources by running
> > > md5sum unuran-1.9.0.tar.gz, which luckily I just guessed.  Now
> everything
> > > seems to be working fine.
> > >
> >
> > Ooops, spoke too soon.
> > fedpkg local
> > Downloading unuran-1.9.0.tar.gz
> > 
> > 100.0%
> > Remove downloaded invalid file
> > /home/nbecker/fedora.git/unuran/unuran-1.9.0.tar.gz
> > Could not execute local: Server returned status code 404
> >
> > No idea what's going on here.
>
> You seem to have gotten a kerberos ticket for:
>
> nbec...@fedoraproject.org
>
> which I guess ipa is fine with giving you.
> However, our upload script checking your username sees "NBECKER" and not
> 'nbecker' and denys you.
>
> Can you do:
>
> kdestroy -A
>
> then
>
> kinit nbec...@fedoraproject.org
>
> and see if it works?
>
> kevin
>

Yes, that was the problem and the solution.  The error messages I saw were
not very helpful.  Thanks!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Can't fedpkg new-sources (403)

[Neal Becker]

On Wed, Mar 16, 2022 at 1:45 PM Neal Becker  wrote:

>
>
> On Wed, Mar 16, 2022 at 1:38 PM Neal Becker  wrote:
>
>> I believe it is failing on the line:
>>   File "/usr/lib/python3.10/site-packages/pyrpkg/lookaside.py", line 298,
>> in upload
>> if self.remote_file_exists(name, filename, hash):
>>   File "/usr/lib/python3.10/site-packages/pyrpkg/lookaside.py", line 259,
>> in remote_file_exists
>> self.raise_upload_error(status)
>>
>> So maybe the file already exists in the cache?  But then, sources has not
>> been updated, and if I try
>> fedpkg local it will attempt to build the old version 1.8.1, not the new
>> 1.9.0.
>>
>>
>>>>
> OK, so unuran-1.9.0.tar.gz already exists in the cache.  So I had to
> manually update sources by running
> md5sum unuran-1.9.0.tar.gz, which luckily I just guessed.  Now everything
> seems to be working fine.
>

Ooops, spoke too soon.
fedpkg local
Downloading unuran-1.9.0.tar.gz

100.0%
Remove downloaded invalid file
/home/nbecker/fedora.git/unuran/unuran-1.9.0.tar.gz
Could not execute local: Server returned status code 404

No idea what's going on here.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Can't fedpkg new-sources (403)

[Neal Becker]

On Wed, Mar 16, 2022 at 1:38 PM Neal Becker  wrote:

> I believe it is failing on the line:
>   File "/usr/lib/python3.10/site-packages/pyrpkg/lookaside.py", line 298,
> in upload
> if self.remote_file_exists(name, filename, hash):
>   File "/usr/lib/python3.10/site-packages/pyrpkg/lookaside.py", line 259,
> in remote_file_exists
> self.raise_upload_error(status)
>
> So maybe the file already exists in the cache?  But then, sources has not
> been updated, and if I try
> fedpkg local it will attempt to build the old version 1.8.1, not the new
> 1.9.0.
>
>
>>>
OK, so unuran-1.9.0.tar.gz already exists in the cache.  So I had to
manually update sources by running
md5sum unuran-1.9.0.tar.gz, which luckily I just guessed.  Now everything
seems to be working fine.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Can't fedpkg new-sources (403)

[Neal Becker]

I believe it is failing on the line:
  File "/usr/lib/python3.10/site-packages/pyrpkg/lookaside.py", line 298,
in upload
if self.remote_file_exists(name, filename, hash):
  File "/usr/lib/python3.10/site-packages/pyrpkg/lookaside.py", line 259,
in remote_file_exists
self.raise_upload_error(status)

So maybe the file already exists in the cache?  But then, sources has not
been updated, and if I try
fedpkg local it will attempt to build the old version 1.8.1, not the new
1.9.0.

On Wed, Mar 16, 2022 at 11:44 AM Neal Becker  wrote:

>
>
> On Wed, Mar 16, 2022 at 11:28 AM Ankur Sinha 
> wrote:
>
>> On Wed, Mar 16, 2022 10:46:43 -0400, Neal Becker wrote:
>> > Sorry if this is a duplicate message, previous one was held for
>> moderation.
>> >
>> > $ fedpkg new-sources ~/Downloads/unuran-1.9.0.tar.gz
>> > Could not execute new_sources: Fail to upload files. Server returns
>> status 403
>> >
>> > I haven't been active in packaging for some time, did I miss something?
>>
>> Another thing to check: did you run the kinit bit before trying the
>> `new-sources`?
>>
>> ```
>> kinit @FEDORAPROJECT.ORG
>> ```
>>
>
> Yes, without running kinit I got "not authorized"
>


-- 
*Those who don't understand recursion are doomed to repeat it*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Can't fedpkg new-sources (403)

[Neal Becker]

On Wed, Mar 16, 2022 at 11:28 AM Ankur Sinha  wrote:

> On Wed, Mar 16, 2022 10:46:43 -0400, Neal Becker wrote:
> > Sorry if this is a duplicate message, previous one was held for
> moderation.
> >
> > $ fedpkg new-sources ~/Downloads/unuran-1.9.0.tar.gz
> > Could not execute new_sources: Fail to upload files. Server returns
> status 403
> >
> > I haven't been active in packaging for some time, did I miss something?
>
> Another thing to check: did you run the kinit bit before trying the
> `new-sources`?
>
> ```
> kinit @FEDORAPROJECT.ORG
> ```
>

Yes, without running kinit I got "not authorized"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Can't fedpkg new-sources (403)

[Neal Becker]

 On Wed, Mar 16, 2022 at 10:57 AM Alexander Sosedkin 
wrote:

> On Wed, Mar 16, 2022 at 3:47 PM Neal Becker  wrote:
> >
> > Sorry if this is a duplicate message, previous one was held for
> moderation.
> >
> > $ fedpkg new-sources ~/Downloads/unuran-1.9.0.tar.gz
> > Could not execute new_sources: Fail to upload files. Server returns
> status 403
> >
> > I haven't been active in packaging for some time, did I miss something?
>
> Just a guess, but given how new-sources also updates at least .gitignore,
> I think it expects maintainers to have the file in the checkout.
> Does it fail the same if you place it there and pass a relative filepath?
> fedpkg new-sources unuran-1.9.0.tar.gz


fedpkg --verbose new-sources unuran-1.9.0.tar.gz
Creating repo object from /home/nbecker/fedora.git/unuran
Could not execute new_sources: Fail to upload files. Server returns status
403
Traceback (most recent call last):
  File "/usr/bin/fedpkg", line 33, in 
sys.exit(load_entry_point('fedpkg==1.42', 'console_scripts',
'fedpkg')())
  File "/usr/lib/python3.10/site-packages/fedpkg/__main__.py", line 89, in
main
sys.exit(client.args.command())
  File "/usr/lib/python3.10/site-packages/pyrpkg/cli.py", line 2688, in
new_sources
self.cmd.upload(
  File "/usr/lib/python3.10/site-packages/pyrpkg/__init__.py", line 3078,
in upload
self.lookasidecache.upload(
  File "/usr/lib/python3.10/site-packages/pyrpkg/lookaside.py", line 298,
in upload
if self.remote_file_exists(name, filename, hash):
  File "/usr/lib/python3.10/site-packages/pyrpkg/lookaside.py", line 259,
in remote_file_exists
self.raise_upload_error(status)
  File "/usr/lib/python3.10/site-packages/pyrpkg/lookaside.py", line 128,
in raise_upload_error
raise UploadError(message, http_status=http_status)
pyrpkg.errors.UploadError: Fail to upload files. Server returns status 403


>
> --
*Those who don't understand recursion are doomed to repeat it*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Can't fedpkg new-sources (403)

[Neal Becker]

Sorry if this is a duplicate message, previous one was held for moderation.

$ fedpkg new-sources ~/Downloads/unuran-1.9.0.tar.gz
Could not execute new_sources: Fail to upload files. Server returns status
403

I haven't been active in packaging for some time, did I miss something?

-- 
*Those who don't understand recursion are doomed to repeat it*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

python3.11a4 pulled in as weak dep

[Neal Becker]

On my update yesterday on F35, python3.11a4 got pulled in as a 'weak'
dependency.  How can I trace where this dep came from?

Thanks,
Neal

-- 
*Those who don't understand recursion are doomed to repeat it*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: OpenVPN 2.x with kernel acceleration

[Neal Becker]

Does this modified openvpn support all the same features/options as the
stable release version?

Thanks,
Neal

On Fri, Feb 4, 2022 at 5:04 AM David Sommerseth  wrote:

> On 03/02/2022 05:52, Demi Marie Obenour wrote:
> > On 2/2/22 13:34, David Sommerseth wrote:
> >>
> >> Hi,
> >>
> >> An OpenVPN colleague of me, Antonio Quartulli (on Cc), has been working
> >> on a kernel acceleration module for OpenVPN for quite some time.  We
> >> call this OpenVPN Data Channel Offload (DCO).  This moves the tunnelled
> >> network traffic to a new kernel module (ovpn-dco) and keep only the
> >> control channel (authentication, VPN IP configuration, etc) in
> >> user-space.  This is gives a noticeable improved performance.
> >
> > Do you plan to submit this kernel module to upstream Linux?  Fedora
> > does not ship out-of-tree kernel modules last I checked.
>
> Yes, we do plan for that.  But before we're ready to do so, we'd like to
> see more broader testing of this module.  This comes in addition to have
> OpenVPN packages available with DCO support.
>
> We use Fedora Copr for the time being to make the availability of both
> kmod-ovpn-dco and OpenVPN builds with DCO support more
>  easily available
> for more testers.
>
> These builds and repository is currently fully supported by the OpenVPN
> community, with the standard clause that this is development builds
> which may contain bugs and not necessarily be as stable as ordinary
> releases.
>
>
> Going forward ...
>
> We plan to release OpenVPN 2.6 later this year, which will be DCO
> capable.  This will be available in the existing Fedora repositories, as
> well as Fedora Copr for releases (like EPEL 7 and 8) where we cannot
> upgrade easily.
>
> As long as RHEL-9 is in Beta, we are considering to move to OpenVPN 2.6
> in the EPEL-9 repositories.  Depending on the community testing of the
> Copr repos announced now, we might also provide similar snapshots in
> default EPEL-9 repos instead of OpenVPN 2.5.z until OpenVPN 2.6 is
> officially released.
>
> Basically: If you want to see OpenVPN 2.6 in EPEL-9, please test our
> EPEL-9 builds in the openvpn-dco Copr repo and provide feedback ASAP.
> If we get confidence t
> his works well, we will start preparing for
> pre-releases in EPEL-9 sooner than later.
>
>
> OpenVPN 2.6 and the openvpn-dco Copr builds should also work even if
> kmod-ovpn-dco is not available.  And we will provide and support the
> kmod-ovpn-dco via the openvpn3 Copr repository until we can get it into
> the far more common Fedora repositories.
>
>
> --
> kind regards,
>
> David Sommerseth
> OpenVPN Inc
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


-- 
*Those who don't understand recursion are doomed to repeat it*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Default To Noto Fonts (System-Wide Change proposal)

[Neal Becker]

Sorry, don't understand the question.  I was testing with non-variable
fonts, all were "mono".

On Wed, Jan 5, 2022 at 9:45 PM Akira TAGOH  wrote:

> On Fri, Dec 31, 2021 at 1:08 AM Neal Becker  wrote:
> >
> > After seeing this proposal I tried playing with Noto Sans Mono.  I
> > find that while it comes with many weights, none look right to me.
> > Language is English.
> >
> > I'm testing in emacs.  My usual default is Source code sans semibold
> > and I find that very pleasing.  I also tried Dejavu Sans Mono
> > semibold, which looks very similar.  But if I try Noto Sans Mono, no
> > weight looks right.  Medium is too light, and the next weight,
> > semibold, is too heavy.
>
> Thank you for the feedback. one question just comes to mind.
> Do you see any difference when you try it again with a non-variable
> font of Noto Sans Mono?
>
> >
> > On Wed, Dec 29, 2021 at 9:59 PM Robert Marcano via devel
> >  wrote:
> > >
> > > On 12/29/21 2:20 PM, Neal Gompa wrote:
> > > > On Wed, Dec 29, 2021 at 12:27 PM Artem Tim 
> wrote:
> > > >>
> > > >> Cantarell current default UI font in GNOME (Workstation) will be
> replaced by Noto font as well or remain?
> > > >
> > > > The current plan is to keep Cantarell for now, though GNOME upstream
> > > > may decide to switch to Noto as KDE Plasma did years ago.
> > > >
> > >
> > > Does Noto have the default font-variant-numeric as tabular-nums? (non
> > > proportional decimal digits) because it will be a welcomed change.
> > >
> > > The current default of Cantarell makes any number showing application a
> > > pain to style, specially on toolkits that use the system font but are
> > > unable to change font variants (Java Swing with GTK Look and Feel).
> > >
> > > Even GNOME applications aren't properly styled for number entry use
> > > cases. See for example Calculator where 111,111,111 looks like a
> smaller
> > > number than 99,999,999 when the are one on top of the other, because
> the
> > > font is proportional by default.
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > > Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
> >
> >
> >
> > --
> > Those who don't understand recursion are doomed to repeat it
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
>
>
> --
> Akira TAGOH
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


-- 
*Those who don't understand recursion are doomed to repeat it*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Default To Noto Fonts (System-Wide Change proposal)

[Neal Becker]

After seeing this proposal I tried playing with Noto Sans Mono.  I
find that while it comes with many weights, none look right to me.
Language is English.

I'm testing in emacs.  My usual default is Source code sans semibold
and I find that very pleasing.  I also tried Dejavu Sans Mono
semibold, which looks very similar.  But if I try Noto Sans Mono, no
weight looks right.  Medium is too light, and the next weight,
semibold, is too heavy.

On Wed, Dec 29, 2021 at 9:59 PM Robert Marcano via devel
 wrote:
>
> On 12/29/21 2:20 PM, Neal Gompa wrote:
> > On Wed, Dec 29, 2021 at 12:27 PM Artem Tim  wrote:
> >>
> >> Cantarell current default UI font in GNOME (Workstation) will be replaced 
> >> by Noto font as well or remain?
> >
> > The current plan is to keep Cantarell for now, though GNOME upstream
> > may decide to switch to Noto as KDE Plasma did years ago.
> >
>
> Does Noto have the default font-variant-numeric as tabular-nums? (non
> proportional decimal digits) because it will be a welcomed change.
>
> The current default of Cantarell makes any number showing application a
> pain to style, specially on toolkits that use the system font but are
> unable to change font variants (Java Swing with GTK Look and Feel).
>
> Even GNOME applications aren't properly styled for number entry use
> cases. See for example Calculator where 111,111,111 looks like a smaller
> number than 99,999,999 when the are one on top of the other, because the
> font is proportional by default.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



-- 
Those who don't understand recursion are doomed to repeat it
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

I'm assuming this is a temporary build failure?

[Neal Becker]

https://koji.fedoraproject.org/koji/taskinfo?taskID=79571245

Thanks,
Neal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Plasmashell: Alt+F2 not working

[Neal Becker]

Sergio Belkin wrote:

> Hi folks,
> 
> Since a few days ago, the keyboard shortcut Alt+F2 for opening "run
> command" box is not working.
> 
> journalctl shows complaints as follows:
> 
> plasmashell[231184]:  Could not open library 'libkdeinit5_'.
> plasmashell[231184]:  Cannot load library libkdeinit5_: (libkdeinit5_:
> cannot open shared object file: No such file or directory)
> 
> Any ideas?
> 
> Thanks in advance!
> 
> 

Wasn't this disabled by default, and you have to setup the keybinding 
yourself if you want it?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F34 update experience

[Neal Becker]

rpm -qa | wc - reports 5939

On Tue, Apr 27, 2021 at 2:13 PM Tomasz Torcz  wrote:
>
> Dnia Tue, Apr 27, 2021 at 04:08:38PM +, Zbigniew Jędrzejewski-Szmek 
> napisał(a):
> > On Tue, Apr 27, 2021 at 10:04:34AM -0400, Neal Becker wrote:
> > > Updated F33 -> F34.  Mostly went well, except there is one thing which
> > > could be better.  This is not new to F34 but has been there since the
> > > dnf system-upgrade.
> > >
> > > Running on a pretty decent laptop (core i7, 8GB, SSD).  The issue is
> > > that the installation hangs a long time with no evidence of activity.
> > > The hang begins at
> > > dnf running transaction.  It is disconcerting because it hangs for
> > > about 20-30 minutes, and during that time the fan is not running, so
> >
> > 20-30 minutes seems unexpected… There is a phase where dnf is solving
> > the deps, but it's usually much much shorter (*), and it's CPU-bound,
> > so the fans should be on. I don't know what's going on in your case,
> > but it sounds like some bug.
>
>   In 2019 I did some measurements of F31→F32. First step of distribution 
> upgrade
> took 16 minutes on a desktop computer. The results are at
> https://enotty.pipebreaker.pl/posts/2019/12/time-needed-to-dist-upgrade-fedora/
>
> > Do you have a huge number of packages? Lot's of modules? A very slow disk?
>
>  `rpm -qa` returns 3109. No modules (I think). Storage is btrfs raid1
> over 2xHDD (5900 RPM) + bcache with 2x384GiB partitions.
>
> --
> Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
> Torcz.. .o .o   .o .o oo   oo .o .. .. oo   oo
> o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



-- 
Those who don't understand recursion are doomed to repeat it
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F34 update experience

[Neal Becker]

As I said, the machine has an ssd.  But it has a very large number of
packages.  It's used for development so has lots of devel pkgs, and a large
selection of the live.

On Tue, Apr 27, 2021, 12:10 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Tue, Apr 27, 2021 at 10:04:34AM -0400, Neal Becker wrote:
> > Updated F33 -> F34.  Mostly went well, except there is one thing which
> > could be better.  This is not new to F34 but has been there since the
> > dnf system-upgrade.
> >
> > Running on a pretty decent laptop (core i7, 8GB, SSD).  The issue is
> > that the installation hangs a long time with no evidence of activity.
> > The hang begins at
> > dnf running transaction.  It is disconcerting because it hangs for
> > about 20-30 minutes, and during that time the fan is not running, so
>
> 20-30 minutes seems unexpected… There is a phase where dnf is solving
> the deps, but it's usually much much shorter (*), and it's CPU-bound,
> so the fans should be on. I don't know what's going on in your case,
> but it sounds like some bug.
>
> Do you have a huge number of packages? Lot's of modules? A very slow disk?
>
> Zbyszek
>
> (*) I was upgrading a rpi3 recently, and I had to wait a few minutes...
> But on a beefy machine, anything above a few dozen seconds is suspicious.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

F34 update experience

[Neal Becker]

Updated F33 -> F34.  Mostly went well, except there is one thing which
could be better.  This is not new to F34 but has been there since the
dnf system-upgrade.

Running on a pretty decent laptop (core i7, 8GB, SSD).  The issue is
that the installation hangs a long time with no evidence of activity.
The hang begins at
dnf running transaction.  It is disconcerting because it hangs for
about 20-30 minutes, and during that time the fan is not running, so
no evidence of cpu usage.  There seems to be no way to switch VT to
try to see what's happening.  I'd hate to see what happens on a less
capable machine.

I wish there was some way to get some better feedback that the update is alive.

-- 
Those who don't understand recursion are doomed to repeat it
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [HEADS UP] Mercurial without Python 2

[Neal Becker]

thg is a separate package, but the versions of hg and thg need to be
coordinated.

On Mon, Nov 30, 2020 at 9:49 AM Ondrej Pohorelsky 
wrote:

> As far as I know tortoisehg is a separate package in Fedora.
> I might give it a look after Mercurial is solved.
>
> Best regards,
> Ondra
>
> On Thu, Nov 26, 2020 at 1:01 AM Neal Becker  wrote:
> >
> > It would be nice to have a version of tortoisehg to go with it.
> Currently I've tried thg-5.6 built as:
> > pip install --user tortoisehg-5.6.tar.gz
> > And using mercurial-5.6 installed as
> > pip install --user --upgrade mercurial (IIRC)
> > And using system versions of PyQt etc.  It segfaults on many operations.
> >
> >
> https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5655#note_148341
> >
> > On Wed, Nov 25, 2020 at 12:07 PM Miro Hrončok 
> wrote:
> >>
> >> On 11/25/20 5:56 PM, Miro Hrončok wrote:
> >> > On 11/25/20 5:15 PM, Ondrej Pohorelsky wrote:
> >> >> We are working on dropping Python 2 version of Mercurial in
> Fedora[0] entirely.
> >> >
> >> > Hurray \o/
> >> >
> >> >> Currently there is a working version of Mercurial 5.6 in COPR[1] that
> >> >> needs further testing. If anyone who uses Mercurial would be able to
> >> >> test it and give me some feedback, I would be glad!
> >> >
> >> > I'll try to build our test-dependent Python packages (setuptools_scm,
> pip) and
> >> > report back.
> >>
> >> Both good:
> >>
> https://copr.fedorainfracloud.org/coprs/churchyard/mercurial-tests/builds/
> >>
> >> --
> >> Miro Hrončok
> >> --
> >> Phone: +420777974800
> >> IRC: mhroncok
> >
> >
> >
> > --
> > Those who don't understand recursion are doomed to repeat it
>
>

-- 
*Those who don't understand recursion are doomed to repeat it*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS UP] Mercurial without Python 2

[Neal Becker]

It would be nice to have a version of tortoisehg to go with it.  Currently
I've tried thg-5.6 built as:
pip install --user tortoisehg-5.6.tar.gz
And using mercurial-5.6 installed as
pip install --user --upgrade mercurial (IIRC)
And using system versions of PyQt etc.  It segfaults on many operations.

https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5655#note_148341

On Wed, Nov 25, 2020 at 12:07 PM Miro Hrončok  wrote:

> On 11/25/20 5:56 PM, Miro Hrončok wrote:
> > On 11/25/20 5:15 PM, Ondrej Pohorelsky wrote:
> >>
> We are working on dropping Python 2 version of Mercurial in Fedora[0] 
> entirely.
> >
> > Hurray \o/
> >
> >> Currently there is a working version of Mercurial 5.6 in COPR[1] that
> >> needs further testing. If anyone who uses Mercurial would be able to
> >> test it and give me some feedback, I would be glad!
> >
> > I'll try to build our test-dependent Python packages (setuptools_scm,
> pip) and
> > report back.
>
> Both good:
> https://copr.fedorainfracloud.org/coprs/churchyard/mercurial-tests/builds/
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>


-- 
*Those who don't understand recursion are doomed to repeat it*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

[Neal Becker]

Might be interesting to try logging in as a new user to see if some older
kde settings are messing things up.

On Thu, Sep 10, 2020 at 6:24 AM Ondrej Mosnacek  wrote:

> On Tue, Sep 8, 2020 at 5:30 PM Ben Cotton  wrote:
> > https://fedoraproject.org/wiki/Changes/WaylandByDefaultForPlasma
> >
> > == Summary ==
> > Change the default session selection in SDDM to prefer the
> > Wayland-based KDE Plasma Desktop session over the X11-based one.
> >
> > == Owner ==
> > * Name: [[User:Ngompa|Neal Gompa]], [[User:Rdieter|Rex Dieter]],
> > [[User:Jgrulich|Jan Grulich]]
> > * Email: ngomp...@gmail.com, rdie...@gmail.com, jgrul...@redhat.com
> > * Product: KDE Spin
> > * Responsible WG: KDE SIG
> >
> >
> > == Detailed Description ==
> >
> > With KDE Plasma 5.20, the KDE Plasma desktop environment has reached a
> > point where nearly all commonly used features in the desktop and all
> > major applications function in the Plasma Wayland environment on all
> > major GPUs (including NVIDIA with the proprietary driver). Starting
> > with Plasma 5.20 in Fedora 34, we will change the default
> > configuration for Wayland and X11 Plasma sessions so that Wayland is
> > preferred and used by default, while permitting the X11 session to be
> > selected as the alternative desktop environment option.
> >
> > == Feedback ==
> >
> >  Is Wayland ready? 
> > Wayland has been used by default for Fedora Workstation (which uses
> > GNOME) since Fedora 25. And while it was somewhat immature initially,
> > today it is a very rock-solid experience on virtually everything
> > Fedora Workstation runs on. The change in Fedora 25 kickstarted the
> > drive to get everything working on Wayland, and the Workstation team
> > succeeded beyond their wildest dreams. Firefox has been Wayland-native
> > by default since Fedora 31 as well.
> >
> > On the KDE side, serious work into supporting Wayland started shortly
> > after GNOME switched to Wayland by default. Unlike GNOME, KDE has a
> > much broader stack in its toolkit, and it has taken longer to get to a
> > usable state. With the Plasma 5.20 release, the Wayland protocol for
> > screencasting as well as middle-click paste finally are supported,
> > completing the required feature set for switching to Wayland by
> > default.
>
> So yesterday I tried to log in to the KDE Plasma + Wayland session on
> my laptop (F32) and the experience was unfortunately quite horrible...
>
> 1. When I logged out of the X session, switched to Wayland on the
> login screen, and logged in, I only got a black screen. After I
> rebooted, I managed to login to the Wayland session (I have automatic
> login after boot enabled), but...
> 2. The desktop was all squeezed into a small 1024x786 rectangle in the
> upper left corner of the screen (my screen is 1920x1080). So I opened
> system settings to change the resolution, but...
> 3. The screen settings were showing "manufacturer_TODO" and
> "model_TODO" as the name of the screen and the only resolution offered
> was 1024x786.
> 4. The window layout of my KDE session was not preserved (I think even
> the distribution of windows to activities was lost). But I probably
> shouldn't expect this to work...
> 5. Logging out of the Wayland session gave me just a black screen with
> blinking cursor, no login screen.
>
> Reading the other posts in this thread it seems I'm the only one
> experiencing such serious breakage (maybe except 4., which is
> understandable), so I'm wondering if I did something wrong... I simply
> installed plasma-workspace-wayland, logged out, and then logged in
> selecting "Plasma (Wayland) (Wayland)" from the session dropdown.
>
> --
> Ondrej Mosnacek
> Software Engineer, Platform Security - SELinux kernel
> Red Hat, Inc.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 
*Those who don't understand recursion are doomed to repeat it*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

[Neal Becker]

On Wed, Sep 9, 2020 at 10:33 AM Dominique Martinet 
wrote:

> Neal Becker wrote on Wed, Sep 09, 2020:
> > I have tested kde/wayland on F32 but have hit a roadblock.  We are all
> > working from home and need to share screens.  Using google chrome, on X11
> > when I try to share an app window (which is my usual choice) there are no
> > problems, but on wayland only some of the windows are given as choices to
> > share.  I haven'tfound any particular pattern to which windows are
> > listed (is it just from certain desktops?)  I believe this isn't
> > chrome specific (have to retest).
>
> I haven't tested but you can probaly only share other Xwayland windows
> (chrome still runs on Xwayland last I checked)
>
> The wayland-native way of sharing app windows is xdg-desktop-portal
> which has a kde implementation:
> https://invent.kde.org/plasma/xdg-desktop-portal-kde
> https://koji.fedoraproject.org/koji/packageinfo?packageID=24326
>
> Do you have xdg-desktop-portal-kde installed?
>
>
rpm -q xdg-desktop-portal-kde
xdg-desktop-portal-kde-5.19.5-1.fc32.x86_64

I tested firefox also, using google meet.  On firefox, no windows are
available to choose for sharing when run under wayland.  All the windows
show as expected
running firefox on plasma/X11.  That's a bit different than chrome but
seems to be some bug common between them.

>
>

-- 
*Those who don't understand recursion are doomed to repeat it*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

[Neal Becker]

I have tested kde/wayland on F32 but have hit a roadblock.  We are all
working from home and need to share screens.  Using google chrome, on X11
when I
try to share an app window (which is my usual choice) there are no
problems, but on wayland only some of the windows are given as choices to
share.  I haven't
found any particular pattern to which windows are listed (is it just from
certain desktops?)  I believe this isn't chrome specific (have to retest).

Where can I report this issue?

Thanks,
Neal

On Wed, Sep 9, 2020 at 9:46 AM José Abílio Matos  wrote:

> On Wednesday, September 9, 2020 4:30:54 AM WEST Tom Seewald wrote:
>
> > Has anyone compiled a (non-exhaustive) list of known issues that are
>
> > specific to KDE Plasma with Wayland?
>
> https://community.kde.org/Plasma/Wayland_Showstoppers
>
> --
>
> José Abílio
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 
*Those who don't understand recursion are doomed to repeat it*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

BTRFS, relatime vs. noatime

[Neal Becker]

If BTRFS is to become fedora default, we should consider this?

"BTRFS relatime vs. noatime - Huge Performance Difference - linux"
https://www.reddit.com/r/linux/comments/imgler/btrfs_relatime_vs_noatime_huge_performance/?utm_source=amp_medium=_content=post_body

-- 
*Those who don't understand recursion are doomed to repeat it*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

btrfs default partitioning/subvolume

[Neal Becker]

I wonder if there's any information or discussion on the default
partitioning and subvoluming
scheme to be used for btrfs install?

The only scheme I've used so far in the past is a single large partition
with one subvolume for /home and another for /root.  I think it might be
good to have another for /snapshots.

Thanks,
Neal

-- 
*Those who don't understand recursion are doomed to repeat it*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

if we want to advocate btrfs

[Neal Becker]

I think if we really want to advocate for btrfs, we also should provide the 
tools to take full advantage of it.  I've been using btrfs since it was 
offered as an option on Fedora.  On Ubuntu, there is a tool "snapper" to
help manage snapshots.  Unfortunately I didn't manage to get this setup on 
Fedora.  A tool like this would really enhance the btrfs experience, I 
believe.

It's been a while, but I think the reason I didn't get snapper running on my 
system is that the arrangement of btrfs subvolumes didn't match the default 
ubuntu used.  I have 2 subvolumes, 1 for root and 1 for home.

A primary use of snapshots would be to snapshot just before system update, 
so update could easily be rolled back.  This could also be helpful for large 
updates within the user directory, for example, using pip to update 
packages.

Thanks,
Neal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

fedpkg broken (pycurl issue?)

[Neal Becker]

Maybe the problem is that my local pycurl is not compatible with fedpkg?

fedpkg 
fedpkg 
Traceback (most recent call last):
  File "/usr/bin/fedpkg", line 11, in 
load_entry_point('fedpkg==1.38', 'console_scripts', 'fedpkg')()
  File 
"/home/nbecker/.local/lib/python3.7/site-packages/pkg_resources/__init__.py", 
line 490, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
  File 
"/home/nbecker/.local/lib/python3.7/site-packages/pkg_resources/__init__.py", 
line 2859, in load_entry_point
return ep.load()
  File 
"/home/nbecker/.local/lib/python3.7/site-packages/pkg_resources/__init__.py", 
line 2450, in load
return self.resolve()
  File 
"/home/nbecker/.local/lib/python3.7/site-packages/pkg_resources/__init__.py", 
line 2456, in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/lib/python3.7/site-packages/fedpkg/__init__.py", line 12, in 

import pyrpkg
  File "/home/nbecker/.local/lib/python3.7/site-packages/pyrpkg/__init__.py", 
line 47, in 
from pyrpkg.lookaside import CGILookasideCache
  File "/home/nbecker/.local/lib/python3.7/site-packages/pyrpkg/lookaside.py", 
line 26, in 
import pycurl
ImportError: pycurl: libcurl link-time ssl backend (openssl) is different from 
compile-time ssl backend (none/other)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: dnf unable to download source due to rpmfusion-free-source

[Neal Becker]

Samuel Sieb wrote:

> On 11/10/19 7:44 AM, Neal Becker wrote:
>> dnf --disablerepo=rpmfusion-free-source download --enablerepo=rawhide
>> --source mercurial enabling fedora-modular-source repository
>> enabling rawhide-source repository
>> enabling updates-modular-source repository
>> enabling updates-source repository
>> enabling fedora-source repository
>> enabling rpmfusion-free-updates-source repository
>> enabling rpmfusion-free-source repository
>> enabling rpmfusion-nonfree-updates-source repository
>> enabling rpmfusion-nonfree-source repository
>> RPM Fusion for Fedora 31 - Free - Source 
>> 267 kB/s |  80 kB 00:00
>> Failed to download metadata for repo 'rpmfusion-free-source' Error:
>> Failed to download metadata for repo 'rpmfusion-free-source'
> 
> Everyone answering so far has missed the important point.  He explicitly
> disabled that repo, but using the "--source" option re-enabled it.  I
> would suggest that you file a bug report for that.
> ___

Well it does work if you do

dnf --disablerepo=rpmfusion-free,rpmfusion-nonfree download --
enablerepo=rawhide --source mercurial

But that is not exactly obvious, so I think it's something dnf could handle 
better (I hesitate to call it a bug).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

dnf unable to download source due to rpmfusion-free-source

[Neal Becker]

dnf --disablerepo=rpmfusion-free-source download --enablerepo=rawhide --source 
mercurial 
enabling fedora-modular-source repository
enabling rawhide-source repository
enabling updates-modular-source repository
enabling updates-source repository
enabling fedora-source repository
enabling rpmfusion-free-updates-source repository
enabling rpmfusion-free-source repository
enabling rpmfusion-nonfree-updates-source repository
enabling rpmfusion-nonfree-source repository
RPM Fusion for Fedora 31 - Free - Source
  267 kB/s |  80 kB 00:00
Failed to download metadata for repo 'rpmfusion-free-source'
Error: Failed to download metadata for repo 'rpmfusion-free-source'
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Upgrade F30->F31 fails on speech-tools-libs

[Neal Becker]

Error: Transaction test error:
  file /usr/lib64/libeststring.so.1.2 from install of speech-tools-
libs-2.5-8.fc31.x86_64 conflicts with file from package festival-
speechtools-libs-1.2.96-39.fc29.x86_64

OK, can we remove speech-tools-libs?

[nbecker@nbecker2 ~]$ sudo dnf remove speech-tools-libs
No match for argument: speech-tools-libs
No packages marked for removal.

Nope, it isn't installed.


[nbecker@nbecker2 ~]$ sudo dnf remove festival-speechtools-libs
Dependencies resolved.

 Package   Architecture   Version   

Repository Size

Removing:
 festival-speechtools-libs x86_64 1.2.96-39.fc29

@fedora   3.7 M
Removing dependent packages:
 festival-freebsoft-utils  noarch 0.10-15.fc30  

@fedora   121 k
 kdeaccessibility  noarch 1:4.14.3-3.fc24   

@@commandline   0  
Removing unused dependencies:
 festival  x86_64 1.96-39.fc29  

@fedora   8.8 M
 festival-lib  x86_64 1.96-39.fc29  

@fedora   1.3 M
 festvox-slt-arctic-htsnoarch 0.20061229-39.fc29

@fedora   2.2 M
 jovie x86_64 17.08.3-6.fc30

@fedora   1.2 M
 jovie-libsx86_64 17.08.3-6.fc30

@fedora79 k
 kaccessible   x86_64 17.08.3-4.fc30

@fedora   113 k
 kaccessible-libs  x86_64 17.08.3-4.fc30

@fedora54 k
 kmag  x86_64 18.12.2-1.fc30

@fedora   1.4 M
 kmousetoolx86_64 18.12.2-1.fc30

@fedora   593 k
 kmouthx86_64 18.12.2-1.fc30

@fedora   3.5 M
 libid3tag x86_64 0.15.1b-30.fc30   

@fedora   165 k
 opusfile  x86_64 0.11-2.fc30   

@fedora   105 k
 sox   x86_64 14.4.2.0-25.fc30  

@fedora   1.4 M

Transaction Summary

Remove  16 Packages

No, I don't really want to remove all of these.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS-UP]: Mercurial with Python3 on rawhide?

[Neal Becker]

Petr, I am sorry to hear of your health problems.  I hope you recover soon.

I have been following this situation but have little time to spend on this.  
I personally use mercurial and depend on extensions: evolve and hg-git.  I 
have been quiet while working on getting these extensions ported.

So far I have not taken action on moving to py3 because these 2 extensions 
have not worked on py3.  I'm pleased to say that as of today, evolve is 
working.

hg-git is not working.  I spent a little time to see if I can port myself, 
but after trying a few naive fixes, it became clear that it was nontrivial 
to port.

Do we have any concensus on how to proceed?

Petr Stodulka wrote:

> Sorry guys
> that I am disconnected last month. I had some problems with health
> and now I am overbusy in work. I hoped that someone else could
> continue on that meanwhile what I started.
> 
> As I pointed, you can continue with move of other packages using
> the copr build anyway. But I understand that's not ideal and it should
> be resolved in rawhide repos.
> 
> On 05. 10. 19 15:31, Mads Kiilerich wrote:
>> 2 months later, and we still don't have Mercurial on Python 3 as an
>> option in 31 or rawhide, and we can thus not do anything to move forward
>> with packages that depend on Mercurial.
>> 
>> What can we do? Offer to take over ownership of the Mercurial package?
>> 
>> /Mads
>> 
>> 
>> On 8/6/19 9:35 PM, Petr Stodulka wrote:
>>> Hi guys,
>>> as discussion was started week ago, Python2 is dying. As that, some
>>> dependencies of mercurial will be orphaned soon (or they are already)
>>> and mercurial as it is has to move in weeks on Python3. As I wrote
>>> in [0], I already started some testing and investigation.
>>>
>>> Currently it seems that with ugly hacky fix, we are able to run
>>> somi-working mercurial with Python3. I did just simple testing
>>> that worked for me and in the latest copr-build (below), it seems
>>> that hgk extension is workin as well. But many of you extensions
>>> will be probably broken. So, I guess the most probably mercurial
>>> will be broken for the others who use it.
>>>
>>> So it's question, should I rebase it in rawhide and setup for Python3
>>> already even when it is so broken, or should I wait several weeks yet
>>> for additional fixes?
>>>
>>> If anyone is interested about testing before it will be done,
>>> just try:
>>> # dnf copr enable pstodulk/mercurial
>>> - it's just first attempt.
>>>
>>> Here is the list of RPMs depending on mercurial:
>>> git-cinnabar
>>> gitifyhg
>>> git-remote-hg
>>> gwsmhg
>>> hg-git
>>> hgsvn
>>> hgview-common
>>> python2-anyvc
>>> python2-wstool
>>> python3-hgapi
>>> python3-wstool
>>> qct-mercurial
>>> rabbitvcs-core
>>> rbm
>>> tortoisehg
>>> trac-mercurial-plugin
>>>
>>>
>>> Cheers,
>>> Petr
>> 
>> 
> 
> --
> Petr Stodulka
> OS & Application Modernization
> IRC nicks: pstodulk, skytak
> Senior Software Engineer
> Red Hat Czech s.r.o.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
> Archives:
> 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS-UP]: Mercurial with Python3 on rawhide?

[Neal Becker]

Seems evolve (tip) is not installable on python3:

python3 setup.py install --user
Traceback (most recent call last):
  File "setup.py", line 37, in 
version=get_version(),
  File "setup.py", line 15, in get_version
return get_metadata()['__version__']
  File "setup.py", line 10, in get_metadata
execfile(fullpath, meta)
NameError: name 'execfile' is not defined
[nbecker@nbecker2 evolve]$ hg id
8a491546e81d (stable) tip

On Sun, Sep 8, 2019 at 12:02 PM Neal Gompa  wrote:
>
> On Tue, Aug 27, 2019 at 7:21 PM Petr Stodulka  wrote:
> >
> > Hi guys,
> > I apologize that I mystified you a little in my prefious email when I wrote 
> > that
> > I resolved majority of problems. I looked at that closer today after 1.5w 
> > and
> > found that I have been near the start of all troubles. My memory just washed
> > that pain out.
> >
> > So I spend some time around and finally it looks that I am able to build at 
> > least
> > something. I guess that all extensions (including hgk, chg) are pretty 
> > broken
> > now as these will have to be build separately probably as well..
> >
> > The patch with POC of the py2 & py3 packages is here:
> >  https://bugzilla.redhat.com/attachment.cgi?id=1608765
> >
> > I think that the solution is pretty bad really (I mean, whole iday about
> > py2 & py3 rpms is wrong and maybe should be created new component that
> > will be conflicting with the mercurial - which should be ported to Py3 
> > only).
> > Such solution would be more clean I guess, with proper Provides/Obsoletes.
> >
> > I will be offline again since the wednesday's night. Hopefully it helps
> > someone at least a little.
> >
>
> I was speaking to the Octobus guys on IRC about this, and the issues
> reported earlier about hg-git and evolve are fixed in the default
> branch tip, just not in a release yet. Can you try pulling snapshots
> for hg-git and evolve based on tip and see if the situation has
> improved?
>
> I'd rather just have us yank Python 2 entirely from the Mercurial
> stack. Barring that, it _is_ possible to make de-conflicted Python 2
> and Python 3 packages. I'd rather the Python 2 one be non-default no
> matter what, since we *are* removing the Python 2 stack in Fedora 32,
> full stop.
>
> If you need help with making less ugly versions of a py2+py3 packaging
> of Mercurial, I'd be happy to help there.
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!



-- 
Those who don't understand recursion are doomed to repeat it
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS-UP]: Mercurial with Python3 on rawhide?

[Neal Becker]

It is intended for both py2 and py3 packages to be parallel installed,
correct?

On Mon, Aug 26, 2019, 1:52 PM Petr Stodulka  wrote:

> Hi guys,
> I already spent some time on that and I have resolved majority of problems
> with split. The blocker for now - which I believe it is possible to resolve
> but I haven't found a solution yet - are libexec files - I need to install
> filse for py3 into mercurial3 (or in different dir in general) and use
> those
> when using hg3.
>
> Unfortunately, to be able to create everything under one specfile, I had to
> create /usr/bin/hg for py2 and /usr/bin/hg3 for py3. In case the hg is
> required
> in both cases, we have to create new component in fedora, otherwise there
> is
> no way to resolve it.
>
> I have very limited time between my two holidays, but I will try to do
> another
> progress and at least attach my latest solution to the BZ so someone can
> continue
> instead of start from the scratch again.
>
> Petr
>
> On 20. 08. 19 19:54, Neal Becker wrote:
> > I agree that subpackages for py2 and py3 seems best, but I'll have to
> > see if mercurial can be parallel installed without too much effort.
> > I don't expect to have time to work on this for the next 2 weeks.
> >
> > On Sun, Aug 18, 2019 at 9:16 PM Mads Kiilerich 
> wrote:
> >>
> >> You are giving many good reasons why we need Mercurial packages for
> >> Python 2 and Python 3, side by side.
> >>
> >> That will make it possible for other packages to jump to Python 3. Your
> >> package will no longer be blocking, and it doesn't have to be your
> concern.
> >>
> >> It will also put the Mercurial package in the good position where it has
> >> done all the work of transitioning, and the python2 part will be
> >> entirely optional, only kept alive for benefit of other packages that
> >> still depend on it.
> >>
> >> I am working upstream with tortoisehg. While late, I don't expect any
> >> problems. The current blocker for Fedora packaging of tortoisehg is the
> >> lack of Python 3 Mercurial, and the biggest risk is that the Python 2
> >> Mercurial package goes away before I had time to transition the
> >> tortoisehg package to depend on Python 3 Mercurial.
> >>
> >> /Mads
> >>
> >>
> >>
> >> On 8/16/19 3:53 PM, Neal Becker wrote:
> >>> I think tortoisehg is not ported to python3
> >>>
> >>> On Wed, Aug 14, 2019 at 1:39 PM Neal Becker 
> wrote:
> >>>> I just tested hg-5.1.0 with the latest git version of hg-evolve on
> >>>> python3 and at least some basic things seem to be working.  One
> >>>> problem:
> >>>> hg
> >>>> *** failed to import extension hggit: No module named 'compat'
> >>>>
> >>>> That's with the latest pip version of hg-git (0.8.12).
> >>>>
> >>>> hg-git is a supported fedora package, so I think we need this to work.
> >>>>
> >>>> On Tue, Aug 13, 2019 at 9:35 AM Petr Stodulka 
> wrote:
> >>>>>
> >>>>>
> >>>>> On 12. 08. 19 22:36, Miro Hrončok wrote:
> >>>>>> On 12. 08. 19 20:37, Petr Stodulka wrote:
> >>>>>>> Can you explain better what do you mean by that? I am little lost
> >>>>>>> here.
> >>>>>> Sure. The idea was:
> >>>>>>
> >>>>>> 1) When Fedora 31 is branched (scheduled for tomorrow [1]), push
> the switch to rawhide (Fedora 32)
> >>>>>>
> >>>>>> 2) See what happens, collect feedback.
> >>>>>>
> >>>>>> 3) Soon before F31 Beta Freeze (scheduled for 2019-08-29 [1])
> decide whether this is worth pushing to F31 (probably not)
> >>>>>>
> >>>>>> 4) Soon before F32 mass Python 2 removal flag day (scheduled for
> mid November [2]), decide whether to revert and request and exception or not
> >>>>>>
> >>>>>> [1] https://fedoraproject.org/wiki/Releases/31/Schedule
> >>>>>> [2]
> https://fedoraproject.org/wiki/Changes/RetirePython2#Detailed_Description
> >>>>>>
> >>>>> Thanks Miro for explanation. That sounds asi the best idea now
> probably. From that point, I will not create new subpackages for Py2 / Py3
> and I will just do the switch tomorrow.
> >>>>>
> >>>>> @mercurial-maintainers: if anyone have something against or

Re: [HEADS-UP]: Mercurial with Python3 on rawhide?

[Neal Becker]

I agree that subpackages for py2 and py3 seems best, but I'll have to
see if mercurial can be parallel installed without too much effort.
I don't expect to have time to work on this for the next 2 weeks.

On Sun, Aug 18, 2019 at 9:16 PM Mads Kiilerich  wrote:
>
> You are giving many good reasons why we need Mercurial packages for
> Python 2 and Python 3, side by side.
>
> That will make it possible for other packages to jump to Python 3. Your
> package will no longer be blocking, and it doesn't have to be your concern.
>
> It will also put the Mercurial package in the good position where it has
> done all the work of transitioning, and the python2 part will be
> entirely optional, only kept alive for benefit of other packages that
> still depend on it.
>
> I am working upstream with tortoisehg. While late, I don't expect any
> problems. The current blocker for Fedora packaging of tortoisehg is the
> lack of Python 3 Mercurial, and the biggest risk is that the Python 2
> Mercurial package goes away before I had time to transition the
> tortoisehg package to depend on Python 3 Mercurial.
>
> /Mads
>
>
>
> On 8/16/19 3:53 PM, Neal Becker wrote:
> > I think tortoisehg is not ported to python3
> >
> > On Wed, Aug 14, 2019 at 1:39 PM Neal Becker  wrote:
> >> I just tested hg-5.1.0 with the latest git version of hg-evolve on
> >> python3 and at least some basic things seem to be working.  One
> >> problem:
> >> hg
> >> *** failed to import extension hggit: No module named 'compat'
> >>
> >> That's with the latest pip version of hg-git (0.8.12).
> >>
> >> hg-git is a supported fedora package, so I think we need this to work.
> >>
> >> On Tue, Aug 13, 2019 at 9:35 AM Petr Stodulka  wrote:
> >>>
> >>>
> >>> On 12. 08. 19 22:36, Miro Hrončok wrote:
> >>>> On 12. 08. 19 20:37, Petr Stodulka wrote:
> >>>>> Can you explain better what do you mean by that? I am little lost
> >>>>> here.
> >>>> Sure. The idea was:
> >>>>
> >>>> 1) When Fedora 31 is branched (scheduled for tomorrow [1]), push the 
> >>>> switch to rawhide (Fedora 32)
> >>>>
> >>>> 2) See what happens, collect feedback.
> >>>>
> >>>> 3) Soon before F31 Beta Freeze (scheduled for 2019-08-29 [1]) decide 
> >>>> whether this is worth pushing to F31 (probably not)
> >>>>
> >>>> 4) Soon before F32 mass Python 2 removal flag day (scheduled for mid 
> >>>> November [2]), decide whether to revert and request and exception or not
> >>>>
> >>>> [1] https://fedoraproject.org/wiki/Releases/31/Schedule
> >>>> [2] 
> >>>> https://fedoraproject.org/wiki/Changes/RetirePython2#Detailed_Description
> >>>>
> >>> Thanks Miro for explanation. That sounds asi the best idea now probably. 
> >>> From that point, I will not create new subpackages for Py2 / Py3 and I 
> >>> will just do the switch tomorrow.
> >>>
> >>> @mercurial-maintainers: if anyone have something against or better 
> >>> solution, answer here guys, otherwise I will do the rebase.
> >>> Just FYI, I will be kinda offline between 2019-08-15 - 2019-08-25 because 
> >>> of PTO. So in case of troubles, I will not be able to do anything during 
> >>> that time. From that point, I could postpone the rebase if needed, but I 
> >>> hope that someone else will be able to help around instead of me in case 
> >>> of troubles.
> >>>
> >>> --
> >>> Petr Stodulka
> >>> OS & Application Modernization
> >>> IRC nicks: pstodulk, skytak
> >>> Software Engineer
> >>> Red Hat Czech s.r.o.
> >>
> >>
> >> --
> >> Those who don't understand recursion are doomed to repeat it
> >
> >
>


-- 
Those who don't understand recursion are doomed to repeat it
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS-UP]: Mercurial with Python3 on rawhide?

[Neal Becker]

I think tortoisehg is not ported to python3

On Wed, Aug 14, 2019 at 1:39 PM Neal Becker  wrote:
>
> I just tested hg-5.1.0 with the latest git version of hg-evolve on
> python3 and at least some basic things seem to be working.  One
> problem:
> hg
> *** failed to import extension hggit: No module named 'compat'
>
> That's with the latest pip version of hg-git (0.8.12).
>
> hg-git is a supported fedora package, so I think we need this to work.
>
> On Tue, Aug 13, 2019 at 9:35 AM Petr Stodulka  wrote:
> >
> >
> >
> > On 12. 08. 19 22:36, Miro Hrončok wrote:
> > > On 12. 08. 19 20:37, Petr Stodulka wrote:
> > >> Can you explain better what do you mean by that? I am little lost
> > >> here.
> > >
> > > Sure. The idea was:
> > >
> > > 1) When Fedora 31 is branched (scheduled for tomorrow [1]), push the 
> > > switch to rawhide (Fedora 32)
> > >
> > > 2) See what happens, collect feedback.
> > >
> > > 3) Soon before F31 Beta Freeze (scheduled for 2019-08-29 [1]) decide 
> > > whether this is worth pushing to F31 (probably not)
> > >
> > > 4) Soon before F32 mass Python 2 removal flag day (scheduled for mid 
> > > November [2]), decide whether to revert and request and exception or not
> > >
> > > [1] https://fedoraproject.org/wiki/Releases/31/Schedule
> > > [2] 
> > > https://fedoraproject.org/wiki/Changes/RetirePython2#Detailed_Description
> > >
> >
> > Thanks Miro for explanation. That sounds asi the best idea now probably. 
> > From that point, I will not create new subpackages for Py2 / Py3 and I will 
> > just do the switch tomorrow.
> >
> > @mercurial-maintainers: if anyone have something against or better 
> > solution, answer here guys, otherwise I will do the rebase.
> > Just FYI, I will be kinda offline between 2019-08-15 - 2019-08-25 because 
> > of PTO. So in case of troubles, I will not be able to do anything during 
> > that time. From that point, I could postpone the rebase if needed, but I 
> > hope that someone else will be able to help around instead of me in case of 
> > troubles.
> >
> > --
> > Petr Stodulka
> > OS & Application Modernization
> > IRC nicks: pstodulk, skytak
> > Software Engineer
> > Red Hat Czech s.r.o.
>
>
>
> --
> Those who don't understand recursion are doomed to repeat it



-- 
Those who don't understand recursion are doomed to repeat it
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS-UP]: Mercurial with Python3 on rawhide?

[Neal Becker]

I just tested hg-5.1.0 with the latest git version of hg-evolve on
python3 and at least some basic things seem to be working.  One
problem:
hg
*** failed to import extension hggit: No module named 'compat'

That's with the latest pip version of hg-git (0.8.12).

hg-git is a supported fedora package, so I think we need this to work.

On Tue, Aug 13, 2019 at 9:35 AM Petr Stodulka  wrote:
>
>
>
> On 12. 08. 19 22:36, Miro Hrončok wrote:
> > On 12. 08. 19 20:37, Petr Stodulka wrote:
> >> Can you explain better what do you mean by that? I am little lost
> >> here.
> >
> > Sure. The idea was:
> >
> > 1) When Fedora 31 is branched (scheduled for tomorrow [1]), push the switch 
> > to rawhide (Fedora 32)
> >
> > 2) See what happens, collect feedback.
> >
> > 3) Soon before F31 Beta Freeze (scheduled for 2019-08-29 [1]) decide 
> > whether this is worth pushing to F31 (probably not)
> >
> > 4) Soon before F32 mass Python 2 removal flag day (scheduled for mid 
> > November [2]), decide whether to revert and request and exception or not
> >
> > [1] https://fedoraproject.org/wiki/Releases/31/Schedule
> > [2] 
> > https://fedoraproject.org/wiki/Changes/RetirePython2#Detailed_Description
> >
>
> Thanks Miro for explanation. That sounds asi the best idea now probably. From 
> that point, I will not create new subpackages for Py2 / Py3 and I will just 
> do the switch tomorrow.
>
> @mercurial-maintainers: if anyone have something against or better solution, 
> answer here guys, otherwise I will do the rebase.
> Just FYI, I will be kinda offline between 2019-08-15 - 2019-08-25 because of 
> PTO. So in case of troubles, I will not be able to do anything during that 
> time. From that point, I could postpone the rebase if needed, but I hope that 
> someone else will be able to help around instead of me in case of troubles.
>
> --
> Petr Stodulka
> OS & Application Modernization
> IRC nicks: pstodulk, skytak
> Software Engineer
> Red Hat Czech s.r.o.



-- 
Those who don't understand recursion are doomed to repeat it
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS-UP]: Mercurial with Python3 on rawhide?

[Neal Becker]

Petr Stodulka wrote:

> 
> 
> On 07. 08. 19 19:31, Petr Stodulka wrote:
>> 
>> On 07. 08. 19 3:34, Mads Kiilerich wrote:
>>> On 8/6/19 9:35 PM, Petr Stodulka wrote:
 So it's question, should I rebase it in rawhide and setup for Python3
 already even when it is so broken, or
>>>
>>>
>>> Hi
>>>
>>> I agree that something like this kind of is the right thing to do.
>>> Mercurial upstream needs our help to get Python3 support out of beta.
>>> But it will be painful. For developers and users.
>> 
>> Yep. That's it. On the other hand, I am thinking now, whether people will
>> have enough time to fix everything in case we will put it into the repo
>> later. I mean, now there is enough time to work on that, bzt doing switch
>> e.g. 3 months before release would generate more pressure on other
>> maintainers.
>> 
>>>
>>> It might get more attention if we take hostages and leave Mercurial
>>> broken for our users, but I would rather avoid that.
>>>
>>> Right now all packages that depend on Mercurial are kind of blocked and
>>> can't migrate because there is no official package with Mercurial on
>>> Python3. I think the best way forward is to get it packaged for python3,
>>> next to the existing python2 package. Perhaps as a sub package, or
>>> perhaps as a separate package that can be patched and move fast. That
>>> will give us opportunity and freedom to experiment and migrate each
>>> dependent package as we see fit, with minimal negative impact on our
>>> users.
>>>
>>> /Mads
>>> packager, hgview and tortoisehg
>>>
>>>
>> 
>> I agree that that seems like best options for people,
>> but honestly I am not sure how much it worth to create
>> such packages and probably remove the old ones before
>> we release new system. I mean, from your email I guess
>> you mean something like this:
>>  - keep these python2 now:
>>  mercurial, mercurial-hgk, mercurial-*
>>  - create new subpkgs for python3
>>  mercurial3, mercurial3-hgk, mercurial3-*
>>  (or vice versa; mercurial for py3, and mercurial2 for py2)
>> Right? As we are talking about temporary state that will be
>> changed in several weeks (one of those groups will be dropped
>> before release of 31) and after that there will be additional
>> release/obsolete set, which jsut beause of that I am not so
>> big fun. I would honestly rather tell people they should use
>> copr builds instead. - or we can guide people in case of troubles
>> to switch to COPR repo for Python2 builds of mercurial and use
>> just the new in rawhide. That would be solution too. What do you
>> think about that?
>> 
>> I will be able to spent 1-2 nights with that next week again.
>> I am able to create the subpackages next week if needed but
>> I would go rather with ways where COPR is included (creating
>> mercurial group including all related people - maintainers -
>> to be able to work there and later switch in rawhide).
>> 
>> Currently, some additional packages that works with mercurial,
>> have to resolve the troubles already as dependencies for them
>> will be broken soon because of orphaned rpms.
>> 
>> I would like to hear even opinions of other people around,
>> especially people around mercurial (including mercurial
>> maintainers, guys?)
>> 
> 
I've tested hg-5.0.2 python3 and I see that many extensions that I depend on 
aren't ported yet (and don't work).  I'm not even sure that all the 
extensions that ship standard with hg work.  IMO, that is not yet ready for 
even rawhide- shipping this will cause too much breakage.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: python-zstd?

[Neal Becker]

According to the discussion here:

https://www.mercurial-scm.org/pipermail/mercurial-devel/2019-April/130061.html

I think maybe we may instead ask to bundle a statically linked zstd with 
mercurial 4.9.  

Thanks,
Neal

Neal Gompa wrote:

> On Mon, Apr 8, 2019 at 8:21 AM Neal Becker  wrote:
>>
>> Neal Gompa wrote:
>>
>> > On Mon, Apr 8, 2019 at 7:36 AM Miro Hrončok 
>> > wrote:
>> >>
>> >> On 08. 04. 19 13:28, Neal Becker wrote:
>> >> > mercurial 4.9 packages zstd and python wrapper.
>> >> >
>> >> > I think we need to use system zstd.  But I don't see python2-zstd.
>> >> >
>> >> > Is anyone working on packaging python2-zstd?  It would be needed to
>> >> > proceed
>> >> > with mercurial 4.9.  (I haven't yet checked on version number
>> >> > compatibility).
>> >>
>> >> To add new python2 package, an exception from FPC or FESCo is needed.
>> >>
>> >> Can we instead update to directly to hg 5.0 in May and switch to
>> >> Python 3?
>> >>
>> >
>> > If all the reverse dependencies of Mercurial in Fedora are made ready
>> > in time, we probably could. But that's still past the expected release
>> > date for Fedora 30.
>> >
>> > Mercurial 4.9 is supposed to be Fedora 30, so I think the only thing
>> > we can do is allow python-zstd in the distribution with an exception
>> > to allow including a python2-zstd subpackage in addition to the
>> > python3-zstd subpackage.
>> >
>>
>> I think mercurial 5.0 on python3 is not quite ready for production use. 
>> I prefer to plan on mercurial 4.9 and package python-zstd, including a
>> python2-zstd.
> 
> I'd like for us to ship Mercurial 5.0 on Python 3 in Fedora Rawhide
> for sure. I think the six(ish) months of baking in Rawhide should be
> sufficient for getting Mercurial ready to go for production use on
> Python 3 and getting the reverse dependencies ported.
> 
> 

___
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: python-zstd?

[Neal Becker]

Neal Gompa wrote:

> On Mon, Apr 8, 2019 at 7:36 AM Miro Hrončok  wrote:
>>
>> On 08. 04. 19 13:28, Neal Becker wrote:
>> > mercurial 4.9 packages zstd and python wrapper.
>> >
>> > I think we need to use system zstd.  But I don't see python2-zstd.
>> >
>> > Is anyone working on packaging python2-zstd?  It would be needed to
>> > proceed
>> > with mercurial 4.9.  (I haven't yet checked on version number
>> > compatibility).
>>
>> To add new python2 package, an exception from FPC or FESCo is needed.
>>
>> Can we instead update to directly to hg 5.0 in May and switch to Python
>> 3?
>>
> 
> If all the reverse dependencies of Mercurial in Fedora are made ready
> in time, we probably could. But that's still past the expected release
> date for Fedora 30.
> 
> Mercurial 4.9 is supposed to be Fedora 30, so I think the only thing
> we can do is allow python-zstd in the distribution with an exception
> to allow including a python2-zstd subpackage in addition to the
> python3-zstd subpackage.
> 

I think mercurial 5.0 on python3 is not quite ready for production use.  I 
prefer to plan on mercurial 4.9 and package python-zstd, including a 
python2-zstd.
___
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: hg + zstd packaging

[Neal Becker]

Neal Becker wrote:

> Hi, I'm helping to maintain hg on Fedora.
> 
> Fedora has a policy of using system libraries where possible.
> 
> Fedora currently has libzstd (1.3.8), but does not appear to have python2-
> zstd module.
> 
> I think we need to build hg to use the system libzstd, and to also package
> python2-zstd seperately.
> 
> Does this plan sound OK?
> ___
Sorry, sent to wrong list! 
___
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

hg + zstd packaging

[Neal Becker]

Hi, I'm helping to maintain hg on Fedora.

Fedora has a policy of using system libraries where possible.

Fedora currently has libzstd (1.3.8), but does not appear to have python2-
zstd module.

I think we need to build hg to use the system libzstd, and to also package 
python2-zstd seperately. 

Does this plan sound OK?
___
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

python-zstd?

[Neal Becker]

mercurial 4.9 packages zstd and python wrapper.

I think we need to use system zstd.  But I don't see python2-zstd.

Is anyone working on packaging python2-zstd?  It would be needed to proceed 
with mercurial 4.9.  (I haven't yet checked on version number 
compatibility).

Thanks,
Neal
___
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: Donate 1 minute of your time to test upgrades from F29 to F30

[Neal Becker]

Miroslav Suchý wrote:

> Do you want to make Fedora 30 better? Please spend 1 minute of your time
> and try to run:
> 
>   sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30
>   --enablerepo=updates-testing distro-sync
> 
> If you get this prompt:
> 
>   ...
>   Total download size: XXX M
>   Is this ok [y/N]:
> 
> you can answer N and nothing happens, no need to test the real upgrade.
> Upgrades will be fine for you.
> 
> But very likely you get some dependency problem now. In that case please
> report it against appropriate package.
> 
> Thank you
> 
> Miroslav
> ___
> 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
Error: 
 Problem 1: package python2-blockdev-2.21-1.fc29.x86_64 requires 
libblockdev(x86-64) = 2.21-1.fc29, but none of the providers can be 
installed
  - libblockdev-2.21-1.fc29.x86_64 does not belong to a distupgrade 
repository
  - problem with installed package python2-blockdev-2.21-1.fc29.x86_64
 Problem 2: package python2-rpkg-1.57-6.fc29.noarch requires rpkg-common = 
1.57-6.fc29, but none of the providers can be installed
  - rpkg-common-1.57-6.fc29.noarch does not belong to a distupgrade 
repository
  - problem with installed package python2-rpkg-1.57-6.fc29.noarch
 Problem 3: package rpmfusion-free-release-29-1.noarch requires system-
release(29), but none of the providers can be installed
  - fedora-release-29-7.noarch does not belong to a distupgrade repository
  - problem with installed package rpmfusion-free-release-29-1.noarch
 Problem 4: package system-config-date-1.10.9-2.fc24.noarch requires python-
slip >= 0.2.21, but none of the providers can be installed
  - python2-slip-0.6.4-12.fc29.noarch does not belong to a distupgrade 
repository
  - problem with installed package system-config-date-1.10.9-2.fc24.noarch
 Problem 5: package vlc-core-1:3.0.6-16.fc29.x86_64 requires libprotobuf-
lite.so.15()(64bit), but none of the providers can be installed
  - protobuf-lite-3.5.0-8.fc29.x86_64 does not belong to a distupgrade 
repository
  - problem with installed package vlc-core-1:3.0.6-16.fc29.x86_64
 Problem 6: package whois-mkpasswd-5.4.1-1.fc29.x86_64 requires whois-nls = 
5.4.1-1.fc29, but none of the providers can be installed
  - whois-nls-5.4.1-1.fc29.noarch does not belong to a distupgrade 
repository
  - problem with installed package whois-mkpasswd-5.4.1-1.fc29.x86_64
 Problem 7: package fedora-release-29-7.noarch requires fedora-repos(29) >= 
1, but none of the providers can be installed
  - package rpmfusion-nonfree-release-29-1.noarch requires system-
release(29), but none of the providers can be installed
  - fedora-repos-29-3.noarch does not belong to a distupgrade repository
  - problem with installed package rpmfusion-nonfree-release-29-1.noarch
 Problem 8: package python3-flake8-3.6.0-2.fc30.noarch requires 
python3.7dist(pycodestyle) < 2.5.0, but none of the providers can be 
installed
  - problem with installed package python3-flake8-3.5.0-6.fc29.noarch
  - python3-pycodestyle-2.4.0-3.fc29.noarch does not belong to a distupgrade 
repository
  - python3-flake8-3.5.0-6.fc29.noarch does not belong to a distupgrade 
repository
 Problem 9: package dbus-common-1:1.12.12-2.fc30.noarch conflicts with 
fedora-release < 30-0.2 provided by fedora-release-29-7.noarch
  - package rpmfusion-free-release-29-1.noarch requires system-release(29), 
but none of the providers can be installed
  - problem with installed package dbus-common-1:1.12.12-1.fc29.noarch
  - package fedy-plugins-4.0.5-1.fc22.noarch requires rpmfusion-free-
release, but none of the providers can be installed
  - dbus-common-1:1.12.12-1.fc29.noarch does not belong to a distupgrade 
repository
  - problem with installed package fedy-plugins-4.0.5-1.fc22.noarch
 Problem 10: package dnf-yum-4.1.0-1.fc30.noarch conflicts with yum provided 
by yum-3.4.3-521.fc30.noarch
  - package yumex-3.0.17-2.fc23.noarch requires yum >= 3.2.23, but none of 
the providers can be installed
  - problem with installed package dnf-yum-4.1.0-1.fc29.noarch
  - yum-3.4.3-518.fc29.noarch does not belong to a distupgrade repository
  - dnf-yum-4.1.0-1.fc29.noarch does not belong to a distupgrade repository
  - problem with installed package yumex-3.0.17-2.fc23.noarch
 Problem 11: package rpmfusion-free-release-29-1.noarch requires system-
release(29), but none of the providers can be installed
  - package dbus-daemon-1:1.12.12-2.fc30.x86_64 conflicts with fedora-
release < 30-0.2 provided by fedora-release-29-7.noarch
  - package fedy-plugins-4.0.5-1.fc22.noarch requires rpmfusion-free-
release, but none of the providers can be installed
  - problem with installed 

Re: F30 change: update mercurial to version 4.9

[Neal Becker]

Zbigniew Jędrzejewski-Szmek wrote:

> On Mon, Feb 11, 2019 at 09:19:08AM -0500, Neal Becker wrote:
>> I'm proposing to update to mercurial 4.9 for F30.
> 
> What is the effect on those dependent packages? How many need
> adjustments?
> 
> Zbyszek

tortoisehg for sure won't run until it is updated, I don't think the 
upstream is ready yet.

Others I don't know.

> 
>> 
>> The following packages are reported by dnf repoquery --whatrequires to
>> depend on mercurial:
>> git-cinnabar-0:0.5.0-1.fc29.x86_64
>> git-remote-hg-0:0.3-9.fc29.noarch
>> gitifyhg-0:0.8.4-11.fc29.noarch
>> golang-bin-0:1.11-1.fc29.x86_64
>> golang-bin-0:1.11.5-1.fc29.x86_64
>> gwsmhg-0:0.13.2-14.fc29.noarch
>> hg-git-0:0.8.11-3.fc29.noarch
>> hgsubversion-0:1.8.7-2.fc27.noarch
>> hgsvn-0:0.5.1-7.fc29.noarch
>> hgview-common-0:1.10.2-1.fc29.noarch
>> mercurial-chg-0:4.5.3-1.fc29.x86_64
>> mercurial-hgk-0:4.5.3-1.fc29.x86_64
>> python2-anyvc-0:0.3.7.1-14.fc29.noarch
>> python2-hgapi-0:1.7.4-5.fc29.noarch
>> python2-hghooks-0:0.7.0-10.fc29.noarch
>> python2-vcstools-0:0.1.40-1.fc29.noarch
>> python2-wstool-0:0.1.17-7.fc29.noarch
>> python2-wstool-0:0.1.17-9.fc29.noarch
>> python3-hgapi-0:1.7.4-5.fc29.noarch
>> python3-vcstools-0:0.1.40-1.fc29.noarch
>> python3-wstool-0:0.1.17-7.fc29.noarch
>> python3-wstool-0:0.1.17-9.fc29.noarch
>> pyvcs-0:0.2.0-15.fc29.noarch
>> qct-mercurial-0:1.7-20.fc28.x86_64
>> rabbitvcs-core-0:0.17.1-7.fc29.noarch
>> rabbitvcs-core-0:0.17.1-9.fc29.noarch
>> rbm-0:0.4-10.20151206gitd50b2a6.fc29.noarch
>> tortoisehg-0:4.6.1-1.fc29.noarch
>> trac-mercurial-plugin-0:1.0.0.4-6.fc29.noarch
>> ___
>> 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: fedpkg push fails

[Neal Becker]

Scott Talbert wrote:

> On Mon, 11 Feb 2019, Neal Becker wrote:
> 
>> I haven't done any fedora packaging work for some time.  I tried to fix
>> https://bugzilla.redhat.com/show_bug.cgi?id=1674789
>> today, but I get:
>>
>> fedpkg push
>> Enumerating objects: 5, done.
>> Counting objects: 100% (5/5), done.
>> Delta compression using up to 4 threads
>> Compressing objects: 100% (3/3), done.
>> Writing objects: 100% (3/3), 429 bytes | 429.00 KiB/s, done.
>> Total 3 (delta 2), reused 0 (delta 0)
>> remote: Denied push for ref 'refs/heads/master' for user 'nbecker'
>> remote: All changes have been rejected
>> To ssh://pkgs.fedoraproject.org/rpms/dblatex
>> ! [remote rejected] master -> master (pre-receive hook declined)
>> error: failed to push some refs to
>> 'ssh://nbec...@pkgs.fedoraproject.org/rpms/dblatex'
>> Could not execute push: Failed to execute command.
> 
> It doesn't look like you have commit rights to that package.
> ___
> 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

Someone with commit rights please try this:

diff --git a/dblatex.spec b/dblatex.spec
index af69bcf..45bf957 100644
--- a/dblatex.spec
+++ b/dblatex.spec
@@ -1,6 +1,6 @@
 Name:   dblatex
 Version:0.3.10
-Release:9%{?dist}
+Release:10%{?dist}
 Summary:DocBook to LaTeX/ConTeXt Publishing
 BuildArch:  noarch
 # Most of package is GPLv2+, except:
@@ -83,6 +83,7 @@ Authors:
 %patch1 -p1 -b .disable-debian
 rm -rf lib/contrib
 pathfix.py -pni "%{__python2} %{py2_shbang_opts}" .
+pathfix.py -pni "%{__python2} %{py2_shbang_opts}" scripts/dblatex
 
 %build
 %{__python2} setup.py build
@@ -132,6 +133,9 @@ cp -p %{SOURCE1} COPYING-docbook-xsl
 %postun -p /usr/bin/texhash
 
 %changelog
+* Mon Feb 11 2019 Neal Becker  - 0.3.10-10
+- Fix scripts/dblatex hashbang
+
 * Thu Jan 31 2019 Fedora Release Engineering  - 
0.3.10-9
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
 

___
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

fedpkg push fails

[Neal Becker]

I haven't done any fedora packaging work for some time.  I tried to fix 
https://bugzilla.redhat.com/show_bug.cgi?id=1674789
today, but I get:

 fedpkg push
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 429 bytes | 429.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: Denied push for ref 'refs/heads/master' for user 'nbecker'
remote: All changes have been rejected
To ssh://pkgs.fedoraproject.org/rpms/dblatex
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 
'ssh://nbec...@pkgs.fedoraproject.org/rpms/dblatex'
Could not execute push: Failed to execute command.
___
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

F30 change: update mercurial to version 4.9

[Neal Becker]

I'm proposing to update to mercurial 4.9 for F30.

The following packages are reported by dnf repoquery --whatrequires to 
depend on mercurial:
git-cinnabar-0:0.5.0-1.fc29.x86_64
git-remote-hg-0:0.3-9.fc29.noarch
gitifyhg-0:0.8.4-11.fc29.noarch
golang-bin-0:1.11-1.fc29.x86_64
golang-bin-0:1.11.5-1.fc29.x86_64
gwsmhg-0:0.13.2-14.fc29.noarch
hg-git-0:0.8.11-3.fc29.noarch
hgsubversion-0:1.8.7-2.fc27.noarch
hgsvn-0:0.5.1-7.fc29.noarch
hgview-common-0:1.10.2-1.fc29.noarch
mercurial-chg-0:4.5.3-1.fc29.x86_64
mercurial-hgk-0:4.5.3-1.fc29.x86_64
python2-anyvc-0:0.3.7.1-14.fc29.noarch
python2-hgapi-0:1.7.4-5.fc29.noarch
python2-hghooks-0:0.7.0-10.fc29.noarch
python2-vcstools-0:0.1.40-1.fc29.noarch
python2-wstool-0:0.1.17-7.fc29.noarch
python2-wstool-0:0.1.17-9.fc29.noarch
python3-hgapi-0:1.7.4-5.fc29.noarch
python3-vcstools-0:0.1.40-1.fc29.noarch
python3-wstool-0:0.1.17-7.fc29.noarch
python3-wstool-0:0.1.17-9.fc29.noarch
pyvcs-0:0.2.0-15.fc29.noarch
qct-mercurial-0:1.7-20.fc28.x86_64
rabbitvcs-core-0:0.17.1-7.fc29.noarch
rabbitvcs-core-0:0.17.1-9.fc29.noarch
rbm-0:0.4-10.20151206gitd50b2a6.fc29.noarch
tortoisehg-0:4.6.1-1.fc29.noarch
trac-mercurial-plugin-0:1.0.0.4-6.fc29.noarch
___
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

Clear Linux's make-fmv-patch Eases The Creation Of GCC FMV-Enabled Code Paths

[Neal Becker]

https://www.phoronix.com/scan.php?page=news_item=GCC-Clear-make-fmv-patch

Sounds like interesting tech.
___
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: dnf download misbehaving?

[Neal Becker]

Should a bug report be filed, and if so where?

Marek Blaha wrote:

> Looks like the problem is with fedora updates source repository metadata.
> I've downloaded metalink from URL
> https://mirrors.fedoraproject.org/metalink?repo=updates-released-source-f29=x86_64
> I checked a few mirrors from the list and the content of primary metadata
> file is somewhat unsatisfying (basically it is empty):
> 
> 
> http://linux.duke.edu/metadata/common; xmlns:rpm="
> http://linux.duke.edu/metadata/rpm; packages="0">
> 
> 
> Marek
> 
> --
> Marek Blaha 
> 
> 
> On Thu, Jan 10, 2019 at 3:56 PM Neal Becker  wrote:
> 
>> dnf download --source wireshark
>> [...]
>> No package wireshark-2.6.5-1.fc29.src available.
>> Exiting due to strict setting.
>> Error: No package wireshark-2.6.5-1.fc29.src available.

___
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

dnf download misbehaving?

[Neal Becker]

dnf download --source wireshark
[...]
No package wireshark-2.6.5-1.fc29.src available.
Exiting due to strict setting.
Error: No package wireshark-2.6.5-1.fc29.src available.

___
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

dnf: update julia would remove dnf??

[Neal Becker]

sudo dnf update --enablerepo=rawhide julia

Dependencies resolved.

 Problem: The operation would result in removing the following protected 
packages: dnf
===
 Package   Arch   Version   
 
Repository   Size
===
Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
 dnf-yum   noarch 
4.0.3.5.1-1.fc30   rawhide  
62 k
 libgit2   x86_64 
0.26.3-1.fc28  fedora  
434 k
 libgit2   x86_64 
0.27.4-1.fc29  rawhide 
414 k
 python3   x86_64 
3.6.5-1.fc28   fedora   
70 k
 python3   x86_64 
3.7.0-9.fc30   rawhide  
39 k
 yum   noarch 
3.4.3-516.fc28 fedora  
1.2 M
 yum   noarch 
3.4.3-518.fc29 rawhide 
1.2 M
Skipping packages with broken dependencies:
 gitg-libs x86_64 
3.26.0-8.fc29  rawhide 
270 k
 julia x86_64 
1.0.0-2.fc30   rawhide  
55 M

Transaction Summary
===
Skip  9 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: [HEADS UP] mercurial rebase for F29

[Neal Becker]

I have no bandwidth to work on this in the next several weeks, so if anyone
else would like to take the lead that would be very helpful.

On Mon, Aug 6, 2018 at 7:05 AM Petr Stodulka  wrote:

> Hi folks,
> we want to do rebase of mercurial for F29 before beta freeze yet. Currently
> we have version v4.4.2 which is already old. Few days ago there have been
> release new stable version v4.7. But many applications would be broken
> because
> of changed API (as it is with every bump of minor version). From this
> point,
> I would like to do rebase to v4.5.3 (or v4.6) as I believe that apps with
> living upstream (and which requires mercurial) are already compatible with
> those versions of mercurial. After the F29 will be branched, we will do
> rebase
> to v4.7 in rawhide so there will be enough time to fix any issues because
> of
> changes in the new version.
>
> Here is the list of components that depends on mercurial:
>   - git-cinnabar
>   - gitifyhg
>   - git-remote-hg
>   - golang
>   - gwsmhg
>   - hg-git
>   - hgsubversion
>   - hgsvn
>   - hgview
>   - python-anyvc
>   - python-hgapi
>   - python-hghooks
>   - python-vcstools
>   - python-wstool
>   - pyvcs
>   - qct
>   - rabbitvcs
>   - rbm
>   - tortoisehg
>   - trac-mercurial-plugin
>
> Please give me a note in case you have troubles with this rebase now. I
> would
> like to do in few days. Add POCs into Cc.
>
> Cheers,
>
> --
> Petr Stodulka
> Core Services (In-place upgrades and migrations)
> IRC nicks: pstodulk, skytak
> 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/message/4GEAF2CDUAW2BOHUIJRC47BMBNZNI4VS/

proposal to update mercurial to 4.5.3 for f28

[Neal Becker]

Inline with this request:

https://src.fedoraproject.org/rpms/mercurial/pull-request/3

I am proposing to update mercurial to 4.5.3 for f28.  Any objections?
___
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/message/ILEA3N3A3H7NFJABHVN2252J4DTLQZCZ/

Re: DNSSEC, DoH, dnscrypt-proxy 1 vs 2

[Neal Becker]

A nice article on dns security:

https://arstechnica.com/information-technology/2018/04/how-to-keep-your-isps-nose-out-of-your-browser-history-with-encrypted-dns/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

package built for rawhide, but not available?

[Neal Becker]

As shown here:
https://koji.fedoraproject.org/koji/packageinfo?packageID=2518

mercurial-4.4.2-1.fc28

is built, but 
dnf --enablerepo=rawhide --show info mercurial

doesn't show it.  Is there now another step needed beyond just fedpkg build?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: mercurial: look for testers and karma

[Neal Becker]

Petr Stodulka wrote:

> Hi folks,
> I have there builds of mercurial in testing that fixes few CVEs.
> Someone who uses mercurial and want to test it yet?
> Thanks,
> 

I use it (lightly) :)  What do you have to test?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

mercurial CVEs - plan for f25 and f26 updates

[Neal Becker]

CVE-2017-1000115:

Mercurial's symlink auditing was incomplete prior to 4.3, and could be 
abused to write to files outside the repository.

CVE-2017-1000116:

Mercurial was not sanitizing hostnames passed to ssh, allowing shell 
injection attacks by specifying a hostname starting with -oProxyCommand. 

Currently we have:

hg  thg
f25 3.8.1   3.8.3(f24)
f26 4.2 4.2.1

Mercurial upstream has provided fixed versions 4.3 and 4.2.3.

I propose that for f26 we update hg to 4.2.3, and together with thg 4.2.3 
(currently latest is 4.2.2)

I propose for f25 to similarly update hg and thg to 4.2.3

Another package that requires mercurial and may be affected is hg-git.

Thoughts?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

can I "watch" a project in bodhi?

[Neal Becker]

If not, it would be a handy feature - to be notified of any updates.  I 
didn't see it looking at https://bodhi.fedoraproject.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

mercurial 4.1.3 for f26

[Neal Becker]

Mercurial < 4.1.3 has a security issue, and an update is highly recommended
https://www.mercurial-scm.org/pipermail/mercurial-packaging/2017-April/000202.html

I propose to update f26 for 4.1.3.
torgoisehg 4.1.3 is (just now) also available.

It would be advisable to backport patches to earlier versions.  I'm hoping 
maintainers of other distros (ubuntu) will provide this and I won't need to 
duplicate the efforts.

Any objections?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Warning before sudo pip'ing?

[Neal Becker]

Having been badly burned by sudo pip install in the past, I agree that a
warning is appropriate, with a suggestion to use pip install --user

On Fri, Feb 10, 2017 at 1:28 PM Tomas Orsava  wrote:

> Hi!
> On the last FESCo meeting while discussing the sudo pip Fedora [Change],
> maxamillion proposed that it might be useful to issue a warning when a
> user tries to run pip with root privileges--as in most cases it's not
> what they should be doing (`pip install --user` is usually more
> appropriate).
>
> What do you think?
>
> [Change] https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe
>
> Regards,
> Tomas Orsava
> ___
> python-devel mailing list -- python-devel@lists.fedoraproject.org
> To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
>
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: kinit OK, but howto ssh?

[Neal Becker]

Jonathan Underwood wrote:

> On 19 December 2016 at 16:48, Jonathan Underwood
> <jonathan.underw...@gmail.com> wrote:
>> On 19 December 2016 at 15:47, Neal Becker <ndbeck...@gmail.com> wrote:
>>>  kinit nbec...@fedoraproject.org
>>> Password for nbec...@fedoraproject.org:
>>> [nbecker@nbecker2 ~]$ ssh nbec...@fedoraproject.org
>>> Permission denied (publickey).
>>
>> Adding the -K switch worked for me...
> 
> Oh, I missread - it worked for me on fedorapeople.

My mistake, I actually DID want fedorapeople, which is working fine.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

kinit OK, but howto ssh?

[Neal Becker]

 kinit nbec...@fedoraproject.org
Password for nbec...@fedoraproject.org: 
[nbecker@nbecker2 ~]$ ssh nbec...@fedoraproject.org
Permission denied (publickey).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Making sudo pip Safe

[Neal Becker]

Currently, pip3 --user installed stuff can be updated with:
pip3 install --upgrade --user  $(pip3 list --user -o | cut -f 1 --delim=' ')

But that isn't obvious/discoverable

On Mon, Dec 12, 2016 at 8:48 AM Petr Viktorin <pvikt...@redhat.com> wrote:

> On 12/12/2016 01:39 PM, Neal Becker wrote:
> > I am one who was badly bitten by pip install into system in the past,
> > and I have been using pip --user since.  But there is one big usability
> > issue here, there isn't a trivially simple way to make sure packages
> > installed by pip are updated, much less automatically updated.  I think
> > it would be important for a change to --user by default to try to
> > address this issue.
>
> But --user doesn't address the issue of updating either.
>
>
> --
> Petr Viktorin
> ___
> python-devel mailing list -- python-devel@lists.fedoraproject.org
> To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
>
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

static linking a library

[Neal Becker]

Mercurial upstream is asking about a compression library zstd.

Specifically:
https://www.mercurial-scm.org/pipermail/mercurial-packaging/2016-November/000178.html

I believe the proposed solution here:
https://www.mercurial-scm.org/pipermail/mercurial-packaging/2016-December/000182.html

which is to statically link the library to the mercurial executable would 
also raise issues?  A special exception to the statically linked binary 
would be required?

Thanks,
Neal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

f25 builds in copr?

[Neal Becker]

It seems at this time f25 builds are not yet turned on in copr.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

test dnf system-upgrade (failed?)

[Neal Becker]

I tried to test upgrade f24->f25:

sudo dnf system-upgrade download --refresh --releasever=25 --allowerasing

but it wanted to downgrade a large number of packages, particularly texlive:
[hundreds of downgrades...]
 texlive-zlmtt  noarch  
5:svn34485.1.01-17.fc25.1   fedora  
 
35 k

Just checking that last one:
 rpm -q texlive-zlmtt
texlive-zlmtt-svn34485.1.01-24.fc24.1.noarch

Yup, the f24 version seems to be newer.

I suppose this is not the correct procedure?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

emacs patched for x2go on copr

[Neal Becker]

Many of us have experience that emacs cannot run under x2go.
https://bugzilla.redhat.com/show_bug.cgi?id=1349412

There is no actual fix, but we can't live without emacs, so I am putting up 
a version on copr which has a workaround (configure options).

It is named:
e.g., emacs-filesystem-25.1-2.x2go.fc24.noarch.rpm

I think this complies with naming conventions.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

update mercurial to 4.0 in rawhide

[Neal Becker]

I'm planning to update mercurial to 4.0 for rawhide.  Any objections?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

dnf should not update debuginfo if not updating packgages

[Neal Becker]

 sudo dnf update
...
updates   77 k
 mercurial-debuginfo   x86_64  4.0-1.fc24
...
 nbecker-mercurial-3  190 k
Skipping packages with broken dependencies:
 mercurial x86_64  4.0-1.fc24 
nbecker-mercurial-3  3.6 M
 mercurial-hgk x86_64  4.0-1.fc24 
nbecker-mercurial-3   55 k

Transaction Summary
=
Upgrade  23 Packages
Skip  2 Packages

So we updated debuginfo, but didn't install the corresponding packages.  
That seems like a bug.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

“Side channel” in Haswell CPUs lets researchers bypass protection known as ASLR.

[Neal Becker]

http://arstechnica.com/security/2016/10/flaw-in-intel-chips-could-make-malware-attacks-more-potent/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

problem with gmp f24? undefined reference to symbol '__gxx_personality_v0@@CXXABI_1.3'

[Neal Becker]

cc -c test_gmp.cpp
cc -o a.out test_gmp.o -lgmp -lgmpxx
/usr/bin/ld: test_gmp.o: undefined reference to symbol 
'__gxx_personality_v0@@CXXABI_1.3'
/usr/lib64/libstdc++.so.6: error adding symbols: DSO missing from command 
line
collect2: error: ld returned 1 exit status

Here is test_gmp.cpp:
#include 
int main() {
  mpz_class a(1);
  return a == 0;
};

--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: having trouble with bodhi

[Neal Becker]

Bruno Wolff III wrote:

> On Wed, Jun 08, 2016 at 15:32:44 -0400,
>   Neal Becker <ndbeck...@gmail.com> wrote:
>>[nbecker@nbecker2 Cython]$ bodhi -n -r F23 -t bugfix -b 1343331
>>Cython-0.23.4-3.fc23
>>No handlers could be found for logger "fedora.client.bodhi"
>>Creating a new update for Cython-0.23.4-3.fc23
>>Traceback (most recent call last):
>>  File "/usr/bin/bodhi", line 537, in 
>>main()
>>  File "/usr/bin/bodhi", line 251, in main
>>data = bodhi.save(**extra_args)
>>  File "/usr/lib/python2.7/site-packages/fedora/client/bodhi.py", line 93,
>>in wrapper
>>raise BodhiClientException(problems)
>>fedora.client.bodhi.BodhiClientException: Required
> 
> I think the last is from note having a note with -N. I get some warnings
> even when it works.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Yes, it appears that without -N ... bodhi chokes.

 bodhi -n -r F23 -t bugfix -b 1343331 -N 'see 
https://github.com/cython/cython/blob/master/CHANGES.rst' 
Cython-0.23.4-3.fc23
No handlers could be found for logger "fedora.client.bodhi"
Creating a new update for Cython-0.23.4-3.fc23

 Cython-0.23.4-3.fc23

  Update ID: FEDORA-2016-1af043e3f4
Release: Fedora 23
 Status: pending
   Type: bugfix
  Karma: 0
Request: testing
   Bugs: 1343331 - None
  Notes: see https://github.com/cython/cython/blob/master/CHANGES.rst
  Submitter: nbecker
  Submitted: 2016-06-08 19:38:51
   Comments: bodhi - 2016-06-08 19:38:51 (karma 0)
 This update has been submitted for testing by nbecker.

  https://bodhi.fedoraproject.org/updates/FEDORA-2016-1af043e3f4

--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

having trouble with bodhi

[Neal Becker]

[nbecker@nbecker2 Cython]$ bodhi -n -r F23 -t bugfix -b 1343331 
Cython-0.23.4-3.fc23
No handlers could be found for logger "fedora.client.bodhi"
Creating a new update for Cython-0.23.4-3.fc23
Traceback (most recent call last):
  File "/usr/bin/bodhi", line 537, in 
main()
  File "/usr/bin/bodhi", line 251, in main
data = bodhi.save(**extra_args)
  File "/usr/lib/python2.7/site-packages/fedora/client/bodhi.py", line 93, 
in wrapper
raise BodhiClientException(problems)
fedora.client.bodhi.BodhiClientException: Required

OK, how about another test?
[nbecker@nbecker2 Cython]$ bodhi -C
No handlers could be found for logger "fedora.client.bodhi"
Traceback (most recent call last):
  File "/usr/bin/bodhi", line 537, in 
main()
  File "/usr/bin/bodhi", line 367, in main
for build in bodhi.candidates():
  File "/usr/lib/python2.7/site-packages/fedora/client/bodhi.py", line 522, 
in candidates
data = self.get_releases()
  File "/usr/lib/python2.7/site-packages/fedora/client/bodhi.py", line 93, 
in wrapper
raise BodhiClientException(problems)
fedora.client.bodhi.BodhiClientException: csrf_token is missing
name is missing
long_name is missing
branch is missing
id_prefix is missing
dist_tag is missing
stable_tag is missing
testing_tag is missing
candidate_tag is missing
override_tag is missing
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

build stuck?

[Neal Becker]

http://koji.fedoraproject.org/koji/taskinfo?taskID=14421664
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[Neal Becker]

Zbigniew Jędrzejewski-Szmek wrote:

> On Fri, May 27, 2016 at 08:09:33AM -0500, Chris Adams wrote:
>> Once upon a time, Zbigniew Jędrzejewski-Szmek  said:
>> > Also note that running jobs in a systemd service has advantages on the
>> > server: better accounting, more transparency, logs are easier to read.
>> > The (old) default of allowing left-over session processes to live on
>> > seems especially bad on a server with multiple users.
>> 
>> Starting a one-off task under screen and detaching is an age-old server
>> management process.  Breaking that is not acceptable IMHO.
> 
> This change was done for a reason: left-over session processes
> are causing real problems.
> You still can start a one-off task under screen, you just need to
> invoke it in one the different ways described in
> https://www.freedesktop.org/software/systemd/man/systemd-run.html#Examples
> 
> Zbyszek
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Similarly, we need a way to fix x2go
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

rpm: %patch needs --fuzz

[Neal Becker]

In an rpm .spec I need a patch with more fuzz

%patch macro

doesn't seem to accept --fuzz=xxx

What's a good solution?  
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

can't login to koji - ssl error

[Neal Becker]

chrome is refusing to login to:

https://koji.fedoraproject.org/koji/login

This site can’t provide a secure connection

koji.fedoraproject.org sent an invalid response.
Try:
Reloading the page
Learn more about this problem.
ERR_SSL_PROTOCOL_ERROR

Appears to be a deprecation in chrome 50:
https://developers.google.com/web/updates/2016/03/chrome-50-deprecations?hl=en=ir_ssl_error=en=1#remove-insecure-tls-version-fallback
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

update mercurial to 3.7.1 in rawhide and F24

[Neal Becker]

I'd like to update to latest mercurial.  I built 3.7.1 in rawhide, and 
AFAICT there's no problem using it with tortoisehg-3.7.1-fc24.

I'd like to update mercurial in F24 - AFAIK there should not be any
compatibility issues.

Any objections?
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [ANNOUNCE] Fedora support for Vulkan

[Neal Becker]

drago01 wrote:

> On Wed, Feb 17, 2016 at 1:24 PM, Peter T.  wrote:
>>> On Tue, 2016-02-16 at 11:34 -0800, Andrew Lutomirski wrote:
>>>
>>>
>>> DRI3 is a prerequisite, yes. The F23 builds of the intel driver had it
>>> disabled until fairly recently, but this update should sort you out:
>>>
>>> https://bodhi.fedoraproject.org/updates/FEDORA-2016-606ca05253
>>
>> This is great, not only does the updated intel driver "enable" Vulkan,
>> but it also seems to have fixed my tearing issue. I guess it what because
>> DRI3 was disabled before?
> 
> Yes.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Looks good, but screen is not power off after 10 min, as configured.  I'm 
using KDE, so that could be an issue.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [ANNOUNCE] Fedora support for Vulkan

[Neal Becker]

Peter T. wrote:

>> On Tue, 2016-02-16 at 11:34 -0800, Andrew Lutomirski wrote:
>> 
>> 
>> DRI3 is a prerequisite, yes. The F23 builds of the intel driver had it
>> disabled until fairly recently, but this update should sort you out:
>> 
>> https://bodhi.fedoraproject.org/updates/FEDORA-2016-606ca05253
> 
> This is great, not only does the updated intel driver "enable" Vulkan, but
> it also seems to have fixed my tearing issue. I guess it what because DRI3
> was disabled before? In any case this is a fantastic update. -- devel
> mailing list devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

How do I get this update?

 sudo dnf --enablerepo=updates-testing install xorg-x11-drv-intel
...
Last metadata expiration check performed 0:00:00 ago on Wed Feb 17 08:41:57 
2016.
Package xorg-x11-drv-intel-2.99.917-16.20150729.fc23.x86_64 is already 
installed, skipping.
Dependencies resolved.
===
 Package ArchVersion
RepositorySize
===
Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
 xorg-x11-drv-intel  x86_64  2.99.917-19.20151206.fc23  
updates-testing  679 k

Transaction Summary
===
Skip  1 Package

Nothing to do.
Complete!
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Cython is failing to build (%check) on f24 (gcc6)

[Neal Becker]

Zbigniew Jędrzejewski-Szmek wrote:

> On Fri, Feb 05, 2016 at 09:43:24AM -0500, Neal Becker wrote:
>> Running %check is giving a compile error.  What's the easiest way to see
>> what the error message is?
>> 
>> https://kojipkgs.fedoraproject.org//work/tasks/3468/12893468/build.log
> 
> Add at the end of %check:
> || gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall
> || -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> || -fstack-protector-strong --param=ssp-buffer-size=4
> || -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> || -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe
> || -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> || -fstack-protector-strong --param=ssp-buffer-size=4
> || -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> || -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC
> || -I/builddir/build/BUILD/Cython-0.23.4/tests/run
> || -I/usr/include/python2.7 -c complex_numbers_c89_T398.cpp -o
> || 
/builddir/build/BUILD/Cython-0.23.4/BUILD/run/cpp/complex_numbers_c89_T398/complex_numbers_c89_T398.o
> || -DCYTHON_REFNANNY=1
> 
> Zbyszek
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Yes, but I want to see the compiler error message
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Cython is failing to build (%check) on f24 (gcc6)

[Neal Becker]

Running %check is giving a compile error.  What's the easiest way to see 
what the error message is?

https://kojipkgs.fedoraproject.org//work/tasks/3468/12893468/build.log
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Boost 1.60?

[Neal Becker]

Jan Kurik wrote:

> There is an approved Change for F24 to upgrade boost:
> https://fedoraproject.org/wiki/Changes/F24Boost160
> Perhaps someone started to work on it.
> 
> Regards,
> Jan
> 
> On Thu, Jan 14, 2016 at 1:49 PM, Peter Robinson 
> wrote:
>> On Thu, Jan 14, 2016 at 12:40 PM, Tom Hughes  wrote:
>>> Are we expecting boost 1.60 to land in Rawhide today?
>>>
>>> I see 1.60.0-1 built in the f24-boost side tag yesterday and then
>>> 1.60.0-2 this morning in the main f24 tag?
>>
>> There's been no request on the rel-eng ticket to tag it all back in so
>> I suspect some one made a mistake.
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
> 
> 

I'm concerned about this issue:
 
//permalink.gmane.org/gmane.comp.python.c++/16601>
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Update mercurial in rawhide to 3.6.2

[Neal Becker]

I'd like to update to the current mercurial version 3.6.2.

Affected packages are:

dnf repoquery --whatrequires mercurial
Last metadata expiration check performed 0:02:51 ago on Thu Dec 24 14:05:58 
2015.
fusionforge-plugin-scmhg-0:6.0.2-1.fc23.noarch
git-remote-hg-0:0.2-6.fc23.noarch
gitifyhg-0:0.8.4-3.fc23.noarch
gwsmhg-0:0.13.2-4.fc23.noarch
hg-git-0:0.8.2-1.fc23.noarch
hgsubversion-0:1.8.3-1.fc23.noarch
hgsvn-0:0.2.3-4.fc23.noarch
hgsvn-0:0.3.12-1.fc23.noarch
hgview-common-0:1.8.2-3.fc23.noarch
python-anyvc-0:0.3.7.1-6.fc23.noarch
python-hgapi-0:1.7.2-2.fc23.noarch
python-hghooks-0:0.6.0-4.fc23.noarch
python-vcpx-0:0.9.35-18.fc23.noarch
python-vcstools-0:0.1.37-1.fc23.noarch
python-vcstools-0:0.1.38-1.fc23.noarch
python-wstool-0:0.1.10-1.fc23.noarch
python-wstool-0:0.1.12-1.fc23.noarch
python3-hgapi-0:1.7.2-2.fc23.noarch
python3-vcstools-0:0.1.37-1.fc23.noarch
python3-vcstools-0:0.1.38-1.fc23.noarch
python3-wstool-0:0.1.10-1.fc23.noarch
python3-wstool-0:0.1.12-1.fc23.noarch
pyvcs-0:0.2.0-8.fc23.noarch
qct-mercurial-0:1.7-14.fc23.x86_64
tortoisehg-0:3.5.1-1.fc23.noarch
trac-mercurial-plugin-0:1.0.0.1-4.fc23.noarch

As far as I know, packages the are sensitive to hg version are:

tortoisehg
hg-git

Based on the fact that I've never heard any report of problems with the 
other packages caused by hg update.

thg is already at 3.6.2 in rawhide, so should be fine with hg 3.6.2

https://bitbucket.org/durin42/hg-git/src indicates the latest hg-git
is compatible with hg 3.6, not sure if the current fedora rawhide package
hg-git-0.8.2 needs to update to 0.8.3.

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: GCC6

[Neal Becker]

Jan Kurik wrote:

> = Proposed System Wide Change: GCC6 =
> https://fedoraproject.org/wiki/Changes/GCC6
> 
> Change owner(s):
> * Jakub Jelínek < jakub AT redhat DOT com >
> 
> Switch GCC in Fedora 24 to 6.x.y, rebuild all packages with it, or
> optionally rebuild just some packages with it and rebuild all packages
> only in Fedora 25.
> 
> == Detailed Description ==
> GCC 6 is currently in stage3, will move to stage4 around mid January,
> in prerelease state with only regression bugfixes and documentation
> fixes allowed. The release will happen probably in the middle of
> April. We are working on scratch gcc rpms and will perform a test mass
> rebuild.
> 
> == Scope ==
> All packages should be rebuilt with the new gcc once it hits f24, or,
> if there is not enough time for that, just all packages built after
> the new gcc hits the buildroots.
> 
> Proposal owners:
> * Build gcc in f24, rebuild packages that have direct dependencies on
> exact gcc version (libtool, llvm, gcc-python-plugin, odb).
> 
> Other developers:
> * First few days/weeks just voluntary rebuilds using the new system
> gcc, if things fail, look at http://gcc.gnu.org/gcc-6/porting_to.html

404 - not found

> and fix bugs in packages or, if there is a gcc bug or suspected gcc
> bug, analyze and report.
> 
> Release engineering:
> * Organize a mass rebuild, either in f24 or in f25
> 
> Policies and guidelines:
> * No policies need to be changed

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Neal Becker]

P J P wrote:

>> On Wednesday, 2 December 2015 6:33 PM, Neal Becker wrote:
> 
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1287607
> 
> 
>   Thank you for filing the bug.
> 
> 
>> * howto prevent dnsmasq from starting (right now I'm just manually
>> killing it for testing)
> 
>   # systemctl disable dnsmasq
> 
> 

ps aux | grep dns
nobody1056  0.0  0.0  57544   484 ?SDec14   0:00 
/sbin/dnsmasq --conf-file=/var/lib/libvir
root  1058  0.0  0.0  5751624 ?SDec14   0:00 
/sbin/dnsmasq --conf-file=/var/lib/libvir

[nbecker@nbecker2 Boost.NumPy]$ systemctl status dnsmasq
● dnsmasq.service - DNS caching server.
   Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service; disabled; vendor 
preset: disabled)
   Active: inactive (dead)

So something else is starting dnsmasq - looks like related to libvirt.

>> * howto get domainname set automatically from dhcp
> 
> 
> 
>   Dhcp configuration manual should help with that.
> 
> ---
>   -P J P
> http://feedmug.com
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Neal Becker]

Tomasz Torcz wrote:

> On Wed, Dec 16, 2015 at 09:33:18AM -0500, Neal Becker wrote:
>> P J P wrote:
>> 
>> >> On Wednesday, 2 December 2015 6:33 PM, Neal Becker wrote:
>> > 
>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1287607
>> > 
>> > 
>> >   Thank you for filing the bug.
>> > 
>> > 
>> >> * howto prevent dnsmasq from starting (right now I'm just manually
>> >> killing it for testing)
>> > 
>> >   # systemctl disable dnsmasq
>> > 
>> > 
>> 
>> ps aux | grep dns
>> nobody1056  0.0  0.0  57544   484 ?SDec14   0:00
>> /sbin/dnsmasq --conf-file=/var/lib/libvir
>> root  1058  0.0  0.0  5751624 ?SDec14   0:00
>> /sbin/dnsmasq --conf-file=/var/lib/libvir
> 
>   Try
> systemctl status 1056
> 
> I guess it's started by libvirtd.
> 

Yes, and does it have to be stopped in order for local dns resolver to 
function?
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Neal Becker]

 
>>> Really, the biggest issue people fear is their split view DNS. Which is
>>> easilly solved by extending the concept of firewalld zones into Network
>>> Manager, and always use broken DNS forwarders on "trusted networks".
>> 
>> Hmmm... "easily solved" is not "solved":
>>  * Has this "biggest issue" really been solved? Do we have this NM
>>  integration?
> 
> I don't know. I don't think the integration with firewalld/NM uses the
> same concept of "zones".
> 
>>Does it show in "nm-applet" (I avoid bringing up KDE which I
>>personally use, or other desktops)
>>  * What other issues we don't know, simply because this Fedora setup
>>  hasn't been *widely* deployed?
> 
> I'd be more sympathetic to this if we haven't gone through major things
> like /usr move already :P
> 
> Paul
> --

The split-dns case is I believe what I have at work.  I did test the 
proposed local dns resolver.  I was able to resolve names of machines 
internal to my work network (after some workaround), but when I needed to 
connect to a machine with a different domainname, and it wasn't resolved, 
and I needed that to do my timesheet, I reverted.

Using firewalld is not a perfect solution either, if that's the suggestion.  
My machines are configured to use iptables.  I have a perfectly good working 
iptables setup, and found firewalld looked like it had too much learning 
curve, so I don't use it.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Neal Becker]

P J P wrote:

> Hello Neal,
> 
>> On Wednesday, 2 December 2015 1:03 AM, Neal Becker wrote:
>> For example, when I'm at work, I can access hostA.work.com
>> where resolving hostA only works by talking to dnsserverA.work.com,
>> which was setup by the usual dhcp and then when I'm at home
>>
>> google.com is resolved as normal, using my ISP's dhcp to configure dns.
>> And this must work without the user ever editing some unbound config
>> file.
> 
> 
>   Yes, it does work that way. The proposed solution(tools) is available in
> current Fedora repositories and is easy to set-up and test.
> 
> 
>   ->
>   
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver#How_To_Test
> 
> 
> Please let us know if you face any difficulties. Thank you.

https://bugzilla.redhat.com/show_bug.cgi?id=1287607


--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Neal Becker]

P J P wrote:

> Hello Neal,
> 
>> On Wednesday, 2 December 2015 1:03 AM, Neal Becker wrote:
>> For example, when I'm at work, I can access hostA.work.com
>> where resolving hostA only works by talking to dnsserverA.work.com,
>> which was setup by the usual dhcp and then when I'm at home
>>
>> google.com is resolved as normal, using my ISP's dhcp to configure dns.
>> And this must work without the user ever editing some unbound config
>> file.
> 
> 
>   Yes, it does work that way. The proposed solution(tools) is available in
> current Fedora repositories and is easy to set-up and test.
> 
> 
>   ->
>   
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver#How_To_Test
> 
> 
> Please let us know if you face any difficulties. Thank you.

Also, I think we need it to work out-of-the-box.  Editing a config file is 
not working out-of-the-box.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Neal Becker]

Neal Becker wrote:

> P J P wrote:
> 
>> Hello Neal,
>> 
>>> On Wednesday, 2 December 2015 1:03 AM, Neal Becker wrote:
>>> For example, when I'm at work, I can access hostA.work.com
>>> where resolving hostA only works by talking to dnsserverA.work.com,
>>> which was setup by the usual dhcp and then when I'm at home
>>>
>>> google.com is resolved as normal, using my ISP's dhcp to configure dns.
>>> And this must work without the user ever editing some unbound config
>>> file.
>> 
>> 
>>   Yes, it does work that way. The proposed solution(tools) is available
>>   in
>> current Fedora repositories and is easy to set-up and test.
>> 
>> 
>>   ->
>>   
> 
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver#How_To_Test
>> 
>> 
>> Please let us know if you face any difficulties. Thank you.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1287607
> 
> 
So remaining difficulties are:

* howto prevent dnsmasq from starting (right now I'm just manually killing 
it for testing)

* howto get domainname set automatically from dhcp
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Neal Becker]

I think in order to make dnssec/local resolver the default, it should be 
required to work for a naive user who works in a changing environment such 
as:

moving between work, which has it's own private dns and
home, which has usual, public dns

without that user needing to understand anything about configuring the 
components.  For example, when I'm at work, I can access

hostA.work.com

where resolving hostA only works by talking to dnsserverA.work.com, which 
was setup by the usual dhcp
and then when I'm at home

google.com

is resolved as normal, using my ISP's dhcp to configure dns.

And this must work without the user ever editing some unbound config file.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

python-cycler has broken dependencies in the rawhide tree:

[Neal Becker]

python-cycler has broken dependencies in the rawhide tree:
On x86_64:
python3-cycler-0.9.0-4.fc24.noarch requires python(abi) = 0:3.4
On i386:
python3-cycler-0.9.0-4.fc24.noarch requires python(abi) = 0:3.4
On armhfp:
python3-cycler-0.9.0-4.fc24.noarch requires python(abi) = 0:3.4

I'm guessing it just needs to be rebuilt?  How do I do this?

I tried: 
fedpkg build
Could not execute build: Package python-cycler-0.9.0-4.fc24 has already been 
built
Note: You can skip this check with --skip-nvr-check. See help for more info.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

What is Source0 tag for this?

[Neal Becker]

What is syntax for Source0 tag for git tag v0.9.0 tarball for this?

https://github.com/matplotlib/cycler/tree/v0.9.0

And how can I verify it works?

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct