On 01/11/2015 09:22 PM, Pasi Kärkkäinen wrote:
> Hello,
>
> People who have their names in the Fedora tcp_wrappers changelog added to CC
> list..
>
> Any comments about the below? Obviously aclexec feature would be useful for
> all services using tcpwrappers/libwrap (ftp,telnet,tftp,ident,nfs,
On 11. 1. 2015 at 20:40:56, Adrian Soliard wrote:
> Hi everyone!
>I'm struggling a bit with dnf. It may have advantages, but as an
> end-user, I'm fighting with the list of packages when I press TAB.
> It's complicated, if I forget to install a specific package, dnf
> wouldn't show it to me, yu
On Mon, Jan 12, 2015 at 09:15:39AM +0100, Petr Lautrbach wrote:
> On 01/11/2015 09:22 PM, Pasi Kärkkäinen wrote:
> > Hello,
> >
> > People who have their names in the Fedora tcp_wrappers changelog added to
> > CC list..
> >
> > Any comments about the below? Obviously aclexec feature would be use
On Mon, Jan 12, 2015 at 11:27 AM, Jan Zelený wrote:
> On 11. 1. 2015 at 20:40:56, Adrian Soliard wrote:
>> Hi everyone!
>>I'm struggling a bit with dnf. It may have advantages, but as an
>> end-user, I'm fighting with the list of packages when I press TAB.
>> It's complicated, if I forget to i
Hello,
> On Sunday, 11 January 2015 2:27 PM, Peter Robinson wrote:
>>> Earlier in the discussions I was told that this is not really an issue: in
>>> production, about every server with remote access also has a KVM.
>>
>> Often not the case in small business or third party hosted environments.
> Hello,
>
> Sshd(8) daemon by default allows remote users to login as root.
>
> 1. Is that really necessary?
> 2. Lot of users use their systems as root, without even creating a
non-root user.
> Such practices need to be discouraged, not allowing remote root
login could be
> usef
- Original Message -
> Will F22 introduce plasma5 when it rolls out?
Yes, it will. KDE SIG guys are working on the Change page for
Fedora 22 [1]. It will be announced soon.
Jaroslav
[1] http://fedoraproject.org/wiki/Changes/Plasma_5
> --
> Mike Chambers
> Madisonville, KY
>
> "Best lit
No, this is not good idea as I wrote few minutes ago because it does not
improve security, it just provide feeling of better security, see:
https://en.wikipedia.org/wiki/Security_through_obscurity
I wonder why no-one responded like me, because this was discussed many
times ago. Well maybe many tim
Hi,
On 08-01-15 13:59, Hans de Goede wrote:
Hi,
On 08-01-15 13:31, Jaroslav Reznik wrote:
- Original Message -
= Proposed System Wide Change: Change xorg input stack to use libinput =
https://fedoraproject.org/wiki/Changes/LibinputForXorg
Change owner(s): Hans de Goede
Replace the
On 12 January 2015 at 09:20, Milan Keršláger wrote:
>> Hello,
>>
> 4) Blocking root access means forcing admins to log as normal user and
> then do su/sudo and providing root password, which is far less secure
> than disable root password authentication and allow login to root with
> SSH key
Compose started at Mon Jan 12 05:15:08 UTC 2015
Broken deps for i386
--
[Sprog]
Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0)
[aeskulap]
aeskulap-0.2.2-0.19beta1.fc22.i686 requires libofstd.so.3.6
aesku
Hi,
That's not security through obscurity. It's a way to limit the exposure to
a brute force attack with an a privileged account.
Also this allows the user uses a different account so remote attacks that
user is unknown and can not be used to brute force delimiting more
exposure.
Most instances cl
2015-01-12 5:35 GMT-03:00 Igor Gnatenko :
> On Mon, Jan 12, 2015 at 11:27 AM, Jan Zelený wrote:
>> On 11. 1. 2015 at 20:40:56, Adrian Soliard wrote:
>>> Hi everyone!
>>>I'm struggling a bit with dnf. It may have advantages, but as an
>>> end-user, I'm fighting with the list of packages when I
- Original Message -
> It has happened again. :-/
>
> | This message is a notice that Fedora 19 is now at end of life. Fedora
> | has stopped maintaining and issuing updates for Fedora 19. It is
> | Fedora's policy to close all bug reports from releases that are no
> | longer maintained.
>
Hello Milan,
> On Monday, 12 January 2015 3:11 PM, Milan Keršláger wrote:
> No, this is not good idea as I wrote few minutes ago because it does not
> improve security, it just provide feeling of better security, see:
> https://en.wikipedia.org/wiki/Security_through_obscurity
I disagree. Fir
Hello,
> On Monday, 12 January 2015 4:09 PM, Ian Malone wrote:
> > On 12 January 2015 at 09:20, Milan Keršláger
>> 4) Blocking root access means forcing admins to log as normal user and
>> then do su/sudo and providing root password, which is far less secure
>> than disable root password aut
You pointed to SELinux and two factor authentication to be like your
solution (ie disabling root login), but these tools (SELinux/twofactor
auth.) are build to completly mitigate the attack (the attacker is
unable to perform the needed action in any way).
You are (instead of completly mitigating),
If anyone is interested in having USB/IP working in Fedora, I'm looking
for someone to review the userspace tools at
https://bugzilla.redhat.com/show_bug.cgi?id=1175270.
While the USB/IP modules were in staging, this was in RPM Fusion, but
the modules have been moved out of staging and into th
On Mon, Jan 12, 2015 at 5:32 AM, Hans de Goede wrote:
> Hi,
>
> On 08-01-15 13:59, Hans de Goede wrote:
>>
>> Hi,
>>
>> On 08-01-15 13:31, Jaroslav Reznik wrote:
>>>
>>> - Original Message -
= Proposed System Wide Change: Change xorg input stack to use libinput =
https://fed
Hi!
I have a couple of packages submitted for review and I offer to make
swaps for them:
Globus Toolkit packages (C code - mostly loadable modules)
https://bugzilla.redhat.com/show_bug.cgi?id=1144800
globus-gridmap-eppn-callout
https://bugzilla.redhat.com/show_bug.cgi?id=1144801
globus-xio-g
> On Monday, 12 January 2015 5:59 PM, Milan Keršláger wrote:
> You are (instead of completly mitigating), only raising complexity a
> little bit (ie not completly avoiding), which is what is "Security
> through obscurity" about (ie. by hiding source code, the attacker only
> solve more complex pro
Dear Fedora developers,
I'd like to collect some feedback about the $SUBJECT, i.e. making
minimal build root really minimal, explicitly specifying build
dependencies, etc.
The topic originally spring out in this [1] discussion on packaging
list. Interesting FPC discussion on this topic can be fin
On 12 January 2015 at 12:48, Josh Boyer wrote:
> There's Workstation, which is actually looking at including KDE as well.
It is? Why?
RIchard
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.o
Am 12.01.2015 um 14:26 schrieb Richard Hughes:
On 12 January 2015 at 12:48, Josh Boyer wrote:
There's Workstation, which is actually looking at including KDE as well.
It is? Why?
why not?
not everybody likes GNOME for several reasons and it would be *so much*
more helpful if a *new user*
W dniu 12.01.2015 o 14:08, Vít Ondruch pisze:
> I'd like to collect some feedback about the $SUBJECT, i.e. making
> minimal build root really minimal, explicitly specifying build
> dependencies, etc.
Are you aware that this means changing build dependencies of most of
packages? Altering them ju
Hi,
On 12-01-15 13:48, Josh Boyer wrote:
On Mon, Jan 12, 2015 at 5:32 AM, Hans de Goede wrote:
Hi,
On 08-01-15 13:59, Hans de Goede wrote:
Hi,
On 08-01-15 13:31, Jaroslav Reznik wrote:
- Original Message -
= Proposed System Wide Change: Change xorg input stack to use libinput =
commit 55c7a5f55fb6ba0aa1bada16315adad046f467b2
Author: Petr Šabata
Date: Mon Jan 12 14:23:44 2015 +0100
0.72 bump; fix stalled transfers (#1177212)
.gitignore|3 ++-
perl-File-RsyncP.spec | 45 +++--
sources |2 +
On 01/12/2015 02:08 PM, Vít Ondruch wrote:
> Dear Fedora developers,
>
> I'd like to collect some feedback about the $SUBJECT, i.e. making
> minimal build root really minimal, explicitly specifying build
> dependencies, etc.
I strongly support this idea.
In the past it probaby made sense to have
On 01/12/2015 02:30 PM, Marcin Juszkiewicz wrote:
> W dniu 12.01.2015 o 14:08, Vít Ondruch pisze:
>
>> I'd like to collect some feedback about the $SUBJECT, i.e. making
>> minimal build root really minimal, explicitly specifying build
>> dependencies, etc.
>
> Are you aware that this means chan
On Mon, Jan 12, 2015 at 8:26 AM, Richard Hughes wrote:
> On 12 January 2015 at 12:48, Josh Boyer wrote:
>> There's Workstation, which is actually looking at including KDE as well.
>
> It is? Why?
Because it was a work item from F21 that didn't make it and we're
continuing off of that. "Includin
On Mon, 12 Jan 2015 14:30:49 +0100
Marcin Juszkiewicz wrote:
> W dniu 12.01.2015 o 14:08, Vít Ondruch pisze:
>
> > I'd like to collect some feedback about the $SUBJECT, i.e. making
> > minimal build root really minimal, explicitly specifying build
> > dependencies, etc.
>
> Are you aware that
- Original Message -
> Dear Fedora developers,
>
> I'd like to collect some feedback about the $SUBJECT, i.e. making
> minimal build root really minimal, explicitly specifying build
> dependencies, etc.
>
> The topic originally spring out in this [1] discussion on packaging
> list. Intere
On 01/12/2015 08:05 AM, P J P wrote:
Again, issue being addressed is not of brute force attacks. But that
of such attacks resulting in gaining 'root' access to remote machines.
They are two distinct issues.
There still needs to be an administrative access to the system, and the
most common im
On Mon, 12 Jan 2015, Przemek Klosowski wrote:
There still needs to be an administrative access to the system, and the most
common implementation by enabling 'sudo'
on the non-privileged account. So, in a sense you are both right: this feature
is just a small step rather than a
security panaceu
On 12 Jan 2015, at 03:56, P J P wrote:
Hello,
On Sunday, 11 January 2015 2:27 PM, Peter Robinson wrote:
Earlier in the discussions I was told that this is not really an
issue: in
production, about every server with remote access also has a KVM.
Often not the case in small business or t
Change in package status over the last 168 hours
9 packages were orphaned
dircproxy [master, f21, f20, el6, el5] was orphaned by kevin
IRC proxy server
https://admin.fedoraproject.org/pkgdb/package/dircproxy
ip6sic
Hi all,
I am Zamir SUN from China. I have been promoting Open Source for some
time and been an ambassador last year. Now I want to help some more bit
in Fedora.
Recently I find some bugs that can be fixed by fixing the spec. So I'd
like to help with the packager in my spare time.
Although I did
= Proposed System Wide Change: Default Local DNS Resolver =
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
This Change was already proposed as Fedora 21 Change but moved to Fedora 22
(and discussed as Fedora 22 Change), re-announcing it as more details were
provided as request
On Sun, 11.01.15 21:29, Tomasz Torcz (to...@pipebreaker.pl) wrote:
> On Sat, Jan 10, 2015 at 12:16:38AM +0200, Pasi Kärkkäinen wrote:
> > Hello,
> >
> > I recently noticed Debian/Ubuntu has had support for "aclexec" in
> > tcp_wrappers via a custom patch since 2006,
> > so you can do this in /et
Dne 12.1.2015 v 14:30 Marcin Juszkiewicz napsal(a):
> W dniu 12.01.2015 o 14:08, Vít Ondruch pisze:
>
>> I'd like to collect some feedback about the $SUBJECT, i.e. making
>> minimal build root really minimal, explicitly specifying build
>> dependencies, etc.
> Are you aware that this means changi
WG meeting will be at 12:00 UTC (07:00 EST, 13:00 Brno, 7:00 Boston,
21:00 Tokyo, 22:00 Brisbane) in #fedora-meeting on Freenode.
= Topics =
* Fedora Rings
* revisit the plan around rings
* interpret rings with users' use cases and requirements
* sync on where SCLs, copr, languages reposit
Dne 12.1.2015 v 15:46 Przemek Klosowski napsal(a):
> There still needs to be an administrative access to the system, and the
> most common implementation by enabling 'sudo' on the non-privileged
> account. So, in a sense you are both right: this feature is just a small
> step rather than a security
> On Monday, 12 January 2015 8:32 PM, Paul Wouters wrote:
> do you use PrzemekKlosowski as your username on your fedora? I doubt it.
> It is more likely to be przemek, klosowski or pklosowski. In fact, often
> this is revealed in mail headers (eg "sendmail invoked by user paul").
> More often, peop
Delimit the remote access to users with privilege is not in any case
based Security
through Obscurity. Obviously the best option for delimiting access is
disabled by default SSH. I consider before taking such drastic measures
that may affect users of cloud, is more than reasonable disable access to
> On Monday, 12 January 2015 8:47 PM, Mike Pinkerton wrote:
> Not just virtualized deployments, but also in remote installs on bare
> metal.
Okay and the '%post' install section trick won't help there?
IIUC, it'd depend on which tool/application is used to do such remote
installations and if
> On Monday, 12 January 2015 10:06 PM, Milan Keršláger wrote:
> No. It improves nothing. This is step backward.
> It gaves bad signal to the user ("strong root password is not needed").
Wrong interpretation.
> It does not mitigate the BF attack. The original and main reason was to
> mitigate BF
On Mon, 12 Jan 2015, P J P wrote:
Agreed Paul, yet it does not mean cracking them would be as easy as slicing
knife through butter. That too for every awkward joe trying their hands at it.
It sounds like all one has to do is just guess the username, and it's game over.
Exactly! Then we are
On 12 Jan 2015, at 12:02, P J P wrote:
On Monday, 12 January 2015 8:47 PM, Mike Pinkerton wrote:
Not just virtualized deployments, but also in remote installs on bare
metal.
Okay and the '%post' install section trick won't help there?
IIUC, it'd depend on which tool/application is used to
Hello Paul,
> On Monday, 12 January 2015 11:18 PM, Paul Wouters wrote:
> What if I told you Neo, that there are no strong passwords?
> Passwords are weak. Some are less weak than others. I'd rather
> teach people to use ssh keys for remote access and only restrict
> passwords to console/physical
On 12 January 2015 at 06:05, P J P wrote:
> > On Monday, 12 January 2015 5:59 PM, Milan Keršláger wrote:
>
> > You are (instead of completly mitigating), only raising complexity a
> > little bit (ie not completly avoiding), which is what is "Security
> > through obscurity" about (ie. by hiding so
> On Monday, 12 January 2015 11:27 PM, Mike Pinkerton wrote:
> Sure, if the tool provides the ability to tweak the install to enable
> password-based root login, then one can log in after installation,
> upload keys, configure sshd, etc. The question is whether the tool
> that is available has
On Sat, Jan 10, 2015 at 6:12 PM, Richard W.M. Jones wrote:
>
> Does this proposal apply to native non-C/C++ programs?
>
> Rich.
>
I would like to see this proposal apply to native non-C/C++ programs,
but I am not sure on how that would be done?
Do the other compilers understand what needs to be
On Tuesday, 13 January 2015 12:05 AM, Stephen John Smoogen wrote:
>I don't see how this is the case. All we have done is move the
>first line of the root-kit script to calling sudo via the password
>that was used to open the account up. Since many of Linux systems
>are single user boxes.. it is mos
On 12 January 2015 at 11:58, P J P wrote:
> On Tuesday, 13 January 2015 12:05 AM, Stephen John Smoogen wrote:
> >I don't see how this is the case. All we have done is move the
> >first line of the root-kit script to calling sudo via the password
> >that was used to open the account up. Since many
Dear PJP, in the ship, there is a hole. You are waving the flag
"unsinkable" instead to stop the flow and screaming: "The flow could be
stopped later!".
You dismiss my arguments without argument, just dismiss them. Unbelievable.
Is this about security or about your ego? Could do you agree that
On Mon, 12 Jan 2015 20:39:35 +0100
Milan Keršláger wrote:
> ...snip...
Hey Milan.
I understand you have a strong opinion on this topic as does pjp.
This is however no reason to bring personal attacks into things.
Please focus on the technical discussion.
kevin
pgph0w9ibZwKJ.pgp
Descri
Dne 12.1.2015 v 20:46 Kevin Fenzi napsal(a):
On Mon, 12 Jan 2015 20:39:35 +0100
Milan Keršláger wrote:
...snip...
Hey Milan.
I understand you have a strong opinion on this topic as does pjp.
This is however no reason to bring personal attacks into things.
Oh well. I'm stupid! Sorry. Or..
On 12 January 2015 at 12:52, Milan Keršláger
wrote:
> Dne 12.1.2015 v 20:46 Kevin Fenzi napsal(a):
>
>> On Mon, 12 Jan 2015 20:39:35 +0100
>> Milan Keršláger wrote:
>>
>> ...snip...
>>>
>>
>> Hey Milan.
>>
>> I understand you have a strong opinion on this topic as does pjp.
>>
>> This is howeve
I noticed that I'm unable to watch Vimeo videos with Firefox without
Flash plugin. Same is not true if I use the Firefox build from upstream.
Do we disable something on our build that may be responsible for such
behavior? Anyone else has the same problem?
I even enabled h264 codec (although I know
> Scrap that, Kevin Kofler pointed me to this post:
>
> https://lists.fedoraproject.org/pipermail/devel/2014-December/205490.html
>
> Which I unfortunately missed, so the info I got from KDE upstream is
> not correct because the KDE spin adds an extra component which does
> directly talk to the l
On Mon, Jan 12, 2015 at 9:31 PM, Miloslav Trmač wrote:
>> Scrap that, Kevin Kofler pointed me to this post:
>>
>> https://lists.fedoraproject.org/pipermail/devel/2014-December/205490.html
>>
>> Which I unfortunately missed, so the info I got from KDE upstream is
>> not correct because the KDE spin
- Original Message -
> Does this proposal apply to native non-C/C++ programs?
As written, it seems to intend so. In practice, it would probably apply or not
depending on whether the non-C/C++ programs’ builds are affected by
_hardened_build.
Ideally, I think this should apply to all la
> That said, even on x86_64 it isn't anything close to no overhead.
> Tried last night to rebuild GCC's cc1plus as -fpie -pie, and then
> rebuild stage3 of GCC with make -j1 separately with the original stage3
> cc1plus (ET_EXEC binary) and PIE cc1plus (ET_DYN). The build (which
> included still t
> - The 'method' used to restrict remote root access is negotiable. Ie. disable
> it completely by setting PermitRootLogin=no OR disable remote root login
> via password by setting PermitRootLogin=without-password.
(The general theme of this mail: Being flexible is fine, and establishing this
t
> > - improves accountability for administrative actions (we know which admin
> > messed up :)
>
> Nonsense. for non-malicious logins, sudo leaves as much as a trail as
> sshd which tells you which credentials were used to login. For malicious
> logins, once root access is obtained via password-le
On Mon, Jan 12, 2015 at 03:37:42PM -0500, Miloslav Trmač wrote:
> - Original Message -
> > Does this proposal apply to native non-C/C++ programs?
>
> As written, it seems to intend so. In practice, it would probably
> apply or not depending on whether the non-C/C++ programs’ builds are
>
First of all, I agree with you that PermitRootLogin without-password is
preferable.
The discussion I am interested in is whether direct password root login
should remain enabled.
On 01/12/2015 10:02 AM, Paul Wouters wrote:
On Mon, 12 Jan 2015, Przemek Klosowski wrote:
- improves accountabilit
Am Montag, den 12.01.2015, 17:20 + schrieb P J P:
> > If you really want to improve security and mitigate BF attacks against
> > root, do this:
> > A) do not run SSHD by default
>
> That's a non-option.
This is actually implemented in Workstation, i.e. the sshd.service is
not enabled by d
On Mon, 12 Jan 2015, Przemek Klosowski wrote:
First of all, I agree with you that PermitRootLogin without-password is
preferable.
Good :)
The discussion I am interested in is whether direct password root login should
remain enabled.
With root logins, all you have on the client machine
Stephen Gallagher wrote:
> I doubt that User C *as described* exists. I suspect you meant "User C
> does not want an interactive notification. They want things to be
> blocked and logged appropriately, so that if things are not behaving as
> expected, they can find out why and what they would need
On Mon, Jan 12, 2015 at 10:57:50AM -0800, Moez Roy wrote:
> On Sat, Jan 10, 2015 at 6:12 PM, Richard W.M. Jones wrote:
> >
> > Does this proposal apply to native non-C/C++ programs?
> >
> > Rich.
> >
>
> I would like to see this proposal apply to native non-C/C++ programs,
> but I am not sure on
Michael Schwendt wrote:
> * Last upstream release is from 2007 and the same as offered by Fedora.
Then it's not the Fedora maintainer who is not doing his/her job.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fe
Vít Ondruch wrote:
> I'd like to collect some feedback about the $SUBJECT, i.e. making
> minimal build root really minimal, explicitly specifying build
> dependencies, etc.
-1, all the serious software requires gcc, gcc-c++ and make to build.
I actually think that cmake should be added to the min
On Tue, Jan 13, 2015 at 12:35 AM, Kevin Kofler wrote:
> Vít Ondruch wrote:
>> I'd like to collect some feedback about the $SUBJECT, i.e. making
>> minimal build root really minimal, explicitly specifying build
>> dependencies, etc.
>
> -1, all the serious software requires gcc, gcc-c++ and make to
Devel,
I would like to un-retire mumble, but that requires ice.
I've just fixed ice to compile on f21 without much effort.
So I think I'll un-retire ice and mumble and maintain them
unless anyone objects.
Is there any reason ice was orphaned and retired other than
lack of interest?
Cheers,
Carl
Hi Carlos,
On Tue, Jan 13, 2015 at 2:41 AM, Carlos O'Donell wrote:
> I would like to un-retire mumble, but that requires ice.
>
> I've just fixed ice to compile on f21 without much effort.
> So I think I'll un-retire ice and mumble and maintain them
> unless anyone objects.
>
> Is there any rea
> On Tuesday, 13 January 2015 3:06 AM, Miloslav Trmač wrote:
> (The general theme of this mail: Being flexible is fine, and establishing
> this
> through this discussion is great; however, ultimately the Change proposal
> needs
> to document the _specific outcome_ of that discussion.²)
I und
On Tuesday, 13 January 2015 1:10 AM, Stephen John Smoogen wrote:
>Sorry if I am misunderstanding but the feature is to address brute
>forcing the root account so that they do not get root access to the server.
Right.
>I am saying that this isn't a speed-bump because they are already trying
>to
On Tue 13 Jan 2015 01:35:26 AM CET Kevin Kofler wrote:
> Vít Ondruch wrote:
>> I'd like to collect some feedback about the $SUBJECT, i.e. making
>> minimal build root really minimal, explicitly specifying build
>> dependencies, etc.
>
> -1, all the serious software requires gcc, gcc-c++ and make to
On Mon, Jan 12, 2015 at 10:50:07PM +0100, Till Maas wrote:
> On Mon, Jan 12, 2015 at 03:37:42PM -0500, Miloslav Trmač wrote:
> > - Original Message -
> > > Does this proposal apply to native non-C/C++ programs?
> >
> > As written, it seems to intend so. In practice, it would probably
> >
> > Vít Ondruch wrote:
> >> I'd like to collect some feedback about the $SUBJECT, i.e. making
> >> minimal build root really minimal, explicitly specifying build
> >> dependencies, etc.
>
+1
As somebody who works on software that sometimes get rebuilt by other
people not using koji or mock, I
On Tue, Jan 13, 2015 at 7:31 AM, Richard W.M. Jones wrote:
> On Mon, Jan 12, 2015 at 10:50:07PM +0100, Till Maas wrote:
>> On Mon, Jan 12, 2015 at 03:37:42PM -0500, Miloslav Trmač wrote:
>> > - Original Message -
>> > > Does this proposal apply to native non-C/C++ programs?
>> >
>> > As wr
On 01/13/2015 07:12 AM, Stanislav Ochotnicky wrote:
On Tue 13 Jan 2015 01:35:26 AM CET Kevin Kofler wrote:
Vít Ondruch wrote:
I'd like to collect some feedback about the $SUBJECT, i.e. making
minimal build root really minimal, explicitly specifying build
dependencies, etc.
-1, all the serious
On 12. 1. 2015 at 07:55:26, Adrian Soliard wrote:
> 2015-01-12 5:35 GMT-03:00 Igor Gnatenko :
> > On Mon, Jan 12, 2015 at 11:27 AM, Jan Zelený wrote:
> >> On 11. 1. 2015 at 20:40:56, Adrian Soliard wrote:
> >>> Hi everyone!
> >>>
> >>>I'm struggling a bit with dnf. It may have advantages, but
84 matches
Mail list logo
