Re: [OM Cooker] Disabling generation of old hdlist.cz in ABF?
So i'm for killing hdlist.cz regenerating all the time one hdlists.cz which
is more that 70MiB is a reall overkill.
2014-04-01 4:49 GMT+02:00 Rolf Pedersen rolfpeder...@mindspring.com:
Sorry, I realized I was doing my urpm* testing in Rosa 2012.1
In OMV 2013.0, I'm finding that, with global policy set to Always and a
freshly-updated info from MandrivaUpdate, urpmf is very fast. Also, booted
back to Rosa, it is now fast, also. My longest waits, previously, were
when I was searching for a file that was not in the distro, so a list from
each repository was downloaded. It appears, with Always configured, some
stale lists are being refreshed when some strange string is given.
Eventually, a nonsense word returns no match quite quickly, without any
downloading. So, as it is, xml files are working just fine for these uses
for me, with Always set, it seems.
Thanks,
Rolf
On 03/31/2014 06:30 AM, Denis Silakov wrote:
Ok, thanks a lot for the info.
So at least handling of xml files can be improved.
As for dropping their generation - actually this won't save much
time/space, unlike hdlist.cz.
On 03/31/2014 05:27 PM, Rolf Pedersen wrote:
On 03/31/2014 01:02 AM, Denis Silakov wrote:
Hi all,
As many of you can likely notice, package publishing in ABF usually
takes relatively significant time - about several minutes (sometimes up to
10 minutes).
One of the time-consuming tasks in the publishing is generation of
hdlist.cz file - this is a huge file containing internal urpm
representation of metadata, including file lists, package descriptions,
etc. This file seems to be redundant - nowadays we generate additional xml
files (changelog.xml, info.xml, etc.) which in combination with lightweight
synthesis.hdlist.cz provide the same information. However, I am not so
familiar with hdlist.cz and can't guarantee that nothing will be lost
if we completely drop it.
So the question is - can somebody say what will we lost (if any) if we
drop hdlist.cz files? Or maybe we should just try and see?
Hi,
I hope someone can make some sense of my experience wrt hdlist.cz etc.
Many years ago, iirc, synthesis.hdlist.cz was introduced as an
optional source of media info that could be chosen by those with a slow
internet connection, as it was smaller and took less time to download than
the traditional, default hdlist.cz. I always chose hdlist.cz as my
connection was relatively quick and, I think, there was more information
included, naturally. Also, whenever I used urpmq/urpmf to query the
database, which is my primary usage of this important tool for
investigating packages capabilities, the result was almost immediate,
since the data was already on my computer. At some point, hdlist.czwas no
longer available as a way to configure urpmi. Every time I search
for a package containing a file of interest, I have to wait a long time for
xml files to be downloaded from each media source. Also, when I look for a
changelog in MandrivaUpdate or with urpmq, it must be retrieved. IIANM,
the package info would already be available on my machine when using
hdlist.cz as urpmi.update had already been done. Admittedly, this is
an accounting of the events of a number of years that is challenging for an
aged memory, but my recollected experience is that the functionality of
urpm was better with hdlist.cz than with anything that has come since.
Maybe generation of the others could be dropped to gain publishing speed?
:) Alternately, perhaps an option could be provided where all the current
information is downloaded when urpmi.update is run and/or with CL switches.
^^^Those words reminded me of the policy option to Always download xml
information in the rpmdrake media manager, which I recall trying, before,
without improvement. I see this in the urpmi.cfg manual about global
options:
xml-info
For remote media, specify when files.xml.lzma,
changelog.xml.lzma and info.xml.lzma are downloaded:
never
on-demand
(This is the default).
The specific xml info file is downloaded when
urpmq/urpmf/rpmdrake ask for it. urpmi.update will remove
outdated xml info file.
nb: if urpmq/urpmf/rpmdrake is not run by root, the xml
info file is downloaded into /tmp/.urpmi-uid/
update-only
urpmi.update will update xml info files already required
at least once by urpmq/urpmf/rpmdrake.
nb: with update-only, urpmi.update will not update
/tmp/.urpmi-uid/ xml info files
always
all xml info files are downloaded when doing
urpmi.addmedia and urpmi.update
I checked and no global policy was defined, so I set it to Always in
media manager, which is reflected, now, in urpmi.cfg:
{
downloader: curl
verify-rpm: 1
xml-info: always
}
This stanza was empty, before, by default, I guess. I then ran a urpmf
query
Re: [OM Cooker] Disabling generation of old hdlist.cz in ABF?
Yeah, but let's also set xml-info to 'always' by default. I'll take care about this in cooker and rosa. On 04/02/2014 12:21 PM, Tomasz Gajc wrote: So i'm for killing hdlist.cz http://hdlist.cz regenerating all the time one hdlists.cz http://hdlists.cz which is more that 70MiB is a reall overkill. 2014-04-01 4:49 GMT+02:00 Rolf Pedersen rolfpeder...@mindspring.com mailto:rolfpeder...@mindspring.com: Sorry, I realized I was doing my urpm* testing in Rosa 2012.1 In OMV 2013.0, I'm finding that, with global policy set to Always and a freshly-updated info from MandrivaUpdate, urpmf is very fast. Also, booted back to Rosa, it is now fast, also. My longest waits, previously, were when I was searching for a file that was not in the distro, so a list from each repository was downloaded. It appears, with Always configured, some stale lists are being refreshed when some strange string is given. Eventually, a nonsense word returns no match quite quickly, without any downloading. So, as it is, xml files are working just fine for these uses for me, with Always set, it seems. Thanks, Rolf On 03/31/2014 06:30 AM, Denis Silakov wrote: Ok, thanks a lot for the info. So at least handling of xml files can be improved. As for dropping their generation - actually this won't save much time/space, unlike hdlist.cz http://hdlist.cz. On 03/31/2014 05:27 PM, Rolf Pedersen wrote: On 03/31/2014 01:02 AM, Denis Silakov wrote: Hi all, As many of you can likely notice, package publishing in ABF usually takes relatively significant time - about several minutes (sometimes up to 10 minutes). One of the time-consuming tasks in the publishing is generation of hdlist.cz http://hdlist.cz file - this is a huge file containing internal urpm representation of metadata, including file lists, package descriptions, etc. This file seems to be redundant - nowadays we generate additional xml files (changelog.xml, info.xml, etc.) which in combination with lightweight synthesis.hdlist.cz http://synthesis.hdlist.cz provide the same information. However, I am not so familiar with hdlist.cz http://hdlist.cz and can't guarantee that nothing will be lost if we completely drop it. So the question is - can somebody say what will we lost (if any) if we drop hdlist.cz http://hdlist.cz files? Or maybe we should just try and see? Hi, I hope someone can make some sense of my experience wrt hdlist.cz http://hdlist.cz etc. Many years ago, iirc, synthesis.hdlist.cz http://synthesis.hdlist.cz was introduced as an optional source of media info that could be chosen by those with a slow internet connection, as it was smaller and took less time to download than the traditional, default hdlist.cz http://hdlist.cz. I always chose hdlist.cz http://hdlist.cz as my connection was relatively quick and, I think, there was more information included, naturally. Also, whenever I used urpmq/urpmf to query the database, which is my primary usage of this important tool for investigating packages capabilities, the result was almost immediate, since the data was already on my computer. At some point, hdlist.cz http://hdlist.cz was no longer available as a way to configure urpmi. Every time I search for a package containing a file of interest, I have to wait a long time for xml files to be downloaded from each media source. Also, when I look for a changelog in MandrivaUpdate or with urpmq, it must be retrieved. IIANM, the package info would already be available on my machine when using hdlist.cz http://hdlist.cz as urpmi.update had already been done. Admittedly, this is an accounting of the events of a number of years that is challenging for an aged memory, but my recollected experience is that the functionality of urpm was better with hdlist.cz http://hdlist.cz than with anything that has come since. Maybe generation of the others could be dropped to gain publishing speed? :) Alternately, perhaps an option could be provided where all the current information is downloaded when urpmi.update is run and/or with CL switches. ^^^Those words reminded me of the policy option to Always download xml information in the rpmdrake media manager,
Re: [OM Cooker] Disabling generation of old hdlist.cz in ABF?
I have rebuilt urpmi for cooker with xml-info set to 'always' by default. I have also built an updated version for omv2014.0, but I don't have permissions to publish the packages there. On 04/02/2014 12:21 PM, Tomasz Gajc wrote: So i'm for killing hdlist.cz http://hdlist.cz regenerating all the time one hdlists.cz http://hdlists.cz which is more that 70MiB is a reall overkill. 2014-04-01 4:49 GMT+02:00 Rolf Pedersen rolfpeder...@mindspring.com mailto:rolfpeder...@mindspring.com: Sorry, I realized I was doing my urpm* testing in Rosa 2012.1 In OMV 2013.0, I'm finding that, with global policy set to Always and a freshly-updated info from MandrivaUpdate, urpmf is very fast. Also, booted back to Rosa, it is now fast, also. My longest waits, previously, were when I was searching for a file that was not in the distro, so a list from each repository was downloaded. It appears, with Always configured, some stale lists are being refreshed when some strange string is given. Eventually, a nonsense word returns no match quite quickly, without any downloading. So, as it is, xml files are working just fine for these uses for me, with Always set, it seems. Thanks, Rolf On 03/31/2014 06:30 AM, Denis Silakov wrote: Ok, thanks a lot for the info. So at least handling of xml files can be improved. As for dropping their generation - actually this won't save much time/space, unlike hdlist.cz http://hdlist.cz. On 03/31/2014 05:27 PM, Rolf Pedersen wrote: On 03/31/2014 01:02 AM, Denis Silakov wrote: Hi all, As many of you can likely notice, package publishing in ABF usually takes relatively significant time - about several minutes (sometimes up to 10 minutes). One of the time-consuming tasks in the publishing is generation of hdlist.cz http://hdlist.cz file - this is a huge file containing internal urpm representation of metadata, including file lists, package descriptions, etc. This file seems to be redundant - nowadays we generate additional xml files (changelog.xml, info.xml, etc.) which in combination with lightweight synthesis.hdlist.cz http://synthesis.hdlist.cz provide the same information. However, I am not so familiar with hdlist.cz http://hdlist.cz and can't guarantee that nothing will be lost if we completely drop it. So the question is - can somebody say what will we lost (if any) if we drop hdlist.cz http://hdlist.cz files? Or maybe we should just try and see? Hi, I hope someone can make some sense of my experience wrt hdlist.cz http://hdlist.cz etc. Many years ago, iirc, synthesis.hdlist.cz http://synthesis.hdlist.cz was introduced as an optional source of media info that could be chosen by those with a slow internet connection, as it was smaller and took less time to download than the traditional, default hdlist.cz http://hdlist.cz. I always chose hdlist.cz http://hdlist.cz as my connection was relatively quick and, I think, there was more information included, naturally. Also, whenever I used urpmq/urpmf to query the database, which is my primary usage of this important tool for investigating packages capabilities, the result was almost immediate, since the data was already on my computer. At some point, hdlist.cz http://hdlist.cz was no longer available as a way to configure urpmi. Every time I search for a package containing a file of interest, I have to wait a long time for xml files to be downloaded from each media source. Also, when I look for a changelog in MandrivaUpdate or with urpmq, it must be retrieved. IIANM, the package info would already be available on my machine when using hdlist.cz http://hdlist.cz as urpmi.update had already been done. Admittedly, this is an accounting of the events of a number of years that is challenging for an aged memory, but my recollected experience is that the functionality of urpm was better with hdlist.cz http://hdlist.cz than with anything that has come since. Maybe generation of the others could be dropped to gain publishing speed? :) Alternately, perhaps an option could be provided where all the current information is downloaded when urpmi.update is run and/or with CL switches. ^^^Those words reminded me of the policy option to Always
Re: [OM Cooker] [om-qa] Currently no packages in repos appear to be signed.
All seems to work now.
Re: [OM Cooker] [om-qa] Currently no packages in repos appear to be signed.
Cool, thanks Crispin for fixing this issue ! 2014-04-02 12:10 GMT+02:00 Jean-Claude Vanier jclvan...@gmail.com: All seems to work now.
Re: [OM Cooker] ISOs for 2014.0 RC release
Hello, we have new ISOs with fixed boot and issue with missing gpg key is gone, also few other bugs were fixed since last rc1 candidate. I still believe we can redeem planned date for RC1 release on 2014-04-04 ! 64 bit: https://abf.io/platforms/openmandriva2014.0/products/70/product_build_lists/3101 32 bit: https://abf.io/platforms/openmandriva2014.0/products/71/product_build_lists/3103 If you have found any bugs please report them on http://issues.openmandriva.org with maximum information provided by you, which mean logs, screenshots and output omv-bug-report.sh added as attachements (do not copy and paste large amount of text into reply text box...) Cheers. 2014-04-01 7:16 GMT+02:00 davide.gara...@linux-corner.it: Unfortunately, I was able to try out the ISO only today ... On three different systems and until now, I have no system with the beta version installed all systems, where i tried to install the RC, are stopped on three points. The only possible operation is the ESC key. all the systems report the same three rows: [OK] Started Show plymouth Boot Screen [OK] Reached target Paths. [OK] Reached target Basic System On Noteboot (i7 +8G ram + nvidia) i tried the boot.and also this test was fail . After a while on the tre dots system halt on dracut.The system is frozen, I can not do anything. frankly I find it strange a fail so extended. I usually use as installation media, memory sticks, I'll try to do them again . When i will be able to get more information I will fill a bug report. Regards --- Davide_01http://www.linux-corner.it Il 2014-04-01 00:09 Robert Xu ha scritto: On 31 March 2014 15:52, Colin Close itc...@compuserve.com wrote: Hi Robert Pretty pointless I think; we have had several reports of no boot I can't boot further than dracut shell (and very early on at that) No modules are being loaded. Tomasz reports he can boot on VB. It could be the very latest kernel start-up is so fast now I think it's probably breaking things and there's not enough semaphoring in the systemd start-up file to ensure that things advance in an orderly fashion. Just a guess though. We have blocker in that the gpg keys are not being downloaded properly so packages are giving bad key errors. So I guess we wait. The guys are under enough pressure I don't think they need an official no-go at the moment. Let's see what transpires tomorrow. Ok; sounds good.
[OM Cooker] Helper scripts to test applications and services
Hi, I have prepared a couple of scripts to perform automated testing of applications and services in the installed system. We use it for ROSA Fresh, but they may be useful for OpenMandriva as well. The scripts are available here: https://abf.rosalinux.ru/spectre/rosa-autotest/tree/master/check_apps namely the following two could be useful: - check_apps.py - check_services.py The rest are more ROSA-specific and are not generally required. Both check_apps.py and check_services.py take the file with the list of packages to be checked as an argument. 1. check_apps.py. For each package to be checked, the script installs it, finds .desktop files in it corresponding to the applications. Then it runs each of these applications, waits a little and looks if they crash. Crash dumps, logs and other info are saved. The idea was that an ordinary user mostly runs apps from the GUI (via their .desktop files), so such apps should be checked first. The lists of the packages are prepared separately. Here are the examples we use in ROSA at the moment: https://abf.rosalinux.ru/spectre/rosa-autotest/blob/master/check_apps/lists/applications/KDE/packages-kde.list https://abf.rosalinux.ru/spectre/rosa-autotest/blob/master/check_apps/lists/applications/GNOME/packages-gnome.list The packages are mostly from main, non-free and restricted repos. The lists for OpenMandriva might be different, of course. 2. check_services.py. Similar to checking the applications but for systemd services this time. The script tries to start each service from the given packages and reports if that fails. The needed preprequisites and other useful information are in Readme.txt: https://abf.rosalinux.ru/spectre/rosa-autotest/blob/master/check_apps/Readme.txt These scripts are not perfect but, I think, they could be useful. Regards, Eugene -- Eugene Shatokhin, ROSA www.rosalab.com
[OM Cooker] Linux Exhibition in Paris: who goes?
Hello teams Raphael has organized a booth for us on a French known Linux exhibition, what gives us even more possibilities to spread the word! Thank you Raph. Who goes? Please announce your wish and ability to go to work on our booth within 1 week, till 9th of April, with all the hassle for FISL and LinuxTag we need to take care of travel etc asap. http://doodle.com/dhdvcwscgkrachtm Please bear in mind, that the event is only on 20-21, I made the poll larger for the cases, if you will need to travel from afar. Let's go!:) cheers
Re: [OM Cooker] [om-workshop] Linux Exhibition in Paris: who goes?
http://www.solutionslinux.fr/?lg=en 2014-04-02 17:25 GMT+02:00 Kate Lebedeff k...@lebedeff.co.uk: Hello teams Raphael has organized a booth for us on a French known Linux exhibition, what gives us even more possibilities to spread the word! Thank you Raph. Who goes? Please announce your wish and ability to go to work on our booth within 1 week, till 9th of April, with all the hassle for FISL and LinuxTag we need to take care of travel etc asap. http://doodle.com/dhdvcwscgkrachtm Please bear in mind, that the event is only on 20-21, I made the poll larger for the cases, if you will need to travel from afar. Let's go!:) cheers
Re: [OM Cooker] [om-workshop] Linux Exhibition in Paris: who goes?
thanks:) forgot to insert that On 2Apr, 2014, at 6:08 PM, Jean-Claude Vanier wrote: http://www.solutionslinux.fr/?lg=en 2014-04-02 17:25 GMT+02:00 Kate Lebedeff k...@lebedeff.co.uk: Hello teams Raphael has organized a booth for us on a French known Linux exhibition, what gives us even more possibilities to spread the word! Thank you Raph. Who goes? Please announce your wish and ability to go to work on our booth within 1 week, till 9th of April, with all the hassle for FISL and LinuxTag we need to take care of travel etc asap. http://doodle.com/dhdvcwscgkrachtm Please bear in mind, that the event is only on 20-21, I made the poll larger for the cases, if you will need to travel from afar. Let's go!:) cheers
[OM Cooker] GO/NOGO 4 April
Hi all, We have a release candidate to evaluate: 64 bit: https://abf.io/platforms/openmandriva2014.0/products/70/product_build_lists/3101 32 bit: https://abf.io/platforms/openmandriva2014.0/products/71/product_build_lists/3103 The GO/NOGO vote on these ISOs are more rigorous - you must vote as if these ISOs are the final release. They must withstand all your tests and provide, essentially, a favourable impression should a new user test these ISOs. If you find ANY bugs that impede operation, it's a NO. Bad artwork? Say NO. Faulty applications? NO. Any packages in main (a.k.a. supported packages) that don't hold up? If it's a common package, check to see if it's included in the ISO. If so, it's a NO; otherwise, request a maintainer to fix it. Obviously, I don't expect you to be that strict when evaluating applications, since we have a bit of leeway on the schedule to allow us time to fix any presaing issues. But do note that this ISO is exactly what it sounds like - a release candidate. This same ISO could be released as the final 2014.0 version. Get to it! I need votes by 1700 UTC Friday. Robert
Re: [OM Cooker] ISOs for 2014.0 RC release
Robert, I cannot see how this iso can be called a release candidate when there is a blocker bug 562 outstanding on it surely that should be an automatic NOGO. That's notwithstanding the four notional blocker issues with MCC 614, 613, 422 and 424. What kind of impression does it give when we cant even make out own tools work properly. Best, Colin Colin Close QA Team On Wednesday 02 Apr 2014 17:34:13 Robert Xu wrote: Tomasz, do you want a vote on this? On 2 April 2014 07:39, Tomasz Gajc tpg...@gmail.com wrote: Hello, we have new ISOs with fixed boot and issue with missing gpg key is gone, also few other bugs were fixed since last rc1 candidate. I still believe we can redeem planned date for RC1 release on 2014-04-04 ! 64 bit: https://abf.io/platforms/openmandriva2014.0/products/70/product_build_lists/3101 32 bit: https://abf.io/platforms/openmandriva2014.0/products/71/product_build_lists/3103 If you have found any bugs please report them on http://issues.openmandriva.org with maximum information provided by you, which mean logs, screenshots and output omv-bug-report.sh added as attachements (do not copy and paste large amount of text into reply text box...) Cheers. 2014-04-01 7:16 GMT+02:00 davide.gara...@linux-corner.it: Unfortunately, I was able to try out the ISO only today ... On three different systems and until now, I have no system with the beta version installed all systems, where i tried to install the RC, are stopped on three points. The only possible operation is the ESC key. all the systems report the same three rows: [OK] Started Show plymouth Boot Screen [OK] Reached target Paths. [OK] Reached target Basic System On Noteboot (i7 +8G ram + nvidia) i tried the boot.and also this test was fail . After a while on the tre dots system halt on dracut.The system is frozen, I can not do anything. frankly I find it strange a fail so extended. I usually use as installation media, memory sticks, I'll try to do them again . When i will be able to get more information I will fill a bug report. Regards --- Davide_01 http://www.linux-corner.it Il 2014-04-01 00:09 Robert Xu ha scritto: On 31 March 2014 15:52, Colin Close itc...@compuserve.com wrote: Hi Robert Pretty pointless I think; we have had several reports of no boot I can't boot further than dracut shell (and very early on at that) No modules are being loaded. Tomasz reports he can boot on VB. It could be the very latest kernel start-up is so fast now I think it's probably breaking things and there's not enough semaphoring in the systemd start-up file to ensure that things advance in an orderly fashion. Just a guess though. We have blocker in that the gpg keys are not being downloaded properly so packages are giving bad key errors. So I guess we wait. The guys are under enough pressure I don't think they need an official no-go at the moment. Let's see what transpires tomorrow. Ok; sounds good.
Re: [OM Cooker] ISOs for 2014.0 RC release
Hi , Am 03.04.2014 01:17, schrieb Colin Close: Robert, I cannot see how this iso can be called a release candidate when there is a blocker bug 562 outstanding on it surely that should be an automatic NOGO. That's notwithstanding the four notional blocker issues with MCC 614, 613, 422 and 424. What kind of impression does it give when we cant even make out own tools work properly. Best, Colin +1 something can only be youthful mischief *giggle* best regards Blacky *lol* Colin Close QA Team On Wednesday 02 Apr 2014 17:34:13 Robert Xu wrote: Tomasz, do you want a vote on this? On 2 April 2014 07:39, Tomasz Gajc tpg...@gmail.com wrote: Hello, we have new ISOs with fixed boot and issue with missing gpg key is gone, also few other bugs were fixed since last rc1 candidate. I still believe we can redeem planned date for RC1 release on 2014-04-04 ! 64 bit: https://abf.io/platforms/openmandriva2014.0/products/70/product_build_lists/3101 32 bit: https://abf.io/platforms/openmandriva2014.0/products/71/product_build_lists/3103 If you have found any bugs please report them on http://issues.openmandriva.org with maximum information provided by you, which mean logs, screenshots and output omv-bug-report.sh added as attachements (do not copy and paste large amount of text into reply text box...) Cheers. 2014-04-01 7:16 GMT+02:00 davide.gara...@linux-corner.it: Unfortunately, I was able to try out the ISO only today ... On three different systems and until now, I have no system with the beta version installed all systems, where i tried to install the RC, are stopped on three points. The only possible operation is the ESC key. all the systems report the same three rows: [OK] Started Show plymouth Boot Screen [OK] Reached target Paths. [OK] Reached target Basic System On Noteboot (i7 +8G ram + nvidia) i tried the boot.and also this test was fail . After a while on the tre dots system halt on dracut.The system is frozen, I can not do anything. frankly I find it strange a fail so extended. I usually use as installation media, memory sticks, I'll try to do them again . When i will be able to get more information I will fill a bug report. Regards --- Davide_01 http://www.linux-corner.it Il 2014-04-01 00:09 Robert Xu ha scritto: On 31 March 2014 15:52, Colin Close itc...@compuserve.com wrote: Hi Robert Pretty pointless I think; we have had several reports of no boot I can't boot further than dracut shell (and very early on at that) No modules are being loaded. Tomasz reports he can boot on VB. It could be the very latest kernel start-up is so fast now I think it's probably breaking things and there's not enough semaphoring in the systemd start-up file to ensure that things advance in an orderly fashion. Just a guess though. We have blocker in that the gpg keys are not being downloaded properly so packages are giving bad key errors. So I guess we wait. The guys are under enough pressure I don't think they need an official no-go at the moment. Let's see what transpires tomorrow. Ok; sounds good.
