Language Selection

English French German Italian Portuguese Spanish

Debian

Syndicate content
Planet Debian - https://planet.debian.org/
Updated: 4 hours 54 min ago

Ruby Team: Ruby Team Sprint 2020 in Paris - Day Two

Wednesday 5th of February 2020 08:23:41 PM

Day Two of the Ruby Team Sprint 2020 in Paris is over. Again we were able to tackle our main goals. There was a lot of silence as everybody was focused on their tasks. At the end we took an hour to discuss our open topics.

As a result of Day Two we achieved the following:

Ruby 2.7 transition

Most key arch:any packages are now fixed or being worked on. The next step will be to rebuild all arch:all packages to find build failures.

Rails 6 transition

The latest version has been uploaded to Debian Experimental. The wiki informs about the packages required to be updated and/or fixed.

Improving/optimizing our usage of the Salsa CI pipeline

We tend to disable the blhc, reprotest, and piuparts jobs of the Salsa CI pipeline by default for all group projects. For C-extension packages bhlc and reprotest will be re-enabled by default. piuparts could be enabled for some critical packages.

We first thought about setting the relevant pipeline variables (SALSA_CI_DISABLE_*) to zero via group variables and let maintainers decide on a case-by-case base to re-enable them via project variables. But it seems more convenient and apparent to instead create our own pipeline file (include the Salsa CI pipeline and set variables there) and include it from all our projects.

Maintainers can still temporarily enable or disable jobs by running a pipeline using the web-interface or API passing the variables along.

New items on our TODO list for next days
  • Start bug triage and fixing for gem2deb.
  • Productize team tools.
  • Fix reprotest failing for all our C-extensions (culprit found).
  • Finish the Kali Ruby packages.
  • Complete source-only uploads for all accepted packages from NEW.
Package uploads and bugs fixed

The number is hard to track as members of the group worked all day and even late in the evening. It is safe to say that it is again a two digit number.

Gunnar Wolf: Migrated to Jekyll

Wednesday 5th of February 2020 08:00:00 AM

I first started this blog back in October 2004. Back then, I used a now-defunct blog engine written by some friends of mine — JAWS, or Just Another Weblog System.

My blog remained with JAWS for four years, but by February 2008, I decided to switch over to Drupal 5; I needed to properly evaluate it in order to use it at work, so I migrated my blog to use Drupal instead. And behold! You can still look at my half-decent and quite long (and specific to my site) JAWS to Drupal 5 migration script!

The upgrade to Drupal 6 was quite uneventful. I don’t remember (and cannot find) when it happened, but it didn’t scare or scar me forever. But, even when I most embraced Drupal 7 (I adopted the Debian packages in 2013, and have kept it at least up to date with the each time less frequent updates), I never got around to do the 6→7 migration on my personal website. Yes, because I don’t want to migrate a sh!tload of posts by hand… And could not be bothered to produce a script to decently replicate the whole thing.

Several months ago, having already decided to switch to a static blog engine, I came across https://jekyllrb.com/. Being a rubyist myself, I started thinking about it… half-seriously.

I started taking it more seriously when I found Jekyll can be persuaded to import whole Drupal6 sites (as well as sites in many other engines). Of course, having added several modules and created a nontrivial structure and data set… So I hacked up a (much smaller than last time!) importer script to do the heavy lifting. And later, did quite a bit of tweaking on the results…

…But was still quite a bit from satisfied. So… In the end, I have to thank my hosting company:

After many years, Dreamhost dropped support for PHP 5.x, making Drupal6 no longer usable. Which, although forced me to work, is very good. PHP5 has been end-of-lifed for over a year, Drupal6 ended its support four long years ago…. And only unforgivable slackers like myself were still running that old code!

Of course, there are myriads of things to fix in my now-somewhat-broken-and-ugly site. But, at least, I managed to keep it semi-functional; over 2500 posts (including images, random stuff I wrote over sixteen years, and whatever extras need to be added to the list) were migrated. Sadly, only a few URLs were correctly preserved… But I trust the world will come to understand and fix the issue ☺

So… I hope I don’t mess with your RSS feeds. My blog now has no comments enabled, which is a shame, but I don’t want to fall over to commercial providers such as Disqus (which would be easily doable with Jekyll). We are commentless… At least for the time being.

