Re: Fedora Hardware portal

[Andrey Ponomarenko]

30.11.2018, 01:58, "Matthew Miller" :
> On Thu, Nov 29, 2018 at 04:57:33PM +0300, Andrey Ponomarenko wrote:
>>  https://github.com/linuxhw/hw-probe (various packages are available:
>>  AppImage, Snap, Flatpak, Docker, RPM, etc.). The tool is intended to
>
> Have you considered packaging this directly in Fedora? That would make it a
> lot easier for users to just run the program.
>

Pending updates:

f28: https://bodhi.fedoraproject.org/updates/FEDORA-2018-87931d1bc0
f29: https://bodhi.fedoraproject.org/updates/FEDORA-2018-780496d498

Please vote to achieve stable threshold.

el6/el7: waiting for hwinfo/libx86emu 
(https://src.fedoraproject.org/rpms/hwinfo/pull-requests, 
https://src.fedoraproject.org/rpms/libx86emu/pull-requests)

Thank you.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Self Introduction: Andrey Ponomarenko

[Andrey Ponomarenko]

Hi all,

I'm upstream author of the abi-compliance-checker, abi-dumper, 
api-sanity-checker and pkgdiff Fedora packages, maintainer of the 
https://abi-laboratory.pro/?view=tracker and developer (in the past) of the LSB 
Infrastructure project and LSB Core tests.

Since 2014 I am passionate about the Linux hardware compatibility. The result 
of my work in this area is the hw-probe tool that checks operability of devices 
on computer board by collecting and analysis of hardware related system logs 
and outputs of other tools like lspci, lsusb, hwinfo, smartctl, etc. Most 
interesting hardware logs and statistics are dumped to the Github repository so 
that anyone can perform any kind of analysis: https://github.com/linuxhw/

Most interesting stats are:

* Reliability of hard drives: https://github.com/linuxhw/SMART
* Devices with poor Linux-compatibility: https://github.com/linuxhw/HWInfo

Adding this package to Fedora will improve stats and may simplify sharing of 
multiple logs between developers and users of the Fedora platform. Private info 
is removed from logs at client-side (username, machine's hostname, IP 
addresses, MAC addresses, serial numbers, etc.), so sharing a probe link is 
more safe than attaching original system logs.

Review Request: https://bugzilla.redhat.com/show_bug.cgi?id=1655421

Can someone take this package or sponsor me to maintain it?

It's a simple noarch package with a simple spec file.

Thank you!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Hardware portal

[Andrey Ponomarenko]

30.11.2018, 01:58, "Matthew Miller" :
> On Thu, Nov 29, 2018 at 04:57:33PM +0300, Andrey Ponomarenko wrote:
>>  https://github.com/linuxhw/hw-probe (various packages are available:
>>  AppImage, Snap, Flatpak, Docker, RPM, etc.). The tool is intended to
>
> Have you considered packaging this directly in Fedora? That would make it a
> lot easier for users to just run the program.
>

Review request: https://bugzilla.redhat.com/show_bug.cgi?id=1655421

I use the same spec to build Fedora rpm package on OBS: 
https://build.opensuse.org/package/show/home:linuxbuild/hw-probe

Could you review it?

Thank you.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora Hardware portal

[Andrey Ponomarenko]

Hi,

The Linux-Hardware.org database has been divided recently into a set of 
databases, one per each Linux distro. The one for Fedora is available at:

https://linux-hardware.org/?d=Fedora

Everyone can contribute to the database with the help of 
https://github.com/linuxhw/hw-probe (various packages are available: AppImage, 
Snap, Flatpak, Docker, RPM, etc.). The tool is intended to simplify collecting 
of hardware info and logs necessary for investigating hardware related 
problems. You need to execute only one simple command to collect all system 
logs at once:

sudo hw-probe -all -upload

Hardware failures are highlighted in the collected logs (important SMART 
attributes, errors in dmesg and xorg.log, etc.). Also it's handy to search for 
particular hardware configurations in the community and review errors in logs 
to check operability of devices on board (for some devices this is done 
automatically by hw-probe — see statuses of devices in your probe).

Hardware stats and raw data are dumped to Github repositories: 
https://github.com/linuxhw

Enjoy!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Reliability test for hard drives and SSD

[Andrey Ponomarenko]

07.08.2018, 12:05, "Jan Kratochvil" :
> Hello,
>
> On Tue, 07 Aug 2018 10:21:05 +0200, Andrey Ponomarenko wrote:
>>  sudo dnf config-manager --add-repo 
>> https://download.opensuse.org/repositories/home:/linuxbuild/Fedora_Rawhide/home:linuxbuild.repo
>>  sudo dnf config-manager --set-enabled home_linuxbuild
>>  sudo dnf install hw-probe
>
> that looks better, thanks. Still it is from non-Fedora build but then it
> contains only a text script anyway.
>
>>  It's better to use lightweight all-in-one AppImage (F15 and higher) or Snap
>>  (F26 and higher):
>>
>>  https://github.com/linuxhw/hw-probe#appimage
>>  https://github.com/linuxhw/hw-probe#snap
>
> I do not like recommending such insecure behavior - to run untrusted binaries
> with root permissions - without even warning it is insecure.
>
>>  Usually people don't create more than two probes per computer, so receiving
>>  updates is not necessary.
>
> It is insecure to keep non-updated software installed/available on your
> computer.
>
> Anyway it somehow does not work for me, in the past I registered
> https://linux-hardware.org/?probe=bf0a7f04b4
>
> But now I cannot update the info trying to prevent a duplicate:
> # hw-probe -get-inventory-id
> Group ID: 8557d9ad
> # hw-probe -inventory-id bf0a7f04b4
> # hw-probe -get-inventory-id
> Group ID: 4d2703f5
> # hw-probe -inventory-id bf0a7f04b4
> # hw-probe -get-inventory-id
> Group ID: 07746fb5
> # hw-probe -get-inventory-id
> Group ID: 077ce20e
> # hw-probe -inventory-id 0xbf0a7f04b4
> # hw-probe -get-inventory-id
> Group ID: 7b448de5
> # hw-probe -get-inventory-id
> Error request
> # hw-probe -get-inventory-id
> Error request

