You are here

Shtëpia › Agreguesi i feed › Burimet

Planet Debian

Subscribe to Feed Planet Debian
Planet Debian - https://planet.debian.org/
URL: https://planet.debian.org/
Përditësimi: 5 months 3 javë më parë

Wouter Verhelst: Visum!

Pre, 01/02/2019 - 10:22md

A year and a half ago, we made a decision: I was going to move.

About a year ago, I decided that getting this done without professional help was not a very good idea and would take forever, so I got set up with a lawyer and had her guide me through the process.

After lots of juggling with bureaucracies, some unfortunate delays, and some repeats of things I had already done before, I dropped off a 1 cm thick file of paperwork at the consulate a few weeks ago

Today, I went back there to fetch my passport, containing the visum.

Tomorrow, FOSDEM starts. After that, I will be moving to a different continent!

Paul Wise: FLOSS Activities January 2019

Pre, 01/02/2019 - 6:23pd
Changes Issues Review Administration
  • Debian: merge patch, install dependencies, fix LDAP server, answer keys question, check build hardware differences, remove references to dead systems
  • Debian wiki: re-enable old account unblacklist IP addresses, whitelist email addresses, ping accounts with bouncing email, investigate password reset issue
  • Debian derivatives census: rerun patch generation to fix broken files
Communication
  • Initiate discussion about the status of hLinux
  • Respond to queries from the Debian derivatives census Outreachy project intern
  • Respond to queries from Debian users and developers on the mailing lists and IRC
Sponsors

The purple-discord work was sponsored by my employer. All other work was done on a volunteer basis.

Louis-Philippe Véronneau: DebConf Videoteam sprint @ FOSDEM report

Pre, 01/02/2019 - 6:00pd

For the past week, the DebConf Videoteam has been hard at work, sprinting in Diegem, Belgium. We've had a lot of fun, but were also able to improve a lot of things.

Raspberry Pi Hacking

Jonathan and Andy eventually want to set up Raspberry Pi 3B+ with screens on the top of our cameras to act as tally lights and enable the video directors to send messages to the camera operators that way. No more sleeping on the switch! To make this possible, Jonathan has been working on adding a custom drop-down menu near the camera preview in voctogui.

Since we don't want to have to jump through hoops to image those boards, Jonathan worked on booting a pure Debian image on the Pi 3B+. He's been able to load an Initramfs and a full mainline kernel on it, but ran into trouble getting the network up because of USB driver problems.

The program Jonathan has been writing to display messages on the Raspberry Pi screens is called toetally. It's still in pre-alpha, but check it out nonetheless!

Opsis

Tzafrir worked on getting his Opsis board up to date with the latest version of HDMI2USB, the firmware we are using on those boards to capture HDMI inputs.

He's been mostly successful in getting it to work, but has been having hardware problems with his Minnowboard Turbot, the SBC we are using to control the Opsis.

Documenting our streaming setup

Nicolas completely rebuilt our streaming setup for DebConf17, migrating from icecast2 to something based on libnginx-mod-rtmp, as icecast2 kept crashing.

It has been working very well since then, but sadly Nicolas hadn't had time to document how it works properly.

This is not the case anymore! You can now check out our streaming documentation.

Nicolas also included our ansible role documentation to the main ansible documentation generated in sphinx.

Hardware Hacking

We recently bought a new audio kit to replace the one we had. It was getting pretty old and was basically crumbling away. At the last mini-DebConf we did in Hamburg, we even had to borrow a kit from the CCC VOC.

Before the sprint, Andy and Kyle worked on listing what hardware we needed to buy and Nicolas had the gear shipped to Paris. Sadly, we only got one of the four wireless receivers we bought, as the other ones were backorder.

During the sprint, Nicolas and Andy worked hard on racking the gear in our new front of stage rack and Andy did a soldering job in our Opsis case to be able to power the Opsis, the turbot and the network switch all at once.

You can find more in depths details about our new audio system and the racking process on Andy's blog.

Thanks to HSBXL for lending us tools to hack sheet metal!

Git LFS

With the phasing out of Alioth, our old git-annex repository was not accessible anymore (Salsa doesn't support git-annex). Judit, Tzafir & Stefano thus worked on migrating it to git LFS.

The plan is to use this new DebConf share repository to host pictures taken by attendees.

As we are trying to migrate away from DebConf hardware, Stefano also wrote a scraper for DebConf Gallery and plans to move the pictures hosted there to DebConf share.

He still plans to modify Wafer to make it easy for speakers to publish their slides on the DebConf website, but if it comes to it, we'll also be able to use that git LFS repository to host slides too.

Playing with the Fomu

Giovanni Mascellani came-by during the week to learn more about the way our setup works. He helped with a bunch of small fixes left and right and we had a very good time!

By pure chance, Stefano came back from LCA with a bunch of Fomu boards (tiny open hardware, open toolchain FPGA boards that fits in your USB port) to give out for FOSDEM and Giovanni managed to flash one of them with a Raspberry Pi. Very neat!

USB installer for our ansible playbooks

Although we mainly install new machines using PXE boot from our network gateway, we sometime need to bootstrap other machines without it. We normally did that by installing Debian manually on a machine and then running ansible on it.

We now have an easy to use USB installer! You can run a simple script that builds a preseeded Debian image and flashes it on a USB key. Once Debian is installed, the machine reboots and runs ansible automatically.

We previously had something similar, but Carl Karsten rebuilt the whole thing and made it easier to use. Louis-Philippe updated the documentation.

Soldering USB ports

When we packed one of our Opsis boards after DebConf18 in Taiwan, one of the USB ports got mangled. Nicolas spent a whole day trying to resolder it back, but finally ended up cutting it from the board and replaced it by a cable attached to a USB header.

systemd in Docker in Gitlab CI

Louis-Philippe worked a large part of the week trying to get systemd to run in Docker in Gitlab CI. We need that to test our ansible modules properly.

Having worked on this previously, this week he tried to build a docker container that ran both systemd as PID 1 and an OpenSSH Server and tried to run this image as a service.

The idea behind this is that since there is no way to run systemd as PID 1 in Gitlab CI, maybe it could be achieved in a service. Ansible roles could then be tested by connecting via ssh.

Sadly, this also proved impossible. Even when using a privileged runner, docker containers need to have volumes like /sys/fs/cgroup explicitly mounted for systemd to run and there is no way to achieve this with a service.

To better test our ansible roles, he added more unit tests that skip the systemd handlers.

DebConf19 preparations

Paulo and Adriana flew in from Brazil to attend the video sprint. With the help of other DebConf people present, they ironed out a few problems and worked some more on planning for DebConf19.

Fixing our example inventory in ansible

Stefano fixed the default ansible inventory that ships with our playbooks. We don't use that inventory very often, as we have a more complete one for our production setup.

It is used by people that want to test our setup though, so that means others will be able to replicate our work more easily.

Thank you!

This sprint would not have been possible without the support of the amazing Jasper Nuyens of Linux Belgium, who very graciously lent us a place to hack and sleep for the week. Jasper also bought us delicious pizza on Thursday night, a gesture everyone highly appreciated.

We also extend our thanks to the Debian Project for giving us a budget for the sprint.

Thank you!

Jonathan McDowell: IoT Security, DRM and user freedom

Enj, 31/01/2019 - 7:39md

IoT security is a hot topic these days, and rightly so. Matthew Garrett has spent a lot of time reverse engineering various IoT light bulbs to determine how secure they are, with depressing results. So when I saw Bruce Schneier’s recent post Security Analysis of the LIFX Smart Light Bulb which started with “it’s terrible” I thought this was more of the same. Except it’s not. The original article is Pwn the LIFX Mini white (and the author has at least a couple of other device teardowns in the same vein).

What these articles are concerned with is not the usual protocol level security which Matthew investigates. Instead they’re about physical device security. In particular the points raised are:

  • Wi-Fi details are stored in the clear on the device
  • The device does not have secure boot or flash encryption enabled
  • The private key for the device can be retrieved easily

All of these boil down to the same root cause; without effective DRM there is no way to protect devices from physical attacks. That can be as simple as having only internal flash and being able to blow a set of EFUSEs to prevent readout/debug interfaces functioning, or it can be a full built in boot ROM with cryptographic verification of an image pulled in from external flash (potentially encrypted) and the building up of a chain of trust. I see 2 main problems with this.

Firstly, getting security like this right is hard. Games console manufacturers are constantly trying to protect their devices against unauthorised code running, and while they seem to be getting better it’s taken quite a number of mistakes to get there. They have a much bigger financial imperative to get this right, as console DRM attacks are frequently used for piracy. An IoT vendor could end up adding significant cost to their BoM if they have to buy a more advanced chip to be able to do the appropriate end-to-end flash encryption required. (The LIFX is using the ESP32, which does have some of these features that are not present in the more basic (and cheaper) ESP8266. I’ve no idea if anyone has done a full analysis of the ESP32 security.)

Secondly, locking devices down in this way has a big impact on user freedom. It should come as no surprise that this is my primary concern, as I believe it is detrimental to the end user in multiple ways.

  • There’s a lot of poor security in the IoT protocol arena. If it’s not possible for anyone other than the manufacturer to update a device, or retrieve the firmware image to examine how a device operates, security will suffer.
  • Updates being locked down to the manufacturer leaves the user open to the prospect of forced obsolescence when the manufacturer decides they will no longer support the device, or goes out of business (assuming a device that has some sort of cloud component).
  • Part of the appeal of a lot of the current IoT devices is the fact they can be repurposed for uses beyond what the manufacturer imagined. Just look at the Sonoff-Tasmota project - this excellent 3rd party support is one of the main reasons I purchased several Sonoff devices. If I hadn’t been able to replace the firmware they wouldn’t have been of interest to me or countless other people who’ve purchased them.

There are ways to enable user freedom while still having a locked down setup by default, but they’re hard to do in the embedded IoT space (generally no hardware infrastructure that allows plugging in a USB stick with a new root certificate on it and enrolling it like EFI Secure Boot), and add significant cost and complexity to devices that are meant to be cheap and ubiquitous. I see the validity in raising concerns about discarded devices leaking Wi-Fi credentials, but it’s something any device you connect to your Wi-Fi is potentially going to do. That means your laptop, your phone and all the random other devices you allow to connect to your Wi-Fi. It’s something we need to be aware of generally, rather than singling some cheap IoT light bulbs out.

The lack of physical security for the firmware image or device credentials is not so worrying to me. A surveillance device in a light bulb is not a new concept; in fact the added complexity of an IoT bulb makes it easier to justify the complex circuitry being present. If it requires physical access to be able to subvert the device like this that’s significantly less worrying than being able to do so remotely.

Don’t get me wrong, I love a good device teardown, and I think there’s an interesting discussion that’s already underway about how to improve physical device security without restricting user freedom. I just don’t think this is the major failure that some commenters are suggesting.

Andy Simpkins: Debconf Video Team Sprint – Day 3

Enj, 31/01/2019 - 2:31md

Today has mostly been spent in conversation.

Jonathan has started to scratch an itch that I share, we need a better tally light solution.  When we were using DV switch we had a simple tally light system using (iirc DTR on a) serial port to turn on or off an LED.  This was fine because there was always a PC available at each camera running DVCapture.

Since the move to Voctomix, each camera no longer has it’s own dedicated PC.  Instead we have long 50R co-ax cables (remember the days of cheaper-net 10 base-2?) going directly to a PC running VoctoCore….  Yes we still use a serial port to drive a tally light (all be it these days from a USB to serial converter) but we could do so much better.

Whilst an LED is good to indicate to a presenter which camera(s) are currently active, but wouldn’t it be good to be able to interact with the camera operator some way as well?

Sure we can dedicate an LED or two for this task, but given how cheep SPI displays are these days why not go for a small display instead?

Now the director can send camera operators canned messages (or free text if they have the time to type one).  The camera operator can easily see what the director would like them to do – and they can acknowledge the instruction.  of cause they can also prod the director as well  – two way comms and all :-)

Our tally light / display can be mounted to our cameras using either a flash shoe (shame we can’t grab power this way) or from a tripod screw, both are available on our cameras.

We could choose to hang all this behind a really cheep SBC (think Arduino) but given the cost and that we only need a few something like a RaspberryPi is perhaps a better option.  We could even add USB headsets and mumble if we later want to have full talk-back…

We spent some time fleshing out the requirements for and the road map of the ToeTally project.

I have ordered myself a little SPI display and a case from ebay (Jonathan already has something similar – there are many such things on Ebay and other sites).  This should be plenty to get the project up and running.

/me has found another rabbit hole to spend my time – I may even make some software commits!

 

Debian Java Packaging Team: Help the Java Team distribute your project!

Enj, 31/01/2019 - 2:00md

There is a vast array of great free software projects written in Java. All sorts of large systems that we all rely on every day are built upon the Apache Foundation libraries. Large companies like Google and IBM put out standard libraries that so many other projects use. Unfortunately, the standard practice for distributing Java code makes it a lot of work to integrate them into Debian.

The Debian Java Team's work is generally under-appreciated, so we are getting the word out here. The Java Team has to consistently fight the Java standard practice of bundling all deps into a single JAR. This means there is no shared security updates, each dev has to update every dependency themselves in that model. That works great for large companies with staff devoted to doing that.

For the majority of Debian use cases, that works poorly. Debian delivers on the promise that people can just apt install foo and have it work, and receive security updates. The user does not even need to know what language the program is written in, it just works.

The Java developer community need to embrace the value of these use cases, and help Debian by making it easier to package Java projects in the standard distro method, with shared dependencies that are independently updated.

Python and Ruby provide great examples of more flexible standard practice for shipping software. Both have methods of describing the dependencies needed, and then automatically fetching them. They are designed in a way that is quite easy to hook into the native build system and make Debian packages. That is sadly not the case with Gradle and Maven, the most popular build systems for Java. For those, the Java Team usually has to extensively patch the build system to make it work for the Debian package.

Steve Kemp: I decided it was time to write a compiler

Enj, 31/01/2019 - 1:46md

I've spent some time in the recent past working with interpreters, and writing a BASIC interpreter, but one thing I'd not done is write a compiler.

Once upon a time I worked for a compiler-company, but I wasn't involved with the actual coding at that time. Instead I worked on other projects, and did a minor amount of system-administration.

There are enough toy-languages that it didn't seem worthwhile to write a compiler for yet another one. At the same time writing a compiler for a full-language would get bogged down in a lot of noise.

So I decided to simplify things: I would write a compiler for "maths". Something that would take an expression and output assembly-language, which could then be compiled.

The end result is this simple compiler:

Initially I wrote something that would parse expressions such as 3 + 4 * 5 and output an abstract-syntax-tree. I walked the tree and started writing logic to pick registers, and similar. It all seemed like more of a grind than a useful exercise - and considering how ludicrous compiling simple expressions to assembly language already was it seemed particularly silly.

So once again I simplified, deciding to accept only a simple "reverse-polish-like" expression, and outputing the assembly for that almost directly.

Assume you want to calculate "((3 * 5) +2)" you'd feed my compiler:

3 5 * 2 +

To compile that we first load the initial state 3, then we walk the rest of the program always applying an operation with an operand:

  • Store 3
  • 5 * -> multiply by 5.
  • 2 + -> add 2.
  • ..

This approach is trivial to parse, and trivial to output the assembly-language for: Pick a register and load your starting value, then just make sure all your operations apply to that particular register. (In the case of Intel assembly it made sense to store the starting value in EAX, and work with that).

A simple program would then produce a correspondingly simple output. Given 1 1 + we'd expect this output:

.intel_syntax noprefix .global main .data result: .asciz "Result %d\n" main: mov rax, 1 add rax, 1 lea rdi,result mov rsi, rax xor rax, rax call printf xor rax, rax ret

With that output you can assemble the program, and run it:

$ gcc -static -o program program.s $ ./program Result 2

I wrote some logic to allow calculating powers too, so you can output 2 ^ 8, etc. That's just implemented the naive-way, where you have a small loop and multiply the contents of EAX by itself the appropriate number of times. Modulus is similarly simple to calculate.

Adding support for named variables, and other things, wouldn't be too hard. But it would involve register-allocation and similar complexity. Perhaps that's something I need to flirt with, to make the learning process complete, but to be honest I can't be bothered.

Anyway check it out, if you like super-fast maths. My benchmark?

$ time perl -e 'print 2 ** 8 . "\n"' 256 real 0m0.006s user 0m0.005s sys 0m0.000s

vs.

$ math-compiler -compile '2 8 ^' $ time ./a.out Result 256 real 0m0.001s user 0m0.001s sys 0m0.000s

Wow. Many wow. Much speed. All your base-two are belong to us.

Jonathan Carter: Free Software Activities (2019-01)

Enj, 31/01/2019 - 1:15md

I used to think monthly logs are too much effort, but I decided to give it a go and it ended up being easy and very non-intrusive to my workflow. Above picture taken at Rhodes memorial while riding bike around Cape Town.

2019-01-01 Published Debian Package of the Day #59: bastet (highvoltage.tv / YouTube)

2019-01 01: Start working on updating Planet Debian policy

2019-01-02: Read 191/349 pages of Python Interviews – Discussions with Python experts

2019-01-03: Update Planet Debian policy, make it live and announce it

2019-01-03: Continued discussion of xfce-screensaver‘s future in Debian (ITP: #911115)

2019-01-03: Sponsor package: camlimages (4.2.6-1) (mentors.debian.net), grant dm upload rights for uploader

2019-01-03: Various discussions regarding DebConf20 bids, following Lisbon recon team live updates

2019-01-04: Finish reading Python Interviews – Discussions with Python experts

2019-01-04: Adopt aalib package, upload new package with vcs now on salsa.debian.org

2019-01-04: Upload new upstream version of toot (0.20.0-1) to debian unstable

2019-01-04: Upload new upstream version of bundlewrap (3.5.3-1) to debian unstable

2019-01-04: Upload new upstream version of flask-restful (0.3.7-1) to debian unstable

2019-01-04: Upload new upstream version of gnome-shell-extension-dash-to-panel (17-1) to debian unstable

2019-01-04: Sponsor package: pass-otp (1.2.0-1) (e-mail request)

2019-01-04: Troubleshoot pythonqt, give up in frustration and take a break for the weekend instead

2019-01-07: Backport firmware-nonfree (20180825+dfsg-2~aimsppa1) for AIMS Desktop (mostly for RTL8237AU support)

2019-01-07: Upload new package xfce4-screensaver (0.1.3-1) to debian experimental

2019-01-08: Update calamares-settings-debian (10.0.15) with preliminary buster artwork and work around stale fstab file left behind by live-build and upload to debian unstable (10.0.15-1). Fix description typo that will be released with next upload (Closes: #918222)

2019-01-09: Fix a whole bunch of AIMS Desktop build related problems and build updated stretch/buster images for testing.

2019-01-10: Upload new upstream version of calamares (3.2.3-1) to debian unstable

2019-01-10: Upload new upstream version of python aniso8601 (4.1.0-1) to debian unstable

2019-01-10: Work on initial announcement for Buster artwork selection

2019-01-13: Upload xfce4-screensaver (0.13-2) (Closes: #919151) (Whoops, accidental upload to unstable, file #919348 to prevent it migrating to testing)

2019-01-11: Initial upload of fonts-quicksand (0.2016.1) to debian unstable (Closes: #918995)

Calamares on Debian Live using new buster artwork

2019-01-15: Test new calamares with buster artwork on debian-live weekly builds

2019-01-16: Upload new upstream version of dash-to-panel gnome shell extention (18-1) to debian unstable

2019-01-16: Release new calamares-settings-debian that fixes setups that contain swap partitions + full disk encryption (10.0.16), upload to debian unstable (10.0.16-1) which also fixes a typo (Closes: #918222)

2019-01-17: Upload new live-installer (57) to remove calamares-settings-debian after live install from d-i

2019-01-17: DebConf meeting with DC20 bid teams to ask questions from DebConf Committee and improve bid pages

2019-01-18: Prepare artwork upload for debian-installer, upload rootskel-gtk (1.41) to debian unstable

2019-01-18: Spent lots of time going through debian-installer code, started working on some skeleton concepts for some ideas that I have that I’ll publicly publish some other time

2019-01-19: Started working on some proof-of-concept system installer code in python3, worked mostly on structure and module importing. More on this much later

2019-01-20: Worked on keyboard, localisation and partitioning modules for a concept distro-installer

2019-01-21: Uploaded fonts-quicksand (0.2016-2) with some minor fixes to correct lintian warnings

2019-01-21: Upload calamares (3.2.3-2), add libpwquality-dev and remove patch to use sudo instead of pkexec (not that pkexec seems to work everywhere)

2019-01-22: Sign gpg key of local Debianite who should soon apply for DD

2019-01-22: Adopt and upload preload (0.6.4-3) (Closes: #646216)

2019-01-22: Reviewed mentors.debian.net package siconos (4.2.0+git20181026.0ee5349+dfsg-1) (needs a little more work)

2019-01-22: Review mentors.debian.net package libcxx-serial (1.2.1-1) (needs a little more work)

2019-01-22: Sponsor package budgie-extras (0.7.0-1) (mentors.debian.net request) (Closes: #917724)

2019-01-23: Sponsor package osmose-emulator (1.4-1) (mentors.debian.net request) (Closes: #918507)

2019-01-23: Sponsor package dhcpcd5 (7.0.8-1) (mentors.debian.net request) (Closes: #914070)

2019-01-23: Review mentors.debian.net package pcapy (0.11.4-1) (needs some more work)

2019-01-23: Sponsor package blastem (0.6.1-1) (mentors.debian.net request) (Closes: #919541)

2019-01-23: Review mentors.debian.net package owlr (5.2.0-1) (needs some more work)

2019-01-23: Upload preload (0.6.4-4) to debian experimental (Closes: #920197, #861937, #893374, #697071)

2019-01-23: Fix some bootloader related stuff when using d-i on AIMS Desktop, add README entry in GRUB.

2019-01-24: Sponsor package dhcpcd5 (7.0.8-2) (e-mail request)

2019-01-24: Upload preload (0.6.4-5~exp1) to debian experimental (attempt to fix some niggles)

2019-01-25: Start traveling from Cape Town to Brussels for Debconf video sprint and FOSDEM (thanks to Debian for covering travelling expenses)

2019-01-29: Sponsor packages for DD with expired: key git-review (1.27.0-1), q-text-as-data (1.7.4+2018.12.21+git+28f776ed46-1), swift (2.19.0-4)

Thanks to Linuxbe for providing the hackspace, drinks and kind hospitality for the DebConf video sprint!

2019-01-28: Day 1 of DebConf video sprint. Work on tillytally (now ToeTally), start to unhardcode test cards, implement planned cards and initial discussion with integrating with voctomix-core.

ToeTally is a tally display system that will be mounted above DebConf video cameras, replacing existing tally lights that work over serial, it should make it easier for the director to co-ordinate the stream. It’s also very early work in progress.


2019-01-29: Learn about raspberry pi netbooting, figure, tweak and build debian(ish) images using rpi23-gen-image (for later use on video tally system)

2019-01-30: Spent some time with Andy from video team properly speccing out Tally project, renamed from TillyTally to ToeTally.

2019-01-31: Started working on cross-building scripts for building tally system (arm64) boot environment on x86 that will eventually be deployed using existing video team Ansible setup.

James Bromberger: 20 Years of Linux.conf.au [Memoirs]

Enj, 31/01/2019 - 1:02md

On the first night I arrived in Christchurch, New Zealand for Linux.conf.au 2019, a group of around a dozen attendees went to dinner. Amongst them were Steve Hanley and Hugh Blemmings, whom I have known since the early 2000’s at various LCAs around the region. They asked for some memoirs of LCA – something small; what follows was my throughts, far longer than expected

Dateline: Just after the Year 2000. The Y2K bug. The first billion seconds of the Unix epoch (Sept 9 2001)…

In the summer of 2001, some friends from Perth and I made a trip to a new conference we had heard about called Linux.conf.au. I was a new Debian Linux developer, my friends were similarly developers, sysadmins, etc. What met us was one of the best interactions of like minded individuals we had seen; deeply technical discussions and presentations by key individuals who not only knew their subject matter, but wrote the code, created the community, or otherwise steered a section of the Open Source software movement from around the world.

Linux.conf.au 2001 – day 1

Living on the opposite side of Australia in Perth meant we were intellectually starved of being able to talk face-to-face to key people from this new world of Open Source and Free Software. The distance across the county is almost the same as East to West coast United States, and not many visitors to Melbourne or Sydney make the long trek over the Great Australian Bight to reach Western Australia’s capital.

We found ourselves asking the LCA 2011 organisers if it would be possible in future to run Linux.Conf.Au in Perth one day.

Having had the initial conference (then called the Conference of Australian Linux Users, or CALU) in 1999 in Melbourne, and then Linux.conf.au 2001 in Sydney, it seemed a natural progression to having LCA roam around different cities year; it felt almost unfair to those who could not afford to travel to Melbourne or Sydney.

The result from 2001 was that in 2002 it would run in Brisbane, but that we should make a proposal and get organised

MiniConfs at LCA

In 1999 I went to AusWeb in Ballina, NSW, and ApacheCon 2K in London.

Closing of ApacheCon 2000 in London – developers on stage Q&A

I also went to DebConf 1 in Bordeaux, France. DebConf was run as an adjunct to the larger French Libre Software Meeting (LSM), as Debian felt that its gathering of developers was too small to warrant the organisational overhead for its own conference at that time.

Debian Developers at DebConf1, Bordeaux 2001

I liked the idea of a pre-conference gathering for Debian for Linux.conf.au 2002 in Brisbane – a Mini Conference.

So in parallel to talking about running LCA in Perth for 2003, I asked Raymond Smith, LCA 2002 lead organiser, and the rest of the Brisbane organising team if I could turn up a few days early to Brisbane for the 2002 conference, use one of the rooms for a small pre-event.

The principle was simple: minimal organisation overhead; don’t get in the way of those setting up for LCA.

LCA2003 Bid Preparation Puffin/Penguin suit

In December 2001 we found what was probably closer to a full-size puffin costume at a fancy dress shop – close enough that it could pass for a penguin.

We started to plan a video as a welcome video – to show some of Perth, and what could be expected in coming to the West.

With a logo I designed from a classic Australian yellow road sign, we had a theme of the Road Trip to Perth.

So with the Puffin/Penguin suit in hand, and a few phone calls, we found ourselves with camera kit on New Years’ Day 2002 at the arrivals hall of Perth airport to film segments for a video to play at the close of LCA2002: the story of tux arriving and making his/her/their way to the conference venue at UWA. Much of the costume performance was Nick Bannon, but also Mark Tearle, and others. I filmed and rough scripted, Tony Breeds edited video, and sought licensing for the music, generously donated by the band credited.

LCA 2002

The MiniConf at LCA ran smoothly. People arrived from around the world, including then DPL Bdale Garbee.

James Bromberger (c) and Bdale Garbee (r) at the Dbeian Mini-Conf, 2002

The main conference was awesome, as always.

Rusty Russell speaking at Linux.conf.au 2002 Jeremy Allison (l) and Andrew Tridgell (r) tlaking Samba at Linux.conf.au 2002 Raymond Smith, lead organiser LCA 2002 Ted T’so talking filesystems at LCA 2002. “In Ted we trust”. LCA2003 closing James Bromberger (l) and Tony Breeds (r) – co-chairs of LCA 2003 LCA2003 invite video being played at LCA2002 Closing Post 2002 prep for 2003

We ran monthly, then weekly face to face meetings, we split into teams – web site, papers committee, travel & accommodation, swag, catering, venue, AV and more. Bernard Blackham made significant changes to get us able to process the crypto to talk to the CommSecure payment gateway so we could process registrations (and send signed receipts).

We thought that not many people would come to Perth, a worry that drove us to innovate. Sun Microsystems agreed to sponsor a program we devised called the Sun Regional Delegate Programme, funding a sizable amount of money to fly people from across the state down to Perth to attend

I left my full time job in November 2002 to work full time on the conference, having planned to start travelling in Europe sometime after LCA in 2003. Hugh Blemmings (then at IBM) sponsored Linus Torvalds to attend, which we kept under wraps.

A small group worked on making a much better, full size Penguin costume, which days before the opening we proposed to put Linus in as part of the opening welcome.

I sourced some white label wine, designed and had printed some custom labels, naming this the Holy Penguin Pee, which was to be our conference dinner wine (amongst other beverages). While at the time this was a nice little drop; the bottles I now hold some 16 years later are a little less palatable.

Perth 2003

Miniconfs had blown out to several sessions. Attendance was projected to exceed 500 attendees (excluding speakers and organisers).

As the audience gathered for the welcome in the Octagon Theatre at UWA, we had amongst us Tove Torvalds, and their three small girls: Patricia (6), Daniella (4), and Celeste (2).

James Bromberger (l), Rusty Russel (c), Linus Torvalds (r

As the conference opened, I took to the stage, and the Penguin waddled on. I commented that we have a mascot, and he’s here; Rusty then joined me, and removed the head of the Penguin to reveal Linus within.

Along with Linus, we also had Tove Torvalds, and their three small girls: Patricia (6), Daniella (4), and Celeste (2). During the earlier rehearsal, the girls were so amused to see their Daddy in a penguin suit; there were some lovely photos of them inspecting the suit, and looking at their Dad change the world while having fun.

On that opening welcome – the morning in the Penguin suit – the temperature was over 40°C.

For a non-profit event, we had too much money left over that it was decided to reduce the profit by ordering pizza for lunch on the last day. Days ahead, we drove to a local pizza hut branch, and asked what would be required to order some 300 pizzas, and could they deliver them effectively. We cut a cheque (remember those) two days in advance, and on the day, two minivans stuffed to the roof turned up.

LCA spelt with Pizza Boxes, a slang name for a common form factor of servers around this time, and one of the LCA yellow banners.

Prior to recycling, I suggested we spell out the name of this even in Pizza boxes as a fun tribute to the amount of pizza we all consumed as we cut code, and changed the world. This photo embodies LCA (and appears on the Wikipedia page). I think I took the image from the library balcony, but I may be wrong.

LCA2003 was the first time we had full audio recordings of all main conference sessions. Ogg Speex was the best codec at the time, and video was just beyond us. A CD was produced containing all recordings, plus a source copy of the Speex codec.

LCA2003 closed on 25 January 2003.

Then on the 26th (Australia Day) my then girlfriend and I grabbed our bags, and moved to the UK for 1 year (PS: it was 8).

Roaming around the northern hemisphere

My time in Europe got me to FOSDEM and DebConf many times. I was at UKUUG, tripping through Cambridge occasionally, seeing people whom I had previously met from the Debian community at the LSM in Bordeaux. I met new people as well, some of whom have since made the trip to Australia in order to present at LCA.

James Bromberger (far l), Barry White (l), Pierre Denis (c), Simon Wardley (far r), at the Fotango Christmas party (skiiing) in Chamonix in 2004.

I spent time at Fotango (part of Canon Europe) working with some awesome Perl developers, and running the data centres and infrastructure.

Returning Home

Upon my return to Perth in 2010, I went back to PLUG, to find a new generation of people who were going to LCA 2011 in Brisbane.

I started a cunning plan with the PLUG crew; we put forward a proposal to the Lottery commission for $10,000 to get equipment for us to set up a single stream for video recording using DVSwitch in order to record the regular PLUG meetings.

Euan (l) and Jason (r) playing with DVSwitch at Perth Artifactory in 2011

It worked; a crew came together, and PLUG had some practice at what running a Video Team required (at the time).  I managed to convince Luke John to put forward a proposal to run LCA – it had been nearly 10 years since it had been in Perth – and thus it came to pass.

I, however, was not going to be front and centre in 2014 (though I did give a presentation on Debian and AWS at the 2014 conference).

But I found a new role I could play. With the additional video kit, and a bit of organising, we grabbed a couch and for one year, created LCA TV – an opportunity to grab on video some of the amazing people who come to Linux.conf.au. While we now have great video of presentations, it’s nice to have a few minutes for chat with those amongst us, captured for posterity.

LCA TV 2014

I want to thank LA Council who have had the courage to have LCA wander the region year to year. I want to thank the LCA crews I have worked with in 2003 and 2014, but I want to thank the crew from every year, the speakers who have stood up and spoken, the video teams, and the volunteers.

Looking forward; I want to thank people who haven’t done what they are going to do yet: those who will run LCA in future, and those who will give their time to share their knowledge with others, across countries, languages, companies and more.

Linux.Conf.Au has been central to the success of technical talent in the Linux and Open Source space in this region.

Arriving at CHC Airport, LCA 2019 was present for conference registrations in the terminal.

I have one more person to thank. My then-girlfriend in 2003, now my wife of many years who has put up with me spending so much time attending, planning and running a technical conference over the years. Thanks Andrea.

Michal Čihař: wlc 1.0

Enj, 31/01/2019 - 12:30md

wlc 1.0, a command line utility for Weblate, has been just released. The most important change is marking this stable and releasing actual 1.0. It has been around long enough to indicate it's stability.

Full list of changes:

  • Marked as stable release.
  • Added support for more parameters on file upload.

wlc is built on top of Weblate API, you can use it on Weblate 2.10 or newer, though some features might require more recent version. Of course you use it on our hosting offering. Usage examples can be found in the wlc documentation.

Filed under: Debian English SUSE Weblate

Andy Simpkins: Debconf Video Team Sprint – Day 2

Enj, 31/01/2019 - 12:04md

Two things to concentrate on today, getting the stage box rack populated and following conversation with starting to Jonathan last night, to look at Raspberry Pi boot.

So task 1 Racking up the stage box equipment

It is a shame that we do not have all of the radio receivers for the stage box yet, never mind; I can leave a 1U space in the case for 2 of the missing receivers and I can fit the the one receiver I have with the log side ear that comes with the kit so that it can still be fitted into the rack…  Note to self DO NOT lose the little mounting plate to bind two receivers together – I will need 2 of them, and each receiver comes with just 1…

OK so the box assembled quite well:

Front of rack. Missing 3 of the Radio Mic Receivers

The two (tiny) aerials on the front are connected to the antenna distribution amplifier.  This acts as a buffer amplifier splitting each antenna signal 5 ways;  providing a pair of antenna signals for each of the radio mic receivers and an additional output to ‘daisy chain’ into further distribution amplifiers (we will not need this).

But why have 2 independent antenna systems?  Well this is all about signal path.  When the system is in use the receivers don’t move about, however the radio mic transmitters do (as presenters move around, mics get handed to different people etc).   Each aerial is separated by a significant fraction of the wavelength of the carrier frequency used by the system; this means that if  (when) the signal path between the transmitter and the receiver antennas is poor, due to the line of sight being blocked, weaker signals reflected off the walls ceiling and floor should still reach the antennas, however these reflected signals are the product of multiple signal paths (reflections of many different surfaces).  This multi-path signal is a combination of all the received reflected signals and because the received signals will have taken paths of different lengths when combined they will be slightly out of phase meaning. By having multiple antennas a receiver is offered several observations of the same signal. Each antenna will experience a different interference environment. Thus, if one antenna is experiencing deep fade, it is likely that another has a sufficient signal. Collectively such a system can provide a much more robust link.

The Antenna distribution unit comes with a power supply large enough to power itself and 4 receivers, so it also provides 4 DC power outputs and cables to power the receivers, meaning I only have the one mains power supply for all of the radio mic system.

Below the antenna distribution amplifier there will be 4 radio mic receivers (right now there is only the one – the remaining three are on back order).  Each radio mic receiver comes with enough hardware that it can be installed on its own in a rack; one small ear, and one large ear.  It also comes with a link plate to join to another receiver.  To fit two receivers side by side the large ear is left off and both small ears are used (one from each receiver), the two receivers are linked together with the link plates – located one on the top of the receivers and the other on the bottom (again only one is supplied with each receiver).  Because I have only been sent one receiver so far I have installed this as you can see in the photo.  I MUST NOT LOSE the link plate – It will be needed when I want to fit one of the 3 recivers on back order by the side of the one already in the rack.  A space of 1U has been left for the other 2.

Below the radio mic receivers we have installed our OPSIS / Turbot HDMI capture system.

Finally below that Nicolas has fitted a 2U high draw.  The draw has machined cut-outs so we can store and transport the 2 hand held radio mics and the 2 ‘head set’ mics and their body pack transmitters.  There is even enough space to store some batteries!

Storage for the hand held and headset mic transmitters

Now to the back of the rack…

back of the rack

At the top we have fitted a 2U ventilation plate, behind the distribution amplifier and the top pair of receivers.  A solid 2U blanking plate is at the bottom of the rack behind the draw.

Behind the bottom pair of radio mic receivers (the currently empty space in the picture) I have fitted a 1U short depth shelf.  This proved a but of a faff because I have fitted it BEHIND the face rail so that we can still fit a 2 blanking plate to cover the remaining ‘gap’.

Onto this shelf I planed to mount the power power supply for the radio system, a small packet switch and a 4 way mains power block (to distribute power to the OPSIS, radio receivers and the ‘Wall wart’ power brick for the packet switch)

The 2U blanking plate will be cut out to house all of the plugs and sockets that need to be connected to the rack that is:

1x IEC switched & Fused power inlet
4x XLR mic sockets
1x HDMI in (from presenter laptop)
2x HDMI out (to projector and confidence screen)
4x Ethernet sockets

Each of the above will be cabled to the appropriate locations inside the rack.  The HDMI input cable will also have the ‘MAGIC’ Reamere signal conditioning chip that cleans and reforms the HDMI signal enough that cheep ‘out of spec’ HDMI cables can still be used…    Who would have thaught that those cheep thin HDMI cables you buy from eBay and the likes wouldn’t be HDMI spec compliant?

Anyway the reason for going to all the trouble of fitting a cable between the equipment and a connector mounted on a backplate is two fold:

Firstly it means that we can leave connected all the buts that stay together in the rack.  Nobody is going to disconnect them by mistake when unplugging the cables that go to the outside of the rack.  There is a minimum number of connections presented on the back of the rack to plug into – making this much simpler to use and harder to plug into the wrong socket.

Secondly (in most importantly) it reduces damage to the kit.  Someone will trip over a cable at some point, they will bend a pin, or force the wrong connector into a socket or the right connector upside down…  Cables are cheep and easily replaced, so to are the connectors on the back plate, but a surface mount HDMI connector on the OPSIS or an XLR fitted to the equipment?  Having “Sacrificial” connectors on the back of the unit will hopefully save us a lot of money in the long term.

Ahh that reminds me – the Power supplies on the OPSIS / Turbot in the cases we have a switch for 240 and 110 VAC so we should change them to a wide input version (as is the case for the radio receivers and the packet switch)

Something like this should be fine (we don’t need a full PC power supply – we don’t need the 3V3 rail) 1866-3987-ND.

And then a “Eurica” moment happed…

IF I put the packet switch inside the OPSIS / Turbot rack then I can also power the packet switch from the same 12V rail we power the OPSIS from.  That gets rid of the nasty ‘Wall Wart’ PSU which I hadn’t yet worked out how to mount.  It also means that I don’t need the 1U shelf any more.  I can cable tie the Radio PSU to the ventalation pannel, and I only need to run 2 IEC power cables – one to the radio PSU and the other to the PSU in the OPSIS / Turbot case – AC power distribution is now just 2 wires sharing a ‘Spade’ connection to the Power Inlet Socket / Switch / Fuse Module.

Great problem solved – and much much cleaner / simpler than before.

And then the next problem shows up…

When we put HDMI cables on the back of the OPSIS they protrude too far out the back that they foul the back plate.  So as well as needing to move the Turbot to make way for the packet switch we also need to step back the OPSIS.

First lets move the Turbot.  There are a pair of disk trays in the case that are not being used in this installation.  We will probably install a small SSD to replace the uSD card we are currently using for the Turbot in one, and the Turbot itself can be installed in the other.  Nicolas reached for the Dremal to make some holes in one of the cages… Dremals are really not the right tool here and one broken drill bit and and hour later we decide that no they really are not the right tool here (we still don’t have the correct sized hole for the stand-offs to mount the Turbot)

There has to be a local make space round here?

Indeed there is… and they have an open meeting this evening which we are invited to attend (a talk on OpenLDAP)  after which we can use the workshop.  Many thanks to betz & askarel at the hsbxl Hackerspace Brussels for letting us use the your facility.

The modified OPSIS / Turbot case now looks like this:

Updated chassis

The PSU still needs to be replaced (see above) but as you can see the OPSIS now sits further inside the case, we have a packet switch where the Turbot used to be and the Turbot has been moved to one of the drive bays.  I have also simplified the cabling pruned back the unused wires.

Still to do (not during this sprint):

– Replace the PSU in the OPSIS / Turbot case
– Add a small SSD to the Turbot
– Source connectors for the back plate of the rack and fit
– Cable between the case and the back plate
– Add a FET to power cycle the OPSIS under GPIO control from the Turbot (Hard reset of the FPGA after reprogramming / Remote reset if things go TU during a talk)

Mike Gabriel: FOSDEM 2019

Enj, 31/01/2019 - 10:46pd

All family members (including myself) are healthy and well, so I am sitting on my yearly train to Belgium. Looking forward to meeting many of you there.

light+love
Mike

Chris Lamb: Free software activities in January 2019

Enj, 31/01/2019 - 9:21pd

Here is my monthly update covering what I have been doing in the free software world during January 2019 (previous month):

Reproducible builds

Whilst anyone can inspect the source code of free software for malicious flaws almost all software is distributed pre-compiled to end users.

The motivation behind the Reproducible Builds effort is to ensure no flaws have been introduced during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised.

The initiative is proud to be a member project of the Software Freedom Conservancy, a not-for-profit 501(c)(3) charity focused on ethical technology and user freedom.

Conservancy acts as a corporate umbrella, allowing projects to operate as non-profit initiatives without managing their own corporate structure. If you like the work of the Conservancy or the Reproducible Builds project, please consider becoming an official supporter.

This month:

Debian LTS

This month I have worked 18 hours on Debian Long Term Support (LTS) and 12 hours on its sister Extended LTS project.


Debian uploads

  • python-django:

  • redis:

    • 5.0.3-3 — Fix FTBFS on hurd-i386 by updating a patch to avoid MAXPATHLEN reference.

    • 5.0.3-4 — Fix a cross build failure when building the Debian-suplied Lua libraries. (#919682)

  • mtools (4.0.23-1) — New upstream release, salvaging the package via #916127.

  • libfiu (0.98-2) — Honour CPPFLAGS and LDFLAGS when building shared libraries to ensure hardening is applied to generated objects.

  • bfs:

    • 1.3.1-1 & 1.3.2-1 — New upstream releases.

    • 1.3.2-2 — Only require libacl1-dev and libcap-dev on systems with the Linux kernel. (#920288)

  • redisearch:

    • 1.2.1-2 — Define CLOCK_MONOTONIC_RAW for kFreeBSD.

    • 1.2.1-3 — Check for __FreeBSD_kernel__ over __FreeBSD__ for CLOCK_MONOTONIC_RAW.

    • 1.2.1-4 — Pass -ffile-prefix-map for a reproducible build.

  • installation-birthday (12) — New upstream release.


I also performed a sponsored uploads of c-graph, connman-gtk, connman-ui and elpy.


FTP Team


As a Debian FTP assistant I ACCEPTed 85 packages: agg, akira, apt-config-auto-update, beancount, botan, cairosvg, chaosread, corosync-qdevice, deepdiff, desktopfolder, dh-vim-addon, distorm3, exempi, fava, fonts-noto, fonts-quicksand, gcc-9, gnustep-back, gnustep-base, gnustep-gui, heudiconv, ilmbase, kamailio, leaflet, leaflet-image, leaflet-markercluster, libcatmandu-filestore-perl, libgeoip2-perl, libical3, libjs-rtcpeerconnection-shim, libjs-sdp, libjs-webrtc-adapter, libjwt, liblist-utilsby-xs-perl, libmaxmind-db-reader-xs-perl, libnfs, libpillowfight, libqmatrixclient, libwin32-exe-perl, lighttpd, lix, looking-glass, lrslib, musescore-general-soundfont, musescore-general-soundfont-small, netdata, nextcloud-desktop, node-chai, node-domino, node-yarnpkg, omegat, openexr, pacemaker, package-update-indicator, pdfarranger, pkg-js-tools, plinth, pmdk, ptunnel-ng, popper.js, progress-linux, pyninjotiff, pyphen, python-shade, rdkit, ruby-asciidoctor-pdf, ruby-mini-mime, ruby-prawn-icon, ruby-prawn-svg, ruby-voight-kampff, rust-rand-0.5, rust-rand-core-0.2, rust-tokio, silkaj, slirp4netns, spirv-tools, squashfuse, twitter-bootstrap3, uglify-js, use-package, utox, valentina, vulkan-validationlayers, xdg-dbus-proxy & yaz.

I additionally filed 12 RC bugs against packages that had potentially-incomplete debian/copyright files against beancount, fava, libpillowfight, libwin32-exe-perl, netdata, netdata, openexr, pdfarranger, python-shade, rust-rand-0.5, spirv-tools ptunnel-ng & vulkan-validationlayers.

Scott Kitterman: Rise and fall of libclamav

Enj, 31/01/2019 - 7:36pd

Because I was bored and needed to procrastinate, I decided to look at the history of packages using libclamav over the last several releases. This is binary reverse-depends in main on i386:

Release

libclamav soname

rdepends

Sarge

libclamav1

2

Etch

libclamav2

9

Lenny

libclamav5

5

Squeeze

libclamav6

3

Wheezy

libclamav7

3

Jessie

libclamav7

4

Stretch

libclamav7

4

Buster

libclamav7

4

I started working on clamav around Etch (in Ubuntu, so it’s not an exact match) and transitions were a blast back then. Every single soname bump needed significant sourceful changes. It killed quite a number of projects. Of the four we still have in Debian (dansguardian, havp, icap, and python-clamav) only the icap modules aren’t essentially dead upstream.

I guess API stability counts for something if you want people to use your library.

P.S. None of the people working on clamav today are the same as when we had 3 soname bumps in one release cycle.

 

Gunnar Wolf: Back to the teaching business!

Enj, 31/01/2019 - 5:29pd

Sometimes, life is measured in semesters.

This is the 13th semester I teach. I can no longer feel a newbie. I am still just a part-time teacher, but I know it's an activity I very much enjoy, and I hope I can at some point manage it to become full-time activity.

After three months of slumber (three weeks of which were the hard vacations, but then there's the intersemestral active period), our university came back to life and full occupation.

Due to one fellow teacher taking a sabbatical, I have the largest group that I have been assigned. 40 students does not seem an easy task! Lets see how it comes...

Anyway... I am happy!

AttachmentSize las_islas.jpg275.9 KB

Andy Simpkins: Debconf Video Team Sprint – Day 1

Mër, 30/01/2019 - 6:54md

The Debconf Video team has got together for a sprint…

Travel.
I asked my wife to drop me off at Waterbeach station for 09:45, from there I caught a train to Kings Cross, Walked across the road to St Pancras and caught the Eurostar To Brussels, and then a local service into Diegem. A short walk from the station to the sprint venue and I arrived at 17:45… 7 hours door to door OK that was quite some time but I am overly paranoid about missing trains etc so could have trimmed at least 1 possibly 2 hours off this – I don’t mind waiting for a connection, I am less stressed when I travel if I have a lot of slack between connections that allows for unexpected hold ups and delays…

Finding the right building was very easy :

I wonder if this is something to do with Linux?

I must say a big thank you to Jasper Nuyens for letting us use the Linux Belgium  building (including crash space! for the week)

Catch Up
I missed Debconf Last year, so I haven’t seen most of the team for quite a while. A quick hello took until dinner time. Cooking with Rattus once again :-) Todays’ team meal Chili and Rice
Despite leaving leaving out the chillies until near the end (to provide a spice free version for Judit) a nice rich dinner was provided – Thanks to Nicolas for cooking the rice.

Evening session
I then spent most of the evening getting familiarised with the new rack hardware that has mostly now arrived (3 of the radio mic receivers have not yet arrived and are on back order) – it is a shame, but I am sure that we can make do for the moment. again many thanks Nicolas for ordering in and lugging all the kit from Paris.

What is going on? We must be getting old – it is midnight, we are in Brussels and I am the last person still up. And we have only shared one bottle of beer so far…

Thomas Lange: dracut problems fixed and a new FAI version

Mër, 30/01/2019 - 3:53md

Before preparing a new FAI release, I had to debug a nasty boot problem in FAI. Booting a FAI CD on a notebooks only hang when no ethernet cable was connected. This was strange, because the automatic installation does not need a network connection and gets all packages from the installation media.

Since FAI is using dracut (a replacement for initramfs-tools) and we use the kernel cmdline option rd.neednet, dracut only boots if it can set up at least one ethernet device. Without using this option, dracut does not activate the network at all and FAI cannot configure the /etc/network/interface. There's no option to tell dracut just to try to activate network device, but do not rely on being successful. In the end the fix was to edit a dracut script, so dracut does not wait forever for devices to come up. It was just a simple sed -e 's/exit 1/exit 0/'. Nice.

After this fix the new FAI release 5.7.4 was uploaded. Support for installing notebooks is now improved.

Changes:

  • network-manager-gnome is now installed for class XFCE

  • the network device config is now correct if NetworkManager is installed

  • Booting does not hangs any more when installing a notebook without the ethernet being connected

New FAI ISO images are available from [1]. Then can install Debian 9 using XFCE or GNOME or just a server installation without any desktop. We also have a Ubuntu version of the ISO, and CentOS can be installed.

The FAIme build service [2] for customized cloud and installation images also uses the newest FAI version.

[1] https://fai-project.org/fai-cd/

[2] https://fai-project.org/FAIme

FAI dracut

Reproducible builds folks: Reproducible Builds: Weekly report #196

Mar, 29/01/2019 - 2:56md

Here’s what happened in the Reproducible Builds effort between Sunday January 20 and Saturday January 26 2019:

Packages reviewed and fixed, and bugs filed Test framework development

We operate a comprehensive Jenkins-based testing framework that powers tests.reproducible-builds.org. This week:

  • Eli Schwartz:
    • Fix the “preseed” of Arch Linux’s PGP keys by sending output to stdout. […]
  • Holger Levsen:
    • Arch Linux-specific changes:
      • Refactor the scheduler’s “interesting” use of $repo and $REPO variables. […][…]
      • Correct a fencepost error in the scheduler; if we want to request n packages we need to set a limit of n + 1. […]
      • Include an n builds in the last 3h statistic in the IRC notifications. […]
      • Schedule packages six times a day instead of eight. […]
    • F-Droid-specific changes:
      • Run the setup job three times a week now, building all apps daily. […]
    • LEDE/OpenWrt, coreboot and NetBSD changes:
      • Test three times per week instead of just once. […]
      • Move building to OSUOSL nodes 171 & 172, from pb3 & pb4. […]
      • Build at different times to not interfere. […]
    • Misc/generic changes:
      • Update status of the deployment of the new OSUOSL nodes. […]
      • Fix the Debian dsa-check-running-kernel to deal with the Ubuntu LTS changes. […]
      • Correct KGB IRC interface’s directory permissions and create it if it does not exist. […][…]
      • Fix a bug that was preventing OSUOSL hosts from running correctly in the future. […]
      • Set the correct permissions on the jenkins user’s ~/.ssh directory. […]
    • Node maintenance. ([…], […], […], etc.)
  • Mattia Rizzolo:
    • Update the expiration of the GPG key used to sign our experimental Debian archive. […]
    • In our pbuilder configuration, use the APT dependency resolver […] simplify the section for i386/armhf hosts […] and DRY the MIRRORSITE configuration, now that is the same for everything. […]
    • Node maintenance. ([…], […], […], etc)

This week’s edition was written by Bernhard M. Wiedemann, Chris Lamb, Holger Levsen, Mattia Rizzolo & reviewed by a bunch of Reproducible Builds folks on IRC & the mailing lists.

Julien Danjou: Serious Python released!

Enj, 17/01/2019 - 5:56md

Today I'm glad to announce that my new book, Serious Python, has been released.

However, you wonder… what is Serious Python?

Well, Serious Python is the the new name of The Hacker's Guide to Python — the first book I published. Serious Python is the 4th update of that book — but with a brand a new name and a new editor!

For more than a year, I've been working with the editor No Starch Press to enhance this book and bring it to the next level! I'm very proud of what we achieved, and working with a whole team on this book has been a fantastic experience.

The content has been updated to be ready for 2019: pytest is now a de-facto standard for testing, so I had to write about it. On the other hand, Python 2 support was less a focus, and I removed many mentions of Python 2 altogether. Some chapters have been reorganized, regrouped and others got enhanced with new content!

The good news: you can get this new edition of the book with a 15% discount for the next 24 hours using the coupon code SERIOUSPYTHONLAUNCH on the book page.

The book is also released as part as No Starch collection. They also are in charge of distributing the paperback copy of the book. If you want a version of the book that you can touch and hold in your arms, look for it in No Starch shop, on Amazon or in your favorite book shop!

No Starch version of Serious Python cover

Kunal Mehta: Eliminating PHP polyfills

Enj, 17/01/2019 - 8:50pd

The Symfony project has recently created a set of pure-PHP polyfills for both PHP extensions and newer language features. It allows developers to add requirements upon those functions or language additions without increasing the system requirements upon end users. For the most part, I think this is a good thing, and valuable to have. We've done similar things inside MediaWiki as well for CDB support, Memcached, and internationalization, just to name a few.

But the downside is that on platforms where it is possible to install the missing PHP extensions or upgrade PHP itself, we're shipping empty code. MediaWiki requires both the ctypes and mbstring PHP extensions, and our servers have those, so there's no use in deploying polyfills for those, because they'll never be used. In September, Reedy and I replaced the polyfills with "unpolyfills" that simply provide the correct package, so the polyfill is skipped by composer. That removed about 3,700 lines of code from what we're committing, reviewing, and deploying - a big win.

Last month I came across the same problem in Debian: #911832. The php-symfony-polyfill package was failing tests on the new PHP 7.3, and up for removal from the next stable release (Buster). On its own, the package isn't too important, but was a dependency of other important packages. In Debian, the polyfills are even more useless, since instead of depending upon e.g. php-symfony-polyfill-mbstring, the package could simply depend upon the native PHP extension, php-mbstring. In fact, there was already a system designed to implement those kinds of overrides. After looking at the dependencies, I uploaded a fixed version of php-webmozart-assert, filed bugs for two other packages. and provided patches for symfony. I also made a patch to the default overrides in pkg-php-tools, so that any future package that depends upon a symfony polyfill should now automatically depend upon the native PHP extension if necessary.

Ideally composer would support alternative requirements like ext-mbstring | php-symfony-polyfill-mbstring, but that's been declined by their developers. There's another issue that is somewhat related, but doesn't do much to reduce the installation of polyfills when unnecessary.

Faqet

Alblinux.net mundësohet nga Drupal.