Gunnar Wolf: Migrated to Jekyll

Wednesday 5th of February 2020 08:00:00 AM

I first started this blog back in October 2004. Back then, I used a now-defunct blog engine written by some friends of mine — JAWS, or Just Another Weblog System.

My blog remained with JAWS for four years, but by February 2008, I decided to switch over to Drupal 5; I needed to properly evaluate it in order to use it at work, so I migrated my blog to use Drupal instead. And behold! You can still look at my half-decent and quite long (and specific to my site) JAWS to Drupal 5 migration script!

The upgrade to Drupal 6 was quite uneventful. I don’t remember (and cannot find) when it happened, but it didn’t scare or scar me forever. But, even when I most embraced Drupal 7 (I adopted the Debian packages in 2013, and have kept it at least up to date with the each time less frequent updates), I never got around to do the 6→7 migration on my personal website. Yes, because I don’t want to migrate a sh!tload of posts by hand… And could not be bothered to produce a script to decently replicate the whole thing.

Several months ago, having already decided to switch to a static blog engine, I came across https://jekyllrb.com/. Being a rubyist myself, I started thinking about it… half-seriously.

I started taking it more seriously when I found Jekyll can be persuaded to import whole Drupal6 sites (as well as sites in many other engines). Of course, having added several modules and created a nontrivial structure and data set… So I hacked up a (much smaller than last time!) importer script to do the heavy lifting. And later, did quite a bit of tweaking on the results…

…But was still quite a bit from satisfied. So… In the end, I have to thank my hosting company:

After many years, Dreamhost dropped support for PHP 5.x, making Drupal6 no longer usable. Which, although forced me to work, is very good. PHP5 has been end-of-lifed for over a year, Drupal6 ended its support four long years ago…. And only unforgivable slackers like myself were still running that old code!

Of course, there are myriads of things to fix in my now-somewhat-broken-and-ugly site. But, at least, I managed to keep it semi-functional; over 2500 posts (including images, random stuff I wrote over sixteen years, and whatever extras need to be added to the list) were migrated. Sadly, only a few URLs were correctly preserved… But I trust the world will come to understand and fix the issue ☺

So… I hope I don’t mess with your RSS feeds. My blog now has no comments enabled, which is a shame, but I don’t want to fall over to commercial providers such as Disqus (which would be easily doable with Jekyll). We are commentless… At least for the time being.

Sylvain Beucler: Debian LTS and ELTS - January 2020

Tuesday 4th of February 2020 11:50:46 PM

Here is my transparent report for my work on the Debian Long Term Support (LTS) and Debian Extended Long Term Support (ELTS), which extend the security support for past Debian releases, as a paid contributor.

In January, the monthly sponsored hours were split evenly among contributors depending on their max availability - I was assigned 23.75h for LTS (out of 30 max) and 20h for ELTS (max) of which I did 1.5h.

I couldn't work much on ELTS because there are very few sponsors left for oldoldoldstable (sic!), hence not many packages to support, hence not much possible work.

In a direct communication, one team member expressed that team workflow is to be discussed on a private mailing list because according to them these problems don't need to be discussed in public and only results count. I have an opposite approach -- anything that isn't strictly confidential / security-sensitive is to be discussed publicly. The Debian Social Contract says "We don't hide problems" so if we want to address problems in a Debian workflow, this is to be public. What do you think?

ELTS - Wheezy

  • request supported packages list update
  • sqlite3: re-triage: drop as it just reached end-of-life
  • nss: re-triage: suggest clarification since package just reached end-of-life, yet claimed; actually a static build dependency of openjdk
  • python-apt: re-triage: claimed, checked actual EOL status with triager, unclaimed
  • python2.7: re-triage: was marked end-of-life, checked !EOL status with triager, marked for update

LTS - Jessie

  • wordpress: jessie triage (7 CVEs), security upload
  • tomcat7: start working then cancel work since it was unclaimed since 9 days yet 2 LTS members were already working on it
  • gpac: jessie triage (17 CVEs), reported new crash, reported invalid fix, security upload

Documentation/Scripts

Birger Schacht: Fosdem 2020

Tuesday 4th of February 2020 09:02:51 PM

Today I returned from Brussels, where I attended FOSDEM. It was my first time in Brussels and it was my first FOSDEM.