1) Yep, it's safer to have a package in the official Fedora repositories. Spec 
is available in the OBS project: 
https://build.opensuse.org/package/view_file/home:linuxbuild/hw-probe/hw-probe.spec?expand=1

2) The -get-inventory-id option creates a new inventory id (or 'group') to mark 
new probes by this id. You've created too many inventory ids per day and 
received an error when trying to create more. Usually it's enough to have only 
one inventory id.

bf0a7f04b4 is a probe id (10-digit), not the inventory id. Your inventory id is 
8557d9ad (8-digit). Just use it to mark all your future probes with the help of 
-inventory-id option:

sudo hw-probe -all -upload -inventory-id G

It's enough to mark each unique computer once.

The command:

hw-probe -inventory-id G

does nothing without -all and -upload options.

The command:

hw-probe -get-inventory-id

creates a new group/inventory id (G) each time.

Thank you.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LMGAVYSMRFHW6HYT3WXL4NSAOSOAXUOU/

Re: Library ABI change

[Andrey Ponomarenko]

06.08.2018, 12:49, "Daniel P. Berrangé" :
> On Mon, Aug 06, 2018 at 09:30:39AM +0200, Guido Aulisi wrote:
>>  recently serd library changed its ABI adding 1 function without
>>  bumping the soname.
>
> There's totally normal. It merely added to its ABI - it didn't change
> existing ABI so nothing will break. soname change is only for when
> the library deleted a symbol, or changed API contract of an existing
> symbol.
>
>>  I think adding one function should not be a problem for depending
>>  packages, what do you think about it?
>
> Correct, there's no problem. At the very most applications using the new
> API would want to explicitly require a particular version of the library
> RPM
>

ABI report for Serd:

https://abi-laboratory.pro/?view=timeline=serd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SQTR6H5S24JWFFL5GA2HU4TX42CZOYH2/

Re: Reliability test for hard drives and SSD

[Andrey Ponomarenko]

05.08.2018, 16:09, "Jan Kratochvil" :
> On Sun, 05 Aug 2018 14:47:06 +0200, Andrey Ponomarenko wrote:
>>  I've just created Fedora package for hw-probe. See
>>  
>> https://github.com/linuxhw/hw-probe/blob/master/INSTALL.md#install-on-fedora.
>
> Installing a package out of repository for its maintenance is not great.
> I tried to find a repository for it but what is Build vs. Publish
> vs. Use for Build?
> https://build.opensuse.org/repositories/home:linuxbuild/hw-probe
> COPR would be better for Fedora, until it is in standard Fedora distro.

sudo dnf config-manager --add-repo 
https://download.opensuse.org/repositories/home:/linuxbuild/Fedora_Rawhide/home:linuxbuild.repo
sudo dnf config-manager --set-enabled home_linuxbuild
sudo dnf install hw-probe

But it installs a lot of unused dependencies (about 140 packages on F28 Live). 
It's better to use lightweight all-in-one AppImage (F15 and higher) or Snap 
(F26 and higher):

https://github.com/linuxhw/hw-probe#appimage
https://github.com/linuxhw/hw-probe#snap

Usually people don't create more than two probes per computer, so receiving 
updates is not necessary.

Thank you.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NSU7KGC3SKFVNIVMXN26YP5LSHLS2EFR/

Re: Reliability test for hard drives and SSD

[Andrey Ponomarenko]

03.03.2018, 10:08, "Andrey Ponomarenko" :
> Hi there!
>
> Good news for all interested in hardware compatibility and reliability.
>
> I've started a new project to estimate reliability of hard drives and SSD in 
> real-life conditions based on the SMART data reports collected by Linux users 
> in the Linux-Hardware.org database since 2014. The initial data (SMART 
> reports), analysis methods and results are publicly shared in a new github 
> repository: https://github.com/linuxhw/SMART. Everyone can contribute to the 
> report by uploading probes of their computers by the hw-probe tool!
>
> The primary aim of the project is to find drives with longest "power on 
> hours" and minimal number of errors. The following formula is used to measure 
> reliability: Power_On_Hours / (1 + Number_Of_Errors), i.e. time to the first 
> error/between errors.
>
> Please be careful when reading the results table. Pay attention not only to 
> the rating, but also to the number of checked model samples. If rating is 
> low, then look at the number of power-on days and number of errors occurred. 
> New drive models will appear at the end of the rating table and will move to 
> the top in the case of long error-free operation.

Hi,

I've just created Fedora package for hw-probe. See 
https://github.com/linuxhw/hw-probe/blob/master/INSTALL.md#install-on-fedora.

The command to replenish the database:

sudo hw-probe -all -upload

AppImage is also available to run without installing: 
https://github.com/linuxhw/hw-probe#appimage

OBS project: https://build.opensuse.org/package/show/home:linuxbuild/hw-probe

Thank you.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DCIEHU32EH5E5MN6USL7QMWHGRDDA5F3/

List of devices with poor Linux compatibility

[Andrey Ponomarenko]

Hello,

A new open project has been created to collect the list of computer hardware 
devices with poor Linux compatibility based on the Linux-Hardware.org data 
within 4 years: https://github.com/linuxhw/HWInfo

There are about 29 thousands of depersonalized hwinfo reports 
(https://github.com/openSUSE/hwinfo) in the repository from Linux-powered 
computers in various configurations. The device is included into the list of 
poorly supported devices if there is at least one user probe in which the 
driver for this device was not found. The column 'Missed' indicates the 
percentage of such probes. If the number is small, it means that the driver was 
added in newer versions of the kernel. In this case we show minimal version of 
the Linux kernel in which the driver was present.

Devices are divided into categories. For each category we calculate the ratio 
of poorly supported devices to the total number of devices tested in this 
category.

Everyone can contribute to this repository by uploading probes of their 
computers by the hw-probe tool: https://github.com/linuxhw/hw-probe

Thanks to all for attention and new computer probes!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QKA7RRYGW35MEWBZBAYGPPKEP25C4GQC/

Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Andrey Ponomarenko]

Added qpdf to the ABI tracker: https://abi-laboratory.pro/tracker/timeline/qpdf/

