fidzu : Debian

I've written a lot about my various home automation bits, but I haven't generally posted pictures. That's because my construction skills aren't great; I'm wiring together modules and that tends to make it harder to case things properly and make them look nice. My first attempt to be better about this was to buy a prototyping box which had a case + board paired with it I could attach modules to. This helped a bit, but still involved a mess set of wiring to attach things together (proper strip board would have been more useful than just copper pads).

I then started to notice I was getting JLCPCB ads while web browsing, offering 10 PCBs for $2. That seemed like a good deal, and I thought if I did things right I could find the right case and then make sure the PCB fitted in it. I found a small vented white case available from CPC. This allows me to put a temperature sensor inside for some devices. KiCad seemed like a good option for trying to design my basic schematic and lay it out, so I installed it and set to work trying to figure out what I wanted to put on the board, and how to actually drive KiCad.

As the core I chose an ESP-07 ESP8266 module. I've used a few of them before and they're cheap and convenient. I added an LDO voltage regulator (LD1117) so I could use a 5V PSU (and I'm hoping with a heatsink I can get away with a 12V supply as well, even if it's more inefficient). That gave enough to get a basic schematic once I'd added the necessary pull-up/down resistors for the ESP8266 and decoupling capacitors. I included a DC barrel jack for the PSU, and pin headers for the serial port, SPI pins and GPIO0 for boot selection. One of my use cases is to make an LED strip controller, so I threw in a screw terminal block for power + control - the board is laid out to allow a MOSFET for a simple white 12V LED strip, or the same GPIO taken straight to the terminal block for controlling a WS2812 strip. By including a couple of extra pull-up resistors I added the option of I2C for further expansion.

After I had the basic schematic I moved to layout. Luckily Hammond provide 2D CAD files for the case, so I figured I would import them into KiCad's PCB layout tool to make sure things would fit. That took a little bit of effort to go from DWG to DXF and trim it down (I found a web tool to do the initial conversion and then had to strip out the bits of the case that weren't related to the PCB size + mounting points). I wasn't confident enough that the edge cuts layer would include the mounting holes, so I manually placed some from KiCad over the right spots.