The days before FOSDEM, from Wednesday to Friday, there was a MiniDebCamp in the local Hackerspace. The Hackerspace is located at Studio CityGate, a collective space which was apparently an old factory for textile and medical equipment and can now be used by cultural projects (though I think its only temporary). There is a Bar at the ground floor, a recording studio in the basement, a skate park and a climbing wall and much more. The building and the yard reminded me a bit of the collective art space Fux, where the Hamburg MiniDebConfs 2018 and 2019 were located.

I only visited DebCamp on Friday and did a bit of work on the debian timeline (researched dates/events to be added) and on sway related packages.

The two days of FOSDEM were very interesting, although draining. There were talks and discussions all the time in multiple rooms of every size. On Saturday I found the policy debates in the Legal and Policy Issues devroom to be very interesting and entertaining. The culture of debate competition is something I didn’t know at all before (besides from movies) and it was a fascinating experience to see people so eloquently defend views they actually don’t really hold. There were also some points raised about ethical licensed that gave me a lot to think about.

On Sunday I started the day by watching a short introduction to hard disk encryption in Linux suspend mode with cryptsetup-suspend which I’m looking forward to try out (though I’ll need support for suspend to RAM on the Pinebook first). Later that day I watched a couple of talks in the Community devroom. There was a great talk about Building Ethical Software Under Capitalism by Deb Nicholson from Software Freedom Conservancy and Megan Sanicki from Google gave a talk about Leadership in Open Source (“Every contributor is a leader”). The last talk of the day I watched was Who will Decentralise the Fediverse? about Mastodon et al and the challenges of decentralization in federated networks.

I actually planned to do some tests of the Pinebook Pro during FOSDEM, but in the end I only opened the notebook once a day for a short time. I even forgot to stop by at the Pine64 stand.

All in all, it were interesting days. Apart from the talks I met some new people, some old friends and had inspiring discussions. What I’ll definitely skip next time is the Beer Event, that’s not my kind of evening activity but I’ll plan to spend more time at the DebCamp (if it happens again).

Sylvain Beucler: SCP Foundation needs you!

Tuesday 4th of February 2020 03:26:59 PM

SCP is a mind-blowing, diverse, high-quality collection of writings and illustrations, all released under the CC-BY-SA free license.
If you never read horror stories written with scientific style -- have a try

[obviously this has nothing to do with OpenSSH Secure CoPy ;)]

Faced with a legal threat through the aggressive use of a RU/EU trademark, the SCP project is raising a legal fund.
I suggest you have a look.

Sylvain Beucler: RenPyWeb - one year

Tuesday 4th of February 2020 03:26:58 PM

One year ago I posted a little entry in Ren'Py Jam 2018, which was the first-ever Ren'Py game directly playable in the browser

Big thanks to Ren'Py's author who immediately showed full support for the project, and to all the other patrons who joined the effort!

One year later, RenPyWeb is officially integrated in Ren'Py with a one-click build, performances improved, countless little fixes to the Emscripten technology stack provided stability, and more than 60 games of all sizes were published for the web.

What's next? I have plans to download resources on-demand (rather than downloading the whole game on start-up), to improve support for mobile browsers, and of course to continue the myriad of little changes that make RenPyWeb more and more robust. I'm also wondering about making our web stack more widely accessible to Pygame, so as to bring more devs in the wonderful world of python-in-the-browser and improve the tech ecosystem - let me know if you're interested.

Hoping to see great new Visual Novels on the web this coming year

Sylvain Beucler: Debian LTS and ELTS - September 2019

Tuesday 4th of February 2020 03:26:58 PM

Here is my transparent report for my work on the Debian Long Term Support (LTS) and Debian Extended Long Term Support (ELTS), which extend the security support for past Debian releases, as a paid contributor.

In September, the monthly sponsored hours were split evenly among contributors depending on their max availability - I was assigned 23.75h for LTS (out of 30 max) and 20h for ELTS (max).

I was again able to factor out some time between LTS and ELTS.

The qemu update required more testing than I expected, as it's used with lots of different CPU and disk backends.