27.02.2018, 21:16, "Adam Williamson" :
> qpdf was updated from 7.1.1-4 to 8.0.0-1 in Rawhide on 2018-02-26.
> This update bumped the soname from libqpdf.so.18 to libqpdf.so.21 .
> This soname bump was not announced, as it is supposed to be, and
> dependent packages were not rebuilt.
>
> cups-filters depends on qpdf, so anything that includes cups-filters is
> now broken. This includes at least the Astronomy_KDE live image, per
> https://pagure.io/dusty/failed-composes/issue/24#comment-496381 .
>
> Once again, folks, *please* announce your soname bumps, and co-ordinate
> rebuilds. (In fact it looks like Zdenek is the maintainer of both
> packages and could have rebuilt cups-filters, but just forgot to).
>
> I will attempt a rebuild of cups-filters using provenpackager
> privileges.
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> 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

Reliability test for hard drives and SSD

[Andrey Ponomarenko]

Hi there!

Good news for all interested in hardware compatibility and reliability.

I've started a new project to estimate reliability of hard drives and SSD in 
real-life conditions based on the SMART data reports collected by Linux users 
in the Linux-Hardware.org database since 2014. The initial data (SMART 
reports), analysis methods and results are publicly shared in a new github 
repository: https://github.com/linuxhw/SMART. Everyone can contribute to the 
report by uploading probes of their computers by the hw-probe tool!

The primary aim of the project is to find drives with longest "power on hours" 
and minimal number of errors. The following formula is used to measure 
reliability: Power_On_Hours / (1 + Number_Of_Errors), i.e. time to the first 
error/between errors.

Please be careful when reading the results table. Pay attention not only to the 
rating, but also to the number of checked model samples. If rating is low, then 
look at the number of power-on days and number of errors occurred. New drive 
models will appear at the end of the rating table and will move to the top in 
the case of long error-free operation.

Thanks to ROSA, Fedora, Ubuntu, Debian, Mint, openSUSE, Arch, Gentoo users and 
others who had made this work possible by contribution to the database!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

ABI Navigator

[Andrey Ponomarenko]

Hello, I'd like to present a new project called "ABI Navigator" for searching binary symbols (functions, methods, global data, etc.) in open-source libraries: https://abi-laboratory.pro/index.php?view=navigator The project allows to find out in which versions of libraries some symbol is defined, added, removed or changed. The data is taken from the ABI Tracker project (238 libraries and 0.9 million symbols currently): https://abi-laboratory.pro/tracker/ Example for _ZN5DbEnv10mutex_freeEm from libdb_cxx.so (Berkeley DB): https://abi-laboratory.pro/index.php?view=navigator=_ZN5DbEnv10mutex_freeEm The project aims to help Linux developers and maintainers to resolve issues with missed symbols and navigate through the reports in the ABI Tracker. Have you ever encountered the "undefined reference" error or want to know whether the symbol is _stable_ enough to use in your code? Try to find it in the ABI Navigator! Enjoy! ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Decompress debug-info compressed by dwz

[Andrey Ponomarenko]

Hello, Is there a way to decompress the debug-info compressed by dwz? The issue is that all compile units in the DWARF dump may depend on each other in the compressed debug-info and they can't be analyzed independently for this reason. In case of a big debug-info dump (>10Gb) I need a lot of RAM to load them all and analyze. Thank you.___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Hi Guys !

[Andrey Ponomarenko]

Jules Bashizi wrote:

I got admission into some British university and I am to buy a laptop .
wish to know a machine which is good with Linux . any advice on which and
where to get it  please !


Take a look at this list of laptops/notebooks tested with the Linux 
kernels from 3.14 to 4.1: 
http://hw.rosalinux.ru/index.php?show=machines=notebook


You can sort the list by the computer model and select a most popular one.

--
Andrey Ponomarenko

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

Re: Unannounced ABI change without soname bump in libevdev-0.6 in Rawhide (and F19 and F20...) breaks GNOME, probably other consumers

[Andrey Ponomarenko]

I've added libevdev to the ABI tracker for this reason: 
http://upstream-tracker.org/versions/libevdev.html


Adam Williamson wrote:

Time for another PSA...

It appears libevdev 0.6 breaks the library's ABI without bumping the
soname (and without an announcement here or anywhere else I can find,
but an ABI change without an soname bump is just flat out wrong whether
announced or not). 0.6 was sent to Rawhide, F19 and F20 simultaneously.

The ABI change breaks GNOME in F20 and Rawhide (because clutter was
using the calls that disappeared in the 0.6 build):

undefined symbol: LIBEVDEV_READ_NORMAL  (/lib/libclutter-1.0.so.0)
undefined symbol: LIBEVDEV_READ_SYNC(/lib/libclutter-1.0.so.0)


--
Andrey Ponomarenko, ROSA Lab.

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

Kernel ABI Tracker

[Andrey Ponomarenko]

Hi all,

