Yaniv Bronhaim | 14 Dec 12:00 2014
Picon

ssh problem with pkgs.fedoraproject.org

Hey,

According to https://lists.fedoraproject.org/pipermail/devel/2014-June/199631.html disabling selinux should do the trick, in my case it didn't really help

still getting:

OpenSSH_6.4, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /home/ybronhei/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 51: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to pkgs.fedoraproject.org [209.132.181.4] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/ybronhei/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/ybronhei/.ssh/id_rsa type 1
debug1: identity file /home/ybronhei/.ssh/id_rsa-cert type -1
debug1: identity file /home/ybronhei/.ssh/id_dsa type -1
debug1: identity file /home/ybronhei/.ssh/id_dsa-cert type -1
debug1: identity file /home/ybronhei/.ssh/id_ecdsa type -1
debug1: identity file /home/ybronhei/.ssh/id_ecdsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.4

and when trying to clone a project 

fedpkg clone vdsm
Cloning into 'vdsm'...
ssh_exchange_identification: read: Connection reset by peer
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
Could not execute clone: Command '['git', 'clone', 'ssh://bronhaim <at> pkgs.fedoraproject.org/vdsm', '--origin', 'origin']' returned non-zero exit status

It worked few weeks ago.. and I updated my pk in my fas account.. its not permission failure, so any ideas what can is it ?

Thanks
Yaniv Bronhaim.
--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Hedayat Vatankhah | 13 Dec 22:10 2014
Picon

F21 downloads repository metadata in 3 places!

Hi!
I noticed that F21 can potentially download repository metadata 3 times: 
1. Yum cache 2. DNF cache 3. PackageKit cache! It really hurts to see 
how Fedora ignorance towards different kind of users is being increased 
as time passes. If Fedora is an international distro, it should try to 
consider condition of different users, not just a portion of them.
Fedora repository metadata format was already hostile, it wastes 
bandwidth considerably downloading mostly useless data repeatedly. 
Things got worse for DNF as it decides to also always download filelists.

Now, Fedora 21 contains yum, dnf and PackageKit (software center) with 
new backend. Surprisingly, PackageKit uses its own separate cache. DNF 
refreshes its cache automatically (without user's consent) every 3 hours 
by default (according to 'man dnf.conf'). PackageKit also does the same, 
but I don't know when it does (also without user's consent).

Now, if you are exclusively a 'yum' user, you'll end up with 3 
repository metadata downloads, two of which you are unaware of. 
Probably, it is OK for most of you having access to cheap, fast internet 
access. But not everybody in the world has such access. It was not long 
ago that dial-up internet access was a norm in my area (there are still 
some using it!). I'm not using dial-up, but still can't afford such a 
waste of bandwidth. I'm using a 'fast' internet access, which is 
512Kb/sec, and have 6GiB for 3 months (with free access at nights, which 
I use to update/install Fedora packages). As I've described at [1], DNF 
alone can potentially consume all my internet credit very soon; even if 
I don't want to use any package manager at all. This will make many 
users with conditions like me very angry when they realize that Fedora 
has eaten their money silently.

Another side of the story is how Fedora lacks any integration in this 
area. There are separate caches. Fedora doesn't tell you that it'll eat 
your internet. Also, there is nowhere you can tell Fedora 'Please don't 
eat my internet without my permission'. Even there is no single 
configuration option for it. You should manually disable automatic 
downloading for DNF, and then separately for gnome software using some 
obscure gsettings commands you should look for. Well, I've not tried 
other desktops, each one might have each own settings for that too! 
(though usually such ignorance is the worst in GNOME).

It's so unfortunate to see how Fedora lacks any integration (one of the 
main things that a distro is expected to provide) in its package 
management software (one of the main distro specific software, where you 
fairly expect an integrated experience as an 'internal' software).

As I was expecting, I've already seen how a user in our local community 
cried about Fedora 21 consuming his Internet credit the day after the 
release. The number of Fedora users around me were already low, and I 
expect it to become less if Fedora continues its ignorance trend.  I'm 
not annoyed that much yet, as I'm just considering switching to a 
different DE after suffering GNOMEs decisions for a long time hoping 
that 'things will be better soon'; and finding out that my needs are 
something that 'THEY see no reasons to support'.

P.S. sorry for the somewhat long email. I'm a little bit angry! :P

Regards,
Hedayat

[1] 
https://hedayatvk.wordpress.com/2014/07/26/the-shiny-new-dnf-and-why-i-prefer-yum/
--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Atin Mukherjee | 13 Dec 16:19 2014
Picon

yum update failure in fedora19

Hi List,

I've been facing a multilib protection failure in yum update. When I tried to clean /var/run/cache/yum/* as well passing setopt=protected_multilib=false as parameter in yum update, but none of them actually resolved the issue. After turning off protected_multilib, I am getting the following error:

