With 26.10 in Feature Freeze, wore my Release team hat to:
Review and approve a bunch of Feature Freeze Exceptions, including the Go 1.27 transition, Qt 6.11.2, rust-coreutils 0.12.0, devscripts 2.6.12, kdump-tools moving to dracut, and a few GCE packages.
Point linux-entra-sso to the SRU team, as it didn t need an FFe at all, and milestone a couple of bugs for 26.10.
Continued to push for infrastructure improvements:
Made ubuntu-cdimage more resilient to Launchpad hiccups (MP).
Taught generate-freeze-block in ubuntu-archive-tools a couple of new options (--skip-update and --series) and better error handling (MP).
Bumped the arm64 generic non-cloud image to 4.5G in livecd-rootfs and uploaded it as 26.10.16; also sponsored the follow-up 26.10.17 for Chlo .
Reviewed quite a lot of MPs - britney hints, meta-release, ubuntu-release-tools, ubuntu-archive-tools, ubuntu-cdimage, livecd-rootfs, ubuntu-seeds, and so on.
Did Archive Admin, DMB, and Release team duties as usual.
Debian (E)LTS
This month I have worked 33.5 hours
on Debian Long Term Support (LTS)
and on its sister Extended LTS
project and did the following things:
(A quick note that I did quite a lot of the work during my work as Frontdesk that went on till 4th Oct, so 33.50 hours include the work I did till 4th October 2026.)
Released Security Updates
node-lodash: Prototype pollution in _.unset and _.omit (plus a bypass of the initial fix for it), and code injection via the imports option of _.template.
This is the bookworm follow-up to DLA 4663-1 that I carried over from July. The update had been sitting prepared and tested on debusine, so once the upstream discussion wrapped up, it went straight out. It also carries an extra patch to the lodash-cli dependency map - without it, the regenerated lodash.template module throws assignWith is not defined at runtime, which node-gulp-util s autopkgtest caught.
libpng1.6: Use-after-free of zlib input in png_read_end() after incomplete zTXt, iTXt, or iCCP decompression, which could result in denial of service.
I picked this one up whilst on front desk; the upstream fix that went into trixie via DSA 6537-1 applied to 1.6.39 as-is.
Work in Progress
libpng1.6: The same CVE-2026-46675.
[ELTS]: Claimed in ela-needed; the same upstream fix applies to all three ELTS suites, so this should go out shortly.
Other Activities
[E/LTS] Did my front-desk week from 28-09 to 04-10.
Over the week I did roughly:
Triage of 524 unique CVEs across 192 source packages and all four suites. And 1 automated ELTS end-of-life sweep.
Additional data is now part of the front-desk job too, so 75 commits record it for 179 CVEs across 71 packages.
Newly queued 22 source packages - 13 in dla-needed (apache2, chromium, firefox-esr, libnet-idn-encode-perl, libpng1.6, node-shell-quote, nvidia-graphics-drivers, openssl, pcre2, php-mongodb, php8.2, social-auth-core, and wpa) and 16 in ela-needed (apache2, firefox-esr, gegl, lemonldap-ng, libnet-idn-encode-perl, libpng1.6, libwebsockets, nsd, nvidia-graphics-drivers, pcre2, php7.0, php7.3, php7.4, rar, unrar-nonfree, and wpa), 7 of them in both. Also widened 3 ELTS entries to bullseye - antiword, ocaml, and openvswitch.
Most of the interesting work was again in the <not-affected> verdicts: 217 of 263 (83%, across 57 packages) rest on showing that the vulnerable code or feature isn t in the source we ship. Another 17 cover incomplete upstream fixes that we either never shipped or shipped with the follow-up already in (expat, libxml2, node-tar, and pyjwt). 15 come from bundled components we don t ship - node-ajv again, which uses uri-js and not fast-uri, and nvidia-open, which doesn t ship the NGX updater. And 13 are vendor- or platform-specific - openssh s CVE-2026-55654 lives only in a Red Hat GSSAPI patch, and the netdata and PHP ones only affect Windows.
Did 4 rounds of newly supported bullseye packages (33 packages overall), plus libmail-mboxparser-perl for buster - 34 in all. The existing CVE data mostly held up; the real finds were discovery gaps. One interesting gotcha: sid renamed stunnel4 to stunnel, and two new CVEs were associated only with the new name, so they never showed up for trixie, bookworm, or any ELTS suite. I also sorted the 180 Triage needed entries (57 packages) from elts-eol by where each was already handled, and triaged for ELTS the 100 that trixie or bookworm had already decided; the rest come next. And I imported 79 package-level lines for the older source names ELTS still ships (tomcat8, php7.0/7.3/7.4, netty-3.9, openssl1.0, python2.7/3.5/3.7, and pypy).
Caught some inconsistencies in released advisories: DLA 4801-1 (swift) was missing a CVE, ELA 1831-1 (redis) listed the wrong one, and DLA 4808-1 (network-manager-l2tp) listed CVE-2026-75883 - an ID that was renamed and then reassigned to an unrelated ppp issue. I fixed all three in the tracker s advisory lists.
Made the Security team and the uploaders aware of regressions from our own updates:
libde265: the CVE-2026-49337 fix in DLA 4789-1/ELA 1828-1 (and DSA 6413-1) misses upstream s follow-up commit.
libxml2 CVE-2026-76781 and policykit-1 CVE-2026-85498 were introduced by our own back-ports; the policykit-1 one is harmless.
expat: the CVE-2025-59375 backport in DLA 4807-1 is compiled out, because XML_GE is never defined.
xen: DLA 4818-1 s XSA-491 fix makes XSA-510 reachable.
gegl: the CVE-2026-2049/2050 back-port in ELA 1650-1 rejects valid RLE .hdr files.
log4cxx: DLA 4322-1 broke UTF-8 in JSONLayout output. That one is functional, not security.
Helped correct a set of triages and let the Debian Security team know:
ruby-json CVE-2026-71847: the vulnerable code was never in a released Debian version.
openssh CVE-2026-55654: only affects a Red Hat-specific GSSAPI patch.
three libxml2 issues that don t affect trixie either.
the stunnel4 rename above.
trixie <no-dsa> lines on jsch, node-qs, and ruby-loofah, where trixie s version doesn t have the vulnerable feature at all.
Independently found a security issue in rclone and reported it privately upstream through a GitHub security advisory. Upstream already had a report for the same issue, so they folded mine into the existing advisory and credited me as a co-reporter.
Also found some bugs in the additional-data tooling, e.g. cve-ad --package P --severity tbd wipes the CVE-level severity, and the schema doesn t validate package-level entries at all.
[E/LTS] Monitored discussions on mailing lists, IRC, and all the documentation updates.
Rumors are running that python2 is not a thing anymore.
Well, I'm certainly late to the party, but I'm happy to report that
sources.debian.org is now running python3.
Wait, it wasn't?
Back when development started, python3 was very much a real language, but it was
hard to adopt because it was not supported by many libraries. So python2 was
chosen, meaning print-based debugging was used in lieu of print()-based
debugging, and str were bytes, not unicode.
And things were working just fine. One day python2 EOL was announced, with a
date far in the future. Far enough to procrastinate for a long time. Combine
this with a codebase that is stable enough to not see many commits, and the fact
that Debsources is a volunteer-based project that happens at best on week-ends,
and you end up with a dormant software and a missed deadline.
But, as dormant as the codebase is, the instance hosted at
sources.debian.org is very popular and gets 200k
to 500k hits per day. Largely enough to be worth a proper maintenance and a
transition to python3.
Funky file names
While transitioning to python3 and juggling left and right with str, bytes
and unicode for internal objects, files, database entries and HTTP content, I
stumbled upon a bug that has been there since day 1.
Quick recap if you're unfamiliar with this tool: Debsources displays the content
of the source packages in the Debian archive. In other words, it's a bit like
GitHub, but for the Debian source code.
And some pieces of software out there, that ended up in Debian packages, happen
to contain files whose names can't be decoded to UTF-8. Interestingly enough,
there's no such thing as a standard for file names: with a few exceptions that
vary by operating system, any sequence of bytes can be a legit file name. And
some sequences of bytes are not valid UTF-8.
Of course those files are rare, and using ASCII characters to name a file is a
much more common practice than using bytes in a non-UTF-8 character
encoding. But when you deal with almost 100 million files on which you have no
control (those files come from free software projects, and make their way into
Debian without any renaming), it happens.
Now back to the bug: when trying to display such a file through the web
interface, it would crash because it can't convert the file name to UTF-8, which
is needed for the HTML representation of the page.
Bugfix
An often valid approach when trying to represent invalid UTF-8 content is to
ignore errors, and replace them with ? or . This is what Debsources
actually does to display non-UTF-8 file content.
Unfortunately, this best-effort approach is not suitable for file names, as file
names are also identifiers in Debsources: among other places, they are part of
URLs. If an URL were to use placeholder characters to replace those bytes, there
would be no deterministic way to match it with a file on disk anymore.
The representation of binary data into text is a known problem. Multiple
lossless solutions exist, such as base64 and its variants, but URLs looking like
https://sources.debian.org/src/Y293c2F5LzMuMDMtOS4yL2Nvd3NheS8= are not
readable at all compared to
https://sources.debian.org/src/cowsay/3.03-9.2/cowsay/. Plus, not
backwards-compatible with all existing links.
The solution I chose is to use double-percent encoding: this allows the representation of any byte in an
URL, while keeping allowed characters unchanged - and preventing CGI gateways
from trying to decode non-UTF-8 bytes. This is the best of both worlds: regular
file names get to appear normally and are human-readable, and funky file names
only have percent signs and hex numbers where needed.
Here is an example of such an URL:
https://sources.debian.org/src/aspell-is/0.51-0-4/%25EDslenska.alias/. Notice
the %25ED to represent the percentage symbol itself (%25) followed by an
invalid UTF-8 byte (%ED).
Transitioning to this was quite a challenge, as those file names don't only
appear in URLs, but also in web pages themselves, log files, database tables,
etc. And everything was done with str: made sense in python2 when str were
bytes, but not much in python3.
What are those files? What's their network?
I was wondering too. Let's list them!
Running this on the Debsources main instance, which hosts pretty much all Debian
packages that were part of a Debian release, I could find 307 files (among a
total of almost 100 million files).
Without looking deep into them, they seem to fall into 2 categories:
File names that are not valid UTF-8, but are valid in a different charset. Not
all software is developed in English or on UTF-8 systems.
File names that can't be decoded to UTF-8 on purpose, to be used as input to
test suites, and assert resilience of the software to non-UTF-8 data.
That last point hits home, as it was clearly lacking in Debsources. A funky file
name is now part of its test suite. ;)
I attended the MiniDebconf in Toulouse, which was hosted in the larger
Capitole du Libre, a free software event with talks, presentation of
associations, and a keysigning party. I didn't expect the event to be
that big, and I was very impressed by its organization. Cheers to all
the volunteers, it has been an amazing week-end!
Here's a sum-up of the talks I attended.
Du logiciel libre la monnaie libre
Speaker: lo s
The first talk I attended was, translated to English, "from free
software to free money".
lo s compared the 4 freedoms of free software with money, and what
properties money needs to exhibit in order to be considered free. He
then introduced 1, a project of free (as in free speech!) money,
started in the region around Toulouse. Contrary to some distributed
ledgers such as Bitcoin, 1 isn't based on an hash-based
proof-of-work, but rather around a web of trust of people certifying
each other, hence limiting the energy consumption required by the
network to function.
YunoHost
Speaker: Jimmy Monin
I then attended a presentation of YunoHost. Being an happy user
myself, it was very nice to discover the future expected features, and
also meet two of the developers. YunoHost is a Debian-based project,
aimed at providing all the tools necessary to self-host applications,
including email, website, calendar, development tools, and dozens of
other packages.
Premiers pas dans l'univers de Debian
Speaker: Nicolas Dandrimont
For the first talk of the MiniDebConf, Nicolas Dandrimont introduced
Debian, its philosophy, and how it works with regards to upstreams and
downstreams. He gave many details on the teams, the infrastructure,
and the internals of Debian.
Trusting your computer and system
Speaker: Jonas Smedegaard
Jonas introduced some security concepts, and how they are abused and
often meaningless (to quote his own words, "secure is bullshit"). He
described a few projects which lean towards a more secure and open
hardware, for both phones and laptops.
Automatiser la gestion de configuration de Debian avec Ansible
Speaker: J r my Lecour
J r my, from Evolix, introduced Ansible, and how they use it to manage
hundreds of Debian servers. Ansible is a very powerful tool, and a
huge ecosystem, in many ways similar to Puppet or Chef, except it is
agent-less, using only ssh connections to communicate with remote
machines. Very nice to compare their use of Ansible with mine, since
that's the software I use at work for deploying experiments.
Making Debian for everybody
Speaker: Samuel Thibault
Samuel gave a talk about accessibility, and the general availability
of the tools in today's operating systems, including Debian. The
lesson to take home is that we often don't do enough in this domain,
particularly when considering some issues people might have that we
don't always think about. Accessibility on computers (and elsewhere)
should be the default, and never require complex setups.
Retour d'exp rience : mise jour de milliers de terminaux Debian
Speaker: Cyril Brulebois
Cyril described a problem he was hired for, an update of thousands of
Debian servers from wheezy to jessie, which he discovered afterwards
was worse than initially thought, since the machines were running the
out-of-date squeeze. Since they were not always administered with the
best sysadmin practices, they were all exhibiting different
configurations and different packages lists, which raised many issues
and gave him interesting challenges. They were solved using Ansible,
which also had the effect of standardizing their system administration
practices.
Retour d'exp rience : utilisation de Debian chez Evolix
Speaker: Gr gory Colpart
Gr gory described Evolix, a company which manages servers for their
clients, and how they were inspired by Debian, for both their internal
tools and their practices. It is very interesting to see that some of
the Debian values can be easily exported for a more open and
collaborative business.
Lightning talks
To close the conference, two lightning talks were presented,
describing the switch from Windows XP to Debian in an ecologic
association near Toulouse; and how snapshot.debian.org can be used
with bisections to find the source of some regressions.
Conclusion
A big thank you to all the organizers and the associations who
contributed to make this event a success. Cheers!
At DebConf17, John Sullivan, the
executive director of the FSF, gave a talk on the supposed decline of
the use of copyleft licenses use free-software projects. In his
presentation, Sullivan
questioned the notion that permissive licenses, like the BSD or MIT
licenses, are gaining ground at the expense of the traditionally
dominant copyleft licenses from the FSF. While there does seem to be a
rise in the use of permissive licenses, in general, there are several
possible explanations for the phenomenon.
When the rumor mill starts
Sullivan gave a recent example of the claim of the decline of copyleft
in an article on
Opensource.com by Jono
Bacon from February 2017 that showed a histogram of license usage
between 2010 and 2017 (seen below).
From that, Bacon elaborates possible reasons for the apparent decline of
the GPL. The graphic used in the article was actually generated by
Stephen O'Grady in a January article, The State Of Open Source
Licensing,
which said:
In Black Duck's sample, the most popular variant of the GPL version
2 is less than half as popular as it was (46% to 19%). Over the same
span, the permissive MIT has gone from 8% share to 29%, while its
permissive cousin the Apache License 2.0 jumped from 5% to 15%.
Sullivan, however, argued that the methodology used to create both
articles was problematic. Neither contains original research: the graphs
actually come from the Black Duck
Software "KnowledgeBase" data,
which was partly created from the old Ohloh web site now known as Open
Hub.
To show one problem with the data, Sullivan mentioned two free-software
projects, GNU Bash and GNU Emacs, that had been showcased on the front
page of Ohloh.net in 2012. On the site, Bash was (and still
is)
listed as GPLv2+, whereas it
changed
to GPLv3 in 2011. He also claimed that "Emacs was listed as licensed
under GPLv3-only, which is a license Emacs has never had in its
history", although I wasn't able to verify that information from the
Internet archive. Basically, according to Sullivan, "the two projects
featured on the front page of a site that was using [the Black Duck]
data set were wrong". This, in turn, seriously brings into question the
quality of the data:
I reported this problem and we'll continue to do that but when someone
is not sharing the data set that they're using for other people to
evaluate it and we see glimpses of it which are incorrect, that should
give us a lot of hesitation about accepting any conclusion that comes
out of it.
Reproducible observations are necessary to the establishment of solid
theories in science. Sullivan didn't try to contact Black Duck to get
access to the database, because he assumed (rightly, as it turned out)
that he would need to "pay for the data under terms that forbid you to
share that information with anybody else". So I wrote Black Duck myself
to confirm this information. In an email interview, Patrick Carey from
Black Duck confirmed its data set is proprietary. He believes, however,
that through a "combination of human and automated techniques", Black
Duck is "highly confident at the accuracy and completeness of the data
in the KnowledgeBase". He did point out, however, that "the way we track
the data may not necessarily be optimal for answering the question on
license use trend" as "that would entail examination of new open source
projects coming into existence each year and the licenses used by them".
In other words, even according to Black Duck, its database may not be
useful to establish the conclusions drawn by those articles. Carey did
agree with those conclusions intuitively, however, saying that "there
seems to be a shift toward Apache and MIT licenses in new projects,
though I don't have data to back that up". He suggested that "an
effective way to answer the trend question would be to analyze the new
projects on GitHub over the last 5-10 years." Carey also suggested that
"GitHub has become so dominant over the recent years that just looking
at projects on GitHub would give you a reasonable sampling from which to
draw conclusions".
Indeed, GitHub published a
report
in 2015 that also seems to confirm MIT's popularity (45%), surpassing
copyleft licenses (24%). The data is, however, not without its own
limitations. For example, in the above graph going back to the inception
of GitHub in 2008, we see a rather abnormal spike in 2013, which seems
to correlate with the launch of the
choosealicense.com site, described by
GitHub as "our first pass at making open source licensing on GitHub
easier".
In his talk, Sullivan was critical of the initial version of the
site
which he described as biased toward permissive licenses. Because the
GitHub project creation page links to the site, Sullivan explained that
the site's bias could have actually influenced GitHub users' license
choices. Following a
talk
from Sullivan at FOSDEM 2016, GitHub addressed the problem later that
year by
rewording parts of the front page to be more accurate, but that any
change in license choice obviously doesn't show in the report produced
in 2015 and won't affect choices users have already made. Therefore,
there can be reasonable doubts that GitHub's subset of software projects
may not actually be that representative of the larger free-software
community.
In search of solid evidence
So it seems we are missing good, reproducible results to confirm or
dispel these claims. Sullivan explained that it is a difficult problem,
if only in the way you select which projects to analyze: the impact of a
MIT-licensed personal wiki will obviously be vastly different from, say,
a GPL-licensed C compiler or kernel. We may want to distinguish between
active and inactive projects. Then there is the problem of code
duplication, both across publication platforms (a project may be
published on GitHub and SourceForge for example) but also across
projects (code may be copy-pasted between projects). We should think
about how to evaluate the license of a given project: different files in
the same code base regularly have different licenses often none at all.
This is why having a clear, documented and publicly available data set
and methodology is critical. Without this, the assumptions made are not
clear and it is unreasonable to draw certain conclusions from the
results.
It turns out that some researchers did that kind of open research in
2016 in a paper called "The Debsources Dataset: Two Decades of Free and
Open Source Software"
[PDF]
by Matthieu Caneill, Daniel M. Germ n, and Stefano Zacchiroli. The
Debsources data set is the complete
Debian source code that covers a large history of the Debian project and
therefore includes thousands of free-software projects of different
origins. According to the paper:
The long history of Debian creates a perfect subject to evaluate how
FOSS licenses use has evolved over time, and the popularity of
licenses currently in use.
Sullivan argued that the Debsources data set is interesting because of
its quality: every package in Debian has been reviewed by multiple
humans, including the original packager, but also by the FTP masters to
ensure that the distribution can legally redistribute the software. The
existence of a package in Debian provides a minimal "proof of use":
unmaintained packages get removed from Debian on a regular basis and the
mere fact that a piece of software gets packaged in Debian means at
least some users found it important enough to work on packaging it.
Debian packagers make specific efforts to avoid code duplication between
packages in order to ease security maintenance. The data set covers a
period longer than Black Duck's or GitHub's, as it goes all the way back
to the Hamm 2.0 release in 1998. The data and how to reproduce it are
freely available under a CC
BY-SA 4.0 license.
Sullivan presented the above graph from the research paper that showed
the evolution of software license use in the Debian archive. Whereas
previous graphs showed statistics in percentages, this one showed actual
absolute numbers, where we can't actually distinguish a decline in
copyleft licenses. To quote the paper again:
The top license is, once again, GPL-2.0+, followed by:
Artistic-1.0/GPL dual-licensing (the licensing choice of Perl and most
Perl libraries), GPL-3.0+, and Apache-2.0.
Indeed, looking at the graph, at most do we see a rise of the Apache
and MIT licenses and no decline of the GPL per se, although its adoption
does seem to slow down in recent years. We should also mention the
possibility that Debian's data set has the opposite bias: toward GPL
software. The Debian project is culturally quite different from the
GitHub community and even the larger free-software ecosystem, naturally,
which could explain the disparity in the results. We can only hope a
similar analysis can be performed on the much larger Software
Heritage data set eventually, which
may give more representative results. The paper acknowledges this
problem:
Debian is likely representative of enterprise use of FOSS as a base
operating system, where stable, long-term and seldomly updated
software products are desirable. Conversely Debian is unlikely
representative of more dynamic FOSS environments (e.g., modern
Web-development with micro libraries) where users, who are usually
developers themselves, expect to receive library updates on a daily
basis.
The Debsources research also shares methodology limitations with Black
Duck: while Debian packages are reviewed before uploading and we can
rely on the copyright information provided by Debian maintainers, the
research also relies on automated tools (specifically
FOSSology) to retrieve license
information.
Sullivan also warned against "ascribing reason to numbers": people may
have different reasons for choosing a particular license. Developers may
choose the MIT license because it has fewer words, for compatibility
reasons, or simply because "their lawyers told them to". It may not
imply an actual deliberate philosophical or ideological choice.
Finally, he brought up the theory that the rise of non-copyleft licenses
isn't necessarily at the detriment of the GPL. He explained that, even
if there is an actual decline, it may not be much of a problem if
there is an overall growth of free software to the detriment of
proprietary software. He reminded the audience that non-copyleft
licenses are still free software, according to the FSF and the Debian
Free Software Guidelines, so their rise is still a positive outcome.
Even if the GPL is a better tool to accomplish the goal of a
free-software world, we can all acknowledge that the conversion of
proprietary software to more permissive and certainly simpler licenses
is definitely heading in the right direction.
[I would like to thank the DebConf organizers for providing meals for
me during the conference.]
Note: this article first appeared in
the Linux Weekly News.
While teaching this semester a class on concurrent programming, I
realized during the labs that most of the students couldn't properly
debug their code. They are at the end of a 2-year cursus, know many
different programming languages and frameworks, but when it comes to
tracking down a bug in their own code, they often lacked the
basics. Instead of debugging for them I tried to give them general
directions that they could apply for the next bugs. I will try here to
summarize the very first basic things to know about
debugging. Because, remember, writing software is 90% debugging, and
10% introducing new bugs (that is not from me, but I could not find
the original quote).
So here is my take at Debugging 101.
Use the right tools
Many good tools exist to assist you in writing correct software, and
it would put you behind in terms of productivity not to use
them. Editors which catch syntax errors while you write them, for
example, will help you a lot. And there are many features out there in
editors, compilers, debuggers, which will prevent you from introducing
trivial bugs. Your editor should be your friend; explore its features
and customization options, and find an efficient workflow with them,
that you like and can improve over time. The best way to fix bugs is
not to have them in the first place, obviously.
Test early, test often
I've seen students writing code for one hour before running make,
that would fail so hard that hundreds of lines of errors and warnings
were outputted. There are two main reasons doing this is a bad idea:
You have to debug all the errors at once, and the complexity of
solving many bugs, some dependent on others, is way higher than the
complexity of solving a single bug. Moreover, it's discouraging.
Wrong assumptions you made at the beginning will make the following
lines of code wrong. For example if you chose the wrong data
structure for storing some information, you will have to fix all the
code using that structure. It's less painful to realize earlier it
was the wrong one to choose, and you have more chances of knowing
that if you compile and execute often.
I recommend to test your code (compilation and execution) every few
lines of code you write. When something breaks, chances are it will
come from the last line(s) you wrote. Compiler errors will be shorter,
and will point you to the same place in the code. Once you get more
confident using a particular language or framework, you can write
more lines at once without testing. That's a slow process, but it's
ok. If you set up the right keybinding for compiling and executing
from within your editor, it shouldn't be painful to test early and
often.
Read the logs
Spot the places where your program/compiler/debugger writes text, and
read it carefully. It can be your terminal (quite often), a file in
your current directory, a file in /var/log/, a web page on a local
server, anything. Learn where different software write logs on your
system, and integrate reading them in your workflow. Often, it will be
your only information about the bug. Often, it will tell you where the
bug lies. Sometimes, it will even give you hints on how to fix it.
You may have to filter out a lot of garbage to find relevant
information about your bug. Learn to spot some keywords like error
or warning. In long stacktraces, spot the lines concerning your
files; because more often, your code is to be blamed, rather than
deeper library code. grep the logs with relevant keywords. If you
have the option, colorize the output. Use tail -f to follow a file
getting updated. There are so many ways to grasp logs, so find what
works best with you and never forget to use it!
Print foobar
That one doesn't concern compilation errors (unless it's a Makefile
error, in that case this file is your code anyway).
When the program logs and output failed to give you where an error
occured (oh hi Segmentation fault!), and before having to dive into
a memory debugger or system trace tool, spot the portion of your
program that causes the bug and add in there some print
statements. You can either print("foo") and print("bar"), just to
know that your program reaches or not a certain place in your code, or
print(some_faulty_var) to get more insights on your program
state. It will give you precious information.
stderr>>"foo">>endl;my_db.connect();// is this broken?
stderr>>"bar">>endl;
In the example above, you can be sure it is the connection to the
database my_db that is broken if you get foo and not bar on your
standard error.
(That is an hypothetical example. If you know something can break,
such as a database connection, then you should always enclose it in a
try/catch structure).
Isolate and reproduce the bug
This point is linked to the previous one. You may or may not have
isolated the line(s) causing the bug, but maybe the issue is not
always raised. It can depend on many other things: the program or
function parameters, the network status, the amount of memory
available, the decisions of the OS scheduler, the user rights on the
system or on some files, etc. More generally, any assumption you made
on any external dependency can appear to be wrong (even if it's right
99% of the time). According to the context, try to isolate the set of
conditions that trigger the bug. It can be as simple as "when there is
no internet connection", or as complicated as "when the CPU load of
some external machine is too high, it's a leap year, and the input
contains illegal utf-8 characters" (ok, that one is fucked up; but it
surely happens!). But you need to reliably be able to reproduce the
bug, in order to be sure later that you indeed fixed it.
Of course when the bug is triggered at every run, it can be
frustrating that your program never works but it will in general be
easier to fix.
RTFM
Always read the documentation before reaching out for help. Be it
man, a book, a website or a wiki, you will find precious information
there to assist you in using a language or a specific library. It can
be quite intimidating at first, but it's often organized the same
way. You're likely to find a search tool, an API reference, a
tutorial, and many examples. Compare your code against them. Check in
the FAQ, maybe your bug and its solution are already referenced there.
You'll rapidly find yourself getting used to the way documentation is
organized, and you'll be more and more efficient at finding instantly
what you need. Always keep the doc window open!
Google and Stack Overflow are your friends
Let's be honest: many of the bugs you'll encounter have been
encountered before. Learn to write efficient queries on search
engines, and use the knowledge you can find on questions&answers
forums like Stack Overflow. Read the answers and comments. Be wise
though, and never blindly copy and
paste
code from there. It can be as bad as introducing malicious security
issues into your code, and you won't learn anything. Oh, and don't
copy and paste anyway. You have to be sure you understand every single
line, so better write them by hand; it's also better for memorizing
the issue.
Take notes
Once you have identified and solved a particular bug, I advise to
write about it. No need for shiny interfaces: keep a list of your bugs
along with their solutions in one or many text files, organized by
language or framework, that you can easily grep.
It can seem slightly cumbersome to do so, but it proved (at least to
me) to be very valuable. I can often recall I have encountered some
buggy situation in the past, but don't always remember the
solution. Instead of losing all the debugging time again, I search in
my bug/solution list first, and when it's a hit I'm more than happy I
kept it.
Further reading degugging
Remember this was only Debugging 101, that is, the very first steps
on how to debug code on your own, instead of getting frustrated and
helplessly stare at your screen without knowing where to begin. When
you'll write more software, you'll get used to more efficient
workflows, and you'll discover tools that are here to assist you in
writing bug-free code and spotting complex bugs efficiently. Listed
below are some of the tools or general ideas used to debug more
complex software. They belong more to a software engineering course
than a Debugging 101 blog post. But it's good to know as soon as
possible these exist, and if you read the manuals there's no reason
you can't rock with them!
Loggers. To make the "foobar" debugging more efficient, some
libraries are especially designed for the task of logging out
information about a running program. They often have way more
features than a simple print statement (at the price of being
over-engineered for simple programs): severity levels (info,
warning, error, fatal, etc), output in rotating files, and
many more.
Version control. Following the evolution of a program in time,
over multiple versions, contributors and forks, is a hard
task. That's where version control plays: it allows you to keep the
entire history of your program, and switch to any previous
version. This way you can identify more easily when a bug was
introduced (and by whom), along with the patch (a set of changes to
a code base) that introduced it. Then you know where to apply your
fix. Famous version control tools include Git, Subversion, and
Mercurial.
Debuggers. Last but not least, it wouldn't make sense to talk
about debugging without mentioning debuggers. They are tools to
inspect the state of a program (for example the type and value of
variables) while it is running. You can pause the program, and
execute it line by line, while watching the state evolve. Sometimes
you can also manually change the value of variables to see what
happens. Even though some of them are hard to use, they are very
valuable tools, totally worth diving into!
Don't hesitate to comment on this, and provide your debugging 101
tips! I'll be happy to update the article with valuable feedback.
Happy debugging!
DebConf 16 in Capetown/South Africa was fantastic for many reasons.
My Capetown/South Africa/Culture/Flight related lessons:
Avoid flying on Sundays (especially in/from Austria where plenty of hotlines are closed on Sundays or at least not open when you need them)
Actually turn back your seat on the flight when trying to sleep and not forget that this option exists *cough*
While UCT claims to take energy saving quite serious (e.g. turn off the lights mentioned at many places around the campus), several toilets flush all their water, even when trying to do just small business and also two big lights in front of a main building seem to be shining all day long for no apparent reason
There doesn t seem to be a standard for the side of hot vs. cold water-taps
Soap pieces and towels on several toilets
For pedestrians there s just a very short time of green at the traffic lights (~2-3 seconds), then red blinking lights show that you can continue walking across the street (but *should* not start walking) until it s fully red again (but not many people seem to care about the rules anyway :))
Warning lights of cars are used for saying thanks (compared to hand waving in e.g. Austria)
The 40km/h speed limit signs on the roads seem to be showing the recommended minimum speed :-)
There are many speed bumps on the roads
Geese quacking past 11:00 p.m. close to a sleeping room are something I m also not used to :-)
Announced downtimes for the Internet connection are something I m not used to
WLAN in the dorms of UCT as well as in any other place I went to at UCT worked excellent (measured ~22-26 Mbs downstream in my room, around 26Mbs in the hacklab) (kudos!)
WLAN is available even on top of the Table Mountain (WLAN working and being free without any registration)
Number26 credit card is great to withdraw money from ATMs without any extra fees from common credit card companies (except for the fee the ATM itself charges but displays ahead on-site anyway)
Splitwise is a nice way to share expenses on the road, especially with its mobile app and the money beaming using the Number26 mobile app
My technical lessons from DebConf16:
ran into way too many yak-shaving situations, some of them might warrant separate blog posts
finally got my hands on gbp-pq (manage quilt patches on patch queue branches in git): very nice to be able to work with plain git and then get patches for your changes, also having upstream patches (like cherry-picks) inside debian/patches/ and the debian specific changes inside debian/patches/debian/ is a lovely idea, this can be easily achieved via Gbp-Pq: Topic debian with gbp s pq and is used e.g. in pkg-systemd, thanks to Michael Biebl for the hint and helping hand
David Bremner s gitpkg/git-debcherry is something to also be aware of (thanks for the reminder, gregoa)
autorevision: extracts revision metadata from your VCS repository (thanks to pabs)
ifupdown2 (its current version is also available in jessie-backports!) has some nice features, like ifquery running $interface to get the life configuration of a network interface, json support ( ifquery format=json ) and makotemplates support to generate configuration for plenty of interfaces
BTW, thanks to the video team the recordings from the sessions are available online.
Following up on the hack of Matthieu - A one-liner to catch'em all! - and the recent features of Debsources I got the idea to modify a bit the one liner in order to retrieve the license of foo.bar.
The script will calculate the SHA256 hash of the file and then query the Debsources API in order to retrieve the license of that particular file.
Save the following in a file as license-of and add it in your $PATH
if the checksum is not found in the DB (compiled file, modified file, not part of any package) this will fail
if the debian/copyright file of the specific package is not machine readable then you are out of luck!
if there are more than 1 versions of the package you will get all the available information. If you want to get just testing then add "&suite=testing" after the &packagename="$1" in the debsources link.
TL;DR All Debian license and patches are belong to us. Discover them here and here.
In case you hadn't already stumbled upon sources.debian.net in the past, Debsources is a simple web application that allows to publish an unpacked Debian source mirror on the Web. On the live instance you can browse the contents of Debian source packages with syntax highlighting, search files matching a SHA-256 hash or a ctag, query its API, highlight lines, view accurate statistics and graphs. It was initially developed at IRILL by Stefano Zacchiroli and Matthieu Caneill.
During GSOC 2015 I helped introduce two new features.
License Tracker
Since Debsources has all the debian/copyright files and that many of them adopted the DEP-5 suggestion (machine readable copyright files) it was interesting to exploit them for end users. You may find interesting the following features:
an API that allows users to find the license of file "foo" or the licenses for a bunch of packages, using filenames or SHA-256 hashes
a better looking interface for debian/copyright files
Have a look at the documentation to discover more!
Patch tracker
The old patch tracker unfortunately died a while ago. Since Debsources stores all the patches it was, probably, natural for it to be able to exploit them and present them over the web. You can navigate through packages by prefix or by searching them here. Among the use cases:
a summary which contains all the patches of a package together with their diffs and summaries/subjects
In the future these informations will be added in the DB. This will allow:
the license tracker to provide interesting statistics and graphs about licensing trends (What do Pythonistas usually choose as a license, how many GPL-3 files are in Jessie etc). Those are going to be quite accurate since they will take into account each file in a given package and not just the "general" license of the package.
the patch tracker to produce a list of packages that contain patches - this will enable providing links from PTS to the patch tracker.
Not far in the horizon there is also an initial work for exporting debian/copyright files into SPDX documents. You can have a look at a beta / testing version on debsources-dev. (Example)
I hope you find these new features useful. Don't hesitate to report any bugs or suggestions you come accross.
I wrote a Bash one-liner to open the source code (in
Debsources) of any file on your system
(if it belongs to a Debian package).
It will simply retrieve the associated package and point your default
browser to its source code.
Add this somewhere in your $PATH, and name this file debsrc:
Midterm evaluations have already passed and I guess we have also reached a milestone since last week I finished working on the copyright tracker and started the patch tracker.
Here's the list of my reports on soc-coordination for those interested
Copyright tracker status
Most of the functionalities of the copyright tracker are already merged. Specifically navigating in the tracker, rendering the machine readable licenses, API functionalities such as obtaining the license of a file searching by checksum or by a package / version / path or obtaining the licenses of many files at once and their respective views.
Some more functionalities are still under review such as filling the database with copyright related information at update time, using the database to answer the aforementioned requests, license statistics in the spirit of the Debsources ones and exporting a license in SPDX format.
Its going to be pretty exciting when those pull requests are going to be merged since the copyright tracker will be full and complete! Meanwhile I started working on the patch tracker.
Patch tracker
My second task is the implementation of a patch tracker. This feature existed in Debian but unfortunately died recently. I have already started revising the functionalities of the old patch tracker, started identifying target users, creating use stories and cases. Those should help me list the desired functionalities of the tracker, imagine the structure of the blueprint and start writing code to that end.
It is going to be a pretty exciting run of 1 month doing this as my knowledge on the Debian packaging system is not that good just yet. I hope that until Debconf some of the functionalities of the patch tracker are going to be ready.
Debconf
My request for sponsorship for Debconf was accepted and I am pretty excited since this is going to be my first Debconf attendance. I am looking forward meeting my mentors (Zack and Matthieu), the fellow student working on Debsources (Clemux) as well as a lot of other people I happen to chat occasionaly during this summer. I ll arrive on Friday 14th and leave on Sunday 23.
The first 4 weeks have been really great. I had the chance to work on the new webapp, the copyright tracker. Here are my first 4 reports for the weeks:
Summary
During these weeks i completed the navigation (by prefix, list of versions etc) for the copyright tracker, the license rendering and the API for searching by checksum and by package/version/filename.
Still under review the batch API (request many files at once) and the the respective views for the API.
In the following weeks I ll work on the database and the plugins to mine license information on update time.
Experience
The experience i accumulate every week is immense. During the review process of my code i receive great feedback from zack, matthieu, and jpleau. It is a great chance for everyone to improve his/hers coding skills. At the university we barely get any feedback on our code, let alone communicate directly with professors to find the best solution for a given problem.
I think it gets development in another level. For example at the university we use git/mercurial for our projects, although we don't really pay attention at commit messages and we marginally make use of these tools besides 'commit pull push'. During the last weeks i had the chance to use far more commands in order to squash amend rebase commits to have a beautiful and useful log history! And this is just a minor example. All in all I think it is a great introduction to the free/open source community for somebody, like me, who has been for years only a user and couldn't find the opportunity to contribute!
And don't get me wrong, gsoc is not only about coding skills. At least for myself having the chance to get just a small taste of how the Debian community works, gets organised, get things done (!) is somehow priceless!
TDD
I have finally understood why test driven development is so powerful. As i am advancing in the project i am sometimes obliged to retouch some areas, refactor pieces of code. Having a great test suite that keeps you on track about the changes, and possible outages in advance is pretty powerful.
What is coming
I feel the project is on the right path. Both clemux (fellow gsoc student working on debsources) and me are advancing in a productive pace. I hope that soon enough the copyright Blueprint will be completed (most notable pending functionalities are the plugins-hooks to mine the licenses at update time, introduction of at least another license oracle possible ninka, statistics) so that everyone can take profit of the new tools provided by DebSources.
Although we haven't talked much about it the patch tracker should also come into the play sooner rather than later.
Stay tuned!
The first 4 weeks have been really great. I had the chance to work on the new webapp, the copyright tracker. Here are my first 4 reports for the weeks:
Summary
During these weeks i completed the navigation (by prefix, list of versions etc) for the copyright tracker, the license rendering and the API for searching by checksum and by package/version/filename.
Still under review the batch API (request many files at once) and the the respective views for the API.
In the following weeks I ll work on the database and the plugins to mine license information on update time.
Experience
The experience i accumulate every week is immense. During the review process of my code i receive great feedback from zack, matthieu, and jpleau. It is a great chance for everyone to improve his/hers coding skills. At the university we barely get any feedback on our code, let alone communicate directly with professors to find the best solution for a given problem.
I think it gets development in another level. For example at the university we use git/mercurial for our projects, although we don't really pay attention at commit messages and we marginally make use of these tools besides 'commit pull push'. During the last weeks i had the chance to use far more commands in order to squash amend rebase commits to have a beautiful and useful log history! And this is just a minor example. All in all I think it is a great introduction to the free/open source community for somebody, like me, who has been for years only a user and couldn't find the opportunity to contribute!
And don't get me wrong, gsoc is not only about coding skills. At least for myself having the chance to get just a small taste of how the Debian community works, gets organised, get things done (!) is somehow priceless!
TDD
I have finally understood why test driven development is so powerful. As i am advancing in the project i am sometimes obliged to retouch some areas, refactor pieces of code. Having a great test suite that keeps you on track about the changes, and possible outages in advance is pretty powerful.
What is coming
I feel the project is on the right path. Both clemux (fellow gsoc student working on debsources) and me are advancing in a productive pace. I hope that soon enough the copyright Blueprint will be completed (most notable pending functionalities are the plugins-hooks to mine the licenses at update time, introduction of at least another license oracle possible ninka, statistics) so that everyone can take profit of the new tools provided by DebSources.
Although we haven't talked much about it the patch tracker should also come into the play sooner rather than later.
Stay tuned!
This morning, I pushed out version 2.11.17 of the Geode X.Org driver. This is the driver used by the OLPC XO-1 and by a plethora of low-power desktops, micro notebooks and thin clients. This is a minor release. It merges conditional support for the OpenBSD MSR device (Marc Ballmer, Matthieu Herrb), fixes a condition that prevents compiling on some embedded platforms (Brian A. Lloyd) and upgrades the code for X server 1.17 compatibility (Maarten Lankhorst).
Pending issues:
toggle COM2 into DDC probing mode during driver initialization
reset the DAC chip when exiting X and returning to vcons
Debsources (http://sources.debian.net) is
still under active development. We recently had a Gnome Outreachy
intern, Jingjie Jiang, and we're about to work with 2 GSoC students,
Cl ment Schreiner and Orestis Ioannou.
I will present here the GitHub mirror we've set up, in order to allow
external pull requests to be submitted, and to use the continous
integration service provided by Travis-CI.
GitHub and Travis-CI
Debsources' source code is hosted on
Debian's git servers,
and from there is mirrored to
GitHub. Every time a commit is
pushed (to master or other branches) or a pull request is open, the
test suite will be automatically run on Travis-CI, and the result
(tests pass or don't) is displayed on GitHub. This allows us to
quickly filter external contributions (when they are submitted on
GitHub), and be sure everything works with our setup, before reviewing
work.
Travis-CI runs the tests on OpenVZ containers. The complete
infrastructure was a bit challenging to setup, but as we now have a
Docker recipe to quicly begin to hack on Debsources, most of the work
could be done using the Dockerfile instructions.
In average, a run on Travis-CI (which includes git cloning the code
and test data, setup the server, and run the tests suite) takes 7
minutes, which is an ok amount of time to wait for before submitting a
pull request, in my opinion.
Bugs discovered in the process
Setting up this continuous integration infrastructure made me discover
a few bugs.
Python magic does black magic
Debsources runs fine on Debian (not surprisingly), but I got tricked
by black magic when I tried to run it on Ubuntu (which is the OS run
in Travis-CI's containers).
We use the magic library to guess the type of files we're dealing
with, for instance when we need to decide between rendering a file
(for text files) or downloading it (for binary files).
Here comes the tricky part: the Python bindings for libmagic are not
the same in Debian and Pypi. Debsources uses Debian package
python-magic, which is not in Ubuntu 12.04. Moreover, there's no
Python egg for it on Pypi, which has however another package (called
magic) which provides a different API.
I solved this with a dirty hack, using the fact python-magic lies in a
single file:
It simply downloads the library, saves it in a temporary folder and
includes it in the Python path. Let's see for how long it works before
everything breaks!
Size of a directory
One test in the suite was ensuring the information returned by ls -l
on a directory and stored in the DB was the right information. Inode
metadata was tested, such as name, permissions, type, or size.
Interestingly enough, the size of a directory was tested, and expected
to be 4096 bytes. The size of a directory actually depends on the
filesystem in use, and on the number of files this directory
contains. We often see 4096 because it's the size of a not-too-big
directory on ext4.
Travis-CI doesn't use ext4:
Simfs is a container filesystem for OpenVZ, on which directories have
different sizes than on ext4:
$ ls -al /
total 0
drwxr-xr-x 23 root root 480 Feb 4 18:08 .
drwxr-xr-x 23 root root 480 Feb 4 18:08 ..
drwxr-xr-x 2 root root 2480 Feb 4 18:20 bin
drwxr-xr-x 2 root root 40 Apr 192012 boot
drwxr-xr-x 5 root root 660 Apr 30 13:56 dev
drwxr-xr-x 99 root root 3560 Apr 30 13:56 etc
-rw-r--r-- 1 root root 0 Feb 4 17:56 fastboot
drwxr-xr-x 3 root root 80 Feb 4 17:57 home
[...]
Directory sizes are not even powers of 2.
Hence I changed the test to not check directory sizes. Hopefully this
will help to make Debsources work on more filesystems!
An empty file is hiding
Last but not least, because this
bug is
still open in the wild. A file, which appears to be empty, is not
taken into account by Debsources' updater. This file is
sources/non-free/m/make-doc-non-dfsg/4.0-2/.pc/applied-patches. It
is present in the filesystem in the container, is not the only empty
file over there, but still doesn't appear in the database, and make
fail the test which counts files.
The test has been commented out (booooooh), so that we still can use
Travis-CI's platform for our GSoC students, before it's fixed.
Conclusion
Making Debsources run automatically on a different platform as the one
we usually use permitted us to spot bugs, write dirty hacks, and
expand the filesystems it's supposed to run on.
Now, let's hope the continuous integration will help our GSoC
students, and let's wish them good luck!
Debian Jessie has been released on April 25th, 2015. This has opened the
Stretch development cycle. Reactions to the idea of making Debian
build reproducibly have
been pretty enthusiastic. As the pace is now likely to be even faster,
let's see if we can keep everyone up-to-date on the developments.
Before the release of Jessie
The story goes back a long
way
but a formal announcement to the
project
has only been sent in February 2015.
Since then, too much work has happened to make a complete report, but
to give some highlights:
New variations are now tested: umask, kernel version, domain name,
and timezone. We might only be missing CPU type and current date now.
Number of identified issues has grown from about 80 to 123 today.
Lunar did a pretty improvised lightning
talk
during the Mini-DebConf in
Lyon.
This past week
It seems changes were pilling behind the curtains given the amount of activity
that happened in just one week.
Toolchain fixes
Niels Thykier uploaded
debhelper/9.20150501
which includes fixes to dh_makeshlibs
(#774100), dh_icons
(#774102), dh_usrlocal
(#775020). Patches written
by Lunar.
Helmut Grohne uploaded
doxygen/1.8.9.1-3 which
will not generate timestamps in HTML by default. Kudos to
akira for bringing the issue
upstream.
Kenneth J. Pronovici uploaded
epydoc/3.0.1+dfsg-6
adding a --no-include-build-time option.
Patch by Jelmer
Vernooij.
David Pr vot uploaded
php-apigen/2.8.1+dfsg-2
which now has reproducible output.
C dric Boutillier uploaded
ruby-prawn/2.0.1+dfsg-1
which now produce a deterministic output when using gradients.
Patch by Lunar.
Jelmer Vernooij uploaded
samba/2:4.1.17+dfsg-4 which
contains a patch by Matthieu Patou making the output of pidl
(from libparse-pidl-perl) reproducible.
Dmitry Shachnev uploaded
sphinx/1.3.1-1 in experimental
which should produce deterministic output. The original
patch from Chris Lamb has
inspired the upstream
fix.
Improvements to reproducible.debian.net
Mattia Rizzolo has been working on compressing logs using gzip to save
disk space. The web server would uncompress them on-the-fly for clients
which does not accept gzip content.
Mattia Rizzolo worked on a new page listing various
breakage: missing
or bad debbindiff output, missing build logs, unavailable build
dependencies.
Holger Levsen added a new execution environment to run debbindiff using
dependencies from testing. This is required for packages built with
GHC as the compiler only understands interfaces built by the same
version.
debbindiff development
Version 17 has been uploaded to unstable. It now supports comparing
ISO9660 images, dictzip files and should compare identical files much
faster.
Documentation update
Various small updates and fixes to the pages about
PDF produced by LaTeX,
DVI produced by
LaTeX,
static
libraries,
Javadoc,
PE
binaries,
and Epydoc.
Package reviews
Known issues have been tagged when known to be deterministic as some
might unfortunately not show up on every single build.
For example, two new issues have been identified by building with one
timezone in April and one in May. RD
and help2man add current month and
year to the documentation they are producing.
1162 packages have been removed and 774 have been added in
the past week. Most of them are the work of proper automated
investigation done by Chris West.
Summer of code
Finally, we learned that both akira and Dhole were accepted for
this Google Summer of
Code.
Let's welcome them!
They have until May 25th before coding officialy begins. Now is the good time
to help them feel more comfortable by sharing all these little bits of
knowledge on how Debian works.
In the middle of OPW internship
I originally thought taking part in FOSSOPW is a great chance to lift my coding skills and I shouldn t miss it. As time passes by, I now have a new thought towards it.
# 1 It do improves your coding skill.
Zack, Matthieu and I often have discussions on coding style. For example, once Zack said, For code like this, you should explicitly use an if/else clause, not if-return. I was totally unaware of this sort of issue. Actually I even didn t know how I should call this problem. Matthieu gave me a detailed FYI link on this in no time.
Besides, my completeness of thinking is also trained. Recently, I was fixing a HTTP GET Method ?suite=suite-name issue. It s a trivial task. And you know most trivial tasks require lots of scattered modification on the source code base. I did have fixed most places, such as the pages of /src/packagename and /search/ . Zack did a thorough review, and pointed out that the pages rendered by /prefix has some malformed urls in the HTML. Waiiiit, I should have noticed it. But somehow I missed it. Maybe because my mind was wandering at that time? This made me think, I shall have a thorough view of what I should do before getting my hands dirty. Or more preferably, if I could write down what I exactly want to achieve before coding, then silly problems definitely wouldn t occur. This may sound a little bit like TDD. ;).
# 2 It makes you look like a (not-that-good) ninja.
I use a macbook. It s not my fault! I ve tried several times, but I never successfully find a laptop that is not capable of boiling eggs when running Debian. (and especially KDE+Debian). So I have no way but switched to OSX. The development of Debsources happens on a remote Ubuntu LTS (now Debian SID, haha) virtual machine. Of course I have to install all the dependency on my own, e.g., Postgres, set up port-forwarding, e.g., ssh -D, write automate shell scripts, e.g., dash, but more importantly, I am forced to live under the dark terminal with no GUI. You know the feeling when pain hurts? Yes, exactly! But I survived. How shall I call myself now? A dedicated with-a-lot-of-useless-plugin-installed vimmer? A fond-of-fancy-window tmux-er? Yep, both. I finally found a comfort zone under the black-white-blinking screen. I wonder how people feel when they see a girl hanging out in the library, facing a full-screened black console, typing at a speed of 140wpm (Yeah, I am kidding). I don t know, but please don t call me a geek. Show me your respect, I am a ninja!
# 3 It tells you communication is the most important.
I bet anyone who has participated in a group-based project would understand what I mean. For one perspective, communication helps to eliminate misunderstanding. So I won t doing some useless stuff for all day and finally find out that it totally doesn t meet the requirement. On the other hand, it speeds up your learning process. I often have problems on git. So in the email I will complain if I mess up with the git repo. After a short while, my dear mentors will reply in detail on how to correctly do the git stuff.
My OPW journey is cool! ;).
The Tropy
In this period, I have tackled several bugs and got them finally about to be merged in the codebase. Namely, they are:
#761121 allow symbolic links within same version, #761861 override detected language type. I also spent some time on making debsouces runnable on sor.debian.org.
But still there is some db related problem on it. I am not quite familiar with psql, and kinda at a loss as what to do. Zack said he would take it over and I shall focus on what really I likes. Cool.
For some non-code tasks, I have a detailed read on machine-readable debian/copyright . The other task is on flask blueprint . The idea of flask blueprint , as far as I am concerned, is sort of what apps are in django.
Zack has drafted a specification on debian/copyright which serves as the goal of copyright.debian.net. Combined with the above reading knowledge, and with the help of Flask expert matthieu, I will get my hands dirty in the comming weeks to create a fantastic new site, aka, copyright.d.n. Stay tuned.
some thought
I did spend some time learning how to use git, and read quite a lot of materials. But, I shamely forgot most of them. So when I am frequently using git these days, I feel kinda incompetent and sometimes awkward. I am thinking now, maybe I shall stop overlearn some technology that I might never use. Only real usage and practice could help me get comfort with those tools. Overlearn something which I am not currently using and either won t in the future might just be a waste of time.
and finally, I spent a great Christmas. Wish everyone happy, and merry Christmas!
Down the rabbit hole
Starting from this week, my OPW period officially begins.
I am thankful and very grateful to this chance. One for the reason I can get an opportunity to contribute to a beneficial, working, meaningful, real-world software. The other seemingly reason is, I can learn much experience and design philosophy from my mentors zack and matthieu. :)
This week my fix is on, bug #763921. It s basically making the folder page rendering providing more information, specifically the ls -l format. This offers information such as filetype, permission, size, etc.
I learned some new knowledge about man 2 stat , and also got more familiar(actually confident) with front end stuff, namely css.
I also get myself familiar with the python test (coverage). Next week, I will try to increase the test coverage a bit. Tests is an essential part of software. It ensures the correctness and robustness. And more importantly, by making tests, we can easily debug the software. The so called,
The trello cards of next week is interesting. (in case you dunno the site, it s here:http://trello.com
Let s see it.
Jingjie Jiang selected as OPW intern for Debsources
I'm glad to announce that Jingjie Jiang, AKA sophiejjj,
has been selected as intern to work on Debsources as part of the FOSS Outreach Program (formerly known
as Outreach Program for Women, or OPW). I'll co-mentor her work
together with Matthieu
Caneill.
I've just added sophiejjj's blog to Planet
Debian, so you will soon hear about her work in the Debian
blogosphere.
I've been impressed by the interest that the
Debsources proposal in this round of OPW has spawned. Together
with Matthieu I have interacted with more than a dozen OPW
applicants. Many of them have contributed useful patches during the
application period, and those patches have been in production at
http://sources.debian.net
since quite a while now (see the commit log for details). A special
mention goes to Akshita Jha, who has shown a lot of determination
in tackling both simple and complex issues affecting Debsources. I
hope there will be other chances to work with her in the
future.
OPW internship will begin December 9th, fasten your seat belts
for a boost in Debsources development!