There is a new tool available for Linux maintainers: Kernel ABI Tracker 
(http://upstream-tracker.org/kernel/).


This tool looks for new releases of the Linux kernel, builds them and 
tracks API/ABI changes using a set of basic tools: ABI Dumper and ABI 
Compliance Checker. The tool is intended for Linux maintainers and 
developers of device drivers/kernel modules who are interested in 
ensuring backward compatibility of the Linux kernel interfaces.


More info: 
http://wiki.rosalab.com/en/index.php/Blog:ROSA_Planet/Linux_Kernel_ABI_Tracker


--
Andrey Ponomarenko, ROSA Lab.

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

Re: Who uses abi-compliance-checker?

[Andrey Ponomarenko]

Sérgio Basto wrote:

On Qui, 2013-07-11 at 12:49 +0400, Andrey Ponomarenko wrote:

Sérgio Basto wrote:

On Qui, 2013-07-04 at 16:47 +0400, Andrey Ponomarenko wrote:

Starting with 1.6 version of pkgdiff if you compare debug packages
and
add --details option on the command line then the tool will
automatically run abi-dumper to dump ABI of old and new shared
objects
found in the packages and then compare them by the
abi-compliance-checker tool.

hum , so pkgdiff -details doesn't use abi-compliance-checker without
abi-dumper installed ?

Yes, it doesn't. Detailed checks of ABI changes in shared objects will
be disabled in this case. They are enabled only if you install both
tools and compare appropriate debug-info RPM packages.

ah ABI Status, just appears when we compare debuginfo packages (with
-details )




pkgdiff x264-0.130-3.20130502git1db4621.fc20.i686.rpm
x264-0.133-1.20130709git585324f.fc20.i686.rpm -details
ERROR: cannot find ABI Dumper
reading packages ...
comparing packages ...
creating changes report ...
result: CHANGED (18.4%)
see detailed report:

pkgdiff_reports/x264/0.130-3.20130502git1db4621.fc20_to_0.133-1.20130709git585324f.fc20/changes_report.html

Total Objects (with debug-info) 2
ABI Compatibility 70.8%


Cool thanks,

pkgdiff print some errors [1] are you interested in reports ?


[1] pkgdiff x264-debuginfo-0.130-3.20130502git1db4621.fc20.i686.rpm
x264-debuginfo-0.133-1.20130709git585324f.fc20.i686.rpm -details
reading packages ...
comparing packages ...
Compare ABIs of x264 (0.8M) ...
ERROR: missed type id 130179
ERROR: missed type id 131954
ERROR: missed type name (82925)
ERROR: missed type id 23828
ERROR: missed type id 132137
ERROR: missed type id 47285
ERROR: missed type id 47358
ERROR: missed type id 6333
ERROR: missed type id 134805
ERROR: missed type id 131958
ERROR: missed type id 134661
Compare ABIs of libx264.so.130 (2.3M) ...
ERROR: Failed to run ABI Compliance Checker (7)
Compare ABIs of libx26410b.so.130 (2.2M) ...
ERROR: Failed to run ABI Compliance Checker (7)
Compare ABIs of libx264.so.130 (2.4M) ...
ERROR: missed type id 36143
creating changes report ...
result: CHANGED (97.1%)
see detailed report:

pkgdiff_reports/x264-debuginfo/0.130-3.20130502git1db4621.fc20_to_0.133-1.20130709git585324f.fc20/changes_report.html




Readelf from elfutils reports invalid DWARF on libx264.so.130.debug:

$ eu-readelf --debug-dump=info libx264.so.130.debug

DWARF section [27] '.debug_info' at offset 0x50b:
 [Offset]
 Compilation unit at offset 0:
 Version: 4, Abbreviation section offset: 8442, Address size: 4, Offset 
size: 4

 [ b]  partial_unit
   stmt_list(sec_offset) 0
   comp_dir (form: 0x1f21) ???
eu-readelf: cannot get next DIE: invalid DWARF

Readelf from binutils reports:

$ readelf --debug-dump=info libx264.so.130.debug

Contents of the .debug_info section:

  Compilation Unit @ offset 0x0:
   Length:0xba (32-bit)
   Version:   4
   Abbrev Offset: 8442
   Pointer Size:  4
 0b: Abbrev Number: 105 (DW_TAG_partial_unit)
c   DW_AT_stmt_list   : 0x0
readelf: Warning: Unrecognized form: 7969
10   DW_AT_comp_dir:
 110: Abbrev Number: 7566
readelf: Warning: DIE at offset 10 refers to abbreviation number 7566 
which does not exist


Why debug objects in x264-debuginfo package are invalid?

--
Andrey Ponomarenko, ROSA Lab.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Who uses abi-compliance-checker?

[Andrey Ponomarenko]

Sérgio Basto wrote:

On Qui, 2013-07-04 at 16:47 +0400, Andrey Ponomarenko wrote:

Starting with 1.6 version of pkgdiff if you compare debug packages
and
add --details option on the command line then the tool will
automatically run abi-dumper to dump ABI of old and new shared
objects
found in the packages and then compare them by the
abi-compliance-checker tool.


hum , so pkgdiff -details doesn't use abi-compliance-checker without
abi-dumper installed ?


Yes, it doesn't. Detailed checks of ABI changes in shared objects will 
be disabled in this case. They are enabled only if you install both 
tools and compare appropriate debug-info RPM packages.





pkgdiff x264-0.130-3.20130502git1db4621.fc20.i686.rpm
x264-0.133-1.20130709git585324f.fc20.i686.rpm -details
ERROR: cannot find ABI Dumper
reading packages ...
comparing packages ...
creating changes report ...
result: CHANGED (18.4%)
see detailed report:

pkgdiff_reports/x264/0.130-3.20130502git1db4621.fc20_to_0.133-1.20130709git585324f.fc20/changes_report.html




--
Andrey Ponomarenko, ROSA Lab.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Who uses abi-compliance-checker?

[Andrey Ponomarenko]

Sérgio Basto wrote:

On Qua, 2013-07-03 at 15:03 -0500, Richard Shaw wrote:

I initially got abi-compliance-checker into Fedora because one of my
packages does not maintain any sort of API/ABI compatibility or even
versioning for that matter. That way I could always check a new
release to see if any of its dependencies needed to be rebuilt.


Since then, I've started using it for all of my libraries in the
spirit of Trust but verify, and I've occasionally found issues even
though upstream didn't bump the soversion.


So out of curiosity, anyone else using this great tool?


If anyone is curious about it, I don't mind typing up the process I go
through to make the checks. I think I've found a pretty good path of
least resistance method :)

could we use this tool on x264/ffmpeg/mplayer packages ?


See results of analysis for ffmpeg here:

  http://upstream-tracker.org/versions/ffmpeg.html

--
Andrey Ponomarenko, ROSA Lab.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Who uses abi-compliance-checker?

[Andrey Ponomarenko]

Xavier Bachelot wrote:

On 07/03/2013 10:03 PM, Richard Shaw wrote:

I initially got abi-compliance-checker into Fedora because one of my packages
does not maintain any sort of API/ABI compatibility or even versioning for that
matter. That way I could always check a new release to see if any of its
dependencies needed to be rebuilt.

Since then, I've started using it for all of my libraries in the spirit of
Trust but verify, and I've occasionally found issues even though upstream
didn't bump the soversion.

So out of curiosity, anyone else using this great tool?


I'm not using abi-compliance-checker by itself but through the pkgdiff wrapper.


Starting with 1.6 version of pkgdiff if you compare debug packages and 
add --details option on the command line then the tool will 
automatically run abi-dumper to dump ABI of old and new shared objects 
found in the packages and then compare them by the 
abi-compliance-checker tool.



I agree this tool is very helpful.


