On Sat, Aug 03, 2019 at 07:29:34PM -0400, Sam Varshavchik wrote:
> I believe that the following construct trips this assertion:
>
> # std::vector foo;
> #
> # std::vector bar;
> #
> # // Populate foo with something.
> #
> # std::copy(&foo[0], &foo[foo.size()], std::back_insert_iterator{bar});
It'
Andrew Lutomirski writes:
On a cursory search of the standard, I couldn't find where it says
what operator* on this type of iterator does at all, let alone whether
it's valid for one-past-the-end iterators, but I'm pretty sure that
your code is, indeed, wrong.
This finally piqued my curiosity
On Sat, Aug 3, 2019 at 3:27 PM Elliott Sales de Andrade
wrote:
>
>
>
> On Sat, Aug 3, 2019, 3:49 PM Christoph Junghans, wrote:
>>
>> Hi,
>>
>> related to https://src.fedoraproject.org/rpms/kim-api/pull-request/1
>> I am getting a strange error:
>>
>> RPM build errors:
>> BUILDSTDERR: More tha
On Sat, Aug 3, 2019 at 4:30 PM Sam Varshavchik wrote:
>
> Tom Hughes writes:
>
> > But I think upstream is giving very bad advice...
> >
> > That define does not "add extra crashes" in the way that they
> > seem to think - well I mean it does literally but those crashes
> > are reports of program
Tom Hughes writes:
But I think upstream is giving very bad advice...
That define does not "add extra crashes" in the way that they
seem to think - well I mean it does literally but those crashes
are reports of program errors on their part.
Specifically in this case they appear to be accessing
On 04. 08. 19 1:14, Iñaki Ucar wrote:
Hi,
Quick question not found in the docs. There's a package with a -devel
subpackage. No package depends on this -devel and upstream removes the
development files in the new release, so I just dropped the -devel
subpackage.
Now, it's improbable, but if the
Hi,
Quick question not found in the docs. There's a package with a -devel
subpackage. No package depends on this -devel and upstream removes the
development files in the new release, so I just dropped the -devel
subpackage.
Now, it's improbable, but if the old -devel subpackage was installed,
the
On 8/2/19 2:05 PM, Steven A. Falco wrote:
> A bug was discovered in a pending KiCAD rawhide build, so I'd like to untag
> kicad-5.1.3-1.fc31 to keep it from going into rawhide. Koji ID 1344019.
>
> I've never done that before, but I tried doing "koji untag-build
> f31-updates-pending kicad-5.1.
On 8/2/19 12:27 PM, Susi Lehtola wrote:
> Hello,
>
>
> is anyone else experiencing weird build notifications? I just got one
> for gsl-1.8-1.1 built by jkeating... on 5 Apr 2007.
Yeah, this was my testing our koji build archiving. Unfortunately our
message bus plugin saw this and emitted message
On 8/2/19 11:45 AM, Gwyn Ciesla via devel wrote:
> I have to say, I've never received a 12-year old koji notification before. :)
Well, you still haven't. ;)
This was because I was testing our koji build archiving on the old fc6
tagged packages. Our koji fedora-messaging plugin saw the event and
e
Koji.fedoraproject.org currently stores every rpm ever shipped to users
since the Fedora 7 days, along with a lot of information about every
build it’s ever made, even if not distributed. We have continued to grow
the storage backing koji over time, but it is close to reaching a size
we can no long
> What is certain is that I won't have time to proverbially sit down (on
> my standing desk) and track bugs down, either as a reporter or as a
> maintainer. Same thing for my stalled review requests I was hoping to
> get done much sooner.
I may be back on track in a couple weeks actually, I may ha
> Anyways, there are easy ways in Autotools to archieve this, and I can
> craft a patch, if you guide me to the canonical upstream of audit.
And even if you don't patch it, the need to export [1] a PYTHON
variable in the environment is exactly what should be done.
The tragedy of autotools is that
On 8/3/19 12:01 AM, Samuel Sieb wrote:
> On 8/1/19 2:44 PM, Steve Grubb wrote:
> [snip]
>
> I don't know if any list admins are following this list, but this email
> was delayed almost two days. From the headers (included below) it looks
> like it might have been stuck in a moderation queue. Is
Hi,
I think that you can just correct the bug, bump the release version, add
a changelog entry describing the fix and build that. If stuff breaks (or
stays broken for a while) in Rawhide, it's okay and expected- that's
what Rawhide is for.
If you unpushed the update in bodhi, it should be su
On 8/2/19 1:38 PM, Jerry James wrote:
> I just visited https://bodhi.fedoraproject.org/ to check on my updates
> in testing. I clicked on my profile. The section named "jjames's
> latest updates" used to show me the most recent few updates I have
> submitted for stable branches. Now it is comple
On Sat, Aug 3, 2019, 3:49 PM Christoph Junghans, wrote:
> Hi,
>
> related to https://src.fedoraproject.org/rpms/kim-api/pull-request/1
> I am getting a strange error:
>
> RPM build errors:
> BUILDSTDERR: More than one file on a line:
> /_kim-api-collections-management
> BUILDSTDERR: More
Hi
On Sat, Aug 3, 2019, 21:31 Jerry James wrote:
> I just visited https://bodhi.fedoraproject.org/ to check on my updates
> in testing. I clicked on my profile. The section named "jjames's
> latest updates" used to show me the most recent few updates I have
> submitted for stable branches. No
Announcing the creation of a new nightly release validation test event
for Fedora 31 Rawhide 20190802.n.1. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test
On Sat, 3 Aug 2019 at 20:34, Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Thu, Aug 01, 2019 at 10:25:55AM +0200, Adam Samalik wrote:
> > I've already done some experiments with that. I used multi-stage builds
> > with podman, but it's the same in principle. And yes, the sizes are
> > smaller. What wa
On 8/2/19 1:13 PM, Björn 'besser82' Esser wrote:
> Am Donnerstag, den 01.08.2019, 14:28 -0400 schrieb Steven A. Falco:
>> The upstream KiCAD project has requested that I remove
>> GLIBCXX_ASSERTIONS from the Fedora package, as described here:
>> https://bugs.launchpad.net/kicad/+bug/1838448
>>
>>
I'll take the python packagesand igraph.
Sent from ProtonMail mobile
Original Message
On Aug 2, 2019, 10:00 AM, Pierre-Yves Chibon wrote:
> Good Morning Everyone,
>
> I think it's time I make amends and recognize that I've been a terrible
> maintainer for a number of my package
Hey folks! I'm proposing we cancel the blocker review meeting for
Monday; we don't have a big list of proposed blockers (only 4) and it's
a public holiday here in Canada so I won't be around to run the
meeting. We can pick back up the following week. If anyone really
thinks we need to do the review
Hi folks! I'm proposing we cancel the QA meeting on Monday: it's a
public holiday here in Canada again, and also there isn't a lot for the
agenda. If anyone feels we really need to meet, you can go ahead and
take over by just sending out an announcement email with an agenda like
the ones I usually
On Sat, Aug 3, 2019, 20:19 Matthew Miller wrote:
> On Thu, Aug 01, 2019 at 10:16:40AM -0700, Adam Williamson wrote:
> > Hmm. I never really chipped into the ~ discussion, but it just occurred
> > to me it intersects with a discussion I care quite a lot about: RPM
> > version comparison. Especiall
On 8/2/19 11:13 AM, Florian Weimer wrote:
> * Pierre-Yves Chibon:
>
>> When you run `fedpkg build` on Rawhide, your package will be built in
>> a new koji tag (which will be the default target for Rawhide). The
>> package will be picked up from this koji tag, signed and moved onto a
>> second tag.
Hi all.
Package review of Sundials2:
https://bugzilla.redhat.com/show_bug.cgi?id=1733704
Available to reviewing another package in return.
--
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x6e0331dd1699e4d7
GPG key server: https://keys.openpgp.org/
sig
Steven A. Falco wrote:
> The upstream KiCAD project has requested that I remove GLIBCXX_ASSERTIONS
> from the Fedora package, as described here:
> https://bugs.launchpad.net/kicad/+bug/1838448
>
> What is the best way to do that? I can add "%undefine _hardened_build"
> (which I am testing now) bu
Am Donnerstag, den 01.08.2019, 17:44 -0400 schrieb Steve Grubb:
> On Thursday, August 1, 2019 4:37:01 AM EDT Miro Hrončok wrote:
> > On 01. 08. 19 4:43, Steve Grubb wrote:
> > > Audit. But is seems that autotools shoul hard code the old
> > > sematics so
> > > that all packages do the right thing.
On Sat, Aug 3, 2019 at 3:10 AM Brian (bex) Exelbierd
wrote:
>
> Hi All,
>
> Barring objection, I plan to retire the release notes package from
> Fedora on or after August 9, 2019. The package has not been updated
> since F28. Despite the fact that we have literally shipped a package
> containing
On 8/1/19 2:44 PM, Steve Grubb wrote:
[snip]
I don't know if any list admins are following this list, but this email
was delayed almost two days. From the headers (included below) it looks
like it might have been stuck in a moderation queue. Is that what
happened? I've noticed a few older e
No missing expected images.
Compose FAILS proposed Rawhide gating check!
13 of 45 required tests failed, 8 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING**
below
Unsatisfied gating requirements that could not be mapped to openQA tests:
FAILED: compose.cl
On Fri, 2 Aug 2019 at 05:33, Adam Williamson wrote:
>
> On Thu, 2019-08-01 at 14:36 +0200, Nicolas Mailhot via devel wrote:
> > Le jeudi 01 août 2019 à 14:19 +0200, Lennart Poettering a écrit :
> > > On Do, 01.08.19 10:14, Fabio Valentini (decatho...@gmail.com) wrote:
> > >
> > > > Since these thi
Hi,
related to https://src.fedoraproject.org/rpms/kim-api/pull-request/1
I am getting a strange error:
RPM build errors:
BUILDSTDERR: More than one file on a line: /_kim-api-collections-management
BUILDSTDERR: More than one file on a line:
/kim-api-collections-management.bash
(see https:/
A bug was discovered in a pending KiCAD rawhide build, so I'd like to untag
kicad-5.1.3-1.fc31 to keep it from going into rawhide. Koji ID 1344019.
I've never done that before, but I tried doing "koji untag-build
f31-updates-pending kicad-5.1.3-1.fc31", which gave me an error:
koji: ActionNotA
I just visited https://bodhi.fedoraproject.org/ to check on my updates
in testing. I clicked on my profile. The section named "jjames's
latest updates" used to show me the most recent few updates I have
submitted for stable branches. Now it is completely full of Rawhide
builds. I don't want to
I think this is what you want:
%global optflags %(echo %{optflags} | sed 's/-Wp,-D_GLIBCXX_ASSERTIONS / /')
Tom
On Fri, Aug 2, 2019 at 11:00 AM Steven A. Falco
wrote:
> The upstream KiCAD project has requested that I remove GLIBCXX_ASSERTIONS
> from the Fedora package, as described here:
> htt
Hello Fedora friends!
I would like to follow up and collect your input on Application Streams and
modularity after all of the discussions over the past month. We have been
listening and brainstorming on how to proceed with both the tooling, user
experience, and communicating better upstream for t
Action summary
Accepted blockers
-
1. dracut-modules-olpc — Cannot be installed due to unsatisfied
'bitfrost' dependency — NEW
ACTION: dracut-modules-olpc to resolve dependency on desired bitfrost package.
Proposed blockers
-
1. gnome-initial-s
Hello,
is anyone else experiencing weird build notifications? I just got one
for gsl-1.8-1.1 built by jkeating... on 5 Apr 2007.
--
Susi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
___
devel mailing list -- devel@lists.fedorapro
I have to say, I've never received a 12-year old koji notification before. :)
--
Gwyn Ciesla
she/her/hers
in your fear, seek only peace
in your fear, seek only love
-d. bowie
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
* Pierre-Yves Chibon:
> When you run `fedpkg build` on Rawhide, your package will be built in
> a new koji tag (which will be the default target for Rawhide). The
> package will be picked up from this koji tag, signed and moved onto a
> second tag. Bodhi will be notified by koji once this new buil
Am Donnerstag, den 01.08.2019, 14:28 -0400 schrieb Steven A. Falco:
> The upstream KiCAD project has requested that I remove
> GLIBCXX_ASSERTIONS from the Fedora package, as described here:
> https://bugs.launchpad.net/kicad/+bug/1838448
>
> What is the best way to do that? I can add "%undefine
Congratulations! You're reading the very first Minimization Objective [1]
update.
== New Minimization Team ==
A new team is being formed, having 9 members already!
Read the team page [2] for more information, including how to join.
Welcome, everyone!
== Communication channels ==
Following are
Steve, as you said in that thread, actually those assertions have
helped uncover a bug (tagged as "critical")! I don't see any way in
which they could "add additional crashes" if upstream does their
homework. So I don't think it's a good idea to remove them.
Iñaki
On Fri, 2 Aug 2019 at 17:47, Ste
On Thu, 2019-08-01 at 14:28 -0400, Steven A. Falco wrote:
> The upstream KiCAD project has requested that I remove
> GLIBCXX_ASSERTIONS from the Fedora package, as described here:
> https://bugs.launchpad.net/kicad/+bug/1838448
>
> What is the best way to do that? I can add "%undefine
> _hardene
Hi Mathew,
I don't have sponsor.
I need a sponsor any help here would be great.
Regards,
Muneendra.
-Original Message-
From: Matthew Miller [mailto:mat...@fedoraproject.org]
Sent: Friday, August 2, 2019 9:25 PM
To: Muneendra Kumar M
Cc: Development discussions related to Fedora
Subject
On Fri, Aug 02, 2019 at 09:18:35PM +0530, Muneendra Kumar M wrote:
> Hi Mathew,
>
> Thanks for providing the info.
> One quick question.
> Robert-Andre has given some review(feedaback) on my spec.
> Once I update the changes do I need to reply in the comments or is there
> any other procedure.
> I
On 8/2/19 11:39 AM, Florian Weimer wrote:
> * Steven A. Falco:
>
>> The upstream KiCAD project has requested that I remove
>> GLIBCXX_ASSERTIONS from the Fedora package, as described here:
>> https://bugs.launchpad.net/kicad/+bug/1838448
>
> I commented on the bug. I think removal of these secur
On 8/1/19 9:28 PM, Steven A. Falco wrote:
The upstream KiCAD project has requested that I remove
GLIBCXX_ASSERTIONS from the Fedora package, as described here:
https://bugs.launchpad.net/kicad/+bug/1838448
What is the best way to do that? I can add "%undefine
_hardened_build" (which I am testin
Hi Mathew,
Thanks for providing the info.
One quick question.
Robert-Andre has given some review(feedaback) on my spec.
Once I update the changes do I need to reply in the comments or is there
any other procedure.
If there is any link to the same if so could you please point me the same.
This info
On Thu, Aug 1, 2019 at 1:28 PM, Steven A. Falco
wrote:
What is the best way to do that?
Don't. As Florian has pointed out in Launchpad, this would convert the
nice crash into a security vulnerability. The assertions have a
negligible impact on performance, so better leave them enabled and
f
* Miro Hrončok:
> I get a FTBFS with micropython that I fail to parse.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1736114
>
> Does anybody know what this means and how shall I fix this?
> May it be a glibc regression?
It's a binutils issue. I updated the bug.
Thanks,
Florian
__
* Steven A. Falco:
> The upstream KiCAD project has requested that I remove
> GLIBCXX_ASSERTIONS from the Fedora package, as described here:
> https://bugs.launchpad.net/kicad/+bug/1838448
I commented on the bug. I think removal of these security checks is not
the right thing to do.
Thanks,
Flo
On Fri, Aug 02, 2019 at 08:59:29PM +0530, Muneendra Kumar M wrote:
> What I want to say is it is available in the open source and iam not sure
> about fedora.
> Sorry I couldn't check the same in fedora .
> Could you please point me to the link where I can look the fedora
> (Rawhide) source code or
Hi Matthew,
The changes are available in open source from 5.2 onwards.
Below is the link which points the same.
https://patchwork.kernel.org/cover/10887947/#22575061
And the below are the commit ids:
https://github.com/torvalds/linux/commit/1a61e5486aeb90d94dd6116c9749e36ed
d10bf9b
https://github
On 8/2/19 11:09 AM, Tom Hughes wrote:
> On 01/08/2019 19:28, Steven A. Falco wrote:
>> The upstream KiCAD project has requested that I remove GLIBCXX_ASSERTIONS
>> from the Fedora package, as described here:
>> https://bugs.launchpad.net/kicad/+bug/1838448
>>
>> What is the best way to do that?
Hello, Steven A. Falco.
Thu, 1 Aug 2019 14:28:31 -0400 you wrote:
> What is the best way to do that? I can add "%undefine _hardened_build"
> (which I am testing now) but I think that will remove other hardening
> features that I might want to leave enabled.
%global optflags %(echo %{optflags}
I personally use:
https://src.fedoraproject.org/rpms/galera/blob/master/f/galera.spec#_40
| %build
| %{set_build_flags}
|
| # FTBFS with the GLIBCXX_ASSERTIONS; #1546787
| CPPFLAGS=`echo $CPPFLAGS| sed -e "s|-Wp,-D_GLIBCXX_ASSERTIONS||g" `
| CFLAGS=`echo $CFLAGS| sed -e "s|-Wp,-D_GLIBCXX_ASSERTION
On 01/08/2019 19:28, Steven A. Falco wrote:
The upstream KiCAD project has requested that I remove GLIBCXX_ASSERTIONS from
the Fedora package, as described here:
https://bugs.launchpad.net/kicad/+bug/1838448
What is the best way to do that? I can add "%undefine _hardened_build" (which
I am t
Good Morning Everyone,
I think it's time I make amends and recognize that I've been a terrible
maintainer for a number of my packages.
So I'd like to orphan the following packages hoping they can find a better home.
I no longer use R, so all of my R libraries:
rpms/R-affy
rpms/R-affydata
rpms/R-a
On Thu, Aug 01, 2019 at 10:25:55AM +0200, Adam Samalik wrote:
> I've already done some experiments with that. I used multi-stage builds
> with podman, but it's the same in principle. And yes, the sizes are
> smaller. What was interesting though that some additional packages (ones
> that wouldn't ap
On Friday, August 2, 2019 8:15:24 AM EDT Miro Hrončok wrote:
> On 02. 08. 19 5:21, Steve Grubb wrote:
> > On Thursday, August 1, 2019 6:37:47 PM EDT Miro Hrončok wrote:
> >> On 01. 08. 19 23:44, Steve Grubb wrote:
> >>> On Thursday, August 1, 2019 4:37:01 AM EDT Miro Hrončok wrote:
> On 01. 08
On Fri, 2019-08-02 at 11:47 +0200, Fabio Valentini wrote:
>
> > > Hmm. I never really chipped into the ~ discussion, but it just occurred
> > > to me it intersects with a discussion I care quite a lot about: RPM
> > > version comparison. Especially RPM version comparison when all you have
> > > to
On Thu, Aug 01, 2019 at 05:55:45PM +0530, Muneendra Kumar M wrote:
> Hi Matthew,
> I have submitted a new package and the details are below.
> The main purpose of this daemon is to add FC network intelligence in host
> and host intelligence in FC network. This daemon would interoperate with
> Broca
On Thu, Aug 01, 2019 at 10:16:40AM -0700, Adam Williamson wrote:
> On Thu, 2019-08-01 at 14:36 +0200, Nicolas Mailhot via devel wrote:
> > Le jeudi 01 août 2019 à 14:19 +0200, Lennart Poettering a écrit :
> > > On Do, 01.08.19 10:14, Fabio Valentini (decatho...@gmail.com) wrote:
> > >
> > > > Sinc
On 02. 08. 19 5:21, Steve Grubb wrote:
On Thursday, August 1, 2019 6:37:47 PM EDT Miro Hrončok wrote:
On 01. 08. 19 23:44, Steve Grubb wrote:
On Thursday, August 1, 2019 4:37:01 AM EDT Miro Hrončok wrote:
On 01. 08. 19 4:43, Steve Grubb wrote:
Audit. But is seems that autotools shoul hard cod
On Thu, Aug 01, 2019 at 10:16:40AM -0700, Adam Williamson wrote:
> Hmm. I never really chipped into the ~ discussion, but it just occurred
> to me it intersects with a discussion I care quite a lot about: RPM
> version comparison. Especially RPM version comparison when all you have
> to deal with i
On Thu, Aug 01, 2019 at 11:10:35AM +0200, Clement Verna wrote:
> The Fedora Infrastructure is planning to retire the infinote [0]
> service. This service allows text collaboration using the Gobby
> client[1] and was mainly used by the Infrastructure team to coordinate
> our weekly meeting and the m
On Fri, Aug 2, 2019, 11:39 Fabio Valentini wrote:
> On Fri, Aug 2, 2019, 11:33 Adam Williamson
> wrote:
>
>> On Thu, 2019-08-01 at 14:36 +0200, Nicolas Mailhot via devel wrote:
>> > Le jeudi 01 août 2019 à 14:19 +0200, Lennart Poettering a écrit :
>> > > On Do, 01.08.19 10:14, Fabio Valentini (d
On Fri, Aug 2, 2019, 11:33 Adam Williamson
wrote:
> On Thu, 2019-08-01 at 14:36 +0200, Nicolas Mailhot via devel wrote:
> > Le jeudi 01 août 2019 à 14:19 +0200, Lennart Poettering a écrit :
> > > On Do, 01.08.19 10:14, Fabio Valentini (decatho...@gmail.com) wrote:
> > >
> > > > Since these things
On 02. 08. 19 10:57, Miro Hrončok wrote:
On 02. 08. 19 5:21, Steve Grubb wrote:
On Thursday, August 1, 2019 6:37:47 PM EDT Miro Hrončok wrote:
On 01. 08. 19 23:44, Steve Grubb wrote:
On Thursday, August 1, 2019 4:37:01 AM EDT Miro Hrončok wrote:
On 01. 08. 19 4:43, Steve Grubb wrote:
Audit.
Hello,
pykalman is no longer maintained upstream. I have, therefore, orphaned
it.
https://src.fedoraproject.org/rpms/python-pykalman
It is now suggested to use other libraries:
https://github.com/pykalman/pykalman/issues/86
--
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) |
https:
On 02. 08. 19 5:21, Steve Grubb wrote:
On Thursday, August 1, 2019 6:37:47 PM EDT Miro Hrončok wrote:
On 01. 08. 19 23:44, Steve Grubb wrote:
On Thursday, August 1, 2019 4:37:01 AM EDT Miro Hrončok wrote:
On 01. 08. 19 4:43, Steve Grubb wrote:
Audit. But is seems that autotools shoul hard cod
On Thursday, August 1, 2019 6:37:47 PM EDT Miro Hrončok wrote:
> On 01. 08. 19 23:44, Steve Grubb wrote:
> > On Thursday, August 1, 2019 4:37:01 AM EDT Miro Hrončok wrote:
> >> On 01. 08. 19 4:43, Steve Grubb wrote:
> >>> Audit. But is seems that autotools shoul hard code the old sematics so
> >>>
On 2019-07-19 6:16 p.m., Kevin Fenzi wrote:
> hey folks, here is a list of currently failing images in rawhide. > Please
> fix if you can. > > 1. design-suite lab: >
https://koji.fedoraproject.org/koji/taskinfo?taskID=36353212 > >
probibly should drop sparkleshare, or someone needs to fix it: > >
On 01. 08. 19 23:44, Steve Grubb wrote:
On Thursday, August 1, 2019 4:37:01 AM EDT Miro Hrončok wrote:
On 01. 08. 19 4:43, Steve Grubb wrote:
Audit. But is seems that autotools shoul hard code the old sematics so
that all packages do the right thing. It seems that python3 equivalents
have been
77 matches
Mail list logo
