pgrosu - is your FAS name?
Are you in packager group?
ср, 20 нояб. 2019 г. в 10:20, Paul Grosu :
>
> Hi Vascom,
>
> Thank you for the quick reply. I already added the SSH public key, but when
> I try to ssh with my private key and enter the username pgrosu at the
> (login:) it says "No supporte
Hi Vascom,
Thank you for the quick reply. I already added the SSH public key, but
when I try to ssh with my private key and enter the username pgrosu at the
(login:) it says "No supported authentication methods available". Does it
mean I should wait a day for it to go through, or should I contac
Notification time stamped 2019-11-20 07:19:28 UTC
From 8c9e3505ec84293aaaf1fb43db5b4893fcb521c2 Mon Sep 17 00:00:00 2001
From: Ralf Corsépius
Date: Nov 20 2019 05:48:46 +
Subject: Update to 0.22.
---
diff --git a/.gitignore b/.gitignore
index f380dc3..f19a402 100644
--- a/.gitignore
+++ b/
You need to add your public ssh key at FAS page
https://admin.fedoraproject.org/accounts
And login via ssh.
Read all information on
https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers
ср, 20 нояб. 2019 г. в 09:54, Paul Grosu :
>
> Hello Fedora Development Community,
>
>
Hello Fedora Development Community,
I work at Northeastern University as a researcher in the Gene Cooperman
Lab, and will be supporting the DMTCP package (
https://apps.fedoraproject.org/packages/dmtcp) and DMTCP-devel (
https://apps.fedoraproject.org/packages/dmtcp-devel). We are about to
releas
Hello Thomas,
I will take your review in exchange of mine below:
https://bugzilla.redhat.com/show_bug.cgi?id=1771173
Would you update yours following the feedback?
--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
___
devel mail
On 2019-11-19 7:49 p.m., Richard Shaw wrote:
I'm all for fixing bugs quickly but it was only assigned to OCIO in BZ
on 11/20 (UTC) and it's still November 19th for me :)
Same for me at the time writing. =) Thank for the quick reply.
It would hopefully be fixed by a simple rebuild which any
On Tue, Nov 19, 2019 at 9:27 PM Luya Tshimbalanga
wrote:
> Some users reported Blender which I maintain failed to start due to this
> issue:
>
> blender: symbol lookup error: /lib64/libOpenColorIO.so.1: undefined symbol:
> _ZN4YAML6detail9node_data12empty_scalarB5cxx11E
>
>
>
> Accordingly, the
Some users reported Blender which I maintain failed to start due to this
issue:
blender: symbol lookup error: /lib64/libOpenColorIO.so.1: undefined symbol:
_ZN4YAML6detail9node_data12empty_scalarB5cxx11E
Accordingly, the problem is caused by OpenColorIO from which Blender
depends. A bug is a
Aleksandra Fedorova wrote:
> I see that Mikolaj has a vision how it supposed to work. And I think he
> spent quite some time designing the workflow which would fit this vision,
> thus it is worth to listen to it with an open mind.
>
> @Mikolaj, can you document the setup for java toolchain somewhe
Sérgio Basto wrote:
> I use nm-applet instead plasma-nm in my kde and nm-applet just enforce
> libgobject , libgtk3 , libmm-glib, libpango, libpangocairo and
> nm-connection-editor [1]
>
> [1]
> dnf repoquery --requires network-manager-applet
We were not talking about things required by network-m
On Wed, 2019-11-20 at 02:56 +0100, Kevin Kofler wrote:
> Raphael Groner wrote:
> > Right, we've planned to use nm-tray for the LXQt spin. But the
> > package is
> > already removed because it never worked as it should. There's
> > indeed not
> > much sense to have another tray icon when NetworkMana
Raphael Groner wrote:
> Right, we've planned to use nm-tray for the LXQt spin. But the package is
> already removed because it never worked as it should. There's indeed not
> much sense to have another tray icon when NetworkManager itself places
> anyways (by enforced dependencies) its own icon asi
Adam Jackson wrote:
> That's about 44M worth of potential savings out of a 204M base image, a
> bit over 20%. I'll happily file proper bug reports for these somewhere
> if we want, but it took me like 30 minutes to look into this. If you're
> not even willing to put in _that_ little effort, then fo
On Tuesday, November 19, 2019 4:42:31 AM MST Petr Pisar wrote:
> Manual work. Random commiters skipping them.
If your goal is to make it so that "Random commiters" are packagers, that's
going to fall flat very quickly - as they'll just throw one version of the
package in, never think about it ag
On Monday, October 28, 2019 12:59:07 PM MST Troy Dawson wrote:
> Smoother initial creation of RHEL 9.[5]
I hope this is already clear, but what is good for RHEL is not necessarily
good for Fedora. If it would do good here too, that's excellent. If not, that
will be something that needs to get don
On Mon, 18 Nov 2019 at 11:17, John M. Harris Jr
wrote:
> I must disagree. That it "works" in RHEL doesn't mean that it should be
done
> in Fedora. The current situation in Fedora, where maven and ant have been
> "moved" to modules has screwed over the Eclipse packagers, for example,
and
> more are
On Tue, Nov 19, 2019, 22:30 Miro Hrončok wrote:
> On 19. 11. 19 21:55, Fabio Valentini wrote:
> > On Tue, Nov 19, 2019 at 8:32 PM Miro Hrončok
> wrote:
> >>
> >> On 19. 11. 19 20:20, Adam Jackson wrote:
> >>> In the spirit of positivity and collaboration, I spent a few minutes
> >>> looking at t
On 19. 11. 19 21:55, Fabio Valentini wrote:
On Tue, Nov 19, 2019 at 8:32 PM Miro Hrončok wrote:
On 19. 11. 19 20:20, Adam Jackson wrote:
In the spirit of positivity and collaboration, I spent a few minutes
looking at the results given to try to find some easy wins. Here's what
I found:
pytho
On Tue, Nov 19, 2019 at 8:32 PM Miro Hrončok wrote:
>
> On 19. 11. 19 20:20, Adam Jackson wrote:
> > In the spirit of positivity and collaboration, I spent a few minutes
> > looking at the results given to try to find some easy wins. Here's what
> > I found:
> >
> > python3-libs ships multiple cop
Announcing the creation of a new nightly release validation test event
for Fedora 32 Rawhide 20191119.n.2. 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
On 19. 11. 19 20:20, Adam Jackson wrote:
In the spirit of positivity and collaboration, I spent a few minutes
looking at the results given to try to find some easy wins. Here's what
I found:
python3-libs ships multiple copies of its pyc files, corresponding to
different optimization levels. I do
On Fri, 2019-11-15 at 23:38 +0100, Kevin Kofler wrote:
> Adam Samalik wrote:
> > 1/ A history chart for base images [2] is now being generated — includes
> > data since 25 September. It's a bit rough initial implementation, but it's
> > there!
>
> Almost 2 months of work to save… 0.5%! That does n
…
> But LXDE and nm-applet are GTK, LXQt and nm-tray are Qt.
Right, we've planned to use nm-tray for the LXQt spin. But the package is
already removed because it never worked as it should. There's indeed not much
sense to have another tray icon when NetworkManager itself places anyways (by
enfo
On Friday, 18 October 2019 22:44:24 CET you wrote:
> On Friday, 11 October 2019 16:10:55 CEST you wrote:
> > Hello,
> >
> > Dav1d 0.5.0 was published today and brings a SONAME bump from libdav1d.so.
> > 2.0.0 to libdav1d.so.3.0.0.
> > I will be updating it next week on F31/32, consumers of these l
On Tue, Nov 19, 2019 at 5:12 PM Aleksandra Fedorova wrote:
>
> Hi, Fabio,
>
> On Mon, Nov 18, 2019 at 10:30 AM Fabio Valentini wrote:
>>
>> Hi everybody,
>>
>> You're probably aware that the Stewardship SIG has been picking up
>> some (±230) Java packages to keep them from getting removed from
>>
Petr Pisar wrote:
> That's nice theory that will never come true becaue it would require to
> make all Perl code parallel-installable. And Perl code is not only
> libraries as in the Python language. That's also myriad of Perl scripts
> that you want to have in PATH.
But the scripts do not need to
Hi, Fabio,
On Mon, Nov 18, 2019 at 10:30 AM Fabio Valentini
wrote:
> Hi everybody,
>
> You're probably aware that the Stewardship SIG has been picking up
> some (±230) Java packages to keep them from getting removed from
> fedora, and to try to keep them maintained. Since the fraction of
> out-o
Il giorno mar 19 nov 2019 alle ore 16:19 Sandro Bonazzola <
sbona...@redhat.com> ha scritto:
>
>
> Il giorno mar 19 nov 2019 alle ore 15:20 Roman Mohr
> ha scritto:
>
>> Hi,
>>
>> I take [1] as the opportunity to orphan the following packages:
>>
>> rpms/aspectjweaver
>> rpms/assertj-core
>> rpm
Il giorno mar 19 nov 2019 alle ore 15:20 Roman Mohr ha
scritto:
> Hi,
>
> I take [1] as the opportunity to orphan the following packages:
>
> rpms/aspectjweaver
> rpms/assertj-core
> rpms/hystrix
> rpms/memoryfilesystem
> rpms/rxjava
> rpms/archaius
>
I need to check with oVirt infra team, but
On Tue, Nov 19, 2019 at 4:54 PM Stephen John Smoogen
wrote:
> On Tue, 19 Nov 2019 at 09:17, Gerald Henriksen wrote:
> >
> > On Mon, 18 Nov 2019 21:08:02 -0800, you wrote:
> >
> > >On 11/18/19 7:29 PM, Neal Gompa wrote:
> > >> I can't speak for everyone, but at least my experience was that it was
On Tue, 19 Nov 2019 at 09:17, Gerald Henriksen wrote:
>
> On Mon, 18 Nov 2019 21:08:02 -0800, you wrote:
>
> >On 11/18/19 7:29 PM, Neal Gompa wrote:
> >> I can't speak for everyone, but at least my experience was that it was
> >> functionally impossible to discover how to package Java stuff. In a
On Mon, 18 Nov 2019 21:08:02 -0800, you wrote:
>On 11/18/19 7:29 PM, Neal Gompa wrote:
>> I can't speak for everyone, but at least my experience was that it was
>> functionally impossible to discover how to package Java stuff. In a
>> lifetime (and a job) ago, I was much more engaged in the Java
>
Hi,
I take [1] as the opportunity to orphan the following packages:
rpms/aspectjweaver
rpms/assertj-core
rpms/hystrix
rpms/memoryfilesystem
rpms/rxjava
rpms/archaius
I don't use these projects anymore, and I don't have time to follow them.
Best Regards,
Roman
[1] https://pagure.io/fesco/issue
On Mon, Nov 18, 2019 at 6:23 AM Mikolaj Izdebski wrote:
>
> On Thu, Nov 14, 2019 at 4:59 PM Miro Hrončok wrote:
> > I've asked whether it wouldn't be in fact much easier to keep the default
> > versions of our packages non-modular.
> >
> > Others have said they are interested in this as well. A h
On Mon, Nov 18, 2019 at 7:24 AM Kevin Kofler wrote:
>
> Mikolaj Izdebski wrote:
> > As Petr Pisar noted earlier, default streams are designed to deliver the
> > same user experience as ursine packages, therefore there is no *direct*
> > advantage or disadvantage of them over ursine packages, for F
On Fri, 2019-11-15 at 02:02 +0100, Miro Hrončok wrote:
> system-config-rootpassword
Fixed to use python3 in system-config-rootpassword-1.99.6-21.fc32,
please do not retire.
--
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
T
On 2019-11-19, Igor Gnatenko wrote:
> Yes, but what you have described is basically to create 2 streams of
> perl-Sys-Virt module. Which is probably not what normal people want.
Having two different perl-Sys-Virt packages was requesed by
Daniel. That was not my choice.
> Creating module for one
On 2019-11-18, Kevin Kofler wrote:
> Petr Pisar wrote:
>> In your example the the packager maintains 4 versions (in the sense of
>> dist-git branches and builds submitted to Koji) of the software
>> (FXX fish 3, FXX+1 fish 4, stream 3 fish 3, stream 4 fish 4).
>>
>> That's exactly what you as a p
Yes, but what you have described is basically to create 2 streams of
perl-Sys-Virt module. Which is probably not what normal people want.
Creating module for one package is the worst idea ever.
Sure, bundling perl-Sys-Virt into the libvirt module would solve the
problem, but then what's the point
On 2019-11-16, Kevin Kofler wrote:
> Petr Pisar wrote:
>> With your proposal Bugzilla packager would have to package Bugzilla
>> twice: as a normal package for default Perl 5.26 and as a module for Perl
>> 5.30. Then a user would have hard time to select the right combinations of
>> Perl and Bugzi
On 2019-11-15, Igor Gnatenko wrote:
> On Fri, Nov 15, 2019, 17:38 Petr Pisar wrote:
>> On 2019-11-15, Daniel P Berrang=C3=A9 wrote:
>> >
>> > Consider if we move the virtualization stack (QEMU & Libvirt) into a
>> > module with two streams, one libvirt 5.8.0 and one libvirt 6.1.0.
>> >
>> > Now
On 2019-11-15, Przemek Klosowski via devel
wrote:
> Of course in practice the combinatorial behavior only happens within the
> subsets of software that depend on each other, but, nevertheless, it
> seems to me that this means that we have to control and limit the number
> of interdependent mod
Most of the primary team members are unavailable today so we are canceling
the meeting.
Join us next week instead!
langdon
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora
Minutes:
https://meetbot.fedoraproject.org/fedora-meeting-3/2019-11-12/modularity.2019-11-12-15.01.html
Minutes (text):
https://meetbot.fedoraproject.org/fedora-meeting-3/2019-11-12/modularity.2019-11-12-15.01.txt
Log:
https://meetbot.fedoraproject.org/fedora-meeting-3/2019-11-12/modularity.2019-11
Dne 28. 10. 19 v 20:59 Troy Dawson napsal(a):
> [3] - The core buildroot is the packages in @buildsys-build, and
> everything needed to build those packages.
[4] - self-hosting is the ability to build all the packages on themselves.
Why?
Why, this needs to be self-hosting? Do we really ne
46 matches
Mail list logo