--
Andrey Ponomarenko, ROSA Lab.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Who uses abi-compliance-checker?

[Andrey Ponomarenko]

Remi Collet wrote:

But I also use http://upstream-tracker.org/
Very usefull, except for not yet released version.



For some libraries we check unreleased versions from the upstream source 
control (git, svn, etc.). See example: 
http://upstream-tracker.org/versions/libssh.html


--
Andrey Ponomarenko, ROSA Lab.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Who uses abi-compliance-checker?

[Andrey Ponomarenko]

Richard Shaw wrote:
This is an extreme example, but after removing the offending headers I 
got this:


https://dl.dropboxusercontent.com/u/34775202/compat_reports/ffmpeg/0.10.7_to_1.2.1/compat_report.html

Thanks,
Richard



New approach (by using the abi-dumper tool) avoids such problems with 
compiling header files. But if you are using basic approach then you can 
take the input XML descriptor from the appropriate upstream-tracker page 
(push on the show log button to extend the content of descriptors):


  http://upstream-tracker.org/versions/ffmpeg.html

--
Andrey Ponomarenko, ROSA Lab.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Who uses abi-compliance-checker?

[Andrey Ponomarenko]

Richard Shaw wrote:
On Wed, Jul 3, 2013 at 9:40 PM, Mathieu Bridon 
boche...@fedoraproject.org mailto:boche...@fedoraproject.org wrote:


On Wed, 2013-07-03 at 15:03 -0500, Richard Shaw wrote:
 If anyone is curious about it, I don't mind typing up the
process I go
 through to make the checks. I think I've found a pretty good
path of least
 resistance method :)

I've never used it, but I'd certainly be interested in reading that if
you ever write it up. :)


I use a directory, abicompare in the home of my build user followed by 
the library name then a version folder, i.e.:


~/abicompare/OpenImageIO/1.0.11
and
~/abicompare/OpenImageIO/1.0.13

Then I use a little scripe I wrote[1] to unpack the main library and 
devel rpms into the version directory of each library because I can 
never remember how to do it manually:


# cd ~/abicompare/OpenImageIO/1.0.11
# rpmunpack /path/to/rpms
(repeat for second version)

# abi-compliance-cheker -l OpenImageIO -dump 1.0.11/
(repeat for second version, the version as a directory works nicely 
because it will assume that's the version of the library so no need to 
specify the version manually)


# abi-compliance-checker -l OpenImageIO -old /path/to/abidump-1.0.11 
-new /path/to/abidump-1.0.13


Works like a charm as long as there's not any bad headers (like 
windows only headers) installed. If that happens I usually just have 
to rm the offending headers till I get a good dump.


Audrey,

How would this process change using abi-dump instead?


The ABI dump should be created in the different way. Use abi-dumper 
1.0.11/usr/lib/libopenImageio.so -o /path/to/abidump-1.0.11 -lver 
1.0.11 command instead of abi-compliance-cheker -l OpenImageIO -dump 
1.0.11/ to create the ABI dump. Note that the library should be 
compiled with debug info, so you should extract and compare appropriate 
debug-info rpm packages instead of release ones. Otherwise the tool will 
report can't find debug info in object(s).


All of these steps are automated in the pkgdiff 1.6. Just compare 
debug-info rpm packages by this tool: pkgdiff --details 
libA-v1-debuginfo.rpm libA-v2-debuginfo.rpm, and see the output html report.


--
Andrey Ponomarenko, ROSA Lab.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

abi-compliance-checker and abi-dumper to track API/ABI

[Andrey Ponomarenko]

Hi,

There is a new simple way to track changes in API/ABI of system 
libraries using a new ABI dumper [1] tool. Just compile two library 
versions with -g additional option (to contain DWARF debug info) or take 
them from the appropriate debug packages and create ABI dumps of both:


  abi-dumper OLD.so -o ABI-0.dump -lver 0
  abi-dumper NEW.so -o ABI-1.dump -lver 1

Then compare these ABI dumps by the ACC [2] tool:

  abi-compliance-checker -l NAME -old ABI-0.dump -new ABI-1.dump

So it is no need to create any input XML descriptors and compile header 
files of a library anymore.


However, this approach has some drawbacks. Perhaps the main drawback is 
the inability to perform some compatibility checks. For example, there 
is no possibility to check for changes in the values of the constants 
(defines as well as const global data), since their values are inlined 
at compile time, and not presented in the debug information of the 
binary ELF-object. In general, there can be checked about 98% of all 
compatibility rules.


Another disadvantage is the long time required to analyse large objects 
bigger than 50 mb. But one can use the dwz utility to compress input 
debug-info.


Enjoy!

[1] https://github.com/lvc/abi-dumper
[2] https://github.com/lvc/abi-compliance-checker

--
Andrey Ponomarenko, ROSA Lab.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: cogl soname bump

[Andrey Ponomarenko]

Peter Robinson wrote:

Sorry, I missed the cogl soname bump when I pushed the build last
night, I'll work to rebuild associated deps now, any help appreciated.


See future cogl soname bumps and ABI breaks analysis here: 
http://upstream-tracker.org/versions/cogl.html


--
Andrey Ponomarenko, ROSA Lab.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Another unannounced soname bump: libseccomp

[Andrey Ponomarenko]

Adam Williamson wrote:

On Mon, 2013-01-28 at 19:44 +, Richard W.M. Jones wrote:

DEBUG util.py:264:  Error: Package: 2:qemu-system-mips-1.3.0-5.fc19.x86_64 
(build)
DEBUG util.py:264: Requires: libseccomp.so.1()(64bit)
DEBUG util.py:264:  Error: Package: 2:qemu-system-or32-1.3.0-5.fc19.x86_64 
(build)
DEBUG util.py:264: Requires: libseccomp.so.1()(64bit)
DEBUG util.py:264:  Error: Package: 
2:qemu-system-microblaze-1.3.0-5.fc19.x86_64 (build)
DEBUG util.py:264: Requires: libseccomp.so.1()(64bit)
[etc]
full log: http://kojipkgs.fedoraproject.org//work/tasks/9474/4909474/root.log

This seems to have been caused by this build:

   http://koji.fedoraproject.org/koji/buildinfo?buildID=380981

Affected packages:

