debci 1.4 was released just a few days ago. Among general improvements, I would like to highlight:
- pretty much every place in the web UI that mentions a PASS or a FAIL also displays the tested package version. This was suggested to me on IRC by Holger
- I also tried to workaround an instability when setting up the LXC containers used for the tests, where the test bed process setup would finish without failure even though some steps in the middle of it failed. This caused the very final step for the debci-specific setup to fail, so there was no
debciuser inside the container, which caused tests to fail because that user was missing. Before that was fixed I was always keeping an eye on this issue, fixing the issue by hand, and re-triggering the affected packages by hand, so as far I can tell there is no package whose status has been permanently affected by this.
- Last, but not least, this release brings an interesting contribution by Gordon Ball, which is keeping track of different failure states. debci will now let you know whether a currently failing package has always failed, has passed in a previous version, or if the same version that is currently failing has previously passed.
ci.debian.net has been upgraded to
debci 1.4 just after that. At the same time I have also upgraded
autopkgtest to their latest versions, available in jessie-backports. This means that it is now safe for Debian packages to assume the changes in autopkgtest 4.0 are available, in special the
$AUTOPKGTEST_* environment variables.
In other news, for several weeks there were had issues with tests not being scheduled when they should have. I was just assuming that the issue was due to the existing test scheduler,
debci-batch, being broken. Today I was working on a new implementation that is going to be a lot faster, I started to hit a similar issue on my local tests, and finally realized what was wrong. The fact is that
debci-batch stores the timestamp of the last time a package has been scheduled to run, and it there are no test result after that timestamp, it assumes the package is still in the queue to be tested, and does not schedule it again. It turns out that a few weeks ago, during maintainance work, I had cleared the queue, discarding all jobs that were there, but forgot to reset those timestamps, so when
debci-batch came around again, it checked the timestamp of the last request and did not make new requests because there was no test result after that timestamp! I cleared all those timestamps, and the system should now go back to normal.
That is it for now. I you want to contribute to the Debian CI project and want to get in touch, you can pop up on the
#debci channel on the OFTC IRC network, or mail the autopkgtest-devel mailing list.
Earlier today I was handling a reproducibility bug and decided I had to try a reproducibility test by myself. I tried reprotest, but I was being hit by a disorderfs issue and I was not sure whether the problem was with reprotest or not (at this point I cannot reproduce that anymore).
So I decided to hack a simple script to that, and it works. I even included it in devscripts after writing a manpage. Of course reprotest is more complete, extensible, and supports arbitrary virtualization backends for doing the more dangerous/destructive variations (such as changing the hostname and other things that require root) but for quick tests
debrepro does the job.
$ debrepro # builds current directory $ debrepro /path/to/sourcepackage # builds package there $ gbp-buildpackage --git-builder=debrepro # can be used with vcs wrappers as well
debrepro will do two builds with a few variations between them, including $USER, $PATH, timezone, locale, umask, current time, and will even build under disorderfs if available. Build path variation is also performed because by definition the builds are done in different directories. If diffoscope is installed, it will be used for deep comparison of non-matching binaries.
If you are interested and don’t want to build devscripts from source or wait for the next release, you can just grab the script, save it as “debrepro” somewhere on your $PATH and make it executable.
As of yesterday, I am the new maintainer of pristine-tar. As it is the case for most of Joey Hess’ creations, it is an extremely useful tool, and used in a very large number of Debian packages which are maintained in git.
My first upload was most of a terrain recognition nature: I did some housekeeping tasks, such as making the build idempotent and making sure all binaries are built with security hardening flags, and wrote a few automated test cases to serve as build-time and run-time regression test suite. No functional changes have been made.
As Joey explained when he orphaned it, there are a few technical challenges involved in making sure pristine-tar stays useful in the future. Although I did read some of the code, I am not particularly familiar with the internals yet, and will be more than happy to get co-maintainers. If you are interested, please get in touch. The source git repository is right there.
Debian Ruby Sprint 2016 - day 5: More Reproducible Builds, Retrospective, and A Little Bit of Tourism5 de Março de 2016, 16:21
Earlier today I was made aware by Holger of the results of our reproducibility efforts during the sprint. I would like to thank Lunar for pinging us about the issue, and Holger for pointing me to updated results. The figure below depicts a stacked area chart where the X axis is time and the green area is reproducible packages. Red is packages that fail to build, and Orange are unreproducible packages
I was able to book accommodation for the sprint attendees very close to both my place and the sprint venue, what was very useful but also had this downside of them not being able to see much of city. As the final day of the sprint was getting closer, we decided to have a different lunch to allow them to see one of the most famous local landmarks, the botanical gardens.
So we headed down to the botanical gardens, grabbed a few items for lunch at the park coffee shop, and set out to visit this very beautiful place. I have to say that there is the place were I usually take every visitor I have. We were joined by Gioavani who had just arrived for the the MiniDebconf on the following weekend.
The final lists of accomplishments of the day was again very impressive
- r10k 2.1.1-2
- run massive update on team repositories
- bump Standards-Version
- fix Vcs-* fields
- drop version in gem2deb build-dependency
- set debhelper compatibility level to 9
- update the default ruby-tests.rake
- day 4 report
- uploaded ruby-faraday-middleware-multi-json 0.0.6-2
- uploaded ruby-powerpack 0.1.1-2
- uploaded ruby-contracts 0.13.0-1
- uploaded ruby-chef-config 12.7.2-1 (NEW)
- uploaded ruby-foreigner #808530 and asked it removal from the NEW queue (was already ROMed)
- filled for RM ruby-opengraph-parser (#816752)
- new how-can-i-help version developed and uploaded
- uploaded ruby-romkan to unstable (from exp)
- uploaded ruby-rinku to unstable (from exp)
- uploaded ruby-ole to unstable (from exp)
- uploaded ruby-net-ldap to unstable (from exp)
- uploaded ruby-rack-mobile-detect to unstable (from exp)
- uploaded gem2deb 0.28 to help with reproducible builds: filenames are now sorted
- uploaded rails 2:184.108.40.206-2 with packaging improvements
- run unit tests during the build and on CI
- apply upstream patch to fix ActiveRecord breakage under Ruby 2.3
- pushed a ton of tags for existing uploads
- merged improvements to the team master repository
- review/cleanup the contents of the repository
- improved helper scripts to automate the workflow (upload, build, new-upstream, etc)
- followed up on ruby2.3 transition, filed #816698 against subversion because of ftbfs on mips, mipsel
- put ruby-cocoon into a better state
- uploaded ruby-plist
- gem2deb: gem2tgz will now create foo.gemspec (easier to patch) instead of metadata.yml
- gemwatch: ditto
- close #794139 jekyll bug (unreproducible)
- close #798934 ruby-ffi-rzmq bug (unreproducible)
- closed ftbfs #816586 #800057 #784699 as unreproducible
- reassigned #760952 #680297 to ruby2.3 (from ruby2.2)
- investigated how to list packages with non-buildd-binary uploads
- ScottK has removed ruby2.1 from unstable!
By the end of the afternoon I asked everyone to fill out a simple retrospective list, what we can use later to make future sprints better and better. Below are the results we got.
What was good:
- restricted room hours actually made for a nice rhythm (did not apply for a long time…)
- very good food
- very cheap food!
- longer period makes the effort of travel more worthwhile
- many participants and longer sprint than usual allowing more work to be done
- good preparation with clear goals, make the sprint usefull
- patience with the less experienced participants
- RFS very fast
- Antônio is an excellent host
- You all are so helpful
- great dinners
What could be better:
- room too close to the street, too much vehicle noise, but sometimes nice music
- more coffee ^W meat
- could know more portugues so ordering food would have been easier
- debian infra could have not been down during the sprint
The night ended at Bar do Alemão (“The German’s Bar”). Both their beer and their food are very good, but I don’t have enough elements to vouch for their authenticity. :) We were joined by Giovani (who we also met earlier in the botanic gardens), and by Paulo and Daniel who are organizing the MiniDebconf.
And that is the end of this year’s Debian Ruby team sprint. I hope we do it all over again next year.
As the day 4 of the Debian Ruby team sprint in Curitiba unfolded, we have now fixed a total of more than 70 build failure bugs, managed to almost finish the Ruby 2.3 transition to be good to migrate into testing, and bootstrapped some documentation that will help new contributors get up to speed with Ruby packaging faster.
We have also requested the removal of several packages that are either severely outdated, abandoned upstream, beyond repair, utterly wrong, or in some cases, all of the above.
The full list of work items finished yesterday is:
- filed for RM ruby-rubysl-test-unit (no rdeps, duplicates ruby-test-unit)
- filed for RM ruby-literati (no rdeps left)
- uploaded ruby-certificate-authority 0.1.6-2
- uploaded ruby-pdf-reader 1.4 (Closes: FTBFS #795763)
- uploaded ruby-http 1.0.2-1 (Closes: #795752)
- raise severity of FTBFS bugs with ruby2.3
- day 3 report
- NMU pcs and upload to DELAYED/2 to remove dependency on ruby-monkey-lib and build-dependency on ruby2.1-dev
- upload ruby-parslet (Closes: #795046)
- initial documentation of packaging workflow with updated helper scripts in the team repo – https://wiki.debian.org/Teams/Ruby/Workflow
- ask for the removal of ruby-rspec-longrun
- ruby-opengraph-parser – upstream bug; upstream unresponsive; asked uploader about removal (no rdeps)
- fix ruby-celluloid-io for ruby2.3
- fixed ruby-buff-extension to work on ruby2.3
- uploaded newer ruby-varia-model upstream to work with newer ruby-hashie
- ask for the removal of mdpress
- uploaded ruby-buff-config, ruby-semverse, ruby-buff-ruby-engine, ruby-buff-ignore, ruby-buff-shell-out to remove spork
- filed for RM spork (obsolete, broken)
- filed for RM ruby-gsl on failing archs
- upload ruby-solve (Closes: #816359, thanks zeha!)
- update ruby-standalone to work properly with ruby2.3 (needs to remove the rake binary)
- upload ruby-memfs
- ruby-rack (1.6.4-3) (ROM ruby-memcache-client)
- ruby-parslet 1.7.1-1 #795046
- upload ruby-listen
- upload ruby-clockwork
- upload ruby-bio with a patch to avoid transient FTBFS because of undefined class names
- fixed ruby-fakeweb ftbfs
- cleaned up old repositories on git.d.o
- investigated PET status (appears to somewhat work, but mostly decaying)
- uploaded ruby-ogginfo
- upload ruby-libxml (agan!)
- upload racc 1.4.14-1
- upload ruby-sidekiq-cron
- how-can-i-help updated
- racc 1.4.14-1 (not ruby-racc ;-))
We also managed to flirt with 2 capital sins. For those who care about these things, which I don’t (but I still care about you), I guess 2 out of 7 still means we are good? :-)
I few people that I will not name complained that they hadn’t had enough steak on the previous night, so we set out to visit a traditional all-you-can-eat Brazilian steakhouse (“churrascaria”). I made a reservation at Jardins Grill and there you have gluttony. I am pretty sure that “not enough steak” wasn’t an issue last night. You can see how happy, despite being full to almost the point of being sick, everyone was.
A disjunct set of people, who I will also not name, were very disappointed to find out that the ruby-tinder package has absolutely nothing to do with Tinder but were still very active on the later. Maybe Friday night we will have to split the group into a lust-free family party and a Tinder party.