Error: Package: 1:NetworkManager-vpnc-0.9.9.0-6.git20140428.el7.x86_64 (epel)
           Requires: NetworkManager >= 1:0.9.9.0
           Installed: 1:NetworkManager-0.9.8.8-2.fc19.x86_64 ( <at> updates)
               NetworkManager = 1:0.9.8.8-2.fc19
           Available: 1:NetworkManager-0.9.8.2-2.fc19.i686 (fedora)
               NetworkManager = 1:0.9.8.2-2.fc19
Error: Package: 2:qemu-system-x86-2.0.0-1.el7.3.x86_64 (epel)
           Requires: libiscsi.so.2()(64bit)


Any help would be appreciated.

Regards,
Atin
--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Ville Skyttä | 13 Dec 11:30 2014
Picon
Picon

javasqlite orphaned

Hi,

I'm not using javasqlite any more so I've orphaned it in all branches (including EPEL).
--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Adam Williamson | 13 Dec 08:14 2014

[Test-Announce] 2014-12-15 <at> 16:00 UTC - Fedora QA Meeting

# Fedora Quality Assurance Meeting
# Date: 2014-12-15
# Time: 16:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net

Greetings testers!

It's meeting time again on Monday! Let's follow up on the action items 
from last week, and also pick up the agenda items we didn't get to, 
and maybe talk over the upgradepath debate a bit.

As always, please reply to this mail if you'd like to propose any 
additional topics!

== Proposed Agenda Topics ==

1. Previous meeting follow-up
  * roshi to look at implementing a compose event listener in taskotron
  * adamw to work on wiki magic and relval

2. Tooling check-in: taskotron, blockerbugs, relval, etc
3. Release criteria changes (esp. multiboot)
4. Upgrade path discussion
5. Open floor
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

_______________________________________________
test-announce mailing list
test-announce <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Kevin Kofler | 13 Dec 02:10 2014
Picon

Re: F22 System Wide Change: Change xorg input stack to use libinput

Jaroslav Reznik posted (and
> Change owner(s): Hans de Goede <hdegoede <at> redhat.com>
wrote):

> KDE: limits itself to standard X11 mouse config interfaces, no changes
> needed.

Not true. We ship kcm_touchpad on the KDE spin, which definitely does depend
on synaptics interfaces (search for "synaptics"
in:
https://projects.kde.org/projects/playground/utils/kcm-touchpad/repository/revisions/master/entry/src/backends/x11/xlibbackend.cpp ).
Anything that does not use the synaptics driver is not considered a
touchpad. And kcm_touchpad is also in the process of becoming a core part of
upstream Plasma. (It is currently in the git.kde.org playground.)

Therefore, porting kcm_touchpad (the rewritten 1.x series we currently ship,
not the old, obsolete, 0.3.x version, please make sure you look at the
correct version) is an essential requirement before we can move away from
the synaptics driver.

An additional objection I have to this change proposal is that libinput
(deliberately) only implements a small subset of the configurability of the
old drivers, and thus, if we are going to remove the old drivers entirely,
we are taking away flexibility from our users.

        Kevin Kofler

--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Colin Walters | 13 Dec 00:31 2014

https://fedoraproject.org/wiki/Layered_build_scripts_for_package_maintainers

Recently, I've ended up interacting with Fedora packages that use several different "higher order" or
"layered" tools on top of fedpkg.

I created this page:

https://fedoraproject.org/wiki/Layered_build_scripts_for_package_maintainers

which attempts to enumerate the ones I know of.  It's certainly non-exhaustive,
so if you maintain a tool that's not listed there, please add it!
--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Richard Hughes | 12 Dec 22:39 2014
Picon

AppData Screenshot Requirements

tl;dr: AppStream builder will reject AppData screenshots smaller than 312x175.

If you want things to be pixel-crisp and your application ships only
one screenshot use 752x423. If you've got multiple screenshots use
624x351, or integer multiples thereof. You can still ship random sized
screenshots bigger than 312x175 and we'll pad them out to the right
size and shape, but choosing a 16:9 resolution makes everything look
consistent in the software center. If you think 312x175 is being too
strict, you really need to have a look at this:
http://alt.fedoraproject.org/pub/alt/screenshots/f22/624x351/proofgeneral-4d9bd746838746355151f75f38e3ac4c.png
-- I'm considering making 624x351 the smallest screenshot size allowed
for F22/F23 although this may be too strict at this stage.

Also, if you need to show the desktop background (e.g. for gimp, where
you want to show multiple windows at once) use an alpha channel as the
background. This allows gnome-software to composite in the current
users desktop when we show it before it's installed.

I've emailed most of the maintainers this affects privately, although
you can check your app by looking at this commit to the logs:
https://github.com/hughsie/createrepo_as_logs/commit/42e4c078a8a8bd882d297862e5868372fc8a58b1
-- Thanks.

Richard
--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Lokesh Mandvekar | 12 Dec 16:57 2014

docker 1.4.0 available, fixes multiple CVEs - testing/karma needed

I've updated docker to 1.4.0 for fedora and fedora epel. This release fixes:
CVE-2014-9357: https://access.redhat.com/security/cve/CVE-2014-9357
CVE-2014-9358: https://access.redhat.com/security/cve/CVE-2014-9358
CVE-2014-9356: https://access.redhat.com/security/cve/CVE-2014-9356

It'd be great if people could test these and add karma/comments:
https://admin.fedoraproject.org/updates/docker-io-1.4.0-1.fc21
https://admin.fedoraproject.org/updates/docker-io-1.4.0-1.fc20
https://admin.fedoraproject.org/updates/docker-io-1.4.0-1.fc19
https://admin.fedoraproject.org/updates/docker-io-1.4.0-1.el6

Thanks!
-- 
Lokesh
Freenode, OFTC: lsm5
GPG: 0xC7C3A0DD
--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Jaroslav Reznik | 12 Dec 16:49 2014
Picon

F22 System Wide Change: Ruby on Rails 4.2

= Proposed System Wide Change: Ruby on Rails 4.2 =
https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_4.2

Change owner(s): Josef Stříbný <jstribrny <at> redhat.com>, Vít Ondruch 
<vondruch <at> redhat.com>, ruby-sig <at> lists.fedoraproject.org 

Ruby on Rails 4.2 is the latest version of well know web framework written in 
Ruby.

Note: This change might be changed to Rails 5. 

== Detailed Description ==
The Ruby on Rails stack is evolving quickly and Fedora needs to keep pace with 
it. Therefore the whole Ruby on Rails stack should be updated from 4.1 in 
Fedora 21 to 4.2 (latest version) in Fedora 22. This will ensure that all the 
Ruby developers using Fedora have the latest and greatest RPM-packaged Ruby on 
Rails. 

== Scope ==
* Proposal owners:
** The whole Rails stack has to be updated
** Some dependencies of the Rails stack will need update

For set of updated packages, see Change page.

* Other developers: Update Rails dependent packages to be working with Ruby on 
Rails 4.2 

* Release engineering: Not needed. 
* Policies and guidelines: Not needed
_______________________________________________
devel-announce mailing list
devel-announce <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Jaroslav Reznik | 12 Dec 15:44 2014
Picon

F22 System Wide Change: UEFI Secure Boot Blacklist Updates

= Proposed System Wide Change: UEFI Secure Boot Blacklist Updates =
https://fedoraproject.org/wiki/Changes/UEFISecureBootBlacklistUpdates

Change owner(s): Peter Jones <pjones <at> redhat.com>

Currently our implementation of UEFI Secure Boot does not include a facility 
to apply blacklist ("dbx") updates enabled by default. We provide a utility, 
dbxtool, which uses a systemd service to apply updates, and when there are 
updates we update that package with the new data. dbxtool is currently not 
installed on UEFI machines by default, and when it is installed, its systemd 
service does not default to enabled. 

== Detailed Description ==
In UEFI Secure Boot, the ability for a pre-boot binary such as a bootloader or 
hardware maintenance utility to be executed is determined by a whitelist of 
binaries and cryptographic signing certificates, as well as a blacklist of 
binaries and signing certificates which are no longer considered valid. When a 
signed binary is discovered to have vulnerabilities which allow it to be used 
to circumvent the Secure Boot security model, and thus render the system 
unable to prevent execution of pre-boot malware, the UEFI CA, in coordination 
with the UEFI Security Response Team (USRT) and the relevant software vendor, 
must undertake remedial action. The software vendor must fix their 
vulnerability and issue a new version of the software, and the old software 
must be blocked from execution on applicable machines.

The first task is up to the vendor in question. Once the new version is ready 
(or when sufficient time has passed), if a vulnerability is being actively 
exploited or has a sufficiently high likelihood of being so, the UEFI CA issues 
a blacklist entry in the form of an update to the UEFI variable "dbx". That 
update is a cryptographically signed list of binaries and/or signing 
certificates in a format which may be appended to a specific UEFI variable.

Currently Fedora includes the dbxtool [1] utility for updating the UEFI dbx 
blacklist. The dbxtool package includes the most recent UEFI CA blacklist 
update (they each include all data, so previous versions are not required) and 
a systemd service to ensure the update is applied to the system. Currently 
dbxtool is not installed by default on applicable systems, and when it is 
installed, its service is not enabled by default.
This change principally takes place in three packages:

* shim-signed must include a dependency on dbxtool
* dbxtool must have systemd %pre and %post scriptlets added
* systemd must include dbxtool.service in its 90-default.preset

== Scope ==
* Proposal owners: Implement proposed change
* Other developers: potentially the systemd-maint team, though I think I can 
commit the applicable change there.
* Release engineering: N/A
* Policies and guidelines: If we're keeping a list somewhere of things allowed 
to have system preset services, dbxtool should be added.

[1] https://github.com/vathpela/dbxtool
_______________________________________________
devel-announce mailing list
devel-announce <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
--

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

Gmane