- libcacard-tools
- qemu

So, just as a path for anyone who's interested to take a look down, I
think we could potentially Do Something about all these unannounced
soname bumps. We do have a test in autoqa that catches them, and doesn't
seem to have a huge amount of 'false positives'.


FYI

http://upstream-tracker.org/versions/libseccomp.html


The test case is
rpmguard, and here is it noticing this soname bump:

http://autoqa.fedoraproject.org/resultsdb/frontend/testrun?id_=956918
http://autoqa.fedoraproject.org/results/511987-autotest/virt02.qa/rpmguard/results/libseccomp-2.0.0-0.f.html

N: Comparing libseccomp-1.0.1-0.fc19 and libseccomp-2.0.0-0.fc19 (archs:
i686) ...
W: provision-added libseccomp.so.2
W: provision-removed libseccomp.so.1

N: Comparing libseccomp-1.0.1-0.fc19 and libseccomp-2.0.0-0.fc19 (archs: 
x86_64) ...
W: provision-added libseccomp.so.2()(64bit)
W: provision-removed libseccomp.so.1()(64bit)

now rpmguard does various other things, so we'd need to filter out the
provision-removed (especially) results for this case. But we do at least
have this information being captured by autoqa, I think.

That's all I got!


--
Andrey Ponomarenko, ROSA Lab.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Heads-up: cyrus-sasl-2.1.26 with libsasl2 soname bump

[Andrey Ponomarenko]

FYI

I've added cyrus-sasl to the upstream tracker to monitor future soname 
bumps and ABI breaks: http://upstream-tracker.org/versions/cyrus-sasl.html


Petr Lautrbach wrote:
I'm going to push update cyrus-sasl-2.1.26 into Rawhide soon. Part of 
this update

is also SONAME bump to libsasl2.so.3.

The main issue with this update is that it would break buildroot since 
there is the openldap
package requiring libsasl2.so.2 which is part of buildroot. So I'll do 
needed steps in co-operation

with Jan Vcelak - the openldap maintainer - in order not to break it.

There are also several other packages dependent on libsasl2.so.2 [1], 
which will need rebuild.
It's my understanding that there will be mass rebuild soon so I 
wouldn't rebuild all of them manually,

but I would wait for this rebuild.

Comments? Suggestions?

Thanks,

Petr

[1] # repoquery -s --whatrequires --alldeps 'libsasl2.so*' | uniq
389-admin-1.1.31-1.fc19.1.src.rpm
389-ds-base-1.3.0.2-1.fc19.src.rpm
389-dsgw-1.1.9-3.fc18.src.rpm
argus-3.0.4-3.fc18.src.rpm
autofs-5.0.7-10.fc19.src.rpm
claws-mail-3.9.0-1.fc19.src.rpm
cyrus-imapd-2.4.17-1.fc19.src.rpm
cyrus-sasl-2.1.25-2.fc19.src.rpm
ekiga-4.0.0-2.fc19.src.rpm
evolution-data-server-3.7.4-1.fc19.src.rpm
exim-4.80.1-1.fc19.src.rpm
freeipa-3.1.0-1.fc19.src.rpm
gtk-vnc-0.5.1-5.fc19.src.rpm
kdebase3-3.5.10-21.fc18.src.rpm
kdepim-4.9.97-1.fc19.src.rpm
kdepimlibs-4.9.98-1.fc19.src.rpm
libetpan-1.1-3.fc18.src.rpm
libguestfs-1.21.2-2.fc19.src.rpm
libmemcached-1.0.15-1.fc19.src.rpm
nufw-2.4.3-6.fc18.src.rpm
pidgin-2.10.6-4.fc19.src.rpm
libvirt-1.0.1-4.fc19.src.rpm
mozldap-6.0.5-9.fc18.src.rpm
mutt-1.5.21-16.fc19.src.rpm
myproxy-5.9-2.fc19.src.rpm
nss_ldap-265-10.fc17.src.rpm
nufw-2.4.3-6.fc18.src.rpm
openldap-2.4.33-3.fc19.src.rpm
php-5.4.11-1.fc19.src.rpm
postfix-2.9.5-2.fc19.src.rpm
ptlib-2.10.9-1.fc19.src.rpm
qpid-cpp-0.18-5.fc19.src.rpm
saslwrapper-0.16-2.fc18.src.rpm
qca-cyrus-sasl-2.0.0-0.4.beta3.fc18.src.rpm
qemu-1.3.0-3.fc19.src.rpm
qpid-cpp-0.18-5.fc19.src.rpm
rinputd-1.0.5-1.fc19.src.rpm
ruby-qpid-0.8-7.fc18.src.rpm
qpid-cpp-0.18-5.fc19.src.rpm
saslwrapper-0.16-2.fc18.src.rpm
samba-4.0.1-1.fc19.src.rpm
sendmail-8.14.6-2.fc19.src.rpm
spice-gtk-0.16-1.fc19.src.rpm
spice-0.12.2-2.fc19.src.rpm
squid-3.2.5-1.fc19.src.rpm
subversion-1.7.8-3.fc19.src.rpm


--
Andrey Ponomarenko, ROSA Lab.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Update mongodb to 2.2.0 (latest release)

[Andrey Ponomarenko]

Dan Horák wrote:

Troy Dawson píše v Po 08. 10. 2012 v 14:48 -0500:

On 10/05/2012 04:43 PM, Troy Dawson wrote:

Hello,
I have updated mongodb from 2.0.7 to 2.2.0.
It is currently going through the normal channels for rawhide and Fedora 18.

10gen has a very good track record for being backwards compatible.
According to their documentation When upgrading a standalone mongod,
2.2 is a drop-in replacement. and MongoDB 2.0 data files are
compatible with 2.2-series binaries without any special migration process.
If upgrading replica sets and sharded cluster, you should follow the
procedures from their release notes.
http://docs.mongodb.org/manual/release-notes/2.2/#upgrading

What are people's thoughts on bringing it into Fedora 16, Fedora 17,
EPEL6 and EPEL5?

Troy Dawson

I have had requests for mongodb 2.2.0 for Fedora 17, as well as EPEL 6
and 5.  I am going to build for those tomorrow and let things sit in
testing for at least a week (2 weeks for EPEL).

