Re: Automatic testing: openqa.debian.net
On Sun, 03 Dec 2017, Holger Levsen wrote: > Hi Phil, > > (dropping debian-boot@ and adding debian-edu@l.d.o to the recipients, > and leaving context for the latter...) > > On Fri, Nov 24, 2017 at 01:35:41PM +0100, Philip Hands wrote: >> If you look here: >> https://openqa.debian.net/ >> >> You'll see that I've been testing d-i daily images for a while. >> >> The scripts that drive those tests are available here: >> https://anonscm.debian.org/cgit/collab-maint/openqa-tests-debian.git/ > > very cool. (how) can I subscribe to commit notifications for this > repo? I guess we should plumb it up with a link to IRC? At present I'm mostly being naughty and doing my flailing attempts to make things work directly in the live directory, so there are only commits when things start working properly (so pretty rare ;-) ) >> As you can see from the README.md this is based on Fedora's tests. The >> README helpfully points at the original documentation for os-autoinst, >> which is the thing that does the work. >> >> It's possible that the README says things work that I've since broken in >> order to make it work for the Debian tests. Please point that out to me >> if you notice, and I'll either fix things, or fix the README, as >> appropriate. >> >> So far I've been focused on testing d-i up to the point where we can see >> that it's possible to login, and see whatever should be expected for >> each of our desktops. > > I see you also seem to have tests for Debian Edu! > (at http://openqa.debian.net/group_overview/6 ) Yeah -- that was mostly to see how things work once you add another thing to test. It only does a simple install so far, and it gets a bit befuddled by Firefox automatically starting, but it does work. If there are regularly produced betas to test somewhere, that would make it a much more interesting test. >> There is no reason to limit ourselves to that, and since we're >> generating newly installed VM images regularly, it's completely fine to >> write tests that use those as a starting point. It's also possible to >> write tests that use ssh or the serial console, so that yo don't need to >> hunt for things in screenshots. >> >> Currently it's all running in one VM (with nested VMs), but the >> os-autoinst is able to run additional workers, so we should be able to >> scale up as required. >> >> At some point I'll want to reinstall everything, when all the bits are >> available as packages (which might be already true -- I'll check shortly). >> >> BTW In order to log in, you'll currently need an OpenSUSE SSO account >> (because that works out of the box, and I've no idea what needs to be >> done to make things work with sso.debian.org, say -- all hints >> gratefully accepted :-) ) >> >> There's lots of things left to do here, with the most important thing >> probably being making it possible to add tests without needing root >> access to the machine (which is currently needed for some bits) so >> please pester me about what you would like to test, and that will force >> me to make it possible for you to do it without my intervention >> (eventually ;-) ). > > I'd like it to get into a state ASAP so that we can turn of the > "g-i-installation" tests on jenkins.debian.net - how can I help with > that? Me too -- my time is currently being consumed by the fact that my local kindergarten is infested with some sort of vomiting virus, hence I decided Mathilda would be better off using me as a climbing frame (not great for productivity, so don't expect quick replies ;-) ) > If i look at the job group "Debian" I cannot (yet?) clearly see which > Debian images are tested how? The images are available in the assets tab, but you're right -- they are the daily sid images. > I suppose it would be good to setup tests for stable and > testing/unstable, and use the former to tests the tests and the latter > to test Debian... :) (and both combined to test+develop the UI) The current tests should work with stable/testing, so that's just a question of launching the tests. I'd really like to do this using some mechanism for throwing images at the test system, so that when the images are built, the tests can be triggered. Scripting it otherwise has proven rather fragile, and always seems to need a helping hand when releases happen, which is a bit of a bore. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
sources.debian.org stat page broken
Dear debsources team, After migration from sources.debian.net to sources.debian.org, the stat page https://sources.debian.org/stats/ is broken. All graphs would return HTTP 403. Please consider fixing it. Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part.
Re: Automatic testing: openqa.debian.net
Hi fil, On Fri, 24 Nov 2017, Philip Hands wrote: > If you look here: > > https://openqa.debian.net/ > > You'll see that I've been testing d-i daily images for a while. > > The scripts that drive those tests are available here: > > https://anonscm.debian.org/cgit/collab-maint/openqa-tests-debian.git/ In what way is openqa/os-autoinst better than the jenkins jobs that you and Holger have created to do similar tests in the past? I know Holger was at some point considering to replicate what Tails has done: https://tails.boum.org/contribute/release_process/test/automated_tests/ Have you looked into this and how does openqa/os-autoinst compare to this solution? Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: Automatic testing: openqa.debian.net
On Tue, 05 Dec 2017, Raphael Hertzog wrote: > Hi fil, > > On Fri, 24 Nov 2017, Philip Hands wrote: >> If you look here: >> >> https://openqa.debian.net/ >> >> You'll see that I've been testing d-i daily images for a while. >> >> The scripts that drive those tests are available here: >> >> https://anonscm.debian.org/cgit/collab-maint/openqa-tests-debian.git/ > > In what way is openqa/os-autoinst better than the jenkins jobs > that you and Holger have created to do similar tests in the past? > > I know Holger was at some point considering to replicate what Tails > has done: > https://tails.boum.org/contribute/release_process/test/automated_tests/ That's what I started from with what I was doing before. > Have you looked into this and how does openqa/os-autoinst compare > to this solution? It's entirely possible that I wasn't doing that in the most straight-forward manner, and that it's possible to make it easier to work with cucumber/sikuli, but I doubt that it's ever possible to make it a pleasant experience. Sikuli on its own seems like it's probably a nice thing, and cucumber seems very useful if one is doing BDD, but the cucumber web site has a big fat warning on it saying that if you are using it for what we were using it for, then you're doing it wrong. I was already agreeing with them about that before I saw OpenQA, so it was a great relief to discover that I could stop. Having jenkins in the mix makes things at least twice as painful. OpenQA really makes it a lot easier, orders of magnitude quicker, and much more fun. I can imagine getting OpenQA to a point where people can do drive-by test creation when they're testing bugs in random packages, and that not only would it be less effort than testing by hand, but should build into a nice regression suite -- I doubt that was ever going to happen with cucumber etc. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: sources.debian.org stat page broken
Hi, On Tue, Dec 05, 2017 at 07:43:13PM +0800, Boyuan Yang wrote: > After migration from sources.debian.net to sources.debian.org, the stat page > https://sources.debian.org/stats/ is broken. All graphs would return HTTP 403. Thanks for your message! It has been fixed now. Cheers, -- Matthieu signature.asc Description: PGP signature
Bug#850173: marked as done (qa.debian.org: debsources: Please provide link from decorated patch view to download/raw view)
Your message dated Wed, 6 Dec 2017 00:54:04 +0100 with message-id <3fe24c9a-4157-0241-70eb-094ccfdee...@oioannou.com> and subject line fixed and deployed has caused the Debian Bug report #850173, regarding qa.debian.org: debsources: Please provide link from decorated patch view to download/raw view to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 850173: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850173 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: qa.debian.org Severity: wishlist User: qa.debian@packages.debian.org Usertags: debsources [Forwarding the message below, from Christoph Biedl, to BTS.] -- Matthieu Hello, the patch view at e.g. https://sources.debian.net/patches/vblade/23-1/manpage-escape-dash.patch/ adds some decoration to a patch, suitable for human inspection. It was nice if that page could contain a link to the raw view which is https://sources.debian.net/data/main/v/vblade/23-1/debian/patches/manpage-escape-dash.patch At the moment, you'd have to pick the version number from the breadcrumb to get the full patch, then identify the applicable one and click "download". While feasible, a shortcut as above would be of some help, espcially for people outside the Debian project, in my case: upstream. Christoph signature.asc Description: PGP signature --- End Message --- --- Begin Message --- Raw link added in the view. i.e https://sources.debian.org/patches/vblade/23-1/manpage-escape-dash.patch/--- End Message ---
Bug#850186: marked as done (debsources: Patch view fails when there are too many patches)
Your message dated Wed, 6 Dec 2017 00:51:12 +0100 with message-id and subject line Fixed and deployed has caused the Debian Bug report #850186, regarding debsources: Patch view fails when there are too many patches to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 850186: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850186 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: qa.debian.org Severity: normal User: qa.debian@packages.debian.org Usertags: debsources This URL results in an Internal Server Error: https://sources.debian.net/patches/linux/3.2.78-1/ When I reported this outside the BTS, I got these replies: On Wed, 2017-10-04 at 08:11 +0100, Orestis Ioannou wrote: > I am not sure there are many packages with this kind of problem but > maybe a solution would be to do a pagination on this view and parse only > 100 patches at a time or so. On Wed, 2017-01-04 at 14:29 +0100, Stefano Zacchiroli wrote: > This sounds like a sensible workaround, at least as long as we're doing > the patch parsing on the fly. > > And it might end up being useful also later, when we will be doing the > patch parsing at update time, because we probably don't want to show 1 > gazillion patches on a single page anyhow, even if they're coming from > the DB. Ben. -- System Information: Debian Release: stretch/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) --- End Message --- --- Begin Message --- Hello, the bug was fixed today. It is live now on sources.debian.org i.e https://sources.debian.org/patches/linux/4.9.65-1/ Cheers--- End Message ---
