F27 System Wide Change: Switch libidn-using applications to IDNA2008

[Jan Kurik]

= Proposed System Wide Change: Switch libidn-using applications to IDNA2008 =
https://fedoraproject.org/wiki/Changes/IDNA2008

Change owner(s):
* Nikos Mavrogiannopoulos 
* Robert Scheck 

The proposed change is about deprecating libidn, which supports
IDNA2003, and switch all applications using libidn, to libidn2 2.0.0,
which supports IDNA2008.


== Detailed Description ==
Internationalized domain names exist for quite some time (IDNA2003),
although the protocols describing them have evolved in an incompatible
way (IDNA2008). These incompatibilities will prevent applications
written for IDNA2003 to access certain problematic domain names
defined with IDNA2008, e.g., faß.de is translated to domain
xn--fa-hia.de with IDNA2008, while in IDNA2003 it is translated to
fass.de domain. That not only causes incompatibility problems, but may
be used as an attack vector to redirect users to different web sites.

The proposed change is about deprecating libidn, which supports
IDNA2003, and switch all applications using libidn, to libidn2 2.0.0,
which supports IDNA2008. The switch should be transparent as the
libidn2 library is API compatible.

Note that even in the web browsers, field there is much confusion on
the topic. Chromium appears to use IDNA2008 transitional (i.e.,
IDNA2003 mapping for the problematic characters), while Firefox and
Safari have already moved to IDNA2008.

For more information see:
* http://nmav.gnutls.org/2017/04/the-mess-with-internationalized-domain.html
* https://www.plesk.com/blog/what-is-the-problem-with-s/
* http://unicode.org/faq/idn.html#6


== Scope ==
* Proposal owners:
The proposal owner is expected to co-ordinate and fill the required
bugs on the distribution.

* Other developers:
Maintainers, should
- Verify that their software is linked with the libidn library
- Update the software from upstream if it already has been converted to libidn2
- Check the libidn2 instructions on converting a package to libidn2.
- Propose patches (trivial task) to convert to libidn2, and notify
upstream about it.
In short switch software from libidn to libidn2, it is sufficient
replacing idna.h header with idn2.h.

* Release engineering:
This feature requires not action from release engineering.

* Policies and guidelines:
Currently Fedora has no guidelines for IDNA support. With this change
the recommended guideline for applications would be to support
IDNA2008 by default.

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora Rawhide-20170403.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Xfce raw-xz armhfp
Minimal raw-xz armhfp

Failed openQA tests: 28/107 (x86_64), 8/18 (i386)

New failures (same test did not fail in Rawhide-20170402.n.0):

ID: 75246   Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/75246
ID: 75248   Test: x86_64 Server-dvd-iso server_cockpit_default
URL: https://openqa.fedoraproject.org/tests/75248
ID: 75252   Test: x86_64 Server-dvd-iso server_role_deploy_database_server
URL: https://openqa.fedoraproject.org/tests/75252
ID: 75255   Test: x86_64 Server-dvd-iso server_firewall_default
URL: https://openqa.fedoraproject.org/tests/75255
ID: 75257   Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/75257
ID: 75265   Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/75265
ID: 75266   Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/75266
ID: 75275   Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/75275
ID: 75276   Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/75276
ID: 75279   Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/75279
ID: 75280   Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/75280
ID: 75281   Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/75281
ID: 75282   Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/75282
ID: 75283   Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/75283
ID: 75284   Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/75284
ID: 75292   Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/75292
ID: 75294   Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/75294
ID: 75300   Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/75300
ID: 75301   Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/75301
ID: 75305   Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/75305
ID: 75306   Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/75306
ID: 75307   Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/75307
ID: 75308   Test: x86_64 universal install_kickstart_firewall_disabled
URL: https://openqa.fedoraproject.org/tests/75308
ID: 75309   Test: x86_64 universal install_kickstart_firewall_configured
URL: https://openqa.fedoraproject.org/tests/75309
ID: 75317   Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/75317
ID: 75321   Test: x86_64 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/75321
ID: 75332   Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/75332
ID: 75333   Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/75333
ID: 75345   Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/75345
ID: 75347   Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/75347
ID: 75348   Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/75348
ID: 75350   Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/75350
ID: 75356   Test: i386 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/75356
ID: 75361   Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/75361
ID: 75362   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/75362
ID: 75363   Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/75363

Soft failed openQA tests: 9/18 (i386)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test did not soft fail in Rawhide-20170402.n.0):

