The Drupal 8 version of the Brightcove Video Connect module was written from scratch in order to take advantage of the architectural changes in Drupal 8, especially the new Entity Data Model. Designed around the new entity system in Drupal 8, the new Brightcove module seamlessly integrates video publishing into the Drupal editorial workflow and interface. This alleviates the fragmented editorial experience typically associated with 3rd party video hosting services.
We are just kicking off registration - totes, and badges and t-shirts, oh my! We will be open until 6:00pm today and will open up bright and early at 7:00am tomorrow.
We are located in the Hall G lobby of the New Orleans Convention Center. Please note - when you enter, it is quite far down (about 1 mile/1.6km) from the main entrance, but just following the purple signs; we are here waiting for you.
I just submitted another patch series to improve Britney for review. If accepted, they will probably be merged into master within 2 weeks. The changes this time are probably most exciting for people that run/maintain Britney. Key highlights include:
- Britney will be able to use a regular mirror (without partial suites) as data source
- Previously you would have to decompress and merge the Packages/Sources for each component.
- Partial suite support is still not added, but I hope to add it eventually. I know it is feature used by at least Ubuntu.
- This change implies renaming some input files around (Dates, Urgency and BugsV files) as Britney expected these next to the Packages files.
- More machine parsable facts added to “excuses.yaml”. It will cover almost all excuses currently in use.
- Britney will support two use cases for “faux packages” natively.
- I hope to use this to eliminate our need to “injecting” fake packages into Britney’s data source.
I would like to dwell a moment on the “faux packages”. We have had a helper script generate and inject fake packages into the list of packages (called “faux packages”). They generally serve two purposes, which Britney will support:
- Whitelist of fake packages to satisfy dependencies of other packages.
- These are generally stand-in for non-free machine configuration packages, where the end-user system would also fetch packages from the vendor’s repository.
- Packages relying on “faux packages” are generally not in “main” as Debian’s main component is required to be self-contained.
- These are (still) be called “faux packages” in/after the patch series
- Ensuring that certain packages are present and installable in testing.
- We have a lot of d-i related packages here to avoid accidental breakage of d-i.
- These are now referred to as a “constraint” (assuming there is no bike-shedding over the name).
Since Britney will now distinguish between these two use cases, I also make Britney enforce the second use case slightly better. Mind you, it can still be overruled by force-hints and BREAK_ARCHES, so there still enough rope to hang yourself.
The other exciting part of this patch set (for me, at least) is that Britney will hopefully become simpler to deploy. No doubt there are still some missing features and paper cuts left, but I suspect we are not far from a:
- Fill out a template config file pointing Britney to your mirror
- Run britney -c britney.conf
- Make your archive kit update your target suite based on Britney’s output.
- Put step 2+3 in crontab/jenkins/task scheduler of choice
There will certainly be some features that requires extra steps. An example is the “anti rc-bugs regression” feature, which requires you to feed Britney with the list of RC bugs for your source and target suite. But even without, Britney would still protect your target suite from most installability issues.
Filed under: Debian, Release-Team
Petter and Elena both talk enthusiastically about the Pyra. I am currently waiting for the shipment of my C.H.I.P. kit — I pre-ordered my kit when it was still in kickstarter phase, and got the PocketC.H.I.P. level.
It is clearly not the same nor equivalent to the Pyra — The PocketC.H.I.P. is a convenient packaging for what is chiefly an System-on-a-chip; the C.H.I.P. is a small system by today's standards (single-core ARM, 512MB RAM, not meant to be expanded), but still it looks quite usable as a very portable and usable Unix system. Oh, and of course — It's also Debian by default.
I got quite interested in what the Pyra was like. However, the pricing does not make much sense to me. OK, the Pyra is quite a bigger machine, but... While the PocketC.H.I.P. costs officially US$70 (and before June, according to the site, US$50), the Pyra starts at €500 (plus taxes)... It is just too much!
Anyway, I hope to have mine in time to go to DebConf. I also hope Petter and/or Elena can make it this year. And I hope we can compare the systems. I guess the Pyra will sit closer to a regular laptop... But anyway, my two last laptops have been at the bottom of the price scale (both from the Acer Aspire One line). I bought both for around US$300, used the first one as my main laptop for over five years, and have been three with the current one, completely happy.
Good news. The Debian Continuous Integration system is just awesome.
If a developer of a package prepares and declares tests for a given package, this CI system will trigger these test from time to time.
These tests are intended to check packages 'as installed', i.e, test what the end user is going to use in a final system.
The CI system is being improved, and now it supports 2 architectures: amd64 and arm64. Also, it now implements LXC as a backend, so the level of isolation available to run tests is very good, allowing us developers to launch even more elaborated tests.
This is the case of the HA stack (pacemaker, corosync, crmsh...), and the good news is that Debian is now continuously testing these packages.
At the time of this blog post, these are the tests:
- corosync: start the system service (the daemon) with the default Debian configuration
- pacemaker: start the system services (corosync and pacemaker daemons) with the default Debian configuration.
- crmsh: start the system services (corosync, pacemaker) and then add a basic resource (a virtual IP address) and do some tests (start the resource, stop, delete...)
The basic tests for crmsh was contributed by myself, you can check the two  commits in the git packaging repo.
This means that we should be able to detect and fix issues in these software packages very early in the development cycle (very cheap and easy compared to fixing things once packages migrate to testing or even stable).
For all users of HA cluster with Debian, these are definitely good news. We have now a HA stack in a fairly different state than in previous years :-) Big step forward.
Most of my Netfilter packages also implement these tests, but that subject doesn't belong to this blogpost.