The only concern I have received thus far is whether packages will need
to be rebuilt against the new mongodb 2.2.

 From everything I have looked at, the answer is no.
The API's should be backward compatible.
The libraries provided are the same name, there is no increase in number.

you can use the abi-compliance-checker tool to confirm that


or look at the upstream-tracker report for mongodb: 
http://upstream-tracker.org/versions/mongodb.html


particularly, the compatibility report between 2.0.7 and 2.2.0 versions 
is: 
http://upstream-tracker.org/compat_reports/mongodb/2.0.7_to_2.2.0/compat_report.html


--
Andrey Ponomarenko, ROSA Lab.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: xcb-util soname bump in rawhide

[Andrey Ponomarenko]

Hi,

Adam Jackson wrote:
Two (deprecated) functions were removed from libxcb-util, and the 
soname has been bumped to match.


I've added this library to the upstream tracker: 
http://upstream-tracker.org/versions/xcb-util.html


So, one can view upstream ABI changes in the oncoming releases.


The following (binary) packages are affected:

boinc-manager
i3
startup-notification
xcb-util-image
xorg-x11-drv-intel

That last one is a touch unexpected.  At any rate, I'll kick rebuilds 
for these.


- ajax


--
Andrey Ponomarenko, ROSA Lab.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: pari soname bump in Rawhide

[Andrey Ponomarenko]

Hello,

Paul Howarth wrote:

I have just done the long-awaited update of pari from 2.3.x to 2.5.x in
Rawhide, which has associated soname and API changes.


I've added PARI to the upstream tracker, so one can view API changes 
here: http://upstream-tracker.org/versions/pari.html


API compatibility report between 2.3.5 and 2.5.0: 
http://upstream-tracker.org/compat_reports/pari/2.3.5_to_2.5.0/compat_report.html


PkgDiff report between 2.3.5 and 2.5.0: 
http://upstream-tracker.org/pkgdiff_reports/pari/2.3.5_to_2.5.0/changes_report.html



The delay was
mainly due to there being no movement upstream in porting perl-Math-Pari
to the new API, so I have given up on that and introduced a libpari23
package that perl-Math-Pari is now built against.