ELTS - Wheezy

  • CVE-2019-13626/libsdl1.2: triage: mark postponed so it doesn't stay in the triage list
  • freetype: CVE-2015-9381,CVE-2015-9382,CVE-2015-9383 security upload
  • freetype: de-dup TEMP-0773084-4AB1FB / CVE-2014-9659
  • CVE-2019-13232/unzip: regression update (zipbomb)
  • CVE-2019-5481/curl: triage: not-affected
  • CVE-2019-1549/openssl: triage: not-affected
  • CVE-2019-16163/libonig: security upload
  • CVE-2019-2180/cups: triage: was fixed prior CVE assignment, no other significant vulnerability to fix, no upload
  • tomcat7: investigate upgrading to upstream stable version, so as to fix the currently failing testsuite; decide not to when realizing that means applying all upstream changes since 2012
  • CVE-2019-3689/nfs-utils: triage, contact package maintainer
  • CVE-2019-16935/python*: help Ola triage and assess severity

LTS - Jessie

  • freetype: CVE-2015-9381,CVE-2015-9382,CVE-2015-9383 security upload
  • radare2: triage: clarify status, add reference to ML discussion about its support
  • unzip: untriage: false-positive
  • CVE-2019-16163/libonig: security upload
  • qemu:
    • check status of unpublished prepared update for CVE-2016-5126,CVE-2016-5403,CVE-2017-9375,CVE-2017-15124,CVE-2019-12155
    • CVE-2017-11334: triage: clarify, keep postponed (known regression)
    • CVE-2017-13672: triage: ignored: minor issue, guest root DoS, too complex to backport
    • CVE-2017-15124: re-triage: ignored: identify regression in proposed update, too complex to backport; reference complementary VNC/SASL patch
    • CVE-2018-19665: triage: ignored: still no sanctioned patch, bluetooth subsystem deprecated
    • CVE-2018-15746: triage: ignored: non-default configuration, requires backported kernel and libseccomp
    • CVE-2019-12067: triage: postponed: no sanctioned patch
    • setup physical jessie box, test extensively (Xen, KVM, virt-manager/gnome-boxes, VNC, Spice, Windows, LVM, VirtIO, iSCSI...)
    • call for testing
    • security upload: pending update -CVE-2017-15124 +CVE-2019-12068,CVE-2019-13164,CVE-2019-14378,CVE-2019-15890

Documentation/Scripts

  • ASAN (Address Sanitizer): fix missing option and document limitations
  • tomcat: notes from last month about testing tomcat
  • qemu: summarize qemu top use cases
  • bin/contact-maintainers: fix Python 2 code leftover
  • Point out that the training / new member process could be more visible

Sylvain Beucler: Debian LTS and ELTS - November 2019

Tuesday 4th of February 2020 03:26:58 PM

Here is my transparent report for my work on the Debian Long Term Support (LTS) and Debian Extended Long Term Support (ELTS), which extend the security support for past Debian releases, as a paid contributor.

In November, the monthly sponsored hours were split evenly among contributors depending on their max availability - I was assigned 24.5h for LTS (out of 30 max) and 20h for ELTS (max).

Multiple vulnerabilities come from in-process fuzzing (library fuzzing with compiler instrumentation, as opposed to fuzzing a user executable). This is an interesting technique, though those are harder to reproduce, especially with older versions or (even worse) forks. A significant portion of such vulnerabilities comes from google's OSS-117Fuzz infrastructure.

data/CVE/list from the debian security-tracker repository reached 20M. With multiple changes per hour, git blame is consequently near-unusable: several minutes for a targetted, single-line look-up, if the entry is not too old. Despite this, the git commit messages are often used for triage justification or even as a substitute for personal communication, a practice I wouldn't recommend. #908678 looks stalled.