ID: 75260   Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/75260
ID: 75261   Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/75261
ID: 75353   Test: i386 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/75353
ID: 75354   Test: i386 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/

Fedora 26-20170403.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Cloud_base qcow2 x86_64
Cloud_base raw-xz x86_64
Xfce raw-xz armhfp

Failed openQA tests: 12/108 (x86_64), 5/18 (i386), 1/2 (arm)

New failures (same test did not fail in 26-20170402.n.0):

ID: 75371   Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/75371
ID: 75373   Test: x86_64 Server-dvd-iso server_cockpit_default
URL: https://openqa.fedoraproject.org/tests/75373
ID: 75385   Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/75385
ID: 75389   Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/75389
ID: 75397   Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/75397
ID: 75399   Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/75399
ID: 75407   Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/75407
ID: 75416   Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/75416
ID: 75418   Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/75418
ID: 75420   Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/75420
ID: 75429   Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/75429
ID: 75434   Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/75434
ID: 75438   Test: x86_64 universal install_kickstart_nfs
URL: https://openqa.fedoraproject.org/tests/75438
ID: 75473   Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/75473
ID: 75476   Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/75476
ID: 75478   Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/75478
ID: 75489   Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/75489
ID: 75490   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/75490

Soft failed openQA tests: 1/108 (x86_64), 9/18 (i386)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test did not soft fail in 26-20170402.n.0):

ID: 75386   Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/75386
ID: 75435   Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/75435
ID: 75481   Test: i386 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/75481
ID: 75482   Test: i386 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/75482
ID: 75483   Test: i386 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/75483
ID: 75484   Test: i386 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/75484
ID: 75485   Test: i386 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/75485
ID: 75486   Test: i386 universal install_btrfs
URL: https://openqa.fedoraproject.org/tests/75486
ID: 75487   Test: i386 universal install_ext3
URL: https://openqa.fedoraproject.org/tests/75487
ID: 75488   Test: i386 universal install_lvmthin
URL: https://openqa.fedoraproject.org/tests/75488

Passed openQA tests: 91/108 (x86_64), 4/18 (i386)

New passes (same test did not pass in 26-20170402.n.0):

ID: 75364   Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/75364
ID: 75365   Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/75365
ID: 75366   Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/75366
ID: 75367   Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/75367
ID: 75368   Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/75368
ID: 75369   Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/75369
ID: 75370   Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/75370
ID: 75377   Test: x86_64 Server-dvd-iso server_role_deploy_database_server
URL: https://openqa.fedoraproject.org/tests/75377
ID: 75378   Test: x86_64 Server-dvd-iso server_database_client
URL: https://openqa.fedoraproject.org/tests/75378
ID: 75379   Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/75379
ID: 75380   Test: x86_64 Server-dvd-iso server_firewall_default
URL: https://openqa.fedoraproject.org/te

Re: Upgrade path w/ new compat package

[Vít Ondruch]

Dne 3.4.2017 v 21:35 Christopher napsal(a):
> There seem to be a lot of possible guidance on the Wiki for what I'm
> trying to do, but no clear, unambiguous step-by-step path to follow.
> So, I'm seeking advice here.
>
> js-jquery provides jquery 2.x and js-jquery 2.x
> js-jquery1 provides jquery 1.x and js-jquery1 1.x
>
> I want to upgrade js-jquery to 3.x and provide js-jquery2.
> I want to do this efficiently with a minimum amount of time spent in
> reviews.
>
> I *think* the process is:
>
> 1. Create package review for new package js-jquery2
> a. Create js-jquery2 from current js-jquery packaging (with rename)
> b. js-jquery2 should provide jquery 2.x and js-jquery2 2.x
> c. js-jquery2 should obsolete 'js-jquery < 3'

Please do not obsolete anything. For rubygem-jquery-rails, I'd like to
use jQuery 1.x, 2.x as well as 3.x

> 2. Work with depending packages to either upgrade or switch to js-jquery2

Optionally, where feasible.

> 3. Update js-jquery to version 3.x
> a. wait until after js-jquery2 is stable, and push a normal update
> to version 3
>
> Are there any details I'm missing? Any corrections to my understanding
> of the process?
>
> I'd only be targeting F26+ for this change, and hope to get it done
> quickly.

Please do these changes just in Rawhide.


Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

gparted corrupts when shrinking ntfs

[John Reiser]