As a result of the introduction of the libpari23 package, there should
be no broken dependencies caused by this update, but new builds of
packages using libpari will use the new version. We're not envisaging
there being any big issues with this but if there are, please report
them on the pari upgrade ticket (http://bugzilla.redhat.com/821191) and
we'll try to help.

Paul.


--
Andrey Ponomarenko, ROSA Lab.



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Self Introduction

[Andrey Ponomarenko]

Osier Yang wrote:

Hello there,

My name is Osier Yang, and I'm willing to be a Co-maitainer
of libvirt project.


Welcome!

Consider using this API tracker for your library when maintaining 
packages: http://upstream-tracker.org/versions/libvirt.html




Let me introduce myself briefly. I am a Software Engineer in
Red Hat's Virtualization team, and the project I'm working on
is libvirt, (yes, the one I want to build packages for). I
joined in Redhat more than 3 years ago, and have been libvirt
developer for about half past one year. I have been used Linux
for about 7 years, since I was in college, the first distro I
used is Hiweed, which is a light Chinese localized distro based
on GNU/Debian, it was good, but I bet you don't known it. :-).

Okay, I see someone was introducing the hobbies, so my hobbies
are quite a lot, the most favoured one is Guita.

I don't have much experience on Fedora package building yet,
nor for other Linux distributions, but I could learn from the
other maitainers of libvirt quickly to do that.

looking forward to hear from you soon.

Regards,
Osier


--
Andrey Ponomarenko, ROSA Lab.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

pkgdiff

[Andrey Ponomarenko]

Hello list,

A new tool for package maintainers has been released today: pkgdiff [1] 
- a tool for analyzing changes in Linux software packages (RPM, DEB, 
TAR.GZ, etc). The output of the tool is an HTML report like this [2].


Usage is simple:

pkgdiff -old OLD.rpm -new NEW.rpm

[1] http://pkgdiff.github.com/pkgdiff/
[2] 
http://pkgdiff.github.com/pkgdiff/pkgdiff_reports/libqb/0.4.1_to_0.8.1/compat_report.html


--
Andrey Ponomarenko, ROSA Lab.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: pkgdiff

[Andrey Ponomarenko]

Thanks. I've just created a spec-file for Mandriva 2012. You can use it 
as an example:


http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/pkgdiff/current/SPECS/pkgdiff.spec?view=markup

Richard Shaw wrote:

On Mon, Jan 30, 2012 at 5:10 AM, Andrey Ponomarenko
aponomare...@rosalab.ru  wrote:

Hello list,

A new tool for package maintainers has been released today: pkgdiff [1] - a
tool for analyzing changes in Linux software packages (RPM, DEB, TAR.GZ,
etc). The output of the tool is an HTML report like this [2].

Awesome! I'll package it up officially if I get a chance today.

Thanks,
Richard


--
Andrey Ponomarenko, ROSA Lab.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Anyone interested in abi-compliance-checker?

[Andrey Ponomarenko]

Hi,

On 01/06/2012 10:34 PM, Remi Collet wrote:

Le 06/01/2012 19:00, Orion Poplawski a écrit :


How do you generally make use of it?  In the course of my build process
I don't normally have two versions of the same library installed on one
machine which seems to be what is needed to use it.

I use it for some lib I maintain

- generate the analysis with version N

abi-compliance-checker -l libmemcached \
-dump_abi libmemcached042.xml

- build / install new version

- generate the analysis with version N+1

abi-compliance-checker -l libmemcached \
-dump_abi libmemcached043.xml

- Compare the result

abi-compliance-checker -l libmemcached \
-d1 abi_dumps/libmemcached/libmemcached_0.42.abi.tar.gz \
-d2 abi_dumps/libmemcached/libmemcached_0.43.abi.tar.gz \

firefox
file:$(pwd)/compat_reports/libmemcached/0.42_to_0.43/abi_compat_report.html

or, tips, use http://linuxtesting.org/upstream-tracker/   ;)


Remi.


There also exists the --stdout option in the 1.96.1 version of 
abi-compliance-checker tool to print ABI dumps to stdout. So, this 
allows to avoid creating archives and speed up the analysis:


1. abi-compliance-checker -l libmemcached -dump libmemcached042.xml 
-stdout  libmemcached_0.42.abi
2. abi-compliance-checker -l libmemcached -dump libmemcached043.xml 
-stdout  libmemcached_0.43.abi
3. abi-compliance-checker -l libmemcached -d1 libmemcached_0.42.abi -d2 
libmemcached_0.43.abi


Also, we have moved upstream-tracker service from 
http://linuxtesting.org/upstream-tracker/ to the new URL: 
http://upstream-tracker.org/


--
Andrey Ponomarenko, ROSA Lab.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Heads up: bumping libnl to v3 in rawhide/F17 soon

[Andrey Ponomarenko]

On 11/08/2011 09:10 PM, Dan Williams wrote:

Hi,

At some point here I'm going to bump libnl to version 3 in rawhide.  The
libnl 1.1 we use today is way out of date and we want version 3 for the
enhanced capabilities like bonding, bridging, vlan, etc.  This *does*
mean an API break, so packages will need to be updated for libnl3.  The
majority of the changes are simply function renames and changed
structure names.  There's no porting guide that I'm aware of but I and
others working on NetworkManager have spent time porting from libnl1.1
to libnl3 this cycle so we can point you in the right direction.



The compatibility report between 1.1 and 3.2.2 versions of libnl 
generated by abi-compliance-checker [1] tool (see attachment: 
abi_compat_report.html) may be of help.


[1] http://forge.ispras.ru/projects/abi-compliance-checker

--
Andrey Ponomarenko
Mandriva Linux/ROSA Laboratory



abi_compat_report.html.tar.gz
Description: GNU Zip compressed data
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: new upstream tracker (linuxtesting.org)

[Andrey Ponomarenko]

Hello,

On 06/04/2010 08:59 PM, Kevin Kofler wrote:
 Andrey Ponomarenko wrote:
   
 Taken into account, thanks. Some automatic way to add libraries may be
 very useful. At the moment all the libraries can be only manually added
 to the system by the administrator. If you want to add some library to
 the system than send a request to me or
 upstream-trac...@linuxtesting.org
 mailto:upstream-trac...@linuxtesting.org
 
 There are some false positives in your checks. In particular, some 
 (actually, most, if not all) of the new virtual functions you flag for 
 kdelibs are just added reimplementations of virtual functions in a base 
 class. Those don't change the layout of the vtable at all, they just replace 
 an entry pointing to the function inherited from the base class with an 
 entry pointing to the new reimplemented function.
   

Thank you very much for this report. I've fixed a serious bug in the
checker's code relative to this issue.

 Another problem is that e.g. for GTK+, you have a linear sequence including 
 development versions, but ABI guarantees are never from one development 
 version to the next, but only from one stable version to the next. 
 Development versions are only required to be backwards-compatible with the 
 previous stable version, as is the next stable version. So the previous 
 version in linear sequence is not always the correct reference. (The same 
 holds for kdelibs, by the way, but there your table doesn't include 
 development versions, making this a non-issue.) A lot of the breakage 
 reported for GTK+ is actually APIs added in a development branch and 
 adjusted before the official release. This is perfectly within the scope of 
 GTK+'s API/ABI guarantees.

 Kevin Kofler

   


-- 
Andrey Ponomarenko

Linux Verification Center, ISPRAS
 web:http://www.linuxtesting.org

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: new upstream tracker (linuxtesting.org)

[Andrey Ponomarenko]

On 06/03/2010 05:16 PM, Stephen Gallagher wrote:
 On 06/03/2010 09:04 AM, Andrey Ponomarenko wrote:
   
 Hello, I'm from ISPRAS and we have created an experimental system for
 monitoring and analyzing of upstream libraries development. It may be
 helpful for analyzing risks of library updating in the distribution.
 The web page of upstream-tracker is:

 http://linuxtesting.org/upstream-tracker/

 It now includes ABI changes analysis and shallow-quality API test results 
 for
 several versions of 70 popular open source libraries.

 Any bugs or feature requests are welcome. Thanks.

 
 Feature Request: ability to add other libraries to the system for tracking.

   

Taken into account, thanks. Some automatic way to add libraries may be
very useful. At the moment all the libraries can be only manually added
to the system by the administrator. If you want to add some library to
the system than send a request to me or
upstream-trac...@linuxtesting.org mailto:upstream-trac...@linuxtesting.org

-- 
Andrey Ponomarenko

Linux Verification Center, ISPRAS
 web:http://www.linuxtesting.org

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

new upstream tracker (linuxtesting.org)

[Andrey Ponomarenko]

Hello, I'm from ISPRAS and we have created an experimental system for
monitoring and analyzing of upstream libraries development. It may be
helpful for analyzing risks of library updating in the distribution.
The web page of upstream-tracker is:

http://linuxtesting.org/upstream-tracker/

It now includes ABI changes analysis and shallow-quality API test results for
several versions of 70 popular open source libraries.

Any bugs or feature requests are welcome. Thanks.

-- 
Andrey Ponomarenko

Linux Verification Center, ISPRAS
 web:http://www.linuxtesting.org

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

unit test generator for shared C/C++ library API

[Andrey Ponomarenko]

Dear colleagues,

Linux Verification Center at the Institute for System Programming of RAS
and the Linux Foundation have released a free unit test generator for
shared C/C++ library API. It helps to quickly generate simple (sanity
or shallow-quality) tests for all functions from the library API using
their signatures and data type definitions straight from the library
header files. The quality of generated tests allows to check absence of
critical errors in simple use cases and can be improved by involving of
highly reusable specialized types for the library.

This tool can execute generated tests and detect all kinds of emitted signals,
early program exits, program hanging and specified requirement failures.
It can be considered as a tool for low-cost sanity checking of library API
or as a powerful test development framework. Also it supports universal
Template2Code format of tests, random test generation mode and other useful
features. This tool is free software: you can redistribute it and/or modify
it under the terms of the GNU GPLv2.

We suppose this tool can be very useful for shared library developers
and recommend it for including to Fedora.

For more information, please see: 
http://ispras.linux-foundation.org/index.php/API_Sanity_Autotest

Andrey Ponomarenko
Linux Verification Center at the Institute for System Programming of RAS

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel