Rumors are running that python2 is not a thing anymore.<\/p>\n\n
Well, I'm certainly late to the party, but I'm happy to report that\nsources.debian.org<\/a> is now running python3.<\/p>\n\n\n\n Back when development started, python3 was very much a real language, but it was\nhard to adopt because it was not supported by many libraries. So python2 was\nchosen, meaning And things were working just fine. One day python2 EOL was announced, with a\ndate far in the future. Far enough to procrastinate for a long time. Combine\nthis with a codebase that is stable enough to not see many commits, and the fact\nthat Debsources is a volunteer-based project that happens at best on week-ends,\nand you end up with a dormant software and a missed deadline.<\/p>\n\n But, as dormant as the codebase is, the instance hosted at\nsources.debian.org<\/a> is very popular and gets 200k\nto 500k hits per day. Largely enough to be worth a proper maintenance and a\ntransition to python3.<\/p>\n\n While transitioning to python3 and juggling left and right with Quick recap if you're unfamiliar with this tool: Debsources displays the content\nof the source packages in the Debian archive. In other words, it's a bit like\nGitHub, but for the Debian source code.<\/p>\n\n And some pieces of software out there, that ended up in Debian packages, happen\nto contain files whose names can't be decoded to UTF-8. Interestingly enough,\nthere's no such thing as a standard for file names: with a few exceptions that\nvary by operating system, any sequence of bytes can be a legit file name. And\nsome sequences of bytes are not valid UTF-8.<\/p>\n\n Of course those files are rare, and using ASCII characters to name a file is a\nmuch more common practice than using bytes in a non-UTF-8 character\nencoding. But when you deal with almost 100 million files on which you have no\ncontrol (those files come from free software projects, and make their way into\nDebian without any renaming), it happens.<\/p>\n\n Now back to the bug: when trying to display such a file through the web\ninterface, it would crash because it can't convert the file name to UTF-8, which\nis needed for the HTML representation of the page.<\/p>\n\n An often valid approach when trying to represent invalid UTF-8 content is to\nignore errors, and replace them with Unfortunately, this best-effort approach is not suitable for file names, as file\nnames are also identifiers<\/em> in Debsources: among other places, they are part of\nURLs. If an URL were to use placeholder characters to replace those bytes, there\nwould be no deterministic way to match it with a file on disk anymore.<\/p>\n\n The representation of binary data into text is a known problem. Multiple\nlossless solutions exist, such as base64 and its variants, but URLs looking like\n The solution I chose is to use double-percent encoding<\/a>: this allows the representation of any byte in an\nURL, while keeping allowed characters unchanged - and preventing CGI gateways\nfrom trying to decode non-UTF-8 bytes. This is the best of both worlds: regular\nfile names get to appear normally and are human-readable, and funky file names\nonly have percent signs and hex numbers where needed.<\/p>\n\n Here is an example of such an URL:\nhttps:\/\/sources.debian.org\/src\/aspell-is\/0.51-0-4\/%25EDslenska.alias\/<\/a>. Notice\nthe Transitioning to this was quite a challenge, as those file names don't only\nappear in URLs, but also in web pages themselves, log files, database tables,\netc. And everything was done with I was wondering too. Let's list them!<\/p>\n\n Running this on the Debsources main instance, which hosts pretty much all Debian\npackages that were part of a Debian release, I could find 307 files (among a\ntotal of almost 100 million files).<\/p>\n\n Without looking deep into them, they seem to fall into 2 categories:<\/p>\n\n That last point hits home, as it was clearly lacking in Debsources. A funky file\nname is now part of its test suite. ;)<\/p>\n","pubDate":"Mon, 24 Jan 2022 00:00:00 +0100","link":"https:\/\/matthieu.io\/blog\/2022\/01\/24\/debsources-python3-funky-file-names\/","guid":"https:\/\/matthieu.io\/blog\/2022\/01\/24\/debsources-python3-funky-file-names\/"},{"title":"MiniDebconf in Toulouse","description":" I attended the MiniDebconf in Toulouse, which was hosted in the larger\nCapitole du Libre, a free software event with talks, presentation of\nassociations, and a keysigning party. I didn't expect the event to be\nthat big, and I was very impressed by its organization. Cheers to all\nthe volunteers, it has been an amazing week-end!<\/p>\n\n Here's a sum-up of the talks I attended.<\/p>\n\n Speaker<\/strong>: \u00c9lo\u00efs<\/p>\n\n The first talk I attended was, translated to English, \"from free\nsoftware to free money\".<\/p>\n\n \u00c9lo\u00efs compared the 4 freedoms of free software with money, and what\nproperties money needs to exhibit in order to be considered free. He\nthen introduced \u011e1, a project of free (as in free speech!) money,\nstarted in the region around Toulouse. Contrary to some distributed\nledgers such as Bitcoin, \u011e1 isn't based on an hash-based\nproof-of-work, but rather around a web of trust of people certifying\neach other, hence limiting the energy consumption required by the\nnetwork to function.<\/p>\n\n Speaker<\/strong>: Jimmy Monin<\/p>\n\n I then attended a presentation of YunoHost. Being an happy user\nmyself, it was very nice to discover the future expected features, and\nalso meet two of the developers. YunoHost is a Debian-based project,\naimed at providing all the tools necessary to self-host applications,\nincluding email, website, calendar, development tools, and dozens of\nother packages.<\/p>\n\n Speaker<\/strong>: Nicolas Dandrimont<\/p>\n\n For the first talk of the MiniDebConf, Nicolas Dandrimont introduced\nDebian, its philosophy, and how it works with regards to upstreams and\ndownstreams. He gave many details on the teams, the infrastructure,\nand the internals of Debian.<\/p>\n\n Speaker<\/strong>: Jonas Smedegaard<\/p>\n\n Jonas introduced some security concepts, and how they are abused and\noften meaningless (to quote his own words, \"secure is bullshit\"). He\ndescribed a few projects which lean towards a more secure and open\nhardware, for both phones and laptops.<\/p>\n\n Speaker<\/strong>: J\u00e9r\u00e9my Lecour<\/p>\n\n J\u00e9r\u00e9my, from Evolix, introduced Ansible, and how they use it to manage\nhundreds of Debian servers. Ansible is a very powerful tool, and a\nhuge ecosystem, in many ways similar to Puppet or Chef, except it is\nagent-less, using only ssh connections to communicate with remote\nmachines. Very nice to compare their use of Ansible with mine, since\nthat's the software I use at work for deploying experiments.<\/p>\n\n Speaker<\/strong>: Samuel Thibault<\/p>\n\n Samuel gave a talk about accessibility, and the general availability\nof the tools in today's operating systems, including Debian. The\nlesson to take home is that we often don't do enough in this domain,\nparticularly when considering some issues people might have that we\ndon't always think about. Accessibility on computers (and elsewhere)\nshould be the default, and never require complex setups.<\/p>\n\n Speaker<\/strong>: Cyril Brulebois<\/p>\n\n Cyril described a problem he was hired for, an update of thousands of\nDebian servers from wheezy to jessie, which he discovered afterwards\nwas worse than initially thought, since the machines were running the\nout-of-date squeeze. Since they were not always administered with the\nbest sysadmin practices, they were all exhibiting different\nconfigurations and different packages lists, which raised many issues\nand gave him interesting challenges. They were solved using Ansible,\nwhich also had the effect of standardizing their system administration\npractices.<\/p>\n\n Speaker<\/strong>: Gr\u00e9gory Colpart<\/p>\n\n Gr\u00e9gory described Evolix, a company which manages servers for their\nclients, and how they were inspired by Debian, for both their internal\ntools and their practices. It is very interesting to see that some of\nthe Debian values can be easily exported for a more open and\ncollaborative business.<\/p>\n\n To close the conference, two lightning talks were presented,\ndescribing the switch from Windows XP to Debian in an ecologic\nassociation near Toulouse; and how snapshot.debian.org can be used\nwith bisections to find the source of some regressions.<\/p>\n\n A big thank you to all the organizers and the associations who\ncontributed to make this event a success. Cheers!<\/p>\n","pubDate":"Sun, 19 Nov 2017 00:00:00 +0100","link":"https:\/\/matthieu.io\/blog\/2017\/11\/19\/minidebconf-toulouse\/","guid":"https:\/\/matthieu.io\/blog\/2017\/11\/19\/minidebconf-toulouse\/"},{"title":"Debugging 101","description":" While teaching this semester a class on concurrent programming, I\nrealized during the labs that most of the students couldn't properly\ndebug<\/em> their code. They are at the end of a 2-year cursus, know many\ndifferent programming languages and frameworks, but when it comes to\ntracking down a bug in their own code, they often lacked the\nbasics. Instead of debugging for them I tried to give them general\ndirections that they could apply for the next bugs. I will try here to\nsummarize the very first basic things to know about\ndebugging. Because, remember, writing software is 90% debugging, and\n10% introducing new bugs (that is not from me, but I could not find\nthe original quote).<\/p>\n\n So here is my take at Debugging 101<\/em>.<\/p>\n\n Many good tools exist to assist you in writing correct software, and\nit would put you behind in terms of productivity not to use\nthem. Editors which catch syntax errors while you write them, for\nexample, will help you a lot. And there are many features out there in\neditors, compilers, debuggers, which will prevent you from introducing\ntrivial bugs. Your editor should be your friend; explore its features\nand customization options, and find an efficient workflow with them,\nthat you like and can improve over time. The best way to fix bugs is\nnot to have them in the first place, obviously.<\/p>\n\n I've seen students writing code for one hour before running I recommend to test your code (compilation and<\/em> execution) every few\nlines of code you write. When something breaks, chances are it will\ncome from the last line(s) you wrote. Compiler errors will be shorter,\nand will point you to the same place in the code. Once you get more\nconfident using a particular language or framework, you can write\nmore lines at once without testing. That's a slow process, but it's\nok. If you set up the right keybinding for compiling and executing\nfrom within your editor, it shouldn't be painful to test early and\noften.<\/p>\n\n Spot the places where your program\/compiler\/debugger writes text, and\nread it carefully. It can be your terminal (quite often), a file in\nyour current directory, a file in You may have to filter out a lot of garbage to find relevant\ninformation about your bug. Learn to spot some keywords like That one doesn't concern compilation errors (unless it's a When the program logs and output failed to give you where an error\noccured (oh hi In the example above, you can be sure it is the connection to the\ndatabase (That is an hypothetical example. If you know something can break,\nsuch as a database connection, then you should always enclose it in a\n This point is linked to the previous one. You may or may not have\nisolated the line(s) causing the bug, but maybe the issue is not\nalways raised. It can depend on many other things: the program or\nfunction parameters, the network status, the amount of memory\navailable, the decisions of the OS scheduler, the user rights on the\nsystem or on some files, etc. More generally, any assumption you made\non any external dependency can appear to be wrong (even if it's right\n99% of the time). According to the context, try to isolate the set of\nconditions that trigger the bug. It can be as simple as \"when there is\nno internet connection\", or as complicated as \"when the CPU load of\nsome external machine is too high, it's a leap year, and the input\ncontains illegal utf-8 characters\" (ok, that one is a lot, but it\nsurely happens!). But you need to reliably be able to reproduce the\nbug, in order to be sure later that you indeed fixed it.<\/p>\n\n Of course when the bug is triggered at every run, it can be\nfrustrating that your program never works but it will in general be\neasier to fix.<\/p>\n\n Always read the documentation before reaching out for help. Be it\n You'll rapidly find yourself getting used to the way documentation is\norganized, and you'll be more and more efficient at finding instantly\nwhat you need. Always keep the doc window open!<\/p>\n\n Let's be honest: many of the bugs you'll encounter have been\nencountered before. Learn to write efficient queries on search\nengines, and use the knowledge you can find on questions&answers\nforums like Stack Overflow. Read the answers and comments. Be wise\nthough, and never blindly copy and\npaste<\/a>\ncode from there. It can be as bad as introducing malicious security\nissues into your code, and you won't learn anything. Oh, and don't\ncopy and paste anyway. You have to be sure you understand every single\nline, so better write them by hand; it's also better for memorizing\nthe issue.<\/p>\n\n Once you have identified and solved a particular bug, I advise to\nwrite about it. No need for shiny interfaces: keep a list of your bugs\nalong with their solutions in one or many text files, organized by\nlanguage or framework, that you can easily It can seem slightly cumbersome to do so, but it proved (at least to\nme) to be very valuable. I can often recall I have encountered some\nbuggy situation in the past, but don't always remember the\nsolution. Instead of losing all the debugging time again, I search in\nmy bug\/solution list first, and when it's a hit I'm more than happy I\nkept it.<\/p>\n\n Rubber duck debugging<\/a>\nencourages you to explain your problem loudly, for example to a rubber\nduck sitting on your desk. Using plain words to describe a problem\nwill force you to think about it clearly, and you'll be amazed how\nfast it might lead you to identifying the root cause of your bug,\nbecause you'll realize there's a problem somewhere you couldn't think\nabout if you didn't start from the beginning.<\/p>\n\n Remember this was only Debugging 101<\/em>, that is, the very first steps\non how to debug code on your own, instead of getting frustrated and\nhelplessly stare at your screen without knowing where to begin. When\nyou'll write more software, you'll get used to more efficient\nworkflows, and you'll discover tools that are here to assist you in\nwriting bug-free code and spotting complex bugs efficiently. Listed\nbelow are some<\/em> of the tools or general ideas used to debug more\ncomplex software. They belong more to a software engineering course\nthan a Debugging 101 blog post. But it's good to know as soon as\npossible these exist, and if you read the manuals there's no reason\nyou can't rock with them!<\/p>\n\n Loggers<\/em>. To make the \"foobar\" debugging more efficient, some\nlibraries are especially designed for the task of logging out\ninformation about a running program. They often have way more\nfeatures than a simple Version control<\/em>. Following the evolution of a program in time,\nover multiple versions, contributors and forks, is a hard\ntask. That's where version control plays: it allows you to keep the\nentire history of your program, and switch to any previous\nversion. This way you can identify more easily when a bug was\nintroduced (and by whom), along with the patch (a set of changes to\na code base) that introduced it. Then you know where to apply your\nfix. Famous version control tools include Git, Subversion, and\nMercurial.<\/p>\n <\/li>\n Debuggers<\/em>. Last but not least, it wouldn't make sense to talk\nabout debugging without mentioning debuggers. They are tools to\ninspect the state of a program (for example the type and value of\nvariables) while it is running. You can pause the program, and\nexecute it line by line, while watching the state evolve. Sometimes\nyou can also manually change the value of variables to see what\nhappens. Even though some of them are hard to use, they are very\nvaluable tools, totally worth diving into!<\/p>\n <\/li>\n<\/ul>\n\n Don't hesitate to comment on this, and provide your debugging 101\ntips! I'll be happy to update the article with valuable feedback.<\/p>\n\n Happy debugging!<\/p>\n","pubDate":"Sun, 23 Oct 2016 00:00:00 +0200","link":"https:\/\/matthieu.io\/blog\/2016\/10\/23\/debugging-101\/","guid":"https:\/\/matthieu.io\/blog\/2016\/10\/23\/debugging-101\/"},{"title":"A one-liner to catch'em all!","description":" I wrote a Bash one-liner to open the source code (in\nDebsources<\/a>) of any file on your system\n(if it belongs to a Debian package).<\/p>\n\n It will simply retrieve the associated package and point your default\nbrowser to its source code.<\/p>\n\n Add this somewhere in your $PATH, and name this file And try something like Update: improved the one-liner thanks to josch's advice.<\/p>\n","pubDate":"Sun, 16 Aug 2015 00:00:00 +0200","link":"https:\/\/matthieu.io\/blog\/2015\/08\/16\/one-liner-to-catch-em-all\/","guid":"https:\/\/matthieu.io\/blog\/2015\/08\/16\/one-liner-to-catch-em-all\/"},{"title":"Debsources got swag and continuous integration","description":" Debsources (http:\/\/sources.debian.net<\/a>) is still under\nactive development. We recently had a Gnome Outreachy intern, Jingjie Jiang, and we're\nabout to work with 2 GSoC students, Cl\u00e9ment Schreiner and Orestis Ioannou.<\/p>\n\n I will present here the GitHub mirror we've set up, in order to allow external pull\nrequests to be submitted, and to use the continous integration service provided by\nTravis-CI.<\/p>\n\n Debsources' source code is hosted on\nDebian's git servers<\/a>, and from\nthere is mirrored to GitHub<\/a>. Every time a commit\nis pushed (to master<\/em> or other branches) or a pull request is open, the test suite will\nbe automatically run on Travis-CI, and the result (tests pass or don't) is displayed on\nGitHub. This allows us to quickly filter external contributions (when they are submitted\non GitHub), and be sure everything works with our setup, before reviewing work.<\/p>\n\n Travis-CI runs the tests on OpenVZ containers. The complete infrastructure was a bit\nchallenging to setup, but as we now have a Docker recipe to quicly begin to hack on\nDebsources, most of the work could be done using the Dockerfile<\/em> instructions.<\/p>\n\n In average, a run on Travis-CI (which includes git cloning the code and test data, setup\nthe server, and run the tests suite) takes 7 minutes, which is an ok amount of time to\nwait for before submitting a pull request, in my opinion.<\/p>\n\n Setting up this continuous integration infrastructure made me discover a few bugs.<\/p>\n\n Debsources runs fine on Debian (not surprisingly), but I got tricked by black magic when\nI tried to run it on Ubuntu (which is the OS run in Travis-CI's containers).<\/p>\n\n We use the magic<\/em> library to guess the type of files we're dealing with, for instance\nwhen we need to decide between rendering a file (for text files) or downloading it (for\nbinary files).<\/p>\n\n Here comes the tricky part: the Python bindings for libmagic are not the same in Debian\nand Pypi. Debsources uses Debian package python-magic<\/em>, which is not in Ubuntu 12.04.\nMoreover, there's no Python egg for it on Pypi, which has however another package\n(called magic<\/em>) which provides a different API.<\/p>\n\n I solved this with a dirty hack, using the fact python-magic lies in a single file:<\/p>\n\nWait, it wasn't?<\/h2>\n\n
print<\/code>-based debugging was used in lieu of print()<\/code>-based\ndebugging, and str<\/code> were bytes<\/code>, not unicode<\/code>.<\/p>\n\nFunky file names<\/h2>\n\n
str<\/code>, bytes<\/code>\nand unicode<\/code> for internal objects, files, database entries and HTTP content, I\nstumbled upon a bug that has been there since day 1.<\/p>\n\nBugfix<\/h2>\n\n
?<\/code> or \ufffd<\/code>. This is what Debsources\nactually does to display non-UTF-8 file content<\/em>.<\/p>\n\nhttps:\/\/sources.debian.org\/src\/Y293c2F5LzMuMDMtOS4yL2Nvd3NheS8=<\/code> are not\nreadable at all compared to\nhttps:\/\/sources.debian.org\/src\/cowsay\/3.03-9.2\/cowsay\/<\/code>. Plus, not\nbackwards-compatible with all existing links.<\/p>\n\n%25ED<\/code> to represent the percentage symbol itself (%25<\/code>) followed by an\ninvalid UTF-8 byte (%ED<\/code>).<\/p>\n\nstr<\/code>: made sense in python2 when str<\/code> were\nbytes<\/code>, but not much in python3.<\/p>\n\nWhat are those files? What's their network?<\/h2>\n\n
import<\/span> os<\/span>\n\nwith<\/span> open<\/span>(<\/span>'non-utf-8-paths.bin'<\/span>,<\/span> 'wb'<\/span>)<\/span> as<\/span> f<\/span>:<\/span>\n for<\/span> root<\/span>,<\/span> folders<\/span>,<\/span> files<\/span> in<\/span> os<\/span>.<\/span>walk<\/span>(<\/span>b<\/span>'\/srv\/sources.debian.org\/sources\/'<\/span>):<\/span>\n for<\/span> path<\/span> in<\/span> folders<\/span> +<\/span> files<\/span>:<\/span>\n try<\/span>:<\/span>\n path<\/span>.<\/span>decode<\/span>(<\/span>'utf-8'<\/span>)<\/span>\n except<\/span> UnicodeDecodeError<\/span>:<\/span>\n f<\/span>.<\/span>write<\/span>(<\/span>root<\/span> +<\/span> b<\/span>'\/'<\/span> +<\/span> path<\/span> +<\/span> b<\/span>'<\/span>\\n<\/span>'<\/span>)<\/span>\n<\/code><\/pre><\/div><\/div>\n\n\n
Du logiciel libre \u00e0 la monnaie libre<\/h2>\n\n
YunoHost<\/h2>\n\n
Premiers pas dans l'univers de Debian<\/h2>\n\n
Trusting your computer and system<\/h2>\n\n
Automatiser la gestion de configuration de Debian avec Ansible<\/h2>\n\n
Making Debian for everybody<\/h2>\n\n
Retour d'exp\u00e9rience : mise \u00e0 jour de milliers de terminaux Debian<\/h2>\n\n
Retour d'exp\u00e9rience : utilisation de Debian chez Evolix<\/h2>\n\n
Lightning talks<\/h2>\n\n
Conclusion<\/h2>\n\n
Use the right tools<\/h2>\n\n
Test early, test often<\/h2>\n\n
make<\/code>,\nthat would fail so hard that hundreds of lines of errors and warnings\nwere outputted. There are two main reasons doing this is a bad idea:<\/p>\n\n\n
Read the logs<\/h2>\n\n
\/var\/log\/<\/code>, a web page on a local\nserver, anything. Learn where different software write logs on your\nsystem, and integrate reading them in your workflow. Often, it will be\nyour only information about the bug. Often, it will tell you where the\nbug lies. Sometimes, it will even give you hints on how to fix it.<\/p>\n\nerror<\/code>\nor warning<\/code>. In long stacktraces, spot the lines concerning your\nfiles; because more often, your code is to be blamed, rather than\ndeeper library code. grep<\/code> the logs with relevant keywords. If you\nhave the option, colorize the output. Use tail -f<\/code> to follow a file\ngetting updated. There are so many ways to grasp logs, so find what\nworks best with you and never forget to use it!<\/p>\n\nPrint foobar<\/h2>\n\n
Makefile<\/code>\nerror, in that case this file is your code anyway).<\/p>\n\nSegmentation fault<\/code>!), and before having to dive into\na memory debugger or system trace tool, spot the portion of your\nprogram that causes the bug and add in there some print<\/code>\nstatements. You can either print(\"foo\")<\/code> and print(\"bar\")<\/code>, just to\nknow that your program reaches or not a certain place in your code, or\nprint(some_faulty_var)<\/code> to get more insights on your program\nstate. It will give you precious information.<\/p>\n\nstderr<\/span> >><\/span> \"foo\"<\/span> >><\/span> endl<\/span>;<\/span>\nmy_db<\/span>.<\/span>connect<\/span>();<\/span> \/\/ is this broken?<\/span>\nstderr<\/span> >><\/span> \"bar\"<\/span> >><\/span> endl<\/span>;<\/span>\n<\/code><\/pre><\/div><\/div>\n\nmy_db<\/code> that is broken if you get foo<\/code> and not bar<\/code> on your\nstandard error.<\/p>\n\ntry<\/code>\/catch<\/code> structure).<\/p>\n\nIsolate and reproduce the bug<\/h2>\n\n
RTFM<\/h2>\n\n
man<\/code>, a book, a website or a wiki, you will find precious information\nthere to assist you in using a language or a specific library. It can\nbe quite intimidating at first, but it's often organized the same\nway. You're likely to find a search tool, an API reference, a\ntutorial, and many examples. Compare your code against them. Check in\nthe FAQ, maybe your bug and its solution are already referenced there.<\/p>\n\nGoogle and Stack Overflow are your friends<\/h2>\n\n
Take notes<\/h2>\n\n
grep<\/code>.<\/p>\n\nReach out for help (from your duck)<\/h2>\n\n
Further debugging<\/h2>\n\n
\n
print<\/code> statement (at the price of being\nover-engineered for simple programs): severity levels (info<\/code>,\nwarning<\/code>, error<\/code>, fatal<\/code>, etc), output in rotating files, and\nmany more.<\/p>\n <\/li>\n debsrc<\/code>:<\/p>\n\n#!\/bin\/bash<\/span>\n\nfunction <\/span>debsrc {<\/span>\n readlink<\/span> -f<\/span> $1<\/span> | xargs dpkg-query --search<\/span> | cut<\/span> -d<\/span>: -f1<\/span> | xargs apt-cache showsrc | head<\/span> -n<\/span> 1 | grep-dctrl -s<\/span> 'Package'<\/span> -n<\/span> ''<\/span> | awk<\/span> -F<\/span> \" \"<\/span> '{print \"http:\/\/sources.debian.net\/src\/\"$1\"\/latest\/\"}'<\/span> | xargs x-www-browser\n}<\/span>\n\nCMD<\/span>=<\/span>\"<\/span>$1<\/span>\"<\/span>\ndebsrc ${<\/span>CMD<\/span>}<\/span>\n<\/code><\/pre><\/div><\/div>\n\ndebsrc \/usr\/share\/doc\/acpi\/AUTHORS<\/code>. Enjoy!<\/p>\n\nGitHub and Travis-CI<\/h2>\n\n
Bugs discovered in the process<\/h2>\n\n
Python magic does black magic<\/h3>\n\n
mkdir<\/span> \/tmp\/python-magic &&<\/span> wget https:\/\/raw.githubusercontent.com\/file\/file\/master\/python\/magic.py -O<\/span> \/tmp\/python-magic\/magic.py &&<\/span>