At this point I was glad I had a simple design, because it took me a while to decide how to place things and then route the tracks. I ended up altering some header pin assignments from the original design to make things a bit easier to route, and took advantage of the double sided board to put some components underneath, to ease both routing and space constraints. Originally I had planned to make things easy and go for through-hole components (I've never SMD soldered before) but in the interests of making use of space I risked the "1206 Handsoldered" footprint option in KiCad, which seems to be like the Duplo of SMD components. I kept my regulator as through-hole to make a larger heatsink easier. I also discovered I had a bit of spare space, so I put down a footprint and pin headers for a PCF8574 I2C GPIO expander to allow for more IO if I needed it. Finally the I2C pin header was laid out to allow a BME280 module to be soldered directly on top, allowing for easy addition of environmental monitoring without having to solder ridiculously small devices myself.

Once I had all of that done I printed out my final design, carefully cut around the edge and made sure it fitted into the case and the components I already had where the right size. Once I was fairly confident I'd checked as much as I could I then did a Gerber export and uploaded to JLCPCB. The process was very smooth - you upload a zip file, can do a sanity check viewing of how they've parsed it, select various options for the PCB (I left almost everything as the default) and then submit the order. Over the next couple of days you can see things progress through the various manufacturing stages and then get dispatched. For the first order it turns out you get free DHL Express delivery, so I ordered on Friday morning and had 10 boards by Wednesday afternoon. All for £1.58. A friend tells me subsequent orders have standard China Post shipping as standard, but for that price it's still hard to beat!

How did they turn out? Pretty well. The quality of the boards is excellent to my untrained eye. Soldering the SMD bits got easier when I switched to a better bit on my soldering iron and made sure it was well screwed in (otherwise it, er, doesn't heat up particularly reliably) - my soldering is still terrible, but it gets the job done. Most importantly the PCB fit the case footprint perfectly - mounting holes in the right place, edge cuts the right shape/size. A couple of snips to the vents and the barrel jack connector and terminal block are easily accessible, and it still looks fairly neat. The main mistake I made was not thinking about component heights! In particular the barrel jack was a couple of mm too high, which a quick shave with a Dremel sorted. The voltage regulator also stood far too high, which I fixed by bending at a 90° angle over the board. This will limit my options for a heatsink, but for 5V power this isn't necessary anyway.

So far I've assembled 2 boards, both controlling WS2812 LED strips and powered by 5V PSUs. One also has a BME280 added. I'm waiting on more parts arriving and then will try out a 12V / white LED strip combo. I'm really pleased with the overall results; it took a while playing with KiCad to get to the point I was confident to send my files off to be manufactured (the print outs helped a lot), and failing to think about component heights was a silly mistake, but having everything mounted on a single PCB and firmly screwed into a case makes for a much more robust project. The first 2 are both hidden out of the way, but it's reassuring to know they're not particularly fragile like some of my earlier constructions. And I'm already trying to work out what PCB I want to make next…

23 Apr 2019 7:52pm GMT

Here's a tip for mobile Twitter users who are frustrated with either shortcomings of the Twitter app, or the invasive nature of social media apps in general: delete the app, and just use the mobile web view.

I've been doing this for a while now, and the experience is much better for me. With the app, I regularly had my current view of either a timeline or a specific tweet interrupted or lost when the app decided to refresh. With the web view, I have my browser's history and back/forward buttons, and the ability to bookmark specific tweet URIs if I so wish.

I can open multiple windows with different tweets in them, if I want to keep a few around as reminders for something or other. I can switch between multiple tweets; or tweets, the timeline and something completely different, and not lose my views. I can follow a link from a tweet and not be bounced to a different app (or worse: an app-specific, built-in browser with none of my browser settings or sessions, a fresh round of hell clicking on the Cookie and Privacy Choices pop-ups), and clicking "Back" from such articles brings me back to where I came from.

But most importantly, if I get sick and tired of Twitter at any given moment, I can just close that browser tab. I don't have an omni-present Twitter icon on my phone calling me to click on it. It's just a website, like many others, that I can choose to visit, or not, whenever I want. The Twitter web experience is certainly less polished than the app one, but ultimately I feel like I'm in control of it, rather than the other way around.

23 Apr 2019 2:40pm GMT

I released version 1.7 of ledger2beancount, a ledger to beancount converter.

This release contains a number of bug fixes and a new feature:

• Don't misparse account and commodity with mixed tab/space separators
• Rename account names consisting of a root name without subaccount
• Warn when non-standard root names are used
• Avoid duplicate open directives for accounts with name collisions
• Don't warn for renamed tags that won't show up in the beancount file
• Add account_regex option to mass rename account names
• Add man page and improve documentation

You can get ledger2beancount from GitHub.

Thanks to GitHub user Joradi98 for reporting some bugs. Thanks to Jelmer Vernooij for packaging ledger2beancount for Debian.

22 Apr 2019 6:38am GMT

Snek Drives a Lego Car

(click on the picture to see the movie)

This is made from:

• Lego pieces
• Adafruit Crickit FeatherWing
• Circuit Cubes motor
• Home-made light sensors and lights

You can get everything other than the light sensors from various vendors.

More Pictures

Here's a picture from the front showing the light and light sensor mounted next to each other.

And here's the car from the rear showing the motor connections, the other light sensor/light combination and the battery pack:

Source Code

This program is a bit more verbose:

    mr = (MOTOR1A, MOTOR1B)
    ml = (MOTOR2A, MOTOR2B)

    pf = SIGNAL1
    pr = SIGNAL2

    f_speed = 0.5
    r_speed = 0.5
    t_speed_f = 0.6
    t_speed_s = 0.2

    def forw():
        talkto(mr)
        setpower(f_speed)
        setright()
        on()
        talkto(ml)
        setpower(f_speed)
        setleft()
        on()

    def back():
        talkto(mr)
        setpower(r_speed)
        setleft()
        on()
        talkto(ml)
        setpower(r_speed)
        setright()
        on()

    def left():
        talkto(mr)
        setpower(t_speed_f)
        setright()
        on()
        talkto(ml)
        setpower(t_speed_f)
        setright()
        on()

    def right():
        talkto(mr)
        setpower(t_speed_f)
        setleft()
        on()
        talkto(ml)
        setpower(t_speed_f)
        setleft()
        on()

    def stop():
        talkto(ml)
        setpower(0)
        off()
        talkto(mr)
        setpower(0)
        off()

    def go_forw():
        forw()
        listento(pf)
        while read() < .25:
            pass
        stop()

    def go_back():
        back()
        listento(pr)
        while read() < .25:
            pass
        stop()

    def bumper():
        while True:
            go_forw()
            back()
            time.sleep(0.5)
            stop()
            left()
            time.sleep(0.25)
            stop()
            go_forw()
            go_back()
            go_forw()

    bumper()

22 Apr 2019 5:33am GMT

One early result from getting the Kobo Forma reader I wrote before about was "how can I read as much as possible offline?"; and soon enough, I was looking for a man page to ebook (epub) converter.

Initial search seemed successful, but actually, none of the things I found worked correctly, or at least were not working for me. More precisely, I wanted something to generate a "book" with consistent internal links, so that I can jump from one page to another correctly. See the README for what I tried and gave up on.

In Debian, there is of course the online manpages service, and there's also The Linux man-pages project which do this very well. However, the UI and style for these seem to be designed for interactive browsing, whereas a simple output is better for offline browsing.

So, after a bit of playing around with man -T html, mandoc and man2html, I settled on the later to write my tiny wrapper script. It's a v0.0.1 release, but nevertheless works, so here it is: https://github.com/iustin/man2ebook.

Could be made much better, and switching the backend might be interesting, but it doesn't need to be more complex. Of course, customising the metadata via the command line would be useful, the auto-generated TOC contains extraneous items, etc. etc. :)

P.S.: In other open-source related topics, I haven't made a new Corydalis release in ages, but I'm slowly getting there…

21 Apr 2019 10:48pm GMT

The Debian Project Leader elections just finished and the winner is Sam Hartman!

His term as project leader starts inmediately today April 21st and expires on April 20th 2020.

Of a total of 1003 developers, 378 developers voted using the Condorcet method. More information about the result is available in the Debian Project Leader Elections 2019 page.

Many thanks to Joerg Jaspert, Jonathan Carter and Martin Michlmayr for running.

And special thanks to Chris Lamb for his service as DPL during these last twenty-four months!

21 Apr 2019 12:00pm GMT

Snek and a Balloon

(you can click on the picture to watch the model in action)

This represents the scale of projects we typically do in our Lego class. A motor, a couple of sensors and some simple logic. Here's the Snek program driving the balloon:

# Make the balloon go up and down

motor = (D9, D8)
top = A0
bottom = A1

def up():
    talkto(motor)
    listento(top)
    setpower(0.5)
    setright()
    on()
    while read() < .8:
        pass
    off()

def down():
    talkto(motor)
    listento(bottom)
    setpower(0.3)
    setleft()
    on()
    while read() < .8:
        pass
    off()

def play():
    while True:
        up()
        time.sleep(10)
        down()
        time.sleep(10)

play()

Light Sensors and Lights

I like to use light sensors with robotics and wanted to make some new ones sensitive to visible light. I found these Vishay TEPT5600 photo-transistors which are sensitive to most visible light. Using those with a 470kΩ resistor generated a good range of outputs for indoor lights.

For a light source, I'm using Cree 5mm green LEDs with a 5V power supply and a 100Ω current limiting resistor, these draw about 20mA and generate a lot of light.

For both of these, I take a 1x4 brick and drill a 3/16" hole in one end and a 1/8" in the other. The 5mm device fits snugly in the larger hole and the wires thread out through the other hole. The 1/8W resistor is tucked inside the brick.

You can see both of these in action in the example - the white bricks contain LEDs and the red bricks contain light sensors. The path between the light and sensor is interrupted by the model, allowing the program to determine when the motion has completed.

Motors

This model uses the Circuit Cube motors that I discovered last month. There's one visible near the middle of the Ferris wheel and another one just behind the Duemilanove board driving the balloon mechanism.

These motors have a built-in gear reduction and so they offer low speed and high torque. For Lego modelers, that's a pretty useful combination as the older non-geared motors always involved a long gear-train or worm gear to provide a reasonable balance of speed and power. For the balloon, there is a string wrapping around an axle driven directly by one of these motors.

Simple Models with Simple Programs

This class uses Lego to build simple mechanical devices that are controlled with simple computer programs. The Snek environment is the latest in a long history of computer systems which started with Lego Logo on the Apple ][ over twenty years ago.

21 Apr 2019 4:59am GMT

A few weeks ago, after a few days of internal turmoil on the matter, I committed to running for DPL.

The original nomination period was the week before, with no one stepping up for the position and with our current leader indicating that he wouldn't be available to serve another term. This resulted in a bit of a knee-jerk reaction and slight panic, with threads popping up on the debian mailing lists pondering things like what a leaderless Debian would look like and whether we perhaps need more of a team than a single person to be the leader the project. There was also some discussion about burnout and whether it's even fair to put so much pressure on a single person, and whether it's possible to delegate more of the DPL's responsibilities. The press also picked up on this and there were a few big stories on the matter that lead some to be slightly nervous on the matter.

Of course (as the LWN article pointed out), Debian's constitution is quite thorough and has made provision for cases like these. If no one steps up, the nomination period is extended for another week, and it only took one such extension to produce 5 new candidates (of which one retracted soon afterwards due to time commitments).

I mentioned internal turmoil at the beginning of the post, this was because up until a few days before my self-nomination, I've been very confident, and consistently so for a very long time, that I never want to run for DPL. The work that I care about and spend most attention on doesn't at all require me being a DPL. Also, having more responsibility in areas that I'd rather let others take care of sounded a bit daunting. I'd much rather spend time on technical and more general community issues than very specific interpersonal problems or administrative tasks like reading and approving budget proposals, sending out developer certificates, etc. On top of that, I was aware that running for DPL and opening myself like that means that I open myself to a very wide array of critique, that people might put everything I say under a microscope and try to tear it apart, and that running for DPL means being prepared for that.

Despite that turmoil, a small nagging part kept asking the questions "But what if?", what if I were DPL, what would I do? What would I change? What would I do as DPL that would make Debian better, and better as a DPL than I just could as a normal debian developer? These questions helped form in my head what my platform would look like, why I wanted to run for DPL, and how the rest of my campaign would shaped up. This year is also unique for me compared to previous years in that I will actually have time over the next year to focus on DPL-like activities. That, combined with the plans that were shaping up that I'm very enthusiastic about, convinced me that it's time to step up and proceed with my self-nomination.

Directly after the nomination period, the campaign period starts. There are surprisingly few rules (or even guidance) regarding the campaign period, the majority of it is where Debian developers (or anyone really, but mostly DDs) ask questions to the DPL candidates about their stance and policy on certain matters, how they plan to take action and often a few really tough hypothetical situations. Some questions even took advantage of the fact that April fools day falls in the campaign period, which led to some odd and interesting questions. Overall, I really enjoyed the campaign period. I was preparing myself for the worst case scenario before campaigning started, but what actually happened next astonished me. We had all kinds of Debian developers coming forward with high quality, productive discussions on all kinds of aspects which ranged from internal technical policies, how we work with upstreams, community matters, diversity, the DPL role itself, how Debian is changing and how to keep it relevant, community turnover, how we deal with money, how we market ourselves and so one. It was productive discussion and I enjoyed it.

Regardless of the outcome of this election, I'm very happy that I stepped up as a DPL candidate, and I'm very satisfied with how my campaign went and how I answered my questions. I'm also very happy that the elections turned out so vibrant and productive and I dare say even exciting. I hope that this will continue to happen for future elections, because it's clear to me that a productive election period is good for the health of Debian.

In the future, someone may be reading this and ponder "Should I run for DPL?". My advice would be to first take some stock and figure out if you're at a place in your life where you can actually do that (Did you just start a new job? Would your employer support you? Did you recently get married, have kids? How's your health? Can you afford to spend lots of unpaid time doing DPL work? etc…) and then also consider why you'd want to be DPL and what you'd like to achieve with such a role. If you weigh up all the aspects and it still feels right for you, then by all means go for it. In my opinion, even if you're not elected you still help make Debian better by participating in the election process.

Voting closes in around 12 hours at the time of writing this. Good luck to all the candidates and thank you to everyone who participated in making this such a fantastic and surreal experience!

2019-04-21: Update: Congratulations to Sam Hartman who is our new DPL! We've been talking off-list throughout the election process and Sam knows he has my full support and we even plan to collaborate on certain areas, more news to follow in the near future.

20 Apr 2019 12:00pm GMT

Weblate 3.6 has been released today. It brings rewritten notifications, user data download and several other improvements. It also sets depreciation timeline for Python 2 installations - after April 2020 Weblate will only support Python 3.

Full list of changes:

• Add support for downloading user data.
• Addons are now automatically triggered upon installation.
• Improved instructions for resolving merge conflicts.
• Cleanup addon is now compatible with app store metadata translations.
• Configurable language code syntax when adding new translations.
• Warn about using Python 2 with planned termination of support in April 2020.
• Extract special chars from the source string for visual keyboard.
• Extended contributor stats to reflect both source and target counts.
• Admins and consistency addons can now add translations even if disabled for users.
• Fixed description of toggle disabling Language-Team header manipulation.
• Notify users mentioned in comments.
• Removed file format autodetection from component setup.
• Fixed generating MO file for monolingual PO files.
• Added digest notifications.
• Added support for muting component notifications.
• Added notifications for new alerts, whiteboard messages or components.
• Notifications for administered projects can now be configured.
• Improved handling of three letter language codes.

If you are upgrading from older version, please follow our upgrading instructions.

You can find more information about Weblate on https://weblate.org, the code is hosted on Github. If you are curious how it looks, you can try it out on demo server. Weblate is also being used on https://hosted.weblate.org/ as official translating service for phpMyAdmin, OsmAnd, Turris, FreedomBox, Weblate itself and many other projects.

Should you be looking for hosting of translations for your project, I'm happy to host them for you or help with setting it up on your infrastructure.

Further development of Weblate would not be possible without people providing donations, thanks to everybody who have helped so far! The roadmap for next release is just being prepared, you can influence this by expressing support for individual issues either by comments or by providing bounty for them.

Filed under: Debian English SUSE Weblate

20 Apr 2019 11:00am GMT

CrickitSnek - snek on the Adafruit Crickit

I got a Crickit FeatherWing from Adafruit today. This board is supposed to act as an I/O expander for all of the Feather boards, but it's a completely operational SAMD21 machine with a pile of useful GPIO bits:

• 4 "Capacitive Touch" pins (which are just regular GPIOs)
• 8 Analog input/digital output pins
• 4 Digital I/O pins
• 4 High-current 5V digital output pins
• 2 H-bridge motor controllers
• 1 Audio amplifier
• 1 high current output designed for NeoPixels

It's also got a USB port and an on-board NeoPixel, plus headers to plug in a Feather board.

There's no Crystal on the Crickit

To save cost, the Crickit design doesn't include any crystal at all. That required re-configuring the SAMD21 clock configuration to synchronize the 48MHz system clock from USB instead of from the 32.768kHz crystal present on the Metro and Feather boards. Once I had done this, the Crickit board appeared on USB and Snek was running.

Naming the Crickit pins

There are a bunch of separate I/O groupings on the Crickit board, and I wanted to make it easy to remember how to use them. Providing convenient names for each pin seemed like the the best plan.

On the Metro and Duemilanove boards, I just used numbers for all of the pins; 0-13 for the digital pins and 14-19 for the analog pins. This matches the Arduino conventions, although it doesn't provide the convenient 0-5 numbering for analog input. Having names for these pins will also be nice.

So, I hacked up the Snek 'builtins' mechanism to include builtins with numeric values. Now you can have as many builtin values as you want. I first replaced the wacky lexer hacks for values like 'math.pi', 'True' and 'False' and then went and added names for the pins on all devices.

Snek vs TI DRV8833

The TI DRV8833 motor controller chip on the Crickit has two pins per motor -- you set one pin to ground and drive the other with a PWM signal, which pin you PWM selects the direction of the motor. This doesn't directly map to how I expected motor controllers to work in Snek. Snek expects to have one pin control direction and the other control speed.

I had to do a bit of magic to make this work, but the joy of having an interpreter between the application and the hardware is having the ability to hide these kinds of details from the application

Minor Crickit Schematics Error

The Crickit Schematics linked from the Crickit Downloads page have the DRIVE labels flipped -- DRIVEIN1 is actually hooked to PB10, DRIVEIN2 to PB11, DRIVEIN3 to PA12 and DRIVEIN4 to PA13. The Eagle schematics on github are correct; it would be nice to have the images updated as those don't require downloading proprietary software to view.

Status

All of these bits are in the Snek git repository and should be released in the next Snek version (0.97?).

20 Apr 2019 7:45am GMT

Wanted to read up on how TLA+ works. Then I noticed that Leslie's page has lots of videos, and now I'm watching him speak. It might be the way people do it but now I can't seem to focus on a video long enough...

20 Apr 2019 5:56am GMT

It was my first time attending the SRECON series and also one of the big step into learning about Site Reliability and Engineering. The conference had jam packed sessions on site reliability, Chaos engineering, Code reviewing culture, Incidents, SLOs and much more.

My notes would be redundant because there is nothing better than a comprehensive write up about the conference by Tanya Reilly, you can read it here -> https://noidea.dog/blog/srecon-americas-2019.

Thanks to the organizers for putting up such an overwhelming, knowledgeable and fun conference!

19 Apr 2019 6:51pm GMT

The Debian India Community in Delhi along with Mozilla Delhi/NCR community organized DebUtsav Delhi 2019 on 9 and 10 March, 2019.

For those who are unware, DebUtsav is an Indian style version of a typical Mini Debian Conference.

This was the first Debian related conference to be organized in the Northern region of India. We have had Mini Debian conferences previously in Mumbai, Pune, Hyderabad and in different cities of state of Kerala. But this was the very first one in the Northern Region.

DebUtsav was made possible with the help from our sponsors

• Hamara Linux
• National Institute of Public Finance and Policy
• The travel costs of some of our speakers were generously covered by Debian.

The event took place at National Institute of Public Finance and Policy (NIPFP), Delhi.

The event schedule was divided into two tracks.

• Debian Track and FOSS Track. The Debian Track was specific for the talks or workshops related to Debian.
• The FOSS track included talks/workshops ranging from General Free Software, Gender Diversity a Digital Security and privacy. The full schedule is present on the website DebUtsav.in

On the first day of DebUtsav

Debian Track

Although you can check the talks happened at the talks in the link to schedule. Some of the notable talks were Pirate Praveen on Debian Packaging in times of Docker and Flatpak. Abhijit Introduced us to the Debian LTS project. While Raju Devidas talked on "How to become a Debian Developer?" There were also workshops by Utkarsh Gupta and Sagar Ippalpalli on Packaging of Ruby Gems and Node Modules.

FOSS Track

Ashutosh Singh, also known as Juggernaut, talked on getting started into Open Source and Debian. The other talks in FOSS track included, a talk on Cryptography & Cryptanalysis by Ishan Malik. While Mohit Phulera talked about Setting up and using Google Vision API's. Thing to note here that both were first time speakers. DebUtsav got them started. We also had a Rust 101 workshop by Swarnim Arun. Karmanya Talked about Building Data Apps with Grames. The last talk for the day in FOSS track was by Himanshu, it had a funky name to it, SELinux: For the Asgardians

Second Day of DebUtsav

Debian Track

The first talk of the day was on an Introduction to the Hamara Linux project by Shivani Bharadwaj and Raju Devidas. They introduced the Hamara Project to the one's present as well as talked about there upcoming release of Hamara codenamed Svastik.

Later in the Debian track, we had the first ever Bug Squashing Party BSP in India. For the BSP we had 2 DD's and 2 DM's and many other active Debian contributors present. They helped people present to go through the Debian bug tracking system BTS and find bugs that they can help solve. Although we did not manage to get any bugsolved during the duration of BSP, we did managed to get some people get familiar with Debian's bug tracking eco-system, introduced them to the various teams within Debian in which they can co-ordinate to get started for solving bugs as well as contributing to Debian in general. The BSP proved to be a good starting point for Utkarsh Gupta. Within two-three weeks after the BSP he has already solved many bugs including 15 RC bugs.

FOSS track

The first talk in the FOSS track was on Digital Security and Privacy by Shashikanth.

In the second talk our DM Sruthi Chandran raised the question on How gender diverse and inclusinve is the Free Software Community?. She co-ordinated the sicussion very well and made sure that the people present during the session got involved.

Later in the Day we had talks by Pirate Praveen on Take back our data and Freedoms. Vipul Gupta talked about digging Opportunities in Open Source. Last talk which was scheduled for the foss track did not take place because of the un-availability of the speaker Ranjith Raj Vasam. Everyone got involved into the Debian BSP instead.

On the sidelines of the schedule of the second day, the podcast team of Decompiled was also present. With the efforts of the team, Raju Devidas interviewed Pirate Praveen. In the interview they talked about work done by Praveen over the years as well as his journey in Debian project.

Some statistics from DebUtsav

• For both the days combined, around 120 people registered for attending DebUtsav, out of them around 95 attended the conference.
• Around 10-15, unregistered attendees/on spot registrations were also present.
• We had a total of 14 Women Attendees.

DebUtsav Delhi was lucky to have the presence of - 2 Debian Developers Pirate Praveen & Abhijith PA. - 2 Debian Maintainers Sruthi Chandran and Sagar Ippalpalli.

It is during the conversations that happened at the conference that we realized that there are a lot of first's happening in the Debian India Community.

• Sruthi Chandran is the first Women Debian Maintainer from India, also soon to be the first women Debian Developer from India.
• Presence of DD's proved useful for Utkarsh Gupta as he got his initial requirements for a DM fulfilled with his keys signed by the DD's present at DebUtsav. He is at the time of writing this event report, the youngest DM from India.
• Currently Sruthi Chandran and Raju Devidas have there DD applications in process. If they get approved, we will be crossing the Double Digits of DD's from India for the first time. They are 9 now and with two more we will get to 11.
• This was the first Debian related conference in Delhi or anywhere in Northern India.

DebUtsav Delhi proved very productive in introducing many new people to Debian project and to free software in general. Also it provided an opportunity for the Debian contributors from Delhi to meet the Debian Developers.

The conference was made possible by the continuous efforts of people from the communities of Mozilla Delhi NCR and Indian Linux User's Group Delhi. Some of the people involved in the effort could be seen on the Team section of debutsav.in

Thanks a lot to everyone for puting up there efforts for DebUtsav Delhi. We are looking forward to having another Debian event in Delhi and more events around India.

19 Apr 2019 6:30pm GMT

A new version 0.1.2 of the tint package is arriving at CRAN as I write this. It follows the recent 0.1.1 release which included two fabulous new vignettes featuring new font choices. The package name expands from tint is not tufte as the package offers a fresher take on the Tufte-style for html and pdf presentations.

However, with the new vignettes in 0.1.1 we now had four full-length vignettes which made the package somewhat bulky. So for this release I reorganized things a little, added two new shorter vignettes with links to the full-length vignettes but keeping the size more constrained.

Two screenshots for the first pages of the Lato and Garamond vignettes follow (and are links to a higher-resolution full-length pdf versions):

The new vignettes can also be browsed from CRAN: html variant and pdf variant. They also show the new theme borrowed with thanks and credits from ggtufte.

The full list of changes is below.

Changes in tint version 0.1.2 (2019-04-19)

• Two new shorter html and pdf vignettes have been added (with references to the longer vignettes) reducing package size.

• New helper function 'theme_tint' based on a similar function in package 'ggtufte'.

Courtesy of CRANberries, there is a comparison to the previous release. More information is on the tint page.

For questions or comments use the issue tracker off the GitHub repo.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

19 Apr 2019 3:13pm GMT

I became a Debian Developer towards the end of 2018. I started the process in August 2017 at DebConf in Montreal. Over the course of 17 months I wrote emails, searched the Debian wiki, and learned a lot about the project.

What's a non-uploading Debian Developer (DD)?

A non-uploading DD is one who does not upload packages to the Debian code base. A non-uploading DD:

• is member of the Debian project;
• is allowed to vote about issues regarding the whole project;
• can log in on most systems that keep Debian running; and
• has access to the debian-private mailing list.

Why become a DD?

I had two main reasons for becoming a DD: I was told debian-private was mostly vacation notices and baby pictures. I also wanted to vote in the DPL elections.

It turns out -private contains ZERO baby pictures, and choosing who to vote for in DPL elections is hard work.

There are other reasons to become a non-uploading DD. I found that the most compelling one, from my perspective, was the authority and respect that comes along with it. When representing the project, which I have done on several occasions, it's easier to get things done when you have a title or formal affiliation attached to your name.

I joined the A-H team with the understanding that I would become a DD - they preferred someone with official status in the project be on that team. In addition to empty promises of baby pictures, I became a DD because I wanted to take on more responsibility in the project.

There's also a certain amount of the feeling of belonging that goes along with becoming a formal member of a project. There's a lot to say about the value of the recognition of your peers - that they consider you a part of the team.

What do you do for Debian?

I'm on the Outreach and Anti-harassment teams.

Outreach

The Outreach team coordinates Debian participation in internship programs, specifically, and currently, Google Summer of Code and Outreachy. We participate in Outreachy twice a year, and GSoC during the Northern Hemisphere summer. This mostly includes a lot of paperwork, emailing people to make sure they're on task, and talking with the home organizations of Google and Outreachy.

Since I do not mentor any projects, this work is fairly condensed, though very demanding. It's time sensitive, with externally imposed deadlines not of our own creation.

During a period of several weeks - and application periods overlap in March - we:

• confirm with the Debian Project Leader funding for Outreachy;
• put our calls for mentors;
• assist mentors in finding co-mentors when appropriate;
• evaluate projects, separating them into "approved" and "unapproved" categories, based on whether they meet the Debian participation criteria;
• fill out the application forms for GSoC and Outreachy;
• make announcements, calls for mentors, calls for projects, and calls for applicants;
• field questions and requests from applicants;
• keep up with mentors during the application period;
• make formal decisions about the number of interns and who they are based on requests from mentors, available funding, and an amorphous process of reading mentor reports and trying best to judge who will not only be a successful intern, but who will be a successful mentor for a project;
• keep up with mentors and interns during the period of the internship;
• make sure everyone gets invoiced and paid appropriately;
• make sure everyone has a good time; and
• general other things as they come up.

As a total process, it's quite consuming at times, but relaxed at other times. I would say that administering for Outreachy is an "easier" process, as the mentors are (generally, overall, usually) more experienced and self-managing. GSoC is also a much bigger program.

Anti-harassment

I could, and likely will, write a much longer post about this. I gave a talk at FOSDEM on the activities and operating procedures of the team. The quick summary is that we meet every fortnight, discuss reported incidents, and either: make recommendations to other teams about how to proceed or send personal emails to the individuals involved, pointing out inappropriate behaviors, and asking people to be more professional in their project participation.

What did your process include?

Mostly emails. A lot of emails, and back and forth with my AM (application manager). I'm sure many people say this, but my AM was great.

I went through the initial steps - deciding to apply after many, many people convinced me of the validity of my contributions to the project; getting my keysigned by an appropriate number of DDs; recruiting advocates for my application; etc.

Then came the questions and the tests. A big chunk of questions were around philosophy, policy, and procedures of the project. We covered licensing questions, the DFSG, the philosophy of user freedom, how different things within the Debian project are decided, and a bunch of other sections.

There where a technical section of my application, which covered more policy and procedure around how things are done within the Debian project. I worked on a bug (one on a piece of web site content) and submitted the edit on salsa, Debian's instance of git. I collaborated in documents on storm.debian.org, logged into servers using ssh, and encrypted and decrypted a number of files over the course of the procedure.

Why did it take so long?

I started my application in August of 2017, and got my welcome email December 26, 2018. I joked that I was going for the longest application period.

It took so long largely because my AM and I were both very, very busy. When faced with free time, we both frequently agreed to make the decision to instead work on our respective Debian work, rather than the application process. I think I speak for both of us when I say we agreed a lot of the other projects we were working on were more timely than my application.

At DC18, I did a personal sprint on my application, and my AM kindly did a personal sprint reviewing it. We met over IRC to handle final steps later that fall. I finished in November, days before the November keyring update, and my application was reviewed in December.

19 Apr 2019 2:43pm GMT

As planned for this long weekend (in Switzerland), I went and re-read the platforms, and cast my vote. Which made me very happy, because I voted in the elections for the first time in a long while…

But it didn't start like that. The first call for nominations ended up with no (valid) nominations, and the follow-up thread was a bit depressing (high load for the DPL role, unclear expectations, etc.) For a time, it looked like the project is drifting, and some of the trolling on the list definitely didn't help. I managed to prod a bit the thread and there was a nice reply from Lucas which seems to open the gates-the discussion livened up, and after many more meaningful mails, we ended up with 4 candidates. That's, in my memory, a very good result.

Which means I went and read the platforms multiple times, and tried to follow the campaign as well (not so successful though), and today I cast my vote. After the initial sad result, very happy to see there are still people who are willing to invest significant time into Debian and its future. Thanks all!

Coupled with the (hopefully soon) upcoming Buster release, and the fact that I managed to update all my small packages before it, I feel much better both about Debian and my involvement with it than a year ago.

Now just looking forward to Python 2 removal :)

19 Apr 2019 11:43am GMT