July 2011 - autoqa-devel - Fedora Mailing-Lists

by alekcejk＠googlemail.com

Chris Tyler wrote: > I really want to stress that it *may need* attention. During the armv7hl > bring-up, we've realized that there are some *ridiculous* dep chains in > our package collection. Adding in optional build dependencies will cause > the corresponding runtime dependencies (libraries, utilies, etc) to get > pulled in, and there will be many cases where a package maintainer will > legitimately decide not to add an optional BR in order to keep the dep > chains sane. I'd hate for automated test results to convince (especially > new) packagers that they should add in optional BRs without carefully > working through the consequences... the wording of the warning message > will be important here. There are many reasons why not to add optional dependencies in BuildRequires so final decision should made maintainer. Such warnings should be informational only to help maintainer not to lose needed functionality because of unintentionally missed BuildRequires. Alexey Kurov <nucleo(a)fedoraproject.org>

12 years, 9 months

1
0
0 / 0

Looking at URL Shorteners for AutoQA

by Tim Flink

I spent some time this week evaluating 3 different URL shorteners for use with AutoQA. - url-shortener (https://github.com/voidfiles/url-shortener) - TightURL (http://tighturl.com/project/p/tighturl/) - yourls (http://yourls.org/) TL;DR version - I think that yourls would be the best choice for us. It has an API that looks good, it is actively maintained and has features that the others don't. Right now, I only have these set up on a local dev machine. If there is interest, I can try to get something that would be a little more publicly visible. Tim ============================================================ url-shortener (https://github.com/voidfiles/url-shortener) - Django based application - more recently updated fork of the original url-shortener * https://github.com/nileshk/url-shortener ============================================================ I didn't finish trying this one out mostly because of its dependencies. It requires blueprint-css (a ruby based CSS framework) [1] to be installed within its own directories. This would make packaging pretty messy unless we did some code modifications to url-shortener to use a common blueprint-css. In addition to the dependency issue, there doesn't seem to be a whole lot of documentation for the project and once I did get it running in devel mode, its user interface was not incredibly intuitive. Overall, it is written mostly in python but it seems to be rather dead and I think that there are better options. [1] https://github.com/joshuaclayton/blueprint-css/ ============================================================ TightURL (http://tighturl.com/project/p/tighturl/) - Written in PHP - Deployed into production at http://tighturl.com/ ============================================================ TightURL is a simple URL shortener written in PHP. It has been around for a while, has a stable code base and has decent abuse protection. The stable version hasn't been updated for a while but the developer is keeping a devblog [2] that makes it look like the project is still maintained. The documentation is decent and there were no real surprises setting it up. It has good support for templating and I don't think it would be very hard to make it look more like part of Fedora or FedoraQA. Unfortunately, there is no real API for shortening the URLS. It would be possible to interface with the main page by scraping the content and using the form, but that seems like a less-than-elegant way to do it (not to mention being fragile and a pain). [2] http://tighturl.com/project/devblog/ ============================================================ yourls (http://yourls.org/) - Written in PHP - Deployments listed at http://yourls.org/#Showcase - Active development ============================================================ Yourls is an actively maintained, full-featured URL shortener written in PHP. It has a documented API [1], support for requested shortcuts (i.e. use http://short/myshortlink instead of forcing http://short/alVYn), built in statistics and a plugin interface. The documentation is decent and there were no big surprises on installation. The downside to yourls is that it would take some work if we wanted to provide a public html interface or to customize the admin interface. I'm not sure that we really want a public html interface since our use case would be AutoQA only and having a config file based auto system would be acceptable since we don't need many users.

12 years, 9 months

3
5
0 / 0

AutoQA test for missed BR's

by alekcejk＠googlemail.com

> Correct me if I am wrong, but shouldn't such build fail due to unsatisfied dependencies? > And if the build fails, the package maintainer will probably notice that. Is the purpose of > this proposed test to detect such builds that failed and its maintainer didn't notice it, or is there another purpose? > I'm not a package maintainer and I don't have much experience building packages and using Koji, so further explanation is helpful. Thanks. There are two type of dependencies mandatory and optional. If mandatory dependence missing then build will failed. But if optional dependence missing build will be complete but some of functionality will be missing. For example see this okular build log, where BuildRequires qca2-devel was unintentionally missed: http://kojipkgs.fedoraproject.org/packages/okular/4.6.95/2.fc16/data/logs... There is cmake output: ----------------------------------------------------------------------------- -- The following OPTIONAL packages could NOT be located on your system. -- Consider installing them to enable more features from this software. ----------------------------------------------------------------------------- * QCA (2.0.0 or higher) <http://delta.affinix.com/qca/> Qt Cryptographic Architecture (QCA) Support for encrypted OpenDocument Text documents in Okular. But this build was complete. This was wixed in next build by adding needed BuildRequires http://kojipkgs.fedoraproject.org/packages/okular/4.6.95/3.fc16/data/logs... So such missing optional dependencies needs attention.

12 years, 9 months

3
2
0 / 0

[AutoQA] #367: Detect missing optional BuildRequires from Koji log

by fedora-badges

#367: Detect missing optional BuildRequires from Koji log --------------------+------------------------------------------------------- Reporter: kparal | Owner: Type: task | Status: new Priority: minor | Milestone: Future test cases Component: tests | Keywords: --------------------+------------------------------------------------------- Alexey Kurov proposed following: {{{ It wold be nice to have an automated test based on build logs that looks for missed BR's for example in cmake or configure outputs. If such BR's will be found test should war about them but this warning should not mark whole tests results as FAILED. }}} {{{ There are two type of dependencies mandatory and optional. If mandatory dependence missing then build will failed. But if optional dependence missing build will be complete but some of functionality will be missing. For example see this okular build log, where BuildRequires qca2-devel was unintentionally missed: http://kojipkgs.fedoraproject.org/packages/okular/4.6.95/2.fc16/data/logs... There is cmake output: ----------------------------------------------------------------------------- -- The following OPTIONAL packages could NOT be located on your system. -- Consider installing them to enable more features from this software. ----------------------------------------------------------------------------- * QCA (2.0.0 or higher) <http://delta.affinix.com/qca/> Qt Cryptographic Architecture (QCA) Support for encrypted OpenDocument Text documents in Okular. But this build was complete. This was wixed in next build by adding needed BuildRequires http://kojipkgs.fedoraproject.org/packages/okular/4.6.95/3.fc16/data/logs... So such missing optional dependencies needs attention. }}} See https://fedorahosted.org/pipermail/autoqa-devel/2011-July/002676.html . It will be probably needed to have whitelisting capabilities for this test, because similarly to e.g. rpmlint sometimes some warnings might be intentional. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/367> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

12 years, 9 months

1
0
0 / 0

AutoQA test for missed BR's

by alekcejk＠googlemail.com

> What's BR? Sorry, I mean BuildRequires. Sometimes new apps releases adds new deps which needs adding new BuildRequires in spec. So it is will be very useful to have autotest warning if such BuildRequires unintentionally missed.

12 years, 9 months

2
1
0 / 0

AutoQA test for missed BR's

by alekcejk＠googlemail.com

Hi, It wold be nice to have an automated test based on build logs that looks for missed BR's for example in cmake or configure outputs. If such BR's will be found test should war about them but this warning should not mark whole tests results as FAILED. Is idea of such test was discussed earlier? Alexey Kurov <nucleo(a)fedoraproject.org>

12 years, 9 months

2
1
0 / 0

rpmlint auto-ignores - fingerfood?

by James Laska

Greetings, Thought other might find this interesting. We've talked about a mechanism for letting maintainers whitelist feedback from rpmlint. This might be a nice finger-food task to update our rpmlint test to utilize this new feature. http://inputvalidation.blogspot.com/2011/07/addition-of-fedpkg-rpmlint.ht... Thanks, James

12 years, 9 months

2
1
0 / 0

[AutoQA] #149: rpmlint: Provide whitelisting of messages

by fedora-badges

#149: rpmlint: Provide whitelisting of messages --------------------+------------------------------------------------------- Reporter: kparal | Owner: Type: task | Status: new Priority: major | Milestone: Package update tests Component: tests | Version: 1.0 Keywords: | --------------------+------------------------------------------------------- We need to provide some whitelisting capability of rpmlint packages, so the package maintainers can mark some messages as invalid. We will also probably want to mark some messages as invalid by default for the whole Fedora project. As an interesting inspiration, look at lintian project (validation of deb packages). It provides some "overrides" on a package basis, you just create a definition file in /etc/lintian/package_name or kind of. I have the feeling that rpmlint provides something similar, but we need to discover it more properly. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/149> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

12 years, 9 months

1
2
0 / 0

[AutoQA] #359: pretty_log: escape HTML entities

by fedora-badges

#359: pretty_log: escape HTML entities --------------------+------------------------------------------------------- Reporter: kparal | Owner: Type: defect | Status: new Priority: major | Milestone: Finger Food Component: core | Keywords: --------------------+------------------------------------------------------- Currently we copy all test output into the PrettyLog verbatim. It also applies for summary, ID, highlights and pretty much everything. But if some of that text contains HTML entities, it creates invalid HTML page and breaks the report (different browsers may display it differently). Example: Try populating test summary with word '<undefined>'. The browser will consider it an unknown tag and don't display it at all. We need to escape all text we take over before putting it into HTML log. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/359> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

12 years, 9 months

1
3
0 / 0

NEWS file

by Kamil Paral

Hello, I have spend some time on reading about changelogs. In GNU terminology ChangeLogs are files describing changes in the source code [1] [2]. That is already handled for us by Git, we don't need that. And that's also the reason why many projects don't create ChangeLogs anymore. What we want is a NEWS file (in GNU terminology) [3]. This file should describe shortly most important user-visible changes. If you are curious, run: $ find /usr/share/doc -name NEWS I like this one: /usr/share/doc/xz-5.0.1/NEWS I would like to have a similar file inside AutoQA. At the same time we can stop writing out changes into autoqa.spec. Spec file should describe only changes in packaging, not in source code. And our change descriptions were too commit-specific anyway. I have created a draft how could these files look like: http://kparal.fedorapeople.org/autoqa/NEWS http://kparal.fedorapeople.org/autoqa/autoqa.spec (see just %changelog section) Note that the NEWS file is end-user oriented (full sentences, just most important stuff, more readable that commit log) and very similar to what I posted to my blog as the release announcement. That's the goal. I haven't went far into the past when creating the entries, I don't see much sense. Similarly for autoqa.spec, we incorrectly bumped release number in the past for new autoqa releases. Deleted, ancient times available via Git. (I imagine the %changelog section is used for new RPM builds to display changelogs. If it is not the case, I would delete the whole section altogether, you can always see the data from Git). If there are no objections I'll commit the changes and adjust the Release Process wiki page. Kamil [1] http://en.wikipedia.org/wiki/Changelog [2] http://www.gnu.org/prep/standards/html_node/Change-Logs.html [3] http://www.gnu.org/prep/standards/html_node/NEWS-File.html#NEWS-File

12 years, 9 months

1
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

autoqa-devel July 2011