Re: memtest86plus v6.00

[Peter Lemenkov]

Sorry for reviving this old thread but memtest86+ just hit 6.20
milestone and it looks like they restored non-UEFI boot support. Looks
like it could be done for both types of systems as easy as this
(assuming you're using grub2 for booting the kernel):

menuentry 'memtest86+' {
insmod part_gpt
insmod ext2
set root='hd0,gpt1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1
--hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1  
else
  search --no-floppy --fs-uuid --set=root 
fi
linux /boot/memtest64.efi
}

Should we just start moving forward away from the quite antique 5.xx version?

On Fri, Oct 7, 2022 at 3:00 PM Richard W.M. Jones  wrote:
>
>
> Earlier discussion:
> https://www.mail-archive.com/devel@lists.fedoraproject.org/msg169800.html
>
> Current memtest86+ 5.x requires non-UEFI, which makes it increasingly
> irrelevant to modern hardware.  memtest86 forked into a proprietary
> product some time ago.  However there is hope because upstream
> memtest86+ 6.00 is (a) open source and (b) seems to work despite the
> large warnings on the website:
>
> https://memtest.org/
>
> Note this new version is derived from pcmemtest mentioned in the
> thread above which is only indirectly derived from memtest86+ 5.x and
> removes some features.
>
> So my question is are we planning to move to v6.00 in future?
>
> I did attempt to build a Fedora RPM, but it basically involves
> removing large sections of the existing RPM (eg. the downstream script
> we add seems unnecessary now and the downstream README would need to
> be completely rewritten).  It's probably only necessary to have
> memtest.efi be installed as /boot/memtest.efi and although it won't
> appear automatically in the grub menu, it can be accessed by a trivial
> two line command.
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-p2v converts physical machines to virtual machines.  Boot with a
> live CD or over the network (PXE) and turn machines into KVM guests.
> http://libguestfs.org/virt-v2v
> ___
> 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



-- 
With best regards, Peter Lemenkov.
___
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: ImageMagick 7 is landing in Rawhide

[Peter Lemenkov]

Hello!
I'll address autotrace compatibility asap. Meanwhile I'll build it
against less functional (but close enough) Graphicsmagick.

On Fri, Jan 6, 2023 at 10:35 PM Neal Gompa  wrote:
>
> Hey all,
>
> The initial rebase of ImageMagick to v7 is landing in Rawhide now:
> https://bodhi.fedoraproject.org/updates/FEDORA-2023-9d3e9afbfd
>
> Most packages in the reverse dependency chain were rebuilt, though a
> few are still left to fix and will be addressed separately.
>
> The ones remaining are:
>
> * autotrace (contacting upstream planned)
> * q (dead upstream, orphaned)
> * vdr-scraper2vdr (maybe dead upstream?)
> * vdr-skinnopacity (dead upstream)
> * vdr-tvguide (dead upstream)
>
> Either these will switch to GraphicsMagick or we'll introduce an
> ImageMagick6 compatibility package for them.
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://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



-- 
With best regards, Peter Lemenkov.
___
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: Self Introduction: Hussein K.

[Peter Lemenkov]

Hello!
It's always nice for me to see more people with GIS background!

On Fri, Dec 16, 2022 at 3:16 PM  wrote:
>
> Hello everyone
>
>
> This mail should serve as my self introduction to the devel community.
>
> I am a (soon to be) computer science graduate, that has been working
> in the Linux / open source world for about 6 years. I first started working
> as a python developer in the GIS (geographic information system) domain.
> After some time I also began to perform some system administration tasks.
> And before I knew I started to do a bit of everything.
> So to describe my current work, I do
>
> - Python development
> - System administration
> - Kubernetes administration (or whatever you want to call it)
> - A little bit of javascript
> - Devops (Automatic deployments via CI / CD pipelines, mainly using
> Gitlab CI)
>
> Oh, I also picked up rust a couple years ago and have been using it for
> Uni and
> private projects.
>
> Now the reason for why I want to get more involved in the Fedora package
> maintainer community
> is because I want to get a better understanding on how applications are
> packaged and
> distributed to end-users in a secure and stable manner.
> And from my experience, the best way to learn, is to get your hands dirty.
> Naturally, I also want to give back to the community, that has doing amazing
> work at developing Fedora and keeping everything working, and I want to
> become a part of it.
>
>
> In the last week, I have been reading a lot of documentation on RPM
> packaging
> and I have created my first package. I am currently looking for a sponsor
> to help me with my first package review:
> https://bugzilla.redhat.com/show_bug.cgi?id=2154124
>
>
> This concludes my introduction and I hope this was not too much to read :D
>
>
> Best wishes
> Hussein K.
> ___
> 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



-- 
With best regards, Peter Lemenkov.
___
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: Self Introduction: Sergey Mende

[Peter Lemenkov]

Hello Sergey,
Welcome aboard.

вт, 13 сент. 2022 г. в 09:25, Sergey Mende :
>
> Hello, everybody.
>
> My name is Sergey Mende and I am from Saint-Petersburg, Russia. I am a 
> software engineer for 35 years, presently retired. I have been working for 
> several companies during my working life mostly in embedded software 
> development area, the most famous is EMC (presently Dell).
>
> I the past I used to contribute to the OSS development by providing patches 
> for a few packages I have been having issues with.
>
> Recently I updated my system to FC36 and found that the `camotics` package, 
> abandoned a few years ago, won't install anymore without rebuild. So, I 
> updated the spec to the most recent codebase and now I would like to share my 
> efforts with Fedora fellow users. I will be glad if someone sponsor my 
> membership in packager group for this purpose (see rhbz 2126323)
>
>
> Looking forward to collaborate with Fedora developers community
> ___
> 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



-- 
With best regards, Peter Lemenkov.
___
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

Review swap: a port compiler plugin for Rebar3

[Peter Lemenkov]

Hello All!
This spec is actually quite simple - it does all the heavy lifting
with generic Erlang macros, builds cleanly, so it won't take you long

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

I am willing to review something which got stuck in your queue for a while.

-- 
With best regards, Peter Lemenkov.
___
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: [HEADS UP] wxGTK 3.2.0 in Rawhide

[Peter Lemenkov]

Hey!
Sure I'll rebuild it soon

вт, 26 июл. 2022 г. в 04:18, Scott Talbert :
>
> At long last wxWidgets 3.2.0 has been released and I'm getting it into
> Rawhide.  This comes with an soname bump (but this should be the last one
> as 3.2.x should now be ABI stable).
>
> NOTE: users of wxWidgets 3.0 (wxGTK3 package) are now strongly encouraged
> to move their packages to use wxWidgets 3.2.
>
> I've rebuilt these existing users in a side tag (f37-build-side-7):
> - CubicSDR
> - audacity
> - wxmacmolplot
>
> I see that erlang also snuck in as a user recently.  :)  @Peter, can you
> please rebuild erlang in side tag f37-build-side-7?  It should rebuild
> fine without any changes (I tested in copr).
>
> Thanks,
> Scott



-- 
With best regards, Peter Lemenkov.
___
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: Self Introduction: Pavel Odintsov

[Peter Lemenkov]

Hey Pavel,
Welcome aboard!

сб, 28 мая 2022 г. в 15:33, Pavel Odintsov :
>
> Hello, Fedora developer community!
>
> My name is Pavel Odintsov and I'm a software engineer with a passion for 
> computer networks. I'm author of FastNetMon Community, a tool for lightning 
> fast volumetric DDoS attack detection.
>
> My software engineering skills are most solid around C++ with a deep 
> understanding of Go accompanied by Perl for text processing.
>
> My area of interest includes basic network protocols such as Ethernet, IPv4, 
> IPv6, TCP, UDP, BGP, Netflow, IPFIX, sFlow,
>
> I have experience in high speed network traffic processing as it's a crucial 
> part of FastNetMon's traffic processing core.
>
> I'm very open for communications and I use plenty of channels and you can 
> contact me using email or LinkedIN: https://www.linkedin.com/in/podintsov/
>
> I would like to add FastNetMon to official Fedora packages to move the 
> experience of using our tool to the next level.
>
> Thank you!
>
> --
> Sincerely yours, Pavel Odintsov
> ___
> 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



-- 
With best regards, Peter Lemenkov.
___
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: asterisk (FTBFS, upgrade)

[Peter Lemenkov]

Hello!
I'd say we need to move forward with it. Looks good to me.