MITRE is still reactive when reporting issues on various free software project, and still very shy about changing the status of vulnerabilities. This is understandable when dealing with hard-to-reproduce issues, less understandable with legit-looking bogus vulnerabilities, which some people still like to throw at us so we have more work to do and get paid (seriously: please don't).

ELTS - Wheezy

  • Second part of my Front-Desk week, though only auto-triaged unsupported packages
  • CVE-2019-14866/cpio: help opal investigate reproducibility issue, contact cpio maintainer and security@gnu.org to get official patch/review
  • CVE-2019-18684/sudo: deconstruct bogus vulnerability; MITRE now marks it as DISPUTED
  • CVE-2019-5068/mesa: attempt to reproduce the issue, BTS update, testing, security upload
  • CVE-2019-3466/postgresql-common: triage: not-affected
  • libonig: start work on multiple vulnerabilities with non-trivial backports; to be completed in December
  • CVE-2019-19012/libonig: backport for 5.9, get maintainer review
  • CVE-2019-19246/libonig: register CVE for untracked vulnerability (discovered through upstream fuzzing, re-discovered through php-mbstring)
  • libonig: find embedded copy in php7.0 (Stretch) and php7.3 (Buster); LTS/ELTS not-affected

LTS - Jessie

  • CVE-2019-3689/nfs-util: ping upstream and debian sid, no pong
  • CVE-2019-14866/cpio: shared work with ELTS
  • CVE-2019-18684/sudo: shared work with ELTS
  • CVE-2019-5068/mesa: shared work with ELTS, security upload
  • CVE-2019-3466/postgresql-common: confirmed fix: jessie already fixed but I didn't notice due to late DLA
  • CVE-2019-11027/ruby-openid: provide requested second opinion
  • libav: start processing pending issues, package is a ffmpeg fork, was removed from newer dists and is unresponsive to security issues, requiring more work; to be completed in December
  • CVE-2019-17542/libav: heap-based buffer overflow: apply fix though libfuzzer-based reproducer not reproducible
  • CVE-2019-17539/libav: triage: not-affected (vulnerable code introduced later)
  • CVE-2019-14443/libav: reproduce, track down fix in ffmpeg, update libav bug
  • CVE-2019-14441/libav: mitre request: duplicate CVE-2018-19129 (got DISPUTED); fix attempt, update libav bug
  • CVE-2019-14371/libav: triage: already fixed through CVE-2018-11102
  • CVE-2019-9720/libav: triage: unimportant (stretching the definition of DoS)
  • CVE-2019-9719/libav: mitre request: rejection (got DISPUTED): generic warning, no vulnerability
  • CVE-2019-9717/libav: triage: unimportant (stretching the definition of DoS)
  • CVE-2018-20001/libav: jessie triage: postponed (not reproducible)
  • CVE-2018-19130/libav: mitre request: duplicate CVE-2017-17127 (got DISPUTED)
  • CVE-2018-19128/libav: reproduce, track down fix in ffmpeg
  • Welcome new trainee

Documentation/Scripts

Sylvain Beucler: Debian LTS and ELTS - October 2019

Tuesday 4th of February 2020 03:26:58 PM

Here is my transparent report for my work on the Debian Long Term Support (LTS) and Debian Extended Long Term Support (ELTS), which extend the security support for past Debian releases, as a paid contributor.

In October, the monthly sponsored hours were split evenly among contributors depending on their max availability - I was assigned 22.75h for LTS (out of 30 max) and 20h for ELTS (max).

There was a bit of backlog during my LTS triage week and for once I didn't make a pass at classifying old undetermined issues.

MITRE was responsive for public (non-embargoed) issues in common free software packages, when I submitted new references or requested a CVE to identify known issues. There was more ball passing and delays when there was an another CNA (CVE Numbering Authorities).

Interestingly some issues were not fixed in LTS due to them being marked 'ignored' in later distros (sometimes, regrettably, with no clear rationale), as this means there would be a regression when upgrading. It's probably worth I check on my past security uploads to see if such as discrepancies appeared (this month's nfs-utils comes to mind, I'll re-offer a oldstable/stable upload next month).

Ubuntu recently started a post-LTS extended security support as well, with private updates. For now it's not clear whether we can get access to ease cooperation.

The last uploads I did took me some more hours than expected, so I'm a bit over my time - that means I have a few hours in advance for next month (not accounted for above).

ELTS - Wheezy

  • CVE-2019-16928/exim4: triage: not-affected
  • CVE-2019-15165/libpcap: security upload
  • libpcap: triage: other vulnerabilities not-affected
  • CVE-2019-3689/nfs-util: proposed patch and testing procedure to upstream and sid/salsa, ping, security upload
  • CVE-2019-3689/nfs-util: update security tracker: proposed fs.protected_symlinks mitigation is not valid as /var/lib/nfs has no sticky-bit; coordinate with MITRE and SuSE to update CVE
  • CVE-2019-17041,CVE-2019-17042/rsyslog: security upload, clarify triage description
  • CVE-2019-17040/rsyslog: triage: not-affected
  • CVE-2019-14287/sudo: request backport to maintainer, security upload
  • CVE-2019-17544/aspell: security upload
  • CVE-2019-11043/php5: security upload, provide feedback about applicability to cgi
  • CVE triage week part 1
    • CVE-2019-13464/modsecurity-crs: triage: not-affected (affected rules is not present)
    • CVE-2019-14847,CVE-2019-14833/samba: triage: not-affected
    • CVE-2019-10218/samba: triage: affected
    • CVE-2019-14866/cpio: triage: affected
    • CVE-2018-21029/systemd: triage: not-affected

LTS - Jessie

  • Front-Desk week
    • firefox: ping i386 build status following user request
    • CVE-2019-3689/nfs-utils: triage: affected
    • CVE-2019-16723/cacti: triage: affected
    • CVE-2019-16892/ruby-zip: triage: postponed (minor issue, fix is zip bomb mitigation not enabled by default)
    • CVE-2018-21016,CVE-2018-21015/gpac: triage: postponed (minor issue, local DoS)
    • CVE-2019-13376/phpbb3: triage: reference fixes, request CVE for prior incomplete CSRF fix (SECURITY-188), fix-up confusion following that
    • CVE-2018-20839/xorg-server: re-triage: clarify and mark for later fix
    • CVE-2019-13504/exiv2: update: reference missing patch, check that it's not needed for jessie
    • CVE-2019-14369,CVE-2019-14370/exiv2: triage: not-affected
    • CVE-2019-11755/thunderbird: triage: affected
    • CVE-2019-16370,CVE-2019-15052/gradle: triage: postponed (old gradle mainly used for build Debian packages in restricted environment)
    • CVE-2019-12412/libapreq2: triage: affected
    • CVE-2019-0193/lucene-solr: triage: affected; research commit for actual fix
    • CVE-2019-12401/lucene-solr: triage: affected; issue potentially in dependencies
    • CVE-2017-18635/novnc: triage: affected
    • CVE-2019-16239/openconnect: triage: affected
    • CVE-2019-14491,CVE-2019-14492,CVE-2019-14493/opencv: triage: postponed (DoS, PoC not crashing)
    • CVE-2019-14850,CVE-2019-14851/nbdkit: triage: ignored (DoS/amplification for specific configuration, non-trivial backport, low popcon)
    • CVE-2019-16910/polarssl: triage: affected, locate and reference patch
    • CVE-2019-16276/golang: triage: affected; later marked ignored, clarify that it's for consistency with later distros
    • CVE-2019-10723/libpodofo: revisit my early triage: ignored->postponed (minor but easy to add in later security upload)
    • DSA 4509-2/subversion: triage: not-affected
    • CVE-2019-8943/wordpress: triage: add precisions
    • CVE-2019-12922/phpmyadmin: triage: postponed (minor issue, unlikely situation); reference patch, reference patch at MITRE, mark unfixed
    • CVE-2019-16910/polarssl: reference patch at MITRE
    • CVE-2019-10219/libhibernate-validator-java: triage: no changes (still no clear information nor patch)
    • CVE-2019-11027/ruby-openid: triage: no changes (still no clear information nor patch)
    • CVE-2019-3685/osc: triage: no changes, report bug to packager, reference BTS
    • CVE-2019-1010091/tinymce: triage: ignored (questionable self-xss)
    • CVE-2019-16866/unbound: triage: not-affected
    • tcpdump,libpcap: triage: affected
    • CVE-2018-16301/libpcap: triage: asked upstream for commit, conclude duplicate, relay info to MITRE (not clear enough for them to mark duplicate AFAICS)
    • CVE-2019-14553/edk2: triage: end-of-life (non-free)
    • CVE-2019-9959/poppler: triage: affected
    • CVE-2019-10871/poppler: triage: cancel postponed (new upstream fix)
    • Remove remaining "not used by any sponsor" justification for Jessie LTS (one left-over from April clean-up)
  • CVE-2019-14287/sudo: security upload
  • CVE-2019-3689/nfs-utils: security upload
  • CVE-2019-11043/php5: security upload

Documentation/Scripts

  • Development: add reminder to add package short description / context in security announcements, some team members tend to forget it (myself included)
  • ampache: provide feedback about maintaining support
  • libclamunrar: provide feedback about dropping support

Ruby Team: Ruby Team Sprint 2020 in Paris - Day One

Tuesday 4th of February 2020 02:47:08 PM

The Ruby Team Sprint 2020 in Paris started. A dozen of us joined, some of them arriving just after attending MiniDebCamp right before FOSDEM and FOSDEM itself.

Group foto of the Ruby Team Sprint 2020 in Paris

Day One consisted of setting up at the venue, Campus 4 of the Sorbonne University, as well as collecting and discussing our tasks for the next days, and starting the work. The main goals so far for the sprint are:

  • Update packages in preparation for the Ruby 2.7 transition
  • Update packages for the Rails 6 transition
  • Fix several testing migration issues
  • Improve the team’s tools and workflow
    • Optimize usage of Salsa CI and reduce workload for Salsa service
    • Prevent breakages by minor transitions
  • Fix team specific issues
    • Remove the interpreter dependency from libraries
    • Handle rubygems integration warnings (working together with Deivid Rodríguez, upstream rubygems maintainer, who kindly agreed to join the sprint).
    • Optimize and improve installed gemspecs
  • Reduce the differences for Ruby packages on Kali Linux

There are more items on the list which will be discussed during the following days.

At the end of Day One there is already a two digit number of both packages uploaded and bugs approached and fixed, and we managed to go through half of the topics that required discussion.

We hope to be able to keep up the good work and finish on Friday with a lot of our goals to be reached, taking a big step ahead.

More in Tux Machines

Screencasts and Shows: LinuxScoop and mintCast

  • Here’s Ubuntu Budgie 20.04 LTS – See What’s New

    The Ubuntu Budgie team has been announced and released Ubuntu Budgie 20.04 LTS On April 23rd, 2020. Ubuntu Budgie 20.04 LTS is the second Long Term Support (LTS) version after the 18.04 release. It will be supported with security and software updates for 3 years, until April 2023, This release rolls-up various developments, fixes and optimizations that have been released since the 18.04 LTS. Ubuntu Budgie 20.04 LTS ships with the latest Budgie Desktop 10.5.1 series by default, an elegant menu applet by default, a Budgie-based NetworkManager applet by default, a completely revamped Window Shuffler, support for switching between desktop layouts with a single click and a new desktop wallpaper rotator and workspace switcher.

  • Ubuntu Kylin 20.04 LTS – Features the Latest UKUI 3.0 Desktop Environment by Default

    The Ubuntu Kylin Team has been announced and released Ubuntu Kylin 20.04 LTS On April 23rd, 2020. Ubuntu Kylin 20.04 LTS is the fourth Long Term Support (LTS) version after 14.04, 16.04, 18.04 release. It will be supported with security and software updates for 3 years, until April 2023, This release received numerous improvements over previous releases. Ubuntu Kylin 20.04 LTS features the latest UKUI 3.0 desktop environment by default and it’s powered by the most recent and advanced kernel, Long term Support of Linux kernel 5.4. which brings improved hardware support (among other features). Ubuntu Kylin default theme improved, introduced a dark variant, which it comes with two variations that user can switch from “Ubuntu Kylin Control Center”. The start menu is completely revamped with New layout, full-screen window to your heart’s content; carefully categorized, intelligent search with one key, default, and full-screen size switch to your choice, provide alphabetical sorting and sorting by function, more convenient to find.

  • mintCast 335.5 – Big Ol’ Lug

    In our Innards section, we’re making good on the promise to include more community.

Linux Kodachi 7.0 ‘Katana’ Released: Browse The Internet Anonymously

Linux Kodachi is one of the most secure operating systems that offer complete privacy and anonymity. Now with the latest full system update, Warith Al Maawali, developer of Linux Kodachi, has released a new point version Linux Kodachi 7.0. The latest edition further strengthens the security of the OS with the addition of new security packages, updates, and bug fixes. Kodachi 7.0 is built upon the Xubuntu 18.04 LTS featuring the latest stable Linux kernel 5.4. Let’s take a look at all the new features of Kodachi 7.0 — Read more

today's howtos

Today in Techrights