When I use Fedora 25 Workstation Live plus gparted to shrink an ntfs partition,
then the result is corrupt.  This is reproducible on a minimal install
of Windows 10 build 1510 (a raw system image dump fits on 2 DVD),
such as commonly available on inexpensive refurbished PCs.  Running CHKDSK
immediately afterward detects and fixes the corruption for me.
Where/how should I start to investigate: which software component, etc.?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Fedocal] Reminder meeting : Modularity WG (once every two weeks)

[jkurik]

Dear all,

You are kindly invited to the meeting:
   Modularity WG (once every two weeks) on 2017-04-04 from 15:00:00 to 16:00:00 
UTC
   At fedora-meetin...@irc.freenode.net

The meeting will be about:
Meeting of the Modularity Working Group.

More information available at: [Modularity Working Group wiki 
page](https://fedoraproject.org/wiki/Modularity_Working_Group)

The agenda for the meeting is available at [modularity-wg-agendas 
pad](http://piratepad.net/modularity-wg-agendas).



Source: https://apps.fedoraproject.org/calendar/meeting/5249/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Upgrade path w/ new compat package

[Michael Schwendt]

On Mon, 03 Apr 2017 19:35:24 +, Christopher wrote:

> There seem to be a lot of possible guidance on the Wiki for what I'm trying
> to do, but no clear, unambiguous step-by-step path to follow. So, I'm
> seeking advice here.
> 
> js-jquery provides jquery 2.x and js-jquery 2.x
> js-jquery1 provides jquery 1.x and js-jquery1 1.x
> 
> I want to upgrade js-jquery to 3.x and provide js-jquery2.
> I want to do this efficiently with a minimum amount of time spent in
> reviews.
> 
> I *think* the process is:
> 
> 1. Create package review for new package js-jquery2
> a. Create js-jquery2 from current js-jquery packaging (with rename)
> b. js-jquery2 should provide jquery 2.x and js-jquery2 2.x
> c. js-jquery2 should obsolete 'js-jquery < 3'
> 2. Work with depending packages to either upgrade or switch to js-jquery2
> 3. Update js-jquery to version 3.x
> a. wait until after js-jquery2 is stable, and push a normal update to
> version 3
> 
> Are there any details I'm missing? Any corrections to my understanding of
> the process?
> 
> I'd only be targeting F26+ for this change, and hope to get it done quickly.

Step 1 may cause problems already.

You can only safely replace js-query < 3 with a different package, if all
existing packages, which explicitly depend on js-query, either do it with
a specific version or continue to work also with js-query >= 3.
The reason for that is that renaming/replacing packages only works
flawlessly, if there is a strict dependency somewhere (such as with shared
libs and SONAME deps or a dependency on some API/ABI Provides)
or if the code is compatible enough to also work with the new js-query
package. Some Requires on js-jquery are non-versioned. Others use ">=".

They would all need to be examined before replacing any package. Step 1.c
would work for already installed packages, but new installs would pull in
the upgraded js-query to satisfy a weak or non-versioned Requires, OR
solve the dep via the js-jquery Provides from the new js-jquery2 package.

Step 2 sounds strange, because it would come too late, if anyone needed
to adjust explicit Requires from js-jquery something to js-jquery2.
Either the renaming of the package in step 1 has worked already, or the
replacement package has broken deps. If some deps strictly need v2,
their Requires ought to be fixed before upgrading/replacing anything.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Upgrade path w/ new compat package

[Christopher]

There seem to be a lot of possible guidance on the Wiki for what I'm trying
to do, but no clear, unambiguous step-by-step path to follow. So, I'm
seeking advice here.

js-jquery provides jquery 2.x and js-jquery 2.x
js-jquery1 provides jquery 1.x and js-jquery1 1.x

I want to upgrade js-jquery to 3.x and provide js-jquery2.
I want to do this efficiently with a minimum amount of time spent in
reviews.

I *think* the process is:

1. Create package review for new package js-jquery2
a. Create js-jquery2 from current js-jquery packaging (with rename)
b. js-jquery2 should provide jquery 2.x and js-jquery2 2.x
c. js-jquery2 should obsolete 'js-jquery < 3'
2. Work with depending packages to either upgrade or switch to js-jquery2
3. Update js-jquery to version 3.x
a. wait until after js-jquery2 is stable, and push a normal update to
version 3

Are there any details I'm missing? Any corrections to my understanding of
the process?

I'd only be targeting F26+ for this change, and hope to get it done quickly.

Thanks.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Qt 5.8 coming to rawhide

[Rex Dieter]

Dan Horák wrote:

> On Fri, 31 Mar 2017 12:04:36 -0500
> Rex Dieter  wrote:
> 
>> Rex Dieter wrote:
>> 
>> > Mostly fyi/heads-up,
>> > 
>> > kde-sig members imported Qt 5.8 into git over the weekend (kudos to
>> > heliocastro for initial packaging/copr and kkofler for merging
>> > import), and
>> > bootstrap builds are under way.
>> 
>> OK, I think we've got most builds either done or currently-underway.
>> Thanks to everyone that helped out.
>> 
>> I created a tracking bug for any remaining issues:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1438022
>> 
>> and 2 known (so far) related build failures:
>> qgnomeplatform https://bugzilla.redhat.com/show_bug.cgi?id=1438024
>> qt5-qtgamepad https://bugzilla.redhat.com/show_bug.cgi?id=1438027
> 
> I see issues with qt5-qtvirtualkeyboard and qt5-qt3d in the s390 koji,
> they fail because a broken dependency on docs in the buildroot
> 
> No matching package to install: 'qt5-qtsvg-doc'
> resp.
> No matching package to install: 'qt5-qtxmlpatterns-doc'

Thanks, I'll take a look

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Tomasz Kłoczko]

On 3 April 2017 at 09:01, Pierre-Yves Chibon  wrote:

> Just a note that the email you are replying to wasn't send to the list.
> Such
> wording is not welcome on this list and does not reflect how we want the
> fedora
> devel list to be.
>

I know.
As you probably noticed I'm trying to not reply to such comments but this
one I found as kind good opportunity to tell something about m past and my
motivation.

Tomasz Kłoczko | Tel: 0774 1209067 | LinkedIn: *http://lnkd.in/FXPWxH
*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Self Introduction: Bart Kessels

[Silvia Sanchez]

Hi, Bart,
Welcome here! I'm interested in your project, I know Python and
C.  Where I can find it to take a look?
Thanks,Silvia

On Fri, 2017-03-31 at 23:54 +0200, Bart Kessels wrote:
> Hello,
> 
> I am Bart Kessels and I'm a developer from the Netherlands.
> Right now I'm still in college studying computer science and I'd
> like to experience the open source development world. I've only
> worked for closed source companies so I can't link to any of the
> project I've worked on but I'd like to get more involved in the
> open source community (so far I've been only using it).
> I've spend most of that time working on Android apps (using Java) and
> right now I'm learning Gtk with Python and a bit of C++.
> 
> I've just submitted my first project, GetIt, which is a HTTP request
> application, like PostMan but opensource.
> 
> Best wishes,
> 
> Bart Kessels___
> 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: Is Pagure slow for you too?

[Silvia Sanchez]

Hello!
I had some issues to login but Pagure itself is working very nicely,
very fast.  I'm in Germany, in case that changes anything.
Thanks for the great work!Silvia

On Thu, 2017-03-30 at 09:43 +0200, Jiri Eischmann wrote:
> Kevin Fenzi píše v St 29. 03. 2017 v 13:01 -0600:
> > On 03/27/2017 11:35 PM, Adam Williamson wrote:
> > > It never used to be like that, it's probably just load as more
> > > and
> > > more
> > > stuff is moved to it.
> > 
> > yeah. Note that I mentioned upthread that we had been working on
> > performance improvements of late. We just rolled out a new version
> > this
> > morning that has a number of them.
> > 
> > For those that were seeing things be slow: Any improvement?
> > 
> > (There is of course more work to be done...)
> > 
> > kevin
> 
> It seems much faster today. I've never seen Pagure being so fast
> before.
> Thank you for the work!
> 
> Jiri___
> 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: Non-versioned Obsoletes tags

[Michael Schwendt]

On Mon, 03 Apr 2017 11:30:38 +0200, Igor Gnatenko wrote:

> That wasn't call to change anything,

I know.

> I don't want to change anything,

I know.

> RPM behavior is not interesting because it is just evaluating constraints,
> nothing else. Interesting thing is depsolving - libsolv.

Maybe, but the level of comments like that is not deep enough. In the end it is
RPM that is given a transaction set to process, and it doesn't know about any
packages you don't tell it about.

Nowhere in this "thread of doom" somebody has explained *why* current depsolvers
show behaviour that has influenced our packaging guidelines. Reduced/simplified
test-cases aren't worth a penny then. Unfortunately.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Non-versioned Obsoletes tags

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, 2017-04-03 at 11:18 +0200, Michael Schwendt wrote:
> On Sat, 01 Apr 2017 19:54:28 +0200, Igor Gnatenko wrote:
> 
> > repo system 0 testtags 
> > #>=Pkg: foo-static 1 1 x86_64  
> > repo available 0 testtags 
> > #>=Pkg: bar 1 1 x86_64
> > #>=Obs: foo-static
> > #>=Pkg: foo-static 2 1 x86_64  
> > system x86_64 rpm system
> > poolflags implicitobsoleteusescolors
> > solverflags allowvendorchange keepexplicitobsoletes bestobeypolicy
> > keeporphans yumobsoletes
> > job update all packages 
> > result transaction,problems 
> > #>erase foo-static-1-1.x86_64@system bar-1-1.x86_64@available
> > #>install bar-1-1.x86_64@available  
> 
> Here again, a single test is insufficient, if there is no commentary
> that
> explains what the defined behaviour of the RPM backend is and that
> there
> is no alternative solution. Only with documentation of defined
> behaviour
> one could conclude that no other solution exists and that the shown
> behaviour matches the test target.
> 
> If wanting to move forward, anyone raising doubts about the current
> handling of non-versioned Obsoletes tags (and Obsoletes tags in
> general)
> during update transactions, would need to start at the very beginning
> and
> analyze how RPM (_not_ only "rpm -Uvh") can handle Obsoletes in sets
> of
> installed *and* available packages. Based on that, one can come up
> with
> strategies for depsolving based on repo/package metadata, such as
> evaluation order of PRCO or whether and when to ignore older NEVR of
> a
> package where multiple EVRs are found.
That wasn't call to change anything, it was example why we MUST stick
with versioned obeolstes. RPM behavior is not interesting because it is
just evaluating constraints, nothing else. Interesting thing is
depsolving - libsolv.
> 
> Some day I've had a fruitless discussion with Seth Vidal about
> behaviour
> of "yum install foo" and whether it should fetch only the very latest
> package that provides "foo", evaluating Obsoletes and updates
> already,
> or whether it may install any old EVR it finds in the repos and only
> handle available updates/uprades and Obsoletes in subsequent "yum
> update"
> runs. Yum, for example, installed an old package release only to
> replace
> it with an available update immediately afterwards when running "yum
> update".
> Some of the behaviour of tools is based on arbitrary definition by
> developers and possibly not because of strict technical requirements.
> Behaviour could be changed, but not without agreement from the devs.
> If
> you want to change something about handling non-versioned Obsoletes,
> the
> whole thing must be examined at a much deeper level and under
> consideration
> of any documentation there may be that gives a rationale about the
> behaviour
> of current tools and backends.
I don't want to change anything, I'm pretty happy with current
guidelines (moreover, I was asking to make ALL obsoletes versioned some
months ago but didn't got to the point of mass bug filing).
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAljiFj4ACgkQaVcUvRu8
X0yAoA/+Kcddo90AS9tBg7XLLn39P9sR/ly+i4n7en8sGr1C8PEWV0N3J4914UjR
/lAxW4s62evq4/d9xKhWI+EGIcufCweS8/egpJq3EVmStSujJoPZJlhoxiwKQeWV
MHxr5iPuu/oUeDCHecXHkfhGC3bG1ok6PjTvC129ABEYhJrSEkA1rC9yZgUm3pFa
l3MrPIoT+R9SzTjYaIFYSI6drE9hnU+sF9aVMYfPzSdLiSM2Mi0oj7bVU28mhxJ3
9O6BkHowXOFP3s7WA2asBSw7LETe74htXGRmlEovppcJwYmd12qHF7EM+YakfMVk
rBxkM4JEmPjGjp9GVRvtLWHf+FTo41amz+i+WU6Caaa1M7APymoy+sVk5Dlu4iM1
Tfpzj/Y8FlzI6bPcqu7YuKHF7ckWRlXY8h/gVspBFm1RZPxy8WnTpCEUGZ9L0C4r
GycIREUYFWMk82Vu822qJwGSx4TmqDfcsvyNSgsUdxqRL9L051LC3cKtmohl+vJn
BWJWTTu5fWf0eUFDwzwhGHpL+9zKeUkxSZnkIFnc/Fm+FalcXLZQTeZbKqhXR6rs
PKDwkP2guLmrxCGjpnSMk/qaDamZuQPYrpXecVlF+5L9Lke/mqKdHrmHN7F8smcN
1UkkBSF9meITMlnvJTSJzEdOwv9DSh8Ok44c4hhRiTlq0Cv/U1I=
=HhcG
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Non-versioned Obsoletes tags

[Michael Schwendt]

On Sat, 01 Apr 2017 19:54:28 +0200, Igor Gnatenko wrote:

> repo system 0 testtags 
> #>=Pkg: foo-static 1 1 x86_64  
> repo available 0 testtags 
> #>=Pkg: bar 1 1 x86_64
> #>=Obs: foo-static
> #>=Pkg: foo-static 2 1 x86_64  
> system x86_64 rpm system
> poolflags implicitobsoleteusescolors
> solverflags allowvendorchange keepexplicitobsoletes bestobeypolicy
> keeporphans yumobsoletes
> job update all packages 
> result transaction,problems 
> #>erase foo-static-1-1.x86_64@system bar-1-1.x86_64@available
> #>install bar-1-1.x86_64@available  

Here again, a single test is insufficient, if there is no commentary that
explains what the defined behaviour of the RPM backend is and that there
is no alternative solution. Only with documentation of defined behaviour
one could conclude that no other solution exists and that the shown
behaviour matches the test target.

If wanting to move forward, anyone raising doubts about the current
handling of non-versioned Obsoletes tags (and Obsoletes tags in general)
during update transactions, would need to start at the very beginning and
analyze how RPM (_not_ only "rpm -Uvh") can handle Obsoletes in sets of
installed *and* available packages. Based on that, one can come up with
strategies for depsolving based on repo/package metadata, such as
evaluation order of PRCO or whether and when to ignore older NEVR of a
package where multiple EVRs are found.

Some day I've had a fruitless discussion with Seth Vidal about behaviour
of "yum install foo" and whether it should fetch only the very latest
package that provides "foo", evaluating Obsoletes and updates already,
or whether it may install any old EVR it finds in the repos and only
handle available updates/uprades and Obsoletes in subsequent "yum update"
runs. Yum, for example, installed an old package release only to replace
it with an available update immediately afterwards when running "yum update".
Some of the behaviour of tools is based on arbitrary definition by
developers and possibly not because of strict technical requirements.
Behaviour could be changed, but not without agreement from the devs. If
you want to change something about handling non-versioned Obsoletes, the
whole thing must be examined at a much deeper level and under consideration
of any documentation there may be that gives a rationale about the behaviour
of current tools and backends.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Pierre-Yves Chibon]

On Sun, Apr 02, 2017 at 08:49:18PM +0100, Tomasz Kłoczko wrote:
>On 2 April 2017 at 16:25, Reindl Harald  wrote:
> 
>  funny that one assumes you can enter "fedora FPC" in a search engine
>  after playing smart-ass in so many mails and it's your namend
>  responisiblity to inform yourself about the distribution *before* you
>  write hundrets of completly unqualified and uneducated mails about a
>  parallel universe wher you have done so much things without namimg the
>  distribution and the reasons why you are no longer there
> 
>I really don't like when someone during discussion when I'm tryin bring as
>much facts as I can or tests (or similar things used in civilised
>discussion), and someone is not able to to respond on similar level is
>turning conversation (because it is no longer discussion) to "ad personam"
>reply.

Just a note that the email you are replying to wasn't send to the list. Such
wording is not welcome on this list and does not reflect how we want the fedora
devel list to be.

Sorry about this.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Pierre-Yves Chibon]

On Sun, Apr 02, 2017 at 09:25:55PM +0100, Tomasz Kłoczko wrote:
>On 2 April 2017 at 17:06, Jens Lody  wrote:
> 
>  Fedora Packaging Committee:
>  https://fedoraproject.org/wiki/Packaging_Committee?rd=FPC
> 
>Just humle question: why I should contact FPC about two bugs which I found
>in dnf? Comment about contacting FPC was straight under my comment about
>these bugs.
>This committee seems has nothing to do with dnf development.
>And/or as long as no one still confirmed that what I see in result of my
>test unit is real still I have nothing to submit about change anything in
>current packaging methodology.
>Sorry but I'm a bit confused now :-L

This committee is what controls what is and what isn't part of the Fedora
Packaging Guidelines.
So while dnf bugs should be reported on bugzilla, any changes at the policy
level should go through the Fedora Package Committee.
With the understanding that under the current FPG what you are presenting as a
bug in dnf might not be considered as such by the dnf developers, thus potential
need to go to the FPC to get the FPG changed.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org