вт, 26 апр. 2022 г. в 10:07, Michal Josef Spacek :
>
> Hi all,
>
> We have asterisk FTBFS for long time
> (https://bugzilla.redhat.com/show_bug.cgi?id=1977579)
> And we have asterisk not upgraded for long time.
> We have many of CVEs in bugzilla (mostly fixed in upstream).
>
> I prepared PR for fix and upgrade of 18 version in rawhide.
> (https://src.fedoraproject.org/rpms/asterisk/pull-request/15)
> Is there someone who could review or/and move forward this package?
>
> Kind regards,
> Michal Josef Špaček
> ___
> 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



-- 
With best regards, Peter Lemenkov.
___
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: strange ppc64le failures

[Peter Lemenkov]

Thanks, now I can see what's wrong here!
So I am going to update gnulib to something more recent starting from F-36

вт, 22 февр. 2022 г. в 19:01, Jakub Jelinek :
>
> On Thu, Feb 17, 2022 at 07:49:45PM +0100, Peter Lemenkov wrote:
> > Hello,
> > I've got a very suspiciously looking compilation issues while building
> > PSPP package. All other arches are good except for ppc64le. Just grep
> > for "error:" in the log attached.
> >
> > * https://koji.fedoraproject.org/koji/taskinfo?taskID=82939449
> > * https://kojipkgs.fedoraproject.org//work/tasks/9583/82939583/build.log
> > (ppc64le build log)
> >
> > Is it a known issue or something new?
>
> That typically means using old gnulib headers which contained a copy of
> what glibc did, but weren't updated to what glibc does now.
>
> See https://bugzilla.redhat.com/show_bug.cgi?id=2044656 for more details.
>
> Jakub
> ___
> 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



-- 
With best regards, Peter Lemenkov.
___
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

strange ppc64le failures

[Peter Lemenkov]

[resent w/o 500+ kBytes file attached]

Hello,
I've got a very suspiciously looking compilation issues while building
PSPP package. All other arches are good except for ppc64le. Just grep
for "error:" in the build log.

* https://koji.fedoraproject.org/koji/taskinfo?taskID=82939449
* https://kojipkgs.fedoraproject.org//work/tasks/9583/82939583/build.log
(ppc64le build log)

Is it a known issue or something new?


-- 
With best regards, Peter Lemenkov.
___
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: Self Introduction: Stewart Smith

[Peter Lemenkov]

Hello Stewart! Welcome. Hope you will like it.

чт, 20 янв. 2022 г. в 19:50, Stewart Smith via devel
:
>
> Hi there, I’m Stewart, a Principal Engineer at AWS working on Amazon
> Linux, and thanks to our new direction in basing Amazon Linux on Fedora,
> also Fedora.
>
> I have a (decently) long time Linux history, remembering Slackware 3.5
> on floppies, RedHat (not RHEL) 5 from CD-ROM, MkLinux, and YellowDog
> (yay PowerPC). I’ve spent the vast bulk of my carreer around the free
> software ecosystem, having spent a long time in the MySQL community, and
> more recently OpenPOWER, and now working on Amazon Linux.
>
> I have a few areas of interest that I’d personally love to contribute
> around and see progress in the Fedora ecosystem. The idea of atomic
> updates and rollback with systems like rpm-ostree is quite fascinating
> from an operational point of view (my personal desktop is currently
> running Silverblue), and likely fits really well with the versioned (and
> version locked) repositories we’re doing with Amazon Linux 2022 and
> beyond. I also think there’s a lot of interesting supply chain assurance
> we can do to ensure continual and increased confidence in the open source
> ecosystem and way of development. Then there’s things like performance,
> boot times (including time-to-first-useful-work), image based
> deployments (who needs an installer when you can have cloud-init or
> similar to init things). So, that's a few areas of interest :)
>
> With my AWS hat on, I’m pretty excited to see what we do over the coming
> years with Fedora and Amazon Linux, and growing the number of people who
> have working on Fedora as part of their day job (and yes, we're hiring).
> ___
> 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



-- 
With best regards, Peter Lemenkov.
___
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: I quit packaging

[Peter Lemenkov]

Volker, thank you very much for maintaining such a huge list of
scientific packages. I am certain lot of people are deeply grateful
for your efforts.  I personally know students who use Fedora and
software you've maintained in their studies and post-doc research.

вс, 12 дек. 2021 г. в 23:08, Volker Fröhlich :
>
> I don't want to be a package maintainer anymore.
>
> All of my packages are up for grabs.
>
> Volker (FAS volter)
> ___
> 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



-- 
With best regards, Peter Lemenkov.
___
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: Trying to reach "python-sqlobject" maintainer - Peter Lemenkov

[Peter Lemenkov]

Hello!
Sorry - totally missed that one. I've just merged this PR.
It's intended only for F-35, am I right?

вс, 2 мая 2021 г. в 01:54, Michal Schorm :
>
> Hello,
>
> As a part of the initiative of replacing "python-mysql" package by
> "python-mysqlclient" package, we tried to fill PRs to the packages to
> switch to the new implementation. [1]
>
> We filed PR against the "python-sqlobject" package [2], however even
> though the maintainer committed since then to the package, he hasn't
> responded to the PR.
>
> Hope this message will reach him and the request will be taken care of.
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1929101
> [2] https://src.fedoraproject.org/rpms/python-sqlobject/pull-request/1
>
> --
>
> Michal Schorm
> Software Engineer
> Core Services - Databases Team
> Red Hat
>
> --
>


-- 
With best regards, Peter Lemenkov.
___
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

[Heads up] python-sqlobject upgrade from 3.3.0 to 3.9.1

[Peter Lemenkov]

Hello!
Turned out that some basic functionality no longer wiorks even with
python3.9  available in Fedora 33 (see rhbz #1896975). I am going to
upgrade it up to 3.9.1 version where compatibility with Python3 is
ensured. I will upgrade Rawhide, F-34 branches.

Despite of a version gap should be a compatible upgrade but still.
Looks like we don't have any affected packages in a repo.

-- 
With best regards, Peter Lemenkov.
___
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

[heads up] libgsasl upgrade from 1.8.1 to 1.10.0

[Peter Lemenkov]

Hello!
I am going to upgrade libgsasl for Fedora 35.  The last version
available in Fedora 1.8.1 is more than 9 years old so it's time to
move up. It should be backwards-compatible upgrade but still it's a 9
years gap so beware.

Potentially affected packages:

erlang-esasl-0:0.1-29.20120116git665cc80.fc32.x86_64
exim-0:4.94-3.fc33.x86_64
gsignond-plugin-sasl-0:0-0.10.2017.git671022f.fc33.x86_64
jabberd-0:2.6.1-15.fc33.x86_64
jreen-0:1.2.1-18.fc33.x86_64
libinfinity-0:0.7.1-10.fc33.x86_64
msmtp-0:1.8.10-2.fc33.x86_64
pokerth-0:1.1.2-13.fc33.x86_64
tin-0:2.4.5-3.fc33.x86_64


-- 
With best regards, Peter Lemenkov.
___
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: Jami (formerly Ring) P2P softphone packaging?

[Peter Lemenkov]

Hello All!
Regarding Jami - looks like this is the last opensource SIP-client
around which works out-of-the box (no need for extra patches for
recent versions of various libraries, local rebuilds, or git knowledge
required). I use it for SIP testing (OpenSIPS, Kamailio, SEMS,
Asterisk servers) and so far it works as expected. Few glitches here
and there but I overall it's great. Considering how bad is the current
situation with desktop clients for Voice and Video communications I
would say it's a promising project.

I didn't test P2P because nobody (around me) is using it. All my
contacts are either in FB, Telegram, or Signal.

пн, 1 февр. 2021 г. в 19:49, Daniel Pocock :
>
>
> Has anybody tested the Jami softphone from Savoir-Faire Linux?  It was
> formerly known as Ring.
>
> They distribute RPMs directly from the web site[1].  It is already[2] in
> Debian for some time.
>
> They distribute[3] their DHT as a library, OpenDHT, for use in other
> projects.
>
> Regards,
>
> Daniel
>
> 1. https://jami.net/
> 2. https://packages.qa.debian.org/r/ring.html
> 3. https://github.com/savoirfairelinux/opendht
> ___
> 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



-- 
With best regards, Peter Lemenkov.
___
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: Orphaned packages looking for new maintainers

[Peter Lemenkov]

пн, 11 янв. 2021 г. в 16:24, Marius Schwarz :
>
> Am 11.01.21 um 16:07 schrieb Vitaly Zaitsev via devel:
> > On 11.01.2021 14:43, Peter Lemenkov wrote:
> >> XMPP-based and it looks like XMPP days
> >> are numbered.
> >
> > XMPP is alive. I maintain 2 XMPP clients in Fedora.
> >
>
> I just tried Jitsi latest Build 5633 on Fedora 32 and it started and run
> ... for approximatly 10 seconds before it crashed :)

So right now we don't have a opensource VoIP client application for
SIP/XMPP networks in Fedora as far as I know.

I guess everyone is betting on Web-based desktop clients relying on
WebRTC so standalone clients are going to fade away.

-- 
With best regards, Peter Lemenkov.
___
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: Orphaned packages looking for new maintainers

[Peter Lemenkov]

Didn't touch Jitsi for a while but their Git repository looks active:

https://github.com/jitsi/jitsi

The problem is that Jitsi is XMPP-based and it looks like XMPP days
are numbered.

пн, 11 янв. 2021 г. в 14:16, Marius Schwarz :
>
> Am 11.01.21 um 13:56 schrieb Peter Lemenkov:
> > We'd better have Jitsi (Java-based, beware!) ...  in repos.
>
> Jitsi is dead too :(
>
>
> In opposition to ekiga, Jitsi still works as expected.
>
> best regards,
> Marius
> ___
> 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



-- 
With best regards, Peter Lemenkov.
___
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: Orphaned packages looking for new maintainers

[Peter Lemenkov]

пн, 11 янв. 2021 г. в 13:10, Antonio T. sagitter :
>
> On 11/01/21 11:47, Peter Lemenkov wrote:
> > Taking opal, ptlib
> >
> > пн, 11 янв. 2021 г. в 11:37, Miro Hrončok :
> >>
> >> ekiga mcrha, orphan5 weeks 
> >> ago
>
> I'm taking Ekiga.
> It would be a shame letting die the rpm.

Might not be a good idea. Ekiga is dead long time ago, lacks behind
standards and RFCs, and might not be usable in some modern cases. I
personally advice you to let it go and look around for modern
alternatives.

We'd better have Jitsi (Java-based, beware!) or Jami in repos.

-- 
With best regards, Peter Lemenkov.
___
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: Orphaned packages looking for new maintainers

[Peter Lemenkov]

ython-requests_ntlm, python-ntlm-auth, python-winrm
> chimosky: sugar-starchart
> cicku: msv
> clime: python-requests_ntlm, python-ntlm-auth, python-winrm
> coolsvap: apache-log4j-extras
> copr-sig: python-requests_ntlm, python-ntlm-auth, python-winrm
> cwickert: nodoka-theme-gnome
> davidsch: msv
> dbhole: msv
> decathorpe: msv
> defolos: grpc
> dmaphy: msv
> dmick: grpc
> dperpeet: python-requests_ntlm, python-ntlm-auth, python-winrm
> dturecek: python-requests_ntlm, python-ntlm-auth, python-winrm
> eclipse-sig: msv
> elsupergomez: banshee-community-extensions, boo
> fab: grpc
> fale: msv
> fantom: msv
> fbo: python-requests_ntlm, python-ntlm-auth, python-winrm
> filiperosset: msv
> frostyx: python-requests_ntlm, python-ntlm-auth, python-winrm
> gil: msv, apache-log4j-extras
> godas: python-requests_ntlm, python-ntlm-auth, python-winrm
> gordonmessmer: python-requests_ntlm, python-ntlm-auth, python-winrm
> greghellings: python-requests_ntlm, python-ntlm-auth, python-winrm
> hguemar: python-pykafka
> hubbitus: msv
> ignatenkobrain: python-requests_ntlm, python-ntlm-auth, python-winrm
> infra-sig: python-requests_ntlm, python-ntlm-auth, python-winrm
> java-maint-sig: msv
> jcline: msv
> jjohnstn: msv
> jkaluza: msv
> jpena: python-pykafka
> jreznik: msv
> jskarvad: msv
> jwrdegoede: msv
> kdaniel: msv
> kde-sig: msv
> ke4qqq: grpc
> kevin: python-requests_ntlm, python-ntlm-auth, python-winrm
> kkeithle: grpc
> ktdreyer: grpc
> limb: msv
> lkundrak: msv
> louizatakk: msv
> lupinix: msv
> maha: msv
> martinkg: msv
> mbooth: msv
> mcrha: ptlib, ekiga, msv, opal
> melmorabity: python-requests_ntlm, python-ntlm-auth, grpc, python-winrm
> merlinm: python-requests_ntlm, python-ntlm-auth, python-winrm
> mgoodwin: python-requests_ntlm, python-ntlm-auth, python-winrm
> mizdebsk: msv
> mkutlak: pg-semver
> mlichvar: msv
> mmorsi: msv
> mmraka: msv
> moceap: msv
> mso: nodoka-theme-gnome
> msuchy: python-requests_ntlm, python-ntlm-auth, python-winrm
> mtasaka: msv
> nathans: python-requests_ntlm, python-ntlm-auth, python-winrm
> nodejs-sig: nodejs-svgo, nodejs-shelljs
> nonamedotc: nodoka-theme-gnome
> nosnilmot: msv
> nucleo: msv
> openstack-sig: python-requests_ntlm, python-ntlm-auth, python-winrm
> otaylor: msv
> pabelanger: msv
> patches: nodejs-shelljs
> perl-maint-sig: grpc
> peter: msv
> pfrields: ptlib, opal
> pnemade: python-requests_ntlm, python-ntlm-auth, python-winrm
> ppisar: grpc, msv
> praiskup: python-requests_ntlm, python-ntlm-auth, python-winrm
> psss: python-requests_ntlm, python-ntlm-auth, python-winrm
> radez: python-requests_ntlm, python-ntlm-auth, python-winrm
> rdieter: msv
> rebus: msv
> rgrunber: msv
> richardfearn: msv
> robert: msv
> sac: python-requests_ntlm, python-ntlm-auth, python-winrm
> sdgathman: msv
> sharkcz: msv
> simonp: csync2
> slankes: msv
> smani: msv
> spstarr: msv
> steve: grpc, msv
> stingray: grpc
> tc01: msv
> tdawson: msv
> tdecacqu: python-requests_ntlm, python-ntlm-auth, python-winrm
> than: msv
> thm: msv
> toshio: python-requests_ntlm, python-ntlm-auth, python-winrm
> tpokorra: banshee-community-extensions, boo
> vascom: msv
> veillard: ptlib
> wakko666: python-requests_ntlm, python-ntlm-auth, python-winrm
> wart: msv
> wzzrd: python-requests_ntlm, python-ntlm-auth, python-winrm
> xvitaly: msv
> zbyszek: msv
> zuul: python-requests_ntlm, python-ntlm-auth, python-winrm
>
> --
> The script creating this output is run and developed by Fedora
> Release Engineering. Please report issues at its pagure instance:
> https://pagure.io/releng/
> The sources of this script can be found at:
> https://pagure.io/releng/blob/master/f/scripts/find_unblocked_orphans.py



-- 
With best regards, Peter Lemenkov.
___
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: Orphaned packages looking for new maintainers

[Peter Lemenkov]

I'll took couchdb

пн, 30 нояб. 2020 г. в 12:13, Miro Hrončok :
>
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
>
> Note: If you received this mail directly you (co)maintain one of the affected
> packages or a package that depends on one. Please adopt the affected package 
> or
> retire your depending package to avoid broken dependencies, otherwise your
> package will be retired when the affected package gets retired.
>
> Request package ownership via the *Take* button in he left column on
> https://src.fedoraproject.org/rpms/
>
> Full report available at:
> https://churchyard.fedorapeople.org/orphans-2020-11-30.txt
> grep it for your FAS username and follow the dependency chain.
>
> For human readable dependency chains, see 
> https://packager.fedorainfracloud.org/
> For all orphaned packages, see https://packager.fedorainfracloud.org/orphan
>
>  Package  (co)maintainers   Status 
> Change
> 
> RxCpp orphan   1 weeks ago
> ansible-collection-community- orphan   4 weeks ago
> general
> apivizlef, orphan  1 weeks ago
> apper kde-sig, orphan, rhughes 1 weeks ago
> atanuaorphan   0 weeks ago
> bfast orphan   1 weeks ago
> biblesync cicku, orphan1 weeks ago
> bifcl orphan   1 weeks ago
> bmon  orphan   1 weeks ago
> celt071   orphan   5 weeks ago
> colorhug-client   orphan   2 weeks ago
> cook  orphan   1 weeks ago
> coolreaderorphan   1 weeks ago
> couchdb   orphan   1 weeks ago
> cros-guest-tools  orphan   2 weeks ago
> dc3dd maxamillion, orphan  1 weeks ago
> dep   go-sig, orphan   1 weeks ago
> discord-irc   orphan   4 weeks ago
> dnscaporphan   5 weeks ago
> dnsjava   orphan   1 weeks ago
> dumb-init orphan   1 weeks ago
> dynaplugz orphan   1 weeks ago
> edb   orphan   1 weeks ago
> elasticdump   orphan   4 weeks ago
> electric  blackfile, orphan1 weeks ago
> eyesight  cicku, orphan, plfiorini 1 weeks ago
> fedora-developer-portal   orphan   3 weeks ago
> fifechan  orphan   1 weeks ago
> fillets-ngorphan, thias1 weeks ago
> flaconignatenkobrain, orphan   1 weeks ago
> fmpp  orphan   1 weeks ago
> freerdp1.2orphan   0 weeks ago
> freetiger orphan   1 weeks ago
> gaupolmmraka, orphan   1 weeks ago
> ghc-pipes-safeorphan   4 weeks ago
> glyr  orphan   1 weeks ago
> gmpc  orphan   1 weeks ago
> gnome-code-assistance elad, orphan 1 weeks ago
> gnome-documents   anujmore, cosimoc, gnome-sig,1 weeks ago
>orphan
> golang-contrib-opencensus-go-sig, orphan   1 weeks ago
> exporter-ocagent
> golang-github-casbin  go-sig, orphan   0 weeks ago
> golang-k8s-kubernetes go-sig, orphan   1 weeks ago
> gridftp-ifce  orphan   1 weeks ago
> gtatool   orphan   4 weeks ago
> guacamole-server  orphan   0 weeks ago
> 

Re: Orphaned packages looking for new maintainers (hundreds of freshly orphaned F33FTBFS)

[Peter Lemenkov]

I'll take couchdb, fop, erlang-corba, erlang-lager

пн, 23 нояб. 2020 г. в 10:31, Miro Hrončok :
>
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
>
> Note: If you received this mail directly you (co)maintain one of the affected
> packages or a package that depends on one. Please adopt the affected package 
> or
> retire your depending package to avoid broken dependencies, otherwise your
> package will be retired when the affected package gets retired.
>
> Request package ownership via the *Take* button in he left column on
> https://src.fedoraproject.org/rpms/
>
> Full report available at:
> https://churchyard.fedorapeople.org/orphans-2020-11-23.txt
> grep it for your FAS username and follow the dependency chain.
>
> For human readable dependency chains, see 
> https://packager.fedorainfracloud.org/
> For all orphaned packages, see https://packager.fedorainfracloud.org/orphan
>
>  Package  (co)maintainers   Status 
> Change
> 
> Pencil2D  lbazan, orphan   0 weeks ago
> RxCpp orphan   0 weeks ago
> ansible-collection-community- orphan   3 weeks ago
> general
> apivizlef, orphan  0 weeks ago
> apper kde-sig, orphan, rhughes 0 weeks ago
> bfast orphan   0 weeks ago
> biblesync cicku, orphan0 weeks ago
> bifcl orphan   0 weeks ago
> bmon  orphan   0 weeks ago
> celt071   orphan   4 weeks ago
> colorhug-client   orphan   1 weeks ago
> compat-guile18jskarvad, mlichvar, orphan,  3 weeks ago
>tkorbar
> cook  orphan   0 weeks ago
> coolreaderorphan   0 weeks ago
> couchdb   orphan   0 weeks ago
> cpulimit  orphan   0 weeks ago
> cros-guest-tools  orphan   1 weeks ago
> dc3dd maxamillion, orphan  0 weeks ago
> dep   go-sig, orphan   0 weeks ago
> discord-irc   orphan   3 weeks ago
> dnscaporphan   4 weeks ago
> dnsjava   orphan   0 weeks ago
> dumb-init orphan   0 weeks ago
> dynaplugz orphan   0 weeks ago
> edb   orphan   0 weeks ago
> elasticdump   orphan   3 weeks ago
> electric  blackfile, orphan0 weeks ago
> electrum  orphan   4 weeks ago
> erlang-corba  orphan   0 weeks ago
> erlang-lager  bowlofeggs, orphan   0 weeks ago
> eyesight  cicku, orphan, plfiorini 0 weeks ago
> fedora-developer-portal   orphan   2 weeks ago
> fifechan  orphan   0 weeks ago
> fillets-ngorphan, thias0 weeks ago
> flaconignatenkobrain, orphan   0 weeks ago
> fmpp  orphan   0 weeks ago
> fossilorphan   0 weeks ago
> freetiger orphan   0 weeks ago
> gaupolmmraka, orphan   0 weeks ago
> ghc-pipes-safeorphan   3 weeks ago
> glyr  orphan   0 weeks ago
> gmpc  orphan   0 weeks ago
> gnome-code-assistance elad, orphan 0 weeks ago
> gnome-documents   anujmore, cosimoc, gnome-sig,0 weeks ago
>orphan
> 

Re: AAC-Main patent expiration

[Peter Lemenkov]

We do have FDK-AAC-Free imported for a while. Some functionality was
patched out due to various concerns:

*https://src.fedoraproject.org/rpms/fdk-aac-free
* https://cgit.freedesktop.org/~wtay/fdk-aac/log/?h=fedora

вт, 17 нояб. 2020 г. в 16:42, Igor Bukanov :
>
> AAC-Main audio encoder/decoder profile was specified as a part of  
> https://www.iso.org/standard/25035.html standard. That was published in 
> December 1999. Does it mean that software implementing it like ffmpeg in its 
> default configuration can be included into Fedora starting from January 2021?
>
> Regards, Igor
> ___
> 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



-- 
With best regards, Peter Lemenkov.
___
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: Presentation

[Peter Lemenkov]

Hello Yann!

ср, 27 мая 2020 г. в 15:05, :
>
> Hello,
>
> I just registered the Fedora devel list.
> My name is Yann Collette.
> I use Fedora distribution since ... (I started with a Linux 1.2.7 :) and stay 
> attached to Redhat / Fedora for a lng time).
> I use Fedora for music production and I manage a Fedora COPR repo to provide 
> tools related to music:
>
> https://copr.fedorainfracloud.org/coprs/ycollet/linuxmao/
>
> All the spec files are on github:
>
> https://github.com/ycollet/fedora-spec


Wow! That's a substantial amount of work! Well done!

> If you're are looking for people to help packaging and maintaining packages, 
> I can help.

As a person who is interested in a similarly obscure use cases I'd
like to propose you a different way. Instead of waiting for someone
who pops up and asks you for help with packaging you'd better to step
in and start adding packages to Fedora and helping with existing ones.
From my experience people are more likely to act when something big is
going already. And the amount of packages you're dealing with is
already huge!

We can guide you with all technical details related to adding rpms to
Fedora repos.
-- 
With best regards, Peter Lemenkov.
___
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: Self Introduction: Artem Egorenkov

[Peter Lemenkov]

Hello Artem,
Speaking of Java - Java SIG also wants help. Just fyi :)

чт, 19 мар. 2020 г. в 17:35, Artem Egorenkov :
>
> Hi,
>
> My name is Artem Egorenkov. I recently joined Red Hat in Brno, Czech Republic.
> I worked as a Software Developer for around 7 years and most of my experience 
> relates to Java stack, and now I have decided to start in a system 
> development field.
>
> I don't have much experience in open source development, but I'm willing to 
> get it.
>
> I recently became a maintainer of "stabby" package, which was separated from 
> "getdns".
>
> Thanks,
> Artem
> ___
> 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



-- 
With best regards, Peter Lemenkov.
___
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: Will orphan packages with NEW F31FTBFS bugs tomorrow

[Peter Lemenkov]

> ocaml-json-static
> ocaml-mikmatch
> ocaml-openin
> ocaml-pa-monad
> ocaml-pgocaml
> ocaml-sexplib
> ocaml-type-conv
> ocamldsort
> ohc
> paulstretch
> perdition
> pesign
> pesign-test-app
> plasma-sdk
> pyexiv2
> python-bashate
> python-cattrs
> python-cloudservers
> python-gfm
> python-jira
> python-k8sclient
> python-pyopencl
> python-subunit2sql
> redeclipse
> reg
> resiprocate
> rgbds
> rubygem-cookiejar
> rubygem-hiredis
> sassc
> scamper
> scilab
> sqlite2
> swt-chart
> tycho
> tycho-extras
> ugene
> utop
> zanshin
> zathura-cb
> zathura-djvu
> zathura-pdf-mupdf
> zathura-pdf-poppler
> zathura-ps
> zookeeper
>
> This is coordinated (I'm talking to myself) in this releng ticket:
> https://pagure.io/releng/issue/8917
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> 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



-- 
With best regards, Peter Lemenkov.
___
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: Will orphan packages with NEW F31FTBFS bugs tomorrow

[Peter Lemenkov]

> ocaml-json-static
> ocaml-mikmatch
> ocaml-openin
> ocaml-pa-monad
> ocaml-pgocaml
> ocaml-sexplib
> ocaml-type-conv
> ocamldsort
> ohc
> paulstretch
> perdition
> pesign
> pesign-test-app
> plasma-sdk
> pyexiv2
> python-bashate
> python-cattrs
> python-cloudservers
> python-gfm
> python-jira
> python-k8sclient
> python-pyopencl
> python-subunit2sql
> redeclipse
> reg
> resiprocate
> rgbds
> rubygem-cookiejar
> rubygem-hiredis
> sassc
> scamper
> scilab
> sqlite2
> swt-chart
> tycho
> tycho-extras
> ugene
> utop
> zanshin
> zathura-cb
> zathura-djvu
> zathura-pdf-mupdf
> zathura-pdf-poppler
> zathura-ps
> zookeeper
>
> This is coordinated (I'm talking to myself) in this releng ticket:
> https://pagure.io/releng/issue/8917
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> 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



--
With best regards, Peter Lemenkov.
___
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

The same RPM macro but different value for arch/noarch builds - how?

[Peter Lemenkov]

Hello All,
We have a set of macros for Erlang libraries rpm building. Some of
these macros evaliated before actual build (if I understand RPM build
process correctly) and their actual value depends on a type of a
package - arch-dependent or noarch.

Previously we've used %{buildarch} macro to distinguish between
noarch-packages and arch-specific and that  worked well enough.
Unfortunately this macro was removed recently.

Is there a way to pass "noarch" to some scripts from
/usr/lib/rpms/macros.d when building noarch package? Spec-file was
marked already as BuildArch: noarch. Where this information is stored
now?

-- 
With best regards, Peter Lemenkov.
___
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

Cannot add a user to a package as a comaintainer

[Peter Lemenkov]

Hello!
I've just stumbled with a problem - I've sponsored a person to
packagers group (several hours ago) but still cannot add that person
as a comaintainer using account's name in src.fedoraproject.org. Did I
miss something or I just need to wait a bit more?

-- 
With best regards, Peter Lemenkov.
___
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: RPM building on s390x sometimes is very slow on F-30+

[Peter Lemenkov]

Hello All,

I've just got hit by this again - lockups on s390. Looks like I have
100% reproducer (just try to build Erlang and it will stuck
eventually).

* https://koji.fedoraproject.org/koji/taskinfo?taskID=37327589

Where should I open a ticket? Bugzilla.redhat.com or somewhere else?

чт, 25 июл. 2019 г. в 17:44, Kevin Fenzi :
>
> On 7/25/19 3:04 AM, Peter Lemenkov wrote:
> > Hello All!
> > It started to get stuck again. Right now I'm experiencing this issue
> > with RabbitMQ for F-30 and F-31:
> >
> > * https://koji.fedoraproject.org/koji/taskinfo?taskID=36457376
> > * https://koji.fedoraproject.org/koji/taskinfo?taskID=36457345
>
> So, yeah.
>
> >   |   |-kojid,31279 /usr/sbin/kojid --fg --force-lock --verbose
> >   |   |   `-mock,31584 -tt /usr/libexec/mock/mock -r 
> > koji/f30-build-16961487-1222718 --old-chroot --no-clean --target s390x ...
> >   |   |   `-rpmbuild,32205 -bb --target s390x --nodeps 
> > /builddir/build/SPECS/rabbitmq-server.spec
> >   |   |   `-sh,32237 -e /var/tmp/rpm-tmp.GwzEQt
> >   |   |   `-make,32238 -j4 VERSION=3.7.16 V=1
> >   |   |   `-sh,32318 -c...
> >   |   |   `-make,2112 -C 
> > /builddir/build/BUILD/rabbitmq-server-3.7.16/deps/amqp10_client IS_DEP=1
> >   |   |   `-make,2237 --no-print-directory app-build
> >   |   |   `-beam.smp,2302 -sbtu -A0 -- -root 
> > /usr/lib64/erlang -progname erl -- -home /builddir -- ...
> >   |   |   |-{beam.smp},2303
> >   |   |   |-{beam.smp},2304
> >   |   |   |-erl_child_setup,2305 1024
> >   |   |   |-{beam.smp},2306
> >   |   |   |-{beam.smp},2307
> >   |   |   |-{beam.smp},2308
> >   |   |   |-{beam.smp},2309
> >   |   |   |-{beam.smp},2310
> >   |   |   |-{beam.smp},2311
> >   |   |   |-{beam.smp},2312
> >   |   |   |-{beam.smp},2313
> >   |   |   |-{beam.smp},2314
> >   |   |   |-{beam.smp},2315
> >   |   |   |-{beam.smp},2316
> >   |   |   |-{beam.smp},2317
> >   |   |   |-{beam.smp},2318
> >   |   |   |-{beam.smp},2319
> >   |   |   |-{beam.smp},2320
> >   |   |   |-{beam.smp},2321
> >   |   |   |-{beam.smp},2322
> >   |   |   |-{beam.smp},2323
> >   |   |   |-{beam.smp},2324
> >   |   |   `-{beam.smp},2325
>
> When I strace the 2302 process:
>
> strace: Process 2302 attached with 23 threads
> [pid  2324] ppoll([{fd=12, events=POLLIN|POLLRDNORM}], 1, NULL, NULL, 8
> 
> [pid  2320] futex(0x3ff58800550, FUTEX_WAIT_PRIVATE, 4294967295, NULL
> 
> [pid  2321] futex(0x3ff58800590, FUTEX_WAIT_PRIVATE, 4294967295, NULL
> 
> [pid  2319] futex(0x3ff58800510, FUTEX_WAIT_PRIVATE, 4294967295, NULL
> 
> [pid  2318] futex(0x3ff588004d0, FUTEX_WAIT_PRIVATE, 4294967295, NULL
> 
> [pid  2317] futex(0x3ff58800490, FUTEX_WAIT_PRIVATE, 4294967295, NULL
> 
> [pid  2316] futex(0x3ff58800450, FUTEX_WAIT_PRIVATE, 4294967295, NULL
> 
> [pid  2315] futex(0x3ff58800410, FUTEX_WAIT_PRIVATE, 4294967295, NULL
> 
> [pid  2313] futex(0x3ff58800390, FUTEX_WAIT_PRIVATE, 4294967295, NULL
> 
> [pid  2312] futex(0x3ff58800350, FUTEX_WAIT_PRIVATE, 4294967295, NULL
> 
> [pid  2308] restart_syscall(<... resuming interrupted
> syscall_0xfdfc ...>  ed ...>
> [pid  2303] read(14,  
> [pid  2302] select(0, NULL, NULL, NULL, NULL 
> [pid  2309] restart_syscall(<... resuming interrupted select ...>
> 
> [pid  2323] futex(0x3ff58800610, FUTEX_WAIT_PRIVATE, 4294967295, NULL
> 
> [pid  2322] futex(0x3ff588005d0, FUTEX_WAIT_PRIVATE, 4294967295, NULL
> 
> [pid  2314] futex(0x3ff588003d0, FUTEX_WAIT_PRIVATE, 4294967295, NULL
> 
> [pid  2311] futex(0x3ff58800310, FUTEX_WAIT_PRIVATE, 4294967295, NULL
> 
> [pid  2310] futex(0x3ff588002d0, FUTEX_WAIT_PRIVATE, 4294967295, NULL
> 
> [pid  2306] restart_syscall(<... resuming interrupted
> syscall_0xfdfc ...>  ed ...>
> [pid  2304] futex(0x2aa3d9af520, FUTEX_WAIT_PRI

Re: RPM building on s390x sometimes is very slow on F-30+

[Peter Lemenkov]

Hello All!
It started to get stuck again. Right now I'm experiencing this issue
with RabbitMQ for F-30 and F-31:

* https://koji.fedoraproject.org/koji/taskinfo?taskID=36457376
* https://koji.fedoraproject.org/koji/taskinfo?taskID=36457345


чт, 11 июл. 2019 г. в 19:14, Kevin Fenzi :
>
> On 7/11/19 4:13 AM, Stephen John Smoogen wrote:
> > On Thu, 11 Jul 2019 at 06:47, Philip Kovacs via devel <
> > devel@lists.fedoraproject.org> wrote:
> >
> >> It's likely the big endian emulation running on little endian machines
> >> which is killing performance.
> >> I also have some time sensitive package tests failing on s390x.
> >>
> >
> > I am a bit confused by what you are saying. Could you restate?  Compilation
> > on s390x happens on native hardware. But are you meaning that the erlang VM
> > is little endian and the big-endian s390x is having to emulate it?
> >
> > We have been having problems with the s390x systems lately due to multiple
> > reasons outside of infrastructure's control. Kevin Fenzi has been working
> > on trying to get a replacement set of builders in place over the last week
> > to try and deal with this. I do not know if your build got stuck on a
> > builder which was transitioning or something similar.
>
> So, yeah, part of this is my fault. :(
>
> If you look at
> https://koji.fedoraproject.org/koji/taskinfo?taskID=36131065
> you will note that there are 4 buildroots listed. That means the build
> was restarted 4 times. Likely this happened when I was
> installing/updating/shuffling builders around there. Sorry about that.
>
> That said, it still should have finished long ago.
>
> The current state of s390x builders:
>
> buildvm-s390x-01 to 14 are all the existing Z/VM instances we have had
> for a long while. Likely we are going to keep them for a while until we
> are sure the kvm instances are reliable and happy.
>
> buildvm-s390x-15 to 24 are new kvm instances. They have a higher
> 'weight' than the others and from my testing are much faster.
>
> Your build seems perhaps stuck in tests?
>
> I've freed it (again) and it's now running on buildvm-s390x-22 (a kvm
> instance). Lets see how it does there. I will in the meantime
> update/reboot the Z/VM instances.
>
> kevin
>
> ___
> 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



-- 
With best regards, Peter Lemenkov.
___
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

RPM building on s390x sometimes is very slow on F-30+

[Peter Lemenkov]

Hello All,
Not sure if it's only me but every time I'm trying to build Erlang on
F-30 or Rawhide it takes forever to complete. It's all started
relatively recently (maybe a month or two). See the following logs for
the example.

* https://koji.fedoraproject.org/koji/taskinfo?taskID=36131019
* https://koji.fedoraproject.org/koji/taskinfo?taskID=36131065 (s390x
task, two days and still work-in-progress)

Does anyone experience the same issue?
-- 
With best regards, Peter Lemenkov.
___
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: Any new restriction in Koji added recently in Rawhide?

[Peter Lemenkov]

Hello!

чт, 13 июн. 2019 г. в 12:49, Petr Pisar :
>
> On 2019-06-13, Peter Lemenkov  wrote:
> > I've noticed that I cannot build Elixir in Rawhide anymore. It got
> > stuck at tests and all I've got is a cryptic (at least to me) message:
> >
> >
> > + RPM_EC=0
> > BUILDSTDERR: ++ jobs -p
> > + exit 0
> >
> F31 has a new rpm-build with a new features. Your issue seems like
> another bug in the same process clean-up code I reported an hour ago.
> See bug #1720143.

Yes, looks exactly like my case. Thanks for the pointing out!


-- 
With best regards, Peter Lemenkov.
___
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

Any new restriction in Koji added recently in Rawhide?

[Peter Lemenkov]

Hello All!
I've noticed that I cannot build Elixir in Rawhide anymore. It got
stuck at tests and all I've got is a cryptic (at least to me) message:


+ RPM_EC=0
BUILDSTDERR: ++ jobs -p
+ exit 0


See this link for full build log:

* https://kojipkgs.fedoraproject.org//work/tasks/8021/35518021/build.log
* https://koji.fedoraproject.org/koji/taskinfo?taskID=35517975

For comparison here is how successful build log for F-30 looks like
(the same package)

* https://kojipkgs.fedoraproject.org//work/tasks/8987/35518987/build.log
* https://koji.fedoraproject.org/koji/taskinfo?taskID=35518984

Are there any differences between Koji settings for Rawhide and F-30
which we should know about? Selinux, resource constraints etc?
-- 
With best regards, Peter Lemenkov.
___
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: Strange C++ error with GCC 9.0.1

[Peter Lemenkov]

Jonathan, thanks for the tip! It works now!

How cool is that we have a lot of experts in almost every aspect of
software development around?


ср, 27 мар. 2019 г. в 17:43, Jonathan Wakely :
>
> On 27/03/19 16:37 +, Jonathan Wakely wrote:
> >On 27/03/19 16:13 +0100, Jakub Jelinek wrote:
> >>On Wed, Mar 27, 2019 at 04:08:59PM +0100, Peter Lemenkov wrote:
> >>>Jakub, thanks for the tip! Now I moved a little further. I've added
> >>>-save-temps to CXXFLAGS and indeed there is something wrong. Here is
> >>>how this cstddef file was included:
> >>>
> >>>===
> >>># 1 "/usr/lib/gcc/x86_64-redhat-linux/9/include/stddef.h" 1 3 4
> >>># 51 "/usr/include/c++/9/cstddef" 2 3
> >>>
> >>>
> >>># 52 "/usr/include/c++/9/cstddef" 3
> >>>  "C++"
> >
> >Wow, somebody did something very silly.
>
> And here it is:
> https://github.com/SIPp/sipp/blob/fc348b8539949b0533a259e81923ed64e22f4657/include/logger.hpp#L10
>
> A less ridiculous way to do that would be:
>
> #ifdef GLOBALS_FULL_DEFINITION
> #define MAYBE_EXTERN
> #define _DEFVAL(value) = value
> #else
> #define MAYBE_EXTERN extern
> #define _DEFVAL(value)
> #endif
>
> and then use MAYBE_EXTERN instead of extern.
>
> The _DEFVAL is also undefined behaviour, because that's a reserved
> name. It should be DEFVAL.
>
>


-- 
With best regards, Peter Lemenkov.
___
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: Strange C++ error with GCC 9.0.1

[Peter Lemenkov]

Jakub, thanks for the tip! Now I moved a little further. I've added
-save-temps to CXXFLAGS and indeed there is something wrong. Here is
how this cstddef file was included:

===
# 1 "/usr/lib/gcc/x86_64-redhat-linux/9/include/stddef.h" 1 3 4
# 51 "/usr/include/c++/9/cstddef" 2 3


# 52 "/usr/include/c++/9/cstddef" 3
  "C++"
{

namespace std
{

  using ::max_align_t;
}
# 197 "/usr/include/c++/9/cstddef" 3
}
# 25 "./include/strings.hpp" 2

===

Note the missing extern pragma before "C++" token.

ср, 27 мар. 2019 г. в 15:58, Jakub Jelinek :
>
> On Wed, Mar 27, 2019 at 03:48:41PM +0100, Peter Lemenkov wrote:
> > I cannot build SIPp anymore. It fails with a very cryptic (for me) message:
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=33763853
> >
> > ```
> > g++ -DHAVE_CONFIG_H -DUSE_OPENSSL -DPCAPPLAY -DRTP_STREAM -DUSE_SCTP
> > -DHAVE_EPOLL -I. -I./include   -D__LINUX -I./include -Wall -pedantic
> > -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> > -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
> > -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
> > -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
> > -c -o src/sipp-sipp.o `test -f 'src/sipp.cpp' || echo
> > './'`src/sipp.cpp
> > In file included from ./include/strings.hpp:24,
> >  from ./include/sipp.hpp:484,
> >  from src/sipp.cpp:41:
> > /usr/include/c++/9/cstddef:52:8: error: expected unqualified-id before
> > string constant
> >52 | extern "C++"
> >   |^
> > make[1]: *** [Makefile:1768: src/sipp-sipp.o] Error 1
> > make[1]: *** Waiting for unfinished jobs
> > make[1]: Leaving directory '/home/petro/rpmbuild/BUILD/sipp-3.5.2'
> > make: *** [Makefile:830: all] Error 2
> > error: Bad exit status from /var/tmp/rpm-tmp.Y5CFt4 (%build)
> > ```
> > ^^^ That's exactly where I'm stuck now. This is how my
> > `/usr/include/c++/9/cstddef` looks like:
> >
> > * 
> > https://github.com/gcc-mirror/gcc/blob/25694c85/libstdc%2B%2B-v3/include/c_global/cstddef
> >
> > And I tend to think that this issue is related to this commit:
> >
> > * 
> > https://github.com/gcc-mirror/gcc/commit/038feca5beacbe36e28680c8e1a8af83ad4996ae
>
> You should look at what comes before that token and from where,
> that might be a reason why the extern "C++" is rejected at that spot.
> So, preprocess it (-save-temps or -E -o src/sipp-sipp.ii) and look in the
> preprocessed dump.  Perhaps cstddef is included in some context where it
> shouldn't be or there are macros redefining extern or similar bogosities.
>
> Jakub
> ___
> 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



-- 
With best regards, Peter Lemenkov.
___
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

Strange C++ error with GCC 9.0.1

[Peter Lemenkov]

Hello All!
I cannot build SIPp anymore. It fails with a very cryptic (for me) message:

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

```
g++ -DHAVE_CONFIG_H -DUSE_OPENSSL -DPCAPPLAY -DRTP_STREAM -DUSE_SCTP
-DHAVE_EPOLL -I. -I./include   -D__LINUX -I./include -Wall -pedantic
-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-c -o src/sipp-sipp.o `test -f 'src/sipp.cpp' || echo
'./'`src/sipp.cpp
In file included from ./include/strings.hpp:24,
 from ./include/sipp.hpp:484,
 from src/sipp.cpp:41:
/usr/include/c++/9/cstddef:52:8: error: expected unqualified-id before
string constant
   52 | extern "C++"
  |^
make[1]: *** [Makefile:1768: src/sipp-sipp.o] Error 1
make[1]: *** Waiting for unfinished jobs
make[1]: Leaving directory '/home/petro/rpmbuild/BUILD/sipp-3.5.2'
make: *** [Makefile:830: all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.Y5CFt4 (%build)
```
^^^ That's exactly where I'm stuck now. This is how my
`/usr/include/c++/9/cstddef` looks like:

* 
https://github.com/gcc-mirror/gcc/blob/25694c85/libstdc%2B%2B-v3/include/c_global/cstddef

And I tend to think that this issue is related to this commit:

* 
https://github.com/gcc-mirror/gcc/commit/038feca5beacbe36e28680c8e1a8af83ad4996ae

-- 
With best regards, Peter Lemenkov.
___
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: dcmtk upgrade on rawhide

[Peter Lemenkov]

No objections here - go on with it.

сб, 2 мар. 2019 г., 20:31 Antonio Trande :

> Hi all.
>
> I prepared a dcmtk-3.6.4 rpm for upgrading this package on f30/rawhide.
> Its dependencies are:
>
> $ dnf repoquery --release rawhide --enablerepo=*-source
> --disablerepo=rpmfusion* --disablerepo=*modular* --whatrequires dcmtk-devel
> Last metadata expiration check: 3:27:58 ago on sab 02 mar 2019 12:40:33
> CET.
> OpenImageIO-0:2.0.5-1.fc30.src
> aeskulap-0:0.2.2-0.37.beta2.fc30.src
> ctk-0:0.1-0.10.20171224git71799c2.fc29.src
> gtatool-0:2.2.0-11.fc28.src
> orthanc-0:1.5.4-1.fc30.src
> vxl-0:1.17.0-29.fc30.src
>
> dcmtk and related deps have been rebuilt on a dedicated Copr space:
> https://copr.fedorainfracloud.org/coprs/sagitter/ForTesting/builds/
>
> OpenImageIO is OK
>
> aeskulap-0:0.2.2 does not built for a known bug
> (https://github.com/jenslody/aeskulap/issues/14)
>
> ctk updated si OK
>
> gtatool-2.2.2 compile but some tests are failing (upstream informed)
>
> orthanc is OK
>
> vxl is OK
>
> --
> ---
> Antonio Trande
> Fedora Project
> mailto 'sagitter at fedoraproject dot org'
> GPG key: 0x6e0331dd1699e4d7
> GPG key server: https://keys.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: Orphaning mozjs52

[Peter Lemenkov]

Hello All!

I'm working on moving erlang-js to mozjs60 so I don't have any
objections on abandoning mozjs52.

пн, 18 февр. 2019 г. в 12:48, Kalev Lember :
>
>
> Hi all,
>
> All of GNOME and the core desktop stack (gjs, polkit, libproxy etc) are
> ported from mozjs52 to mozjs60 in rawhide/F30 and I'd like to orphan
> mozjs52 or transfer its ownership to someone interested in taking care
> of it.
>
> mozjs52 has two remaining packages linking to it, according to repoquery:
>
> cjs-4.0.0-4.fc30.src.rpm
> erlang-js-1.9.0-2.fc30.src.rpm
>
> Leigh, Peter (CC'd), are either of you interested in taking over
> mozjs52? I can reassing the package to you if you are interested;
> otherwise I'm going to orphan it.
>
> Note that it's unsupported by upstream as Firefox 52 ESR is no longer
> getting fixes, and it's also FTBFS in rawhide with latest gcc 9, and
> also the devel package (mozjs52-devel) is uninstallable as of today
> because of broken dependencies due to libreadline 8 soname bump that
> just landed.
>
> Thanks,
> Kalev



-- 
With best regards, Peter Lemenkov.
___
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: Let's EOL mozjs24 starting from Fedora 29

[Peter Lemenkov]

Hello All!

OK, no objections so far so I'm going to retire it soon.


2018-09-05 16:33 GMT+02:00 Peter Lemenkov :
> Hello All!
> With recent erlang-js build there is no more packages dependent on
> mozjs24 in F-29 and Rawhide. It wasn't build successfully since Fedora
> 26 and no longer updated by upstream. Let's retire it.
>
> * https://koji.fedoraproject.org/koji/packageinfo?packageID=17602
> * https://bugzilla.redhat.com/show_bug.cgi?id=1423963
> * https://bugzilla.redhat.com/show_bug.cgi?id=1373213
>
> --
> With best regards, Peter Lemenkov.



-- 
With best regards, Peter Lemenkov.
___
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

Let's EOL mozjs24 starting from Fedora 29

[Peter Lemenkov]

Hello All!
With recent erlang-js build there is no more packages dependent on
mozjs24 in F-29 and Rawhide. It wasn't build successfully since Fedora
26 and no longer updated by upstream. Let's retire it.

* https://koji.fedoraproject.org/koji/packageinfo?packageID=17602
* https://bugzilla.redhat.com/show_bug.cgi?id=1423963
* https://bugzilla.redhat.com/show_bug.cgi?id=1373213

-- 
With best regards, Peter Lemenkov.
___
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: Mono - Do we have a maintainer?

[Peter Lemenkov]

Hello All!

2018-08-15 12:16 GMT+02:00 Radka Janekova :
>
> Hi,
>
> mono-devel packages are far behind upstream, and the mono-sig seems 
> unresponsive as whole. This leads me to a question, do we have a maintainer 
> for mono?
>
> I can take a look at it within the next month or two if there really isn't 
> anyone else...

Sounds like a plan!

-- 
With best regards, Peter Lemenkov.
___
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/ZBRHX2XHKMK4HXFZ7BUL3YBLQNKJD7CD/

Re: Active but unresponsive maintainer: Peter Lemenkov

[Peter Lemenkov]

Hey,
Sorry for the absence - I'm still around.

2018-07-30 15:34 GMT+02:00 Timothée Floure :
>
> Hello,
>
> Peter Lemenkov [0] is an active packager (he submitted a new erlang
> build to bodhi an hour ago) but I was unable to contact him for the last
> two months.
>
> I first "encountered" him when he used his rights as provenpackager to
> merge some PRs on the elixir package, without thoughts for the ongoing
> discussions. He even submitted builds to bodhi but we *never* got any
> message from him. I'm now trying to contact him over RHBZ #1434779 [1]
> but am still unable to get a response.
>
> Does anyone know how to contact him ? Mail, IRC, RHBZ, Bodhi and src.fp.o
> failed.
>
> [0] https://fedoraproject.org/wiki/User:Peter
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1434779
>
> Thanks,
>
> --
> Timothée
>
> ___
> 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/B7WRRTWBMJLCMUHK7XJRB7WLVEPTQ4AE/
>



-- 
With best regards, Peter Lemenkov.
___
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/SGCNWHJJHY7D2A7YVBRA55VISYAUEKVO/

Re: xfig license change

[Peter Lemenkov]

Xfig has its own strdup implementation - that's funny.

2018-07-15 9:25 GMT+02:00 Honza Horak :
> License of xfig package was changed
> from: MIT
> to: MIT and GPLv3+ and LGPLv2+
>
> PR submitted, not yet merged:
> https://src.fedoraproject.org/rpms/xfig/pull-request/3
>
> Hans or Steve, please, merge.
>
> Thanks,
> Honza
> ___
> 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/YYERKGFWHZUYSOHJZEDRYWEH6HME3FUL/



-- 
With best regards, Peter Lemenkov.
___
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/N5YVTQPSVB47QGLIVKN4F5AKFCDY57JJ/

RFE: update xmlgraphics-commons up to ver. 2.2 in Fedora 28

[Peter Lemenkov]

Hello All!
This package, xmlgraphics-commons, didn't receive much attention
recently, so we missed an opportunity to update it in Fedora 28
without hurry. Unfortunatelyit seems that we have to.

Recently updated pdfbox (which has a subpackage fontbox, a Fop
dependency) makes fop-2.0 unable to produce PDF files (at least in
some cases). Upstream fixed compatibility in Fop version 2.1 (2.2 is
the latest available version).

I've updated Fop to 2.2 in Rawhide, but Fedora 28 still contains
broken Fop because it also requires upgrading xmlgraphics-commons up
to ver. 2.2. We ship ver. 2.0 in Fedora 28 currently. I've tried to
backport xmlgraphics-commons compatibility patches from fop 2.1 to 2.0
but it turned out to be a very complicated (for me) task.

So my proposal is to update xmlgraphics-commons from 2.0 to 2.2 in
Fedora 28. Full list of dependent packages is below (according to dnf
repoquery --whatrequires xmlgraphics-commons):

* arduino
* batik
* fop
* freemind
* jchart2d
* jeuclid
* scilab

I've googled a little and didn't find incompatibility issues betwee
2.0 and 2.x xmlgraphics-commons versions. According to release notes
all 2.x.y releases are minor API-compatible releases (
https://xmlgraphics.apache.org/commons/ ). So it should be ok.

At least fop and freemind were rebuilt successfully against
xmlgraphics-commons. Note that jeuclid and scilab are in FTBFS state
right now.

If nobody has any objections, then I'll update xmlgraphics-commons in
Fedora 28 to version 2.2 soon.

-- 
With best regards, Peter Lemenkov.
___
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/BUAJQA7QRFVYTPO6EIRFKELPTBTEDTCY/

Fop fonts issue in a freshly updated Fedora 28+

[Peter Lemenkov]

Hello All!

Just got a strange issue while generating doc-files from sources with fop:

https://kojipkgs.fedoraproject.org//work/tasks/763/26980763/build.log

Exception in thread "main" java.lang.NoSuchMethodError:
org.apache.fontbox.cff.CFFFont.getProperty(Ljava/lang/String;)Ljava/lang/Object;
at org.apache.fop.fonts.truetype.OTFFile.readName(OTFFile.java:134)
at org.apache.fop.fonts.truetype.OpenFont.readFont(OpenFont.java:740)
at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:109)
at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:93)
at org.apache.fop.fonts.FontLoader.getFont(FontLoader.java:124)
at org.apache.fop.fonts.FontLoader.loadFont(FontLoader.java:108)
at org.apache.fop.fonts.autodetect.FontInfoFinder.find(FontInfoFinder.java:254)
at org.apache.fop.fonts.FontAdder.add(FontAdder.java:63)
at 
org.apache.fop.fonts.FontDetectorFactory$DefaultFontDetector.detect(FontDetectorFactory.java:105)
at org.apache.fop.fonts.FontManager.autoDetectFonts(FontManager.java:229)
at 
org.apache.fop.fonts.DefaultFontConfigurator.configure(DefaultFontConfigurator.java:82)
at 
org.apache.fop.render.PrintRendererConfigurator.getCustomFontCollection(PrintRendererConfigurator.java:147)
at 
org.apache.fop.render.PrintRendererConfigurator.setupFontInfo(PrintRendererConfigurator.java:127)
at org.apache.fop.render.intermediate.IFUtil.setupFonts(IFUtil.java:170)
at 
org.apache.fop.render.intermediate.IFRenderer.setupFontInfo(IFRenderer.java:187)
at org.apache.fop.area.RenderPagesModel.(RenderPagesModel.java:75)
at org.apache.fop.area.AreaTreeHandler.setupModel(AreaTreeHandler.java:135)
at org.apache.fop.area.AreaTreeHandler.(AreaTreeHandler.java:105)
at 
org.apache.fop.render.RendererFactory.createFOEventHandler(RendererFactory.java:350)
at org.apache.fop.fo.FOTreeBuilder.(FOTreeBuilder.java:107)
at org.apache.fop.apps.Fop.createDefaultHandler(Fop.java:104)
at org.apache.fop.apps.Fop.(Fop.java:78)
at org.apache.fop.apps.FOUserAgent.newFop(FOUserAgent.java:179)
at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:107)
at org.apache.fop.cli.Main.startFOP(Main.java:186)
at org.apache.fop.cli.Main.main(Main.java:216)
make[3]: Leaving directory
'/builddir/build/BUILD/otp-OTP-20.3.6/lib/stdlib/doc/src'
make[3]: *** 
[/builddir/build/BUILD/otp-OTP-20.3.6/make/x86_64-redhat-linux-gnu/otp.mk:329:
../pdf/stdlib-3.4.5.pdf] Error 1
make[2]: Leaving directory '/builddir/build/BUILD/otp-OTP-20.3.6/lib/stdlib'
make[2]: *** [/builddir/build/BUILD/otp-OTP-20.3.6/make/otp_subdir.mk:29:
docs] Error 2
make[1]: Leaving directory '/builddir/build/BUILD/otp-OTP-20.3.6/lib'
make[1]: *** [/builddir/build/BUILD/otp-OTP-20.3.6/make/otp_subdir.mk:29:
docs] Error 2
make: *** [Makefile:416: docs] Error 2

For me it looks very much the same as the issue described here -
https://stackoverflow.com/questions/41501641/fop-giving-nosuchmethoderror-when-font-auto-detect-enable

However I'm not sure how to fix it?

>From looking at the RPM versions (comparing last successful buildroot
and this one) I found nothing really suspicious. Maybe Apache Fop
needs rebuild?

-- 
With best regards, Peter Lemenkov.
autoconf.noarch 2.69-27.fc28
automake.noarch 1.15.1-5.fc28
ed.x86_64 1.14.2-2.fc28
emacs.x86_64 1
emacs-common.x86_64 1
erlang.x86_64 20.3.2-2.fc28
flex.x86_64 2.6.1-7.fc28
fop.noarch 2.0-9.fc28
java-1.8.0-openjdk-devel.x86_64 1
libxslt.x86_64 1.1.32-2.fc28
lksctp-tools-devel.x86_64 1.0.16-9.fc28
m4.x86_64 1.4.18-6.fc28
ncurses-devel.x86_64 6.1-4.20180224.fc28
openssl-devel.x86_64 1
systemd-devel.x86_64 238-8.git0e0aa59.fc28
unixODBC-devel.x86_64 2.3.5-3.fc28
wxGTK3-devel.x86_64 3.0.4-1.fc28
xemacs.x86_64 21.5.34-29.20171230hg92757c2b8239.fc28
xemacs-packages-extra-el.noarch 20171219-2.fc28
zlib-devel.x86_64 1.2.11-8.fc28
GConf2.x86_64 3.2.6-20.fc28
ImageMagick-libs.x86_64 1
ModemManager-glib.x86_64 1.6.12-3.fc28
OpenEXR-libs.x86_64 2.2.0-11.fc28
SDL2.x86_64 2.0.8-2.fc28
adobe-mappings-cmap.noarch 20171205-3.fc28
adobe-mappings-cmap-deprecated.noarch 20171205-3.fc28
adobe-mappings-pdf.noarch 20180407-1.fc28
adwaita-cursor-theme.noarch 3.28.0-1.fc28
adwaita-icon-theme.noarch 3.28.0-1.fc28
alsa-lib.x86_64 1.1.6-2.fc28
apache-commons-codec.noarch 1.11-3.fc28
apache-commons-io.noarch 1
apache-commons-logging.noarch 1.2-13.fc28
at-spi2-atk.x86_64 2.26.2-1.fc28
at-spi2-atk-devel.x86_64 2.26.2-1.fc28
at-spi2-core.x86_64 2.28.0-1.fc28
at-spi2-core-devel.x86_64 2.28.0-1.fc28
atk.x86_64 2.28.1-1.fc28
atk-devel.x86_64 2.28.1-1.fc28
avahi-glib.x86_64 0.7-12.fc28
avahi-libs.x86_64 0.7-12.fc28
avalon-framework.noarch 4.3-19.fc28
avalon-logkit.noarch 2.1-29.fc28
batik.noarch 1.9-6.fc28
batik-css.noarch 1.9-6.fc28
brotli.x86_64 1.0.1-3.fc28
bzip2-devel.x86_64 1.0.6-26.fc28
cairo.x86_64 1.15.12-2.fc28
cairo-devel.x86_64 1.15.12-2.fc28
cairo-gobject.x86_64 1.15.12-2.fc28
cairo-gobject-devel.x86_64 1.15.12-2.fc28
cdparanoia-libs.x86_64 10.2-27.fc28
cmake-filesystem.x86_64 3.11.0-1.fc28
colord-libs.x86_64 1.4.2-

Re: Announcement: fdk-aac

[Peter Lemenkov]

Great news! Now we have almost everything required for modern audio decoding!

Any news about mp3 predecessors, btw?

2017-10-12 18:05 GMT+02:00 Tom Callaway <tcall...@redhat.com>:
> Hi Fedorans!
>
> Today, a Third-Party Modified Version of the Fraunhofer FDK AAC Codec
> Library for Android has been cleared for inclusion in Fedora. This
> specific library has been modified to be useful with Linux and
> gstreamer, and provides some support for encoding and decoding of the
> AAC digital audio codec.
>
> The package containing this library is called "fdk-aac".
>
> No other AAC implementations (regardless of copyright license) are
> permitted in Fedora at this time.
>
> Thanks,
>
> Tom Callaway
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
With best regards, Peter Lemenkov.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Self Introduction: David Hendricks

[Peter Lemenkov]

Hello David,
Nice to meet you again!

2017-10-02 8:31 GMT+02:00 David Hendricks <david.hendri...@gmail.com>:
> Hello Fedora Community,
>
> My name is David and my username is "dhendrix". I live in Silicon Valley and
> work for Facebook.
>
> My interest here is to maintain the package for flashrom which is a tool for
> reading and writing ROMs, particularly NOR flash that is commonly used for
> BIOS chips. I'm also involved with coreboot (flashrom was spun out of
> coreboot) and can help with the coreboot-utils package if needed. I've been
> involved with these projects since the early 2000's and am diving into RPM
> packaging since my current employer uses CentOS.
>
> My first package submission is an updated flashrom SRPM and the review
> request is posted here: https://bugzilla.redhat.com/show_bug.cgi?id=1497594.
>
> When/if the package is accepted I will take responsibility for updating the
> snapshot hash so that Fedora users (including those I work with) can enjoy
> the latest hardware support and useful features that are planned or pending
> for flashrom.
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



-- 
With best regards, Peter Lemenkov.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: I need your reviews

[Peter Lemenkov]

Hello Robert-André,
Could you please review these three relatively simple packages in return?

* https://bugzilla.redhat.com/1484835 - erlang-stdlib2
* https://bugzilla.redhat.com/1484843 - erlang-chronos
* https://bugzilla.redhat.com/1484846 - erlang-hyper

2017-08-17 18:45 GMT+02:00 Robert-André Mauchin <zebo...@gmail.com>:
> Hello,
>
> After reviewing near 50 packages recently, I'd really like if anyone
> could also review a few of my packages which are sitting around.
> Of course, I'm open to review swaps, so if you have an old package that
> have been waiting for a review too, please contact me.
>
> Currently, I have waiting:
>  - intel-hybrid-driver: This enables VP9 decoding ability on Skylake/Kabylake
> https://bugzilla.redhat.com/show_bug.cgi?id=1475962
>  - qdirstat: a clone of k4dirstat written with Qt5
>  https://bugzilla.redhat.com/show_bug.cgi?id=1476201
>  - A whole bunch of Golang library needed for packaging rclone. They are
>all generated by the gofed utility so they should be straightforward
>to review:
>  - golang-github-jlaffaye-ftp - A FTP client package for Go
>https://bugzilla.redhat.com/show_bug.cgi?id=1475817
>  - golang-github-golang-sync - Go concurrency primitives
>https://bugzilla.redhat.com/show_bug.cgi?id=1475872
>  - golang-github-billziss-gh-cgofuse - Cross-platform FUSE library for Go
>https://bugzilla.redhat.com/show_bug.cgi?id=1475741
>  - golang-bazil-fuse - Go library for writing FUSE userspace filesystems
>https://bugzilla.redhat.com/show_bug.cgi?id=1475750
>  - golang-github-Unknwon-goconfig - Configuration file parser for the Go
>Programming Language
>https://bugzilla.redhat.com/show_bug.cgi?id=1475763
>  - golang-github-ncw-go-acd - Go library for accessing the Amazon Cloud
>Drive
>https://bugzilla.redhat.com/show_bug.cgi?id=1475841
>  - golang-github-ncw-dropbox-sdk-go-unofficial - An unofficial Go SDK
>for integrating with the Dropbox API v2
>https://bugzilla.redhat.com/show_bug.cgi?id=1475832
>  - golang-github-nsf-termbox-go - A minimalistic API which allows
>programmers to write text-based user interfaces
>https://bugzilla.redhat.com/show_bug.cgi?id=1475846
>  - golang-github-rfjakob-eme - Encrypt-Mix-Encrypt for Go
>https://bugzilla.redhat.com/show_bug.cgi?id=1475850
>  - golang-github-xanzy-ssh-agent - Create a ssh-agent on any type of OS
>from any Go application
>https://bugzilla.redhat.com/show_bug.cgi?id=1475863
>  - golang-github-VividCortex-ewma - Exponentially Weighted Moving Average
>algorithms for Go
>https://bugzilla.redhat.com/show_bug.cgi?id=1475791
>
>  Thanks.
>
>  Robert-André Mauchin
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
With best regards, Peter Lemenkov.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Drop Wireshark GTK+ GUI and use Qt version only

[Peter Lemenkov]

2017-08-14 14:36 GMT+02:00 Martin Sehnoutka <msehn...@redhat.com>:
> Hello,
>
> there is a new version of Wireshark available in Fedora Rawhide (2.4.0)
> and it comes with both Qt and GTK+ GUI. Nonetheless the upstream
> developers do not support GTK version any more.
>
> https://www.wireshark.org/docs/relnotes/wireshark-2.4.0.html
>
> I think it's time to drop it and use Wireshark Qt version only, because
> it is the only GUI supported by upstream. What do you think, do you have
> any objections?

We can't maintain GTK frontend on their own as I believe. We had to
follow upstream's decision. Still I doubt we have to drop GTK GUI
right now or even in F-28 because it works rather well. How about to
keep it until it will be removed by upstream entirely or until F-28
EOL?


-- 
With best regards, Peter Lemenkov.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Build failures on alternative ("secondary") arches

[Peter Lemenkov]

Hello All!
I've got two nasty packages. One fails to pass the tests on BigEndian
arches (s390x, ppc64), another one fails to pass the tests on POWER
(ppc64 and ppc64le).

So I have several questions.

* Can I have a shell access to the ppc64 machine (which covers both
cases) where I can install packages and can run gdb / git / gcc?
* How maintainers are supposed to handle it?
* (A provocative one) - is it better to me just to set ExclusiveArch
and open a bugzilla ticket with build log of the failed build?
Sometimes it's hard to do anything even on supported architecture, so
asking me to support a package for the rarely used architecture (which
I don't even have access to) is, well, slightly overoptimistic, no?


-- 
With best regards, Peter Lemenkov.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to retire fleet in F-27 (F-26?)

[Peter Lemenkov]

2017-03-14 12:07 GMT+01:00 Peter Lemenkov <lemen...@gmail.com>:
> Hello All!
> Upstream decided to abandon fleet in favor of Kubernetes:
>
> * https://coreos.com/blog/migrating-from-fleet-to-kubernetes.html
>
> I believe we should do the same and retire it. I'll mark it as retired
> this weekend (18-19 March).

...and it's gone.


-- 
With best regards, Peter Lemenkov.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Intent to retire fleet in F-27 (F-26?)

[Peter Lemenkov]

Hello All!
Upstream decided to abandon fleet in favor of Kubernetes:

* https://coreos.com/blog/migrating-from-fleet-to-kubernetes.html

I believe we should do the same and retire it. I'll mark it as retired
this weekend (18-19 March).

-- 
With best regards, Peter Lemenkov.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Stepping down as a leveldb primary maintainer/contact.

[Peter Lemenkov]

Hello All!
I'm no longer using leveldb, so I'm no longer interested in
maintaining it. Does anyone want to become a primary maintainer?

-- 
With best regards, Peter Lemenkov.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 25 defaults to X instead of wayland

[Peter Lemenkov]

I believe there is something wrong in the recent (several months) nouveau
driver. So chances are high that your machine will default to Wayland as
soon as you switch off secondary videochip.

There are some rhbz tickets related though.

05 фев 2017 г. 11:52 пользователь "Timothy Ward" 
написал:

> Just wanted the links to more information on what will cause gdm and
> session manager to default to X instead of wayland.
>
> Have a laptop and desktop with fully updated system with debug package
> repos active and both systems default to X and will not start on
> wayland.
>
> This was not he case with Fedora 24 where you could select in the gdm
> login screen and end up with the chosen session.
>
> At the moment both gdm and and session default to X under gnome.
>
> Gdm debug log confirm the fallback but does not provide descriptive
> error messages why.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Orphaning packages

[Peter Lemenkov]

2016-08-30 15:08 GMT+02:00 Antonio Trande <anto.tra...@gmail.com>:
> On 08/30/2016 11:26 AM, Mario Ceresa wrote:
>> Dear all,
>> I'm orphaning the following packages due to not enough time to be a
>> proper mantainer:
>>
>> * dcmtk (https://admin.fedoraproject.org/pkgdb/package/rpms/dcmtk/)
>> * gdcm (https://admin.fedoraproject.org/pkgdb/package/rpms/gdcm/)
>>
>> I'll still be around to help if needed, just can't be the main point of
>> contact.
>>
>> Best,
>>
>> Mario
>>
>
> These packages are maintained by other packagers; are they still active?

Yes. But as usual co-maintainers are very welcome.

Also one more thing to mention. Mario's packages contains a batch of
out-of-tree patches which better be proposed to upstream. Some of them
were some of them weren't yet. Any help in this particular area is
very much appreciated :)



-- 
With best regards, Peter Lemenkov.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Erlang package's versions inconsistency between arm and x86_64/i686 repos

[Peter Lemenkov]

Hello All!
Is there something going wrong with ARM-repository? I can't build
package due to missing required packages although everything is fine
on i686/x86_64.

Namely I can't rebuild Wings because arm-repository has older package
than others.

http://koji.fedoraproject.org/koji/taskinfo?taskID=13625770

How can I build and push package just for arm?

-- 
With best regards, Peter Lemenkov.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Running CLI uitilities not available in Fedora?

[Peter Lemenkov]

Hello All!
I'd like to ask you for advice. I've packaged an application which can
use external CLI tools (not available in Fedora for various non-legal
reasons). Shall I remove support for these tools or better keep it?

-- 
With best regards, Peter Lemenkov.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: libcue soname bump

[Peter Lemenkov]

Hello Adam!
Sorry for this - I've just rebuild tracker.

2016-02-25 1:56 GMT+01:00 Adam Williamson <adamw...@fedoraproject.org>:
> On Wed, 2016-02-24 at 13:23 +0100, Peter Lemenkov wrote:
>> Hello All!
>> I'm going to upgrade libcue. Unfortunately this requires a soname
>> bump. Fortunately only recompilation is necessary.
>
> It works better if you plan this a bit *ahead of time* and actually
> plan for the rebuilds to happen, as opposed to just saying "yo, I'm
> going to bump it" and hoping stuff works out.
>
> This breaks Workstation live compose (and Workstation network install)
> for both Rawhide and the newly-branched F24, because tracker depends on
> libcue, and it was not rebuilt.
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org



-- 
With best regards, Peter Lemenkov.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: libcue soname bump

[Peter Lemenkov]

Hello All!

That would be great!

2016-02-24 13:24 GMT+01:00 Igor Gnatenko <i.gnatenko.br...@gmail.com>:
> I can take care about rebuilds.
>
>
> On Wed, Feb 24, 2016, 1:23 PM Peter Lemenkov <lemen...@gmail.com> wrote:
>>
>> Hello All!
>> I'm going to upgrade libcue. Unfortunately this requires a soname
>> bump. Fortunately only recompilation is necessary.
>>
>> --
>> With best regards, Peter Lemenkov.
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
> --
>
> -Igor Gnatenko
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>



-- 
With best regards, Peter Lemenkov.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

libcue soname bump

[Peter Lemenkov]

Hello All!
I'm going to upgrade libcue. Unfortunately this requires a soname
bump. Fortunately only recompilation is necessary.

-- 
With best regards, Peter Lemenkov.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Is my package a special Conflict: snowflake?

[Peter Lemenkov]

Hello All!
Fortunately this particular issue will be resolved soon. For those who
curious - we decided to switch to rds13 as a new upstream for
erlang-xmlrpc. It looks more promising since it's actively maintained
(last commit to the original xmlrpc repo was ~5 years ago).


2016-02-13 15:59 GMT+01:00 Randy Barlow <ra...@electronsweatshop.com>:
> Hello fellow Fedora hackers!
>
> I am in a sticky packaging situation, and I think setting a Conflicts:
> in my package might be the solution. According to the Conflict
> guidelines[0], making a case here is a good way to go.
>
> jcline and I have been working for a number of weeks on getting the
> ejabberd package updated. It's been unmaintained for quite some time,
> and so updating it involved adding 15 more packages. Unfortunately
> during the process, I failed to notice that the dependency that ejabberd
> needed called "xmlrpc" was not the same upstream as the Fedora package
> "erlang-xmlrpc". We really want to get this in before the F24 branch in
> a week and change, so there's not much time to add the xmlrpc that
> ejabberd needs.
>
> One possibility that I've been investigating is renaming the new package
> to erlang-rds13_xmlrpc (rds13 being the github account that owns it),
> but it's non trivial and means applying lots of patching to both it and
> to ejabberd.
>
> Under more usual circumstances, I might think that's the way to go, but
> ejabberd's master branch has abandoned the use of this package in favor
> of a fork they are carrying of it they call p1_xmlrpc. This makes the
> Conflicts option attractive to me, as I will retire the new package in
> Fedora 25. It also makes it seem like it's not worth trying to get the
> upstreams to rename since I'm planning to drop the new package soon.
>
> I did consider going ahead and packaging their fork, but it may not be
> trivial as they have made changes to it and I'm not sure those changes
> are compatible with their older releases.
>
> I have done a little research on the package that conflicts with mine.
> It seems to be used by yaws:
>
> $ dnf repoquery --whatrequires erlang-xmlrpc
> yaws-0:2.0-2.fc24.x86_64
>
> Of course, we can't know what users might be depending on this package
> who's software is not in Fedora, and what I'm proposing could cause an
> issue for those users who might also want to use ejabberd on the same
> system.
>
> So what do you all think? Are there other options that I should be
> considering? Am I a special snowflake?
>
>
> [0]
> https://fedoraproject.org/wiki/Packaging:Conflicts#Potential_Conflicting_Files
>
> --
> Randy Barlow
> xmpp: bowlofe...@electronsweatshop.com
> irc:  bowlofeggs on Freenode
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>



-- 
With best regards, Peter Lemenkov.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ntpstat

[Peter Lemenkov]

2016-02-12 12:10 GMT+01:00 Miroslav Lichvar <mlich...@redhat.com>:

> I could write a new man page and put it in the ntp package as a
> replacement. Or it could be added as a new package in Fedora, which
> ntp could recommend or suggest. Would that make sense? Another option
> is to simply drop ntpstat from ntp with no replacement.
>
> Thoughts?

I'd simply remove it. Otherwise you have to act as upstream for this
outdated thing.


-- 
With best regards, Peter Lemenkov.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Erlang busted on i386 on rawhide... workaround for erlang-based packages?

[Peter Lemenkov]

Hello All!
Yes, that's a known issue I'm trying to address now. I've got a
possible fix from upstream developers, so things are getting better.


2016-02-10 1:10 GMT+01:00 Martin Langhoff <martin.langh...@gmail.com>:
> Hi folks,
>
> trying to upload a new release of elixir, I am butting into something that
> looks and smells a lot like BZ#1240487 -- the (noarch) rpm builds nicely on
> x86_64 but the erlang runtime segfaults every time on i386.
>
> This FTBS repros for me on koji and under mockbuild locally (x66_64 f23).
>
>  - What's best strategy to bypass this and get it built on x86_64? Setting
> an arch on it seems ugly...
>
>  - Anything we can do to diag?
>
> cheers,
>
>
> m
> --
>  martin.langh...@gmail.com
>  -  ask interesting questions
>  - don't get distracted with shiny stuff  - working code first
>  ~ http://docs.moodle.org/en/User:Martin_Langhoff



-- 
With best regards, Peter Lemenkov.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Erlang busted on i386 on rawhide... workaround for erlang-based packages?

[Peter Lemenkov]

Hello All!

2016-02-10 13:08 GMT+01:00 Martin Langhoff <martin.langh...@gmail.com>:
> Hi Peter(s),
>
> On Wed, Feb 10, 2016 at 5:37 AM, Peter Lemenkov <lemen...@gmail.com> wrote:
>> Yes, that's a known issue I'm trying to address now. I've got a
>> possible fix from upstream developers, so things are getting better.
>
> That's great to hear. Am I tracking the right BZ# with  BZ#1240487?

Yes, that't the corresponding ticket.

https://bugzilla.redhat.com/1240487

-- 
With best regards, Peter Lemenkov.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 Self Contained Change: Erlang 18

[Peter Lemenkov]

Hello All!
Randy, Jeremy, feel free to add yourself to the "Change owners" of
this feature! In fact I strongly advise you to do this :)

2016-01-22 19:57 GMT+01:00 Randy Barlow <ra...@electronsweatshop.com>:
> Jan Kurik wrote:
>>   * Ejabberd
>>   -- We'd better to package all the bundled libraries Ejabberd requires.
>
> jcline and I have been feverishly working on this. It's a lot of work
> (15 new packages!). I think we almost have most of our packages
> submitted (jcline, how many left?) and we have quite a few that are
> waiting for review.
>
> Once those packages are all available in Rawhide, we will start working
> on getting ejabberd >= 16.1 packaged, which should silence the error
> e-mails we get every day ☺
>
> --
> Randy Barlow
> xmpp: bowlofe...@electronsweatshop.com
> irc:  bowlofeggs on Freenode
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org



-- 
With best regards, Peter Lemenkov.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[EPEL-devel] Re: The %license property is now supported in EPEL6

[Peter Lemenkov]

Hello All!

2016-01-20 22:03 GMT+01:00 Jason L Tibbitts III <ti...@math.uh.edu>:
> Just a note that it EPEL6 no longer requires you to include the
> definition of %license property; you can use it freely in your %files
> list as you would in EPEL7 or Fedora.  It simply maps to %doc as it
> would if you had included the magic line noise manually.  This works for
> me in koji; if it doesn't work in your local mock instance, it's
> possible that the mirrors still need to catch up with the change to
> comps.

Great news! Thanks everyone involved!

-- 
With best regards, Peter Lemenkov.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Re: Koji build fails on the same place on i686 in Rawhide

[Peter Lemenkov]

2016-01-16 18:49 GMT+01:00 Kevin Fenzi <ke...@scrye.com>:
> On Fri, 15 Jan 2016 16:23:54 +0100
> Dan Horák <d...@danny.cz> wrote:
>
>> On Fri, 15 Jan 2016 16:14:03 +0100
>> Peter Lemenkov <lemen...@gmail.com> wrote:
>>
>> > Hello All!
>> > I'm afraid I'm stuck with one of my packages. It fails to build on
>> > i686 in Rawhide but builds fine if koji was started with
>> > --arch-override=i686 (no other builds in parallel).
>> >
>> > I suppose I run into some "limits exceeded" issue. Unfortunately all
>> > I've got is the segfault during the documentation build.
>>
>> hmm, OOM killer in kernel in action? because both i686 and x86_64
>> tasks have used buildhw-11.phx2.fedoraproject.org
>>
>> > Technically I could disable docs on i686, but I really don't want
>> > to. Could someone take a look inside - what's going on there?
>> >
>> > Here is my latest build attempt:
>> >
>> > http://koji.fedoraproject.org/koji/taskinfo?taskID=12563046
>
> Doesn't seem to be OOM to me... in the i686 build.log:
>
> /bin/sh: line 6: 18505 Segmentation fault  (core dumped) erl -boot
> start_clean -noshell -pa ebin -s erl_html_tools top_index
> src /builddir/build/BUILD/otp-OTP-18.2.2 ../html 18 -s erlang halt
>
> Is the difference between a working and failed i686 build if it gets a
> buildvm or buildhw?

The only difference was --arch-override=i686 for a successful build.

This was an out-of-memory issue. I've changed Java environmental
variables from -Xmx1024m to -Xmx512m and it builds fine now!

http://koji.fedoraproject.org/koji/taskinfo?taskID=12578827

Although I think it's safe to say that the issue is fixed now
(workaround applied).  I'd like to have more details about Koji jobs.

Also it would be great if different build tasks won't interfere with
each other. I suppose that the limits should be applied to each
arch-build separately rather than for the entire task.

-- 
With best regards, Peter Lemenkov.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Koji build fails on the same place on i686 in Rawhide

[Peter Lemenkov]

2016-01-16 21:51 GMT+01:00 Kevin Fenzi <ke...@scrye.com>:
> On Sat, 16 Jan 2016 21:21:40 +0100
> Peter Lemenkov <lemen...@gmail.com> wrote:
>
>> The only difference was --arch-override=i686 for a successful build.
>
> So that was also a scratch build vs a real one?

No. If I start scratchbuild w/o arch-override it also fails. if I add
--arch-override it works fine.


-- 
With best regards, Peter Lemenkov.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Koji build fails on the same place on i686 in Rawhide

[Peter Lemenkov]

Hello All!
I'm afraid I'm stuck with one of my packages. It fails to build on
i686 in Rawhide but builds fine if koji was started with
--arch-override=i686 (no other builds in parallel).

I suppose I run into some "limits exceeded" issue. Unfortunately all
I've got is the segfault during the documentation build.

Technically I could disable docs on i686, but I really don't want to.
Could someone take a look inside - what's going on there?

Here is my latest build attempt:

http://koji.fedoraproject.org/koji/taskinfo?taskID=12563046

-- 
With best regards, Peter Lemenkov.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Ownership of erlang-mochiweb and couchdb packages

[Peter Lemenkov]

Hello Giovanni!
I'd love to see you (and any other interested person) working on this!
Feel free to reassign it to yourself.

2015-11-24 20:14 GMT+01:00 Giovanni Tirloni <g...@gtirloni.com>:
> Hello,
>
>  I've been using Fedora/CentOS/EPEL for a very long time and I would like to
> start contributing directly to the project by maintaining some packages.
>
>  Recently the erlang-mochiweb and couchdb packages were orphaned and I would
> like to take ownership of their EPEL7 branches.
>
> https://admin.fedoraproject.org/pkgdb/package/couchdb
> https://admin.fedoraproject.org/pkgdb/package/erlang-mochiweb
>
>  Please let me know if there are any concerns. I've read the wiki pages
> related to becoming a package maintainer and I understood introducing myself
> here would be the first step.
>
>  I have got FAS and Bugzilla accounts ('gtirloni' and 'g...@gtirloni.com',
> respectively).
>
> Thank you,
> Giovanni
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct



-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Erlang R18.1 on F23 or too late?

[Peter Lemenkov]

Hello All!
Yes, It's a bit too late. Also I *personally* believe this release is
a little bit fragile - some new features (maps) are still unstable.
See these threads for further details (unfortunately they are in third
Erlang developer's spoken language - Russian):

* https://groups.google.com/forum/#!topic/erlang-russian/oOstFAFNG4Y
* https://groups.google.com/forum/#!topic/erlang-russian/2g7lLplyu70

Anyway upgrading everything to 18.x.y is in my TODO list. Perhaps
before this winter.

2015-09-28 4:23 GMT+02:00 Christopher Meng <i...@cicku.me>:
> Hi,
>
> Is there any possibility to have Erlang 18.1 on F23?
>
> Thanks.
>
>
> [1]---http://www.erlang.org/news/92
> --
>
> Yours sincerely,
> Christopher Meng
>
> http://awk.io
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct



-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Removing packages that have broken dependencies in F22 tree

[Peter Lemenkov]

2015-04-28 1:45 GMT+03:00 Kalev Lember kalevlem...@gmail.com:

 opensipsivaxer, peter
 python-sippypeter

Fixed both. Sorry for the delay.

-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [heads-up] librabbitmq 0.6.0 soon in rawhide

[Peter Lemenkov]

I'll take a look at this FTBFS.

2015-04-21 16:37 GMT+03:00 Remi Collet fed...@famillecollet.com:
 Le 21/04/2015 09:56, Remi Collet a écrit :
 Hi,

 I'm working on the update of librabbitmq 0.6.0 in rawhide.

 Dependencies:

 * collectd: patch needed [1]
 * opensips: build ok
 * rsyslog:  build ok
 * php-pecl-amqp: patch needed, but I will update to 1.6.0beta


 Done.

 opensips was already FTBFS.

 Remi

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



-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Packaging ghostscript's X11 support separately

[Peter Lemenkov]

2014-12-18 20:20 GMT+03:00 Tim Waugh twa...@redhat.com:

 I could package it in its own sub-package, ghostscript-x11, but that
 might be a bit surprising to people who expect 'ghostscript' to have an
 x11alpha driver.

 Alternatively I could move everything else from ghostscript to a new
 sub-package ghostscript-base, and have 'ghostscript' (i.e. just the
 X11.so plugin) require ghostscript-base (i.e. everything else).

The latter approach (ghostscript depending on *-core and *-x11/gui) is
better. it won't break any installations while providing enough
flexibility for the new ones.

-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Did I mess up? [dcmtk abi change in stable branches]

[Peter Lemenkov]

Hello!

2014-12-17 12:58 GMT+03:00 Mario Ceresa mrcer...@gmail.com:

 Now, simply recompiling them fixes the problem in rawhide, but how can I
 avoid breaking things in stable branches? Is there a way to have all three
 packages hit the repositories at the same time?

Sure it's possible - just use BuildOverride facility next time:

https://admin.fedoraproject.org/updates/override/

You can build package and add (override) it to the build root w/o
addig it to the updates(-testing). Then you will be able to build
dependent package(s) with this new version, and submit all of them
together.



-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Heads up! Fedora 21 and Ejabberd

[Peter Lemenkov]

Hello All!

I'm really sad to say that but I overlooked a very nasty upgrade issue
while updating Ejabberd up to a very recent version. As a result it's
barely working now (at least some perfectly valid configurations are
now refusing connections) and what is even worse *it will wipe out all
the data from the previous ejabberd installation* (chat logs, history,
user subscriptions, etc) during the upgrade.

So far I have the only advice - don't upgrade Ejabberd if possible.
I'll try to provide a fixed build soon.

I'm terribly sorry for that.

-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Heads up RabbitMQ users!

[Peter Lemenkov]

Hello All!

I've removed SSLv3 from the list of supported crypto protocols in
Erlang. This should apply only for cases where application doesn't
define explicitly a list of supported protocols. E.g. if your package
explicitly enables SSLv3 then it will be available, otherwise - won't
be. The packages are available in testing repositories:

- erlang-17.3.4-3.fc21
- erlang-R16B-03.10.fc20
- erlang-R16B-03.10.el7

I'm pretty sure this won't break things which weren't broken already.
However I've heard a bizarre report about RabbitMQ failure when using
Erlang with SSlv3 disabled against some 3rd party crypto tool:

* https://groups.google.com/forum/#!topic/rabbitmq-users/Hs5J9UauJz8

I would be thankful for the testing of RabitMQ against these new Erlang builds.

My next goal is to audit CouchDB, Ejabberd, RabbitMQ packages and
remove any SSLv3 traces from them (or even disable explicitly if
possible/necessary). Just fyi.
-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Heads up CouchDB and RabbitMQ users!

[Peter Lemenkov]

Hello All!
I've finally found time to fix a very long-standing issue with Erlang
applications pulling in a lot of X11-related rpms during the
installation. See these two Bugzilla tickets for the details:

* https://bugzilla.redhat.com/784693 (Fedora)
* https://bugzilla.redhat.com/1161922 (EPEL 7)

Now fresh headless Fedora 21+ (and even EPEL7 is you live dangerously
enough to use epel-testing) installations of CouchDB or RabbitMQ won't
pull a long tail of packages related to GUI, which is great. Now
you'll get a more slim and tiny containers with CouchDB or RabbitMQ
inside.

Some of the out-of-the-box Erlang/OTP functionality was intentionally
cut off. Namely the ability to remotely connect to debugger on the
headless node or running dialyzer there - if you try to install the
packages necessary for the remote debugging they will install all the
X11 stuff again.

I believe this isn't a serious issue though (nevertheless I'll try to
address it as time permits). However I'd love to gather some unusual
user experience - if you're using debugger, dialyzer, observer,
applications remotely on a production node then please talk to me. I
believe that the only application which needs to be de-X11-ied further
is observer since my experience tells me than nobody runs dialyzer
(static Erlang code checker) on the production node remotely (unlike
running observer which is necessary in some cases). Prove me wrong if
you can!

if you're just a casual CouchDB or RabbitMQ user then I believe you
won't notice anything (except of more slim and tiny containers with
Erlang applications inside). However if you see something strange then
file a Bugzilla ticket ASAP!

-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

How to stop unneeded services?

[Peter Lemenkov]

Hello All!
Perhaps a silly question but I'm stuck and need your help, my fellow fedorians.

I've got a service foo.service which Requires=bar.socket (which in
turn runs bar.service). So if I start foo.service then systemd opens
bar.socket, captures first packet and runs bar.service (which isn't
intended to be started manually btw). So far everything works as
expected.

I was asked if it's possible to automatically stop bar.service (and
bar.socket) if no services which requires these two are active. I
played with StopWhenUnneeded +
BindsTo but without much success.

I believe this sounds like a generic pattern so perhaps someone
already implemented it. Could somebody point me on working example?
Any other help would be greatly appreciated.

-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Status of weak dependencies support in Fedora 21+

[Peter Lemenkov]

Hello All!
RPM shipped with Fedora 21+ has support for weak dependencies. What's
the current status of that feature? Is it ok to start using them
(building RPM with Recommends/Suggests tags)?

I have a real-world example where I'd like to mark a dependency as
Suggests instead of Requires and want to know if dnf is ready to
process it?

-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No more deltarpms by default

[Peter Lemenkov]

Hello All!

2014-10-06 12:41 GMT+04:00 Rahul Sundaram methe...@gmail.com:
 Hi

 One of the long standing features that were enabled by default in yum is
 support for delta rpms.  dnf developers have disabled this

At last!

-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Proper directory for storing arch-independent data (bytecode)

[Peter Lemenkov]

Hello All!

Imagine a virtual machine, %VMNAME%, which executes a arch-independent
bytecode. Where packager should store it? Most notable candidates are
/usr/share/%VMNAME%, /usr/lib/%VMNAME%.

So far Java has /usr/share/java/, Perl uses %{perl_vendorlib}
(/usr/share/perl5/vendor_perl), PHP uses /usr/share/php, R uses
/usr/share/R/library, Ruby uses /usr/share/ruby/vendor_ruby,
Javascripts are installed into %{_datadir}/javascript, Lisp is using
%{_datadir}/common-lisp, etc

But

Python stores its arch-independent bytecode into
/usr/lib/python?.?/site-packages/, Node.js prefers
%{_prefix}/lib/node_modules, Mono is using /usr/lib/mono.

It seems that there is no consensus on this matter. I personally tend
to agree with those who use /usr/share, but for example systemd stores
everything in /usr/lib including arch-independent stuff.

I wonder what others are thinking about this? Which is the preferred
place for storing arch-independent bytecode?


-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

How to decode/debug this TeXLive error message?

[Peter Lemenkov]

Hello All!
Sorrty for the almost unrelated question but I'm experiencing troubles
with TeXLive. I installed just texlive, texlive-comment, and hevea and
tsee this while rebuilding a package's docs:



LaTeX Font Info:External font `cmex10' loaded for size
(Font)  17.28 on input line 190.
LaTeX Font Info:External font `cmex10' loaded for size
(Font)  12 on input line 190.
! Undefined control sequence.
\@title ...ular}{r} {\huge {\bf ejabberd \version
  \ }} \\ \\ {\huge Installa...
l.190   \maketitle{
   }
?
! Emergency stop.
\@title ...ular}{r} {\huge {\bf ejabberd \version
  \ }} \\ \\ {\huge Installa...
l.190   \maketitle{
   }
End of file on the terminal!



See full log if it matters:

* https://peter.fedorapeople.org/stuff/guide.log

The question is - what's missing on my machine from several thousand
TeXLive packets available, and how to find the missing packet having
only this data?

-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: How to decode/debug this TeXLive error message?

[Peter Lemenkov]

2014-08-30 23:05 GMT+04:00 Kiara Navarro kiarakovalev...@gmail.com:
 I'm not a professional in Latex but have you ever tried install the basic
 texlive scheme?

I've just installed these three packages I mentioned above. I thought
that''s enough:

texlive texlive-comment hevea

 Can you attach your .text file if I can find the problem. I use texmaker and
 most of the cases it tells me where the bug is.

Here it is:

https://raw.githubusercontent.com/processone/ejabberd/14.07/doc/guide.tex

This is a full tree:

https://github.com/processone/ejabberd/tree/14.07/doc


-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: How to decode/debug this TeXLive error message?

[Peter Lemenkov]

2014-08-31 0:56 GMT+04:00 Florian Weimer fwei...@redhat.com:
 On 08/30/2014 08:56 PM, Peter Lemenkov wrote:

 Sorrty for the almost unrelated question but I'm experiencing troubles
 with TeXLive. I installed just texlive, texlive-comment, and hevea and
 tsee this while rebuilding a package's docs:

 
 
 LaTeX Font Info:External font `cmex10' loaded for size
 (Font)  17.28 on input line 190.
 LaTeX Font Info:External font `cmex10' loaded for size
 (Font)  12 on input line 190.
 ! Undefined control sequence.
 \@title ...ular}{r} {\huge {\bf ejabberd \version
\ }} \\ \\ {\huge
 Installa...


 This means that \version is not defined.

 Apparently, there should be a version.tex in the tarball, generated by make
 release.  However, it is missing, and since \include is used to read the
 file, not \input, there's only a warning, “No file version.tex.” in the
 build log, the build doesn't stop with an error at this point.

Thanks! It works now!

-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Non-responsive maintainer: Hubert Plociniczak (fas: hubert)

[Peter Lemenkov]

2014-06-24 13:50 GMT+04:00 Peter Lemenkov lemen...@gmail.com:
 Hello All!
 As fas as we know Hubert quit Fedora for a very long time (said in his
 private email). So it's time to change a poit of contact for the only
 package Hubert maintained - RabbitMQ server.

 https://admin.fedoraproject.org/pkgdb/package/rabbitmq-server/

 I propose myself (FAS name: peter) and John Eckersberg (FAS name:
 jeckersb) as a primary maintainers. If anyone has any objections
 and/or suggestions, please, let us know.

Ping?


-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Non-responsive maintainer: Hubert Plociniczak (fas: hubert)

[Peter Lemenkov]

2014-07-01 21:58 GMT+04:00 Kevin Fenzi ke...@scrye.com:
 On Tue, 1 Jul 2014 16:55:23 +0400
 Peter Lemenkov lemen...@gmail.com wrote:

 2014-06-24 13:50 GMT+04:00 Peter Lemenkov lemen...@gmail.com:
  Hello All!
  As fas as we know Hubert quit Fedora for a very long time (said in
  his private email). So it's time to change a poit of contact for
  the only package Hubert maintained - RabbitMQ server.
 
  https://admin.fedoraproject.org/pkgdb/package/rabbitmq-server/
 
  I propose myself (FAS name: peter) and John Eckersberg (FAS name:
  jeckersb) as a primary maintainers. If anyone has any objections
  and/or suggestions, please, let us know.

 Ping?

 Sorry for the delay.

 I've assigned you as point of contact for the package.

Thanks!

-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Non-responsive maintainer: Hubert Plociniczak (fas: hubert)

[Peter Lemenkov]

Hello All!
As fas as we know Hubert quit Fedora for a very long time (said in his
private email). So it's time to change a poit of contact for the only
package Hubert maintained - RabbitMQ server.

https://admin.fedoraproject.org/pkgdb/package/rabbitmq-server/

I propose myself (FAS name: peter) and John Eckersberg (FAS name:
jeckersb) as a primary maintainers. If anyone has any objections
and/or suggestions, please, let us know.

-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: EPEL EPIC! [was Re: and SCL]

[Peter Lemenkov]

2014-03-21 16:07 GMT+04:00 Matthew Miller mat...@fedoraproject.org:

 It doesn't exist, it's an idea that Robyn has floated semi-seriously
 as a way to provide a repo that moves faster than EPEL. Rather than
 try to jam fast-moving stuff in to EPEL, the idea was to do an Extra
 Packages for Infrastructure and Cloud (EPIC) that had a different,
 faster-moving charter. EPIC would target the *EL platform just as EPEL
 does.

Faster moving rate is great indeed. But adding more than on version of
software (no matter of how many repos it takes) means only one - we
have to impose additional support requiremetns on a packagers.

The social contract requiremens for EPEL support (which of souce
isn't a real support) is way too high for the average maintainer.
That's the reason I believe the entire EPEL idea was a huge mistake
and waste of time - unfortunately I failed to discuss this with other
fellow fedora members during FOSDEM Fedora.NEXT related talks.

 I think this is a great place to try out what we can do with CentOS
 collaboration, since they're officially in the family now. Anyone have
 ideas on how best to proceed with that? New SIGs in both projects? A single
 new SIG spanning both? (CentOS's new SIGs seem to be a lot more heavyweight
 in terms of process than the concept we have for them in Fedora, for better
 or worse.) Some new joint upstream to be the meeting point?

No matter of the current situation I'd love to discuss possible ways
to improve it. So count me in as well.


-- 
With best regards, Peter Lemenkov.
___
epel-devel mailing list
epel-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: boot.fedoraproject.org (BFO)

[Peter Lemenkov]

2014/1/23 Kevin Fenzi ke...@scrye.com:

 Can you please file a infrastructure ticket on this and I will get it
 updated.

Don't know what others think, but I personally prefer GitHub pull
requests because they are much simpler and don't involve any
interaction with stone age software like trac or various MTAs. Just
out of the curiosity why don't we mirror anything related to
Fedora-Infra at GitHub? We actually have a working Fedora-Infra
organisation here:

https://github.com/fedora-infra

Btw I'm also playing with BFO and would love to have a chance to
improve it. Unfortunately a lot of current projects still hosts on
Fedorahosting which is so awful that it should be better to abandon it
completely in favor of something much better (GitHub of self-hosted
GitLab instance maybe)

-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: .spec file Source0 magic for github release source tarballs?

[Peter Lemenkov]

2014/1/21 Kaleb KEITHLEY kkeit...@redhat.com:

 Take, for example, https://github.com/nfs-ganesha/nfs-ganesha/releases,
 where there's a button for Source code (tar.gz) pointing at
 https://github.com/nfs-ganesha/nfs-ganesha/archive/V2.0.0.tar.gz

I'm using a different scheme (there are few at GitHub):

https://github.com/lemenkov/erlsyslog/archive/0.6.2/erlsyslog-0.6.2.tar.gz

E.g.

https://github.com/%{upstream}/%{name}/archive/%{version}/%{name}-%{version}.tar.gz

Actually we should teach our builsystem to work with Git, tags, and
branches and forget about tarballs forever.
-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Non-responsive easytag package maintainer

[Peter Lemenkov]

Hello All!

2014/1/1 David King amigad...@amigadave.com:
 Hi

 The EasyTAG package in Fedora has not been updated since 2.1.8 was released
 last February. There are several open bugs which which would be fixed by the
 update. I have updated the packaging for 2.1.8 in a bug:

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

 I am the upstream maintainer of EasyTAG and I would like to maintain (or
 co-maintain) the package in Fedora. There is more information about the bugs
 which would be fixed by an update in the bug report which I filed about the
 non-responsiveness:

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

 It has now been two weeks without a response to that bug report, so I am
 posting on the devel list to try to get a response.


Matthias seems to stop his participation in Fedora ~1 year ago:

http://koji.fedoraproject.org/koji/tasks?owner=thiasstate=all

Dave, I think you should be granted a primary maintainer status for EasyTAG.


-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: ecryptfs alternatives

[Peter Lemenkov]

2013/12/11 Michał Piotrowski mkkp...@gmail.com:
 Hi,

 I have read in RHEL 7 beta release notes that ecryptfs will be deprecated in
 this release. The problem is that I've got a system on Fedora19 (which I
 want to move to EL7 after release) with some encrypted data. I'm looking for
 realiable alternative to ecryptfs that will work on EL7 out of box or will
 be relatively easy to build (without rebuilding kernel modules every
 update).

 Can you recommend any solutions?

dm-crypt. Also compatible with TrueCrypt (via external userspace
utility - tc-play).


-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: EPEL Updating llvm/clang?

[Peter Lemenkov]

2013/12/2 Dave Johansen davejohan...@gmail.com:
 Currently, llvm/clang in the EPEL repo has been orphaned and I was
 considering packaging YouCompleteMe (
 https://github.com/Valloric/YouCompleteMe ) for EL, but if requires clang
 3.2 or higher and so I was wondering if it would be possible for me
 llvm/clang to be updated to 3.3. I have spoken with the Fedora maintainer
 (ajax) and he was ok with the idea, but said that it would need approval. I
 have made the necessary updates to the .spec file of llvm 3.3 so it will
 build on EL 6 and would be happy with becoming the maintainer if this was
 approved.

Providing LLVM ver. 2.x nowadays sounds a joke so I'd rather update it
to a very recent version. Also it's a leafnode standalone
application(s) which makes updating even simpler.


-- 
With best regards, Peter Lemenkov.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: Using git for patch management in Fedora

[Peter Lemenkov]

2013/11/20 Karel Zak k...@redhat.com:

 All such information belong to spec file :-)

   Fedora-SCM:
   Upstream-SCM:
   Exploded-tree-SCM:

 for example upstream SCM URL is already missing in our spec files,
 it's more important information than URL to tarball.

Love this idea but there is a problem - RPM (at least older versions)
doesn't like unknown fields. It throws error and dies.
-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Using git for patch management in Fedora

[Peter Lemenkov]

2013/11/19 Richard W.M. Jones rjo...@redhat.com:
 Several packages are using git for patch management.  eg:

 http://pkgs.fedoraproject.org/cgit/erlang.git/tree/erlang.spec#n46
 http://pkgs.fedoraproject.org/cgit/libguestfs.git/tree/libguestfs.spec?h=f20#n22
 http://pkgs.fedoraproject.org/cgit/qemu.git/tree/
 http://pkgs.fedoraproject.org/cgit/ocaml.git/tree/ocaml.spec#n16

 Some of these packages have invented home-brewed methods to generate
 the Patch lines in the spec file, eg:

I hope we'll see some progress in RPM in regards to VCS integrations
soon. Because that's the main issue with RPM and related
infrastructure nowadays.

 More importantly, all are using random git repositories to store the
 exploded tree.  This makes it difficult for co-maintainers and proven
 packagers to fit in with the patch management chosen by the
 maintainer.  Usually they won't have access to the git repository for
 these patches, making it difficult to add patches and near impossible
 to upgrade to a new version.

I'm using https://git.fedorahosted.org/git/ for that. For example
erlang is stored here:

https://git.fedorahosted.org/git/erlang.git

It contains a mirror of main upstream repo and few branches with
Fedora-related patches.


I think we should expand this practise (mirroring of a git-reposiories
of upstream projects with a Fedora-specific patches) further and add
more git mirrors here, at Fedorahosted. I personally love to see
fedora kernel as a Git-managed tree instead of few dozens of random
patches and a spec-file.

-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Using git for patch management in Fedora

[Peter Lemenkov]

2013/11/19 Richard W.M. Jones rjo...@redhat.com:

 Peter, is the comment in the spec file wrong?  It refers to two github
 repos:

 http://pkgs.fedoraproject.org/cgit/erlang.git/tree/erlang.spec#n46

Oops, thanks for pointing me on this. Yes, that's just leftover and
should be removed. And the entire patch generation process should be
greatly simplified. Patches are welcome btw :)

 In any case, fedorahosted would be an improvement, but AIUI it doesn't
 automatically give access to co-maintainers and proven packagers.

Yes indeed. Our infrastructure lacks proper integration. What should I
do to add you into giterlang group?

-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Using git for patch management in Fedora

[Peter Lemenkov]

2013/11/19 Peter Lemenkov lemen...@gmail.com:
 2013/11/19 Richard W.M. Jones rjo...@redhat.com:

 Peter, is the comment in the spec file wrong?  It refers to two github
 repos:

 http://pkgs.fedoraproject.org/cgit/erlang.git/tree/erlang.spec#n46

 Oops, thanks for pointing me on this. Yes, that's just leftover and
 should be removed. And the entire patch generation process should be
 greatly simplified. Patches are welcome btw :)

 In any case, fedorahosted would be an improvement, but AIUI it doesn't
 automatically give access to co-maintainers and proven packagers.

 Yes indeed. Our infrastructure lacks proper integration. What should I
 do to add you into giterlang group?

Ok, just figured it out by myself.


-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Owner-change] Fedora packages ownership change

[Peter Lemenkov]

2013/11/12 Richard W.M. Jones rjo...@redhat.com:
 On Mon, Nov 11, 2013 at 10:00:07AM +, nob...@fedoraproject.org wrote:
 erlang-riak_kv [EL-6] was orphaned by peter
 [and many more]

 I'm just about to take some of these erlang packages in EPEL 6.  The
 ones which are dependencies of RabbitMQ only.

 Does anyone object if I update these at will?  I'm unclear on the ABI
 requirements of Erlang, and whether or not this would cause problems
 for users of the package(s) in EPEL.

ABI will be broken in some cases indeed, but since almost nobody uses
Erlang from EPEL I doubt if anyone will complain.


-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct