Elsewhere

Enrico Zini: Software quality in 2016

Planet Debian - Tue, 15/11/2016 - 13:01

Ansible's default output, including the stderr of failed commands, is JSON encoded, which makes reading Jenkins' output hard.

Ansible however has Callback plugins that could be used. In that page it says:

Ansible comes with a number of callback plugins that you can look at for examples. These can be found in lib/ansible/plugins/callback.

That is a link to a git repo with just a pile of Python sources and no, say README.md index to what they do. Hopefully they have some docstring with a short description of what they do? no.

Actually, some do, but just because someone copypasted the default one and didn't even bother removing its docstring.

Categories: Elsewhere

Keith Packard: AltOS-Lisp

Planet Debian - Tue, 15/11/2016 - 08:11
A Tiny Lisp for AltOS

I took a bit of a diversion over the last week or so when I wondered how small a lisp interpreter I could write, and whether I could fit that into one of the processors that AltOS runs on. It turns out, you can write a tiny lisp interpreter that fits in about 25kB of ram with a 3kB heap for dynamic data.

I decided to target our ChaosKey boards; they're tiny, and I've got a lot of them. That processor offers 28kB of usable flash space (after the 4kB boot loader) and 6kB of ram with the processor running at a steaming 48MHz.

I'm not at all sure this is useful, but I always enjoy doing language implementations, and this one presented some 'interesting' challenges:

  • Limited RAM. I don't have space to do a classic stop/copy collector.

  • Limited stack. A simple lisp implementation uses the C stack for all recursion in execution and memory collection. I don't have enough ram for that.

Iterative Compacting Allocator

I'm betting someone has built one of these before, but I couldn't find one, so I wrote my own.

The basic strategy is to walk the heap to find a subset of the active objects which are allocated sequentially in memory with only unused storage between them. These objects are then compacted in-place, and then the heap is walked again to update all references to the moved objects. Then, the process is restarted to find another subset and move them.

By looking for these subsets starting at the bottom of the heap, and working upwards towards the top, the whole heap can be compacted into a contiguous chunk at the bottom of memory.

Allocation involves moving a pointer along at the top of active memory; when it gets to the top of the heap, collect and see if there's space now.

As always, the hardest part was to make sure all active memory was tied down. The second hardest part was to make sure that all active pointers were updated after any allocation, in case a collect moved the underlying object. That was just bookkeeping, but did consume much of the development time.

One additional trick was to terminate the recursion during heap walking by flagging active cons cell locations in a global bitmap and then walking that separately, iterating until that bitmap is empty. Nested lambdas form another recursion which should probably get the same approach, but I haven't done that yet.

An unexpected "benefit" of the tiny heap is that the collector gets called a lot, so any referencing bugs will have a good chance of being uncovered in even a short program execution.

ROM-able Lisp

Instead of implementing all of the language in C, I wanted to be able to implement various pieces in Lisp itself. Because of the complex nature of the evaluation process, adding things like 'let' or even 'defun' turn out to be dramatically simpler in Lisp. However, I didn't want to consume bunches of precious RAM to hold these basic functions.

What I did was to create two heaps, one in ROM and the other in RAM. References are be tagged as to which heap they're in.

16-bit Values

Lisp programs use a pile of references. Using a full 32 bits for each one would mean having a lot less effective storage. So, instead, I use an offset from the base of the heap. The top bit of the offset is used to distinguish between the ROM heap and the RAM heap.

I needed a place to store type information, so I settled on using the bottom two bits of the references. This allows for four direct type values. One of these values is used to indicate an indirect type, where the type is stored in the first byte of the object. The direct types are:

ValueType 0Cons cell 114-bit int 2String 3Other

With 2 tag bits, the allocator needs to work in 32-bit units as the references couldn't point to individual bytes. Finally, I wanted 0 to be nil, so I add four to the offsets within the heaps.

The result is that the ROM and RAM heaps can each cover up to 32k - 4 bytes.

Note that ints are not stored in the heap; instead they are immediate values stored in 14 bits, providing a range of -8192 to 8191. One can imagine wanting more range in ints at some point.

Heap-based Evaluator

A simple lisp implementation uses the fact that eval is re-entrant and do the operation on the C stack:

val eval(val exprs) { val vals; while (exprs) { vals = append(vals, eval(car(exprs))); exprs = exprs->cdr; } return execute (car(vals), cdr(vals)); }

This makes things really simple and provides for a clean framework for implementing various bits of lisp, including control flow and macros. However, it rapidly consumes all of the available memory for a stack, while also requiring separate bookkeeping for the in-use memory in each frame.

I replaced this design with one which keeps the lisp stack on the heap, and then performs eval with a state machine with all state stored in global variables so that the memory manager can reference them directly.

Each eval operation is performed in a separate 'stack' context, which holds the entire eval state except for the current value, which lives in a separate global variable and is used to pass values out of one stack frame and into another. When the last stack context is finished, the evaluation terminates and the value is returned to the caller.

There are nine states in the state machine, each of which is implemented in a separate function, making the state machine a simple matter of pulling the current state from the top of the stack and invoking the associated function:

while (ao_lisp_stack) { if (!(*evals[ao_lisp_stack->state])() || ao_lisp_exception) { ao_lisp_stack_clear(); return AO_LISP_NIL; } } return ao_lisp_v;

Because there's no C recursion involved, catching exceptions is a simple matter of one test at this level.

Primitives like progn, while, cond and eval all take special magic in the state machine to handle; getting all of that working took several attempts before I found the simple loop shown above.

Lexical Scoping

The last time I did a lisp interpreter, I implemented dynamic scoping. Atoms were all global and had values associated directly with them. Evaluating a lambda started by saving all of the existing global values for the parameter atoms and then binding the new values. When finished, the previous values would be restored. This is almost correct, but provides surprising results for things like:

> (setq baz 1) > (def foo (lambda (bar) (+ baz bar))) > (def bletch (lambda (baz) (foo baz))) > (bletch 2) 4

The value that foo gets for 'baz' is 2 instead of 1 under dynamic scoping, which most people find surprising. This time, I was determined to use lexical scoping, and it turned out to be surprisingly easy.

The first trick was to separate the atoms from their 'value'; each atom can have a different value in different lexical scopes. So, each lexical scope gets a 'frame' object, those contain the value for each atom defined in that scope. There's a global scope which holds all of the globally defined values (like baz, foo and bletch above). Each frame points to its enclosing scope, so you can search upwards to find the right value.

The second trick was to realize that the lexical scope of a lambda is the scope in which the lambda itself is evaluated, and that the evaluation of a lambda expression results in a 'function' object, which contains the lambda and its enclosing scope:

> (def foo (lambda (bar bletch) ((lambda (baz) (+ baz bar)) bletch))) > (foo 2 3) 5

In this case, the inner lambda in foo can 'see' the value of bar from the enclosing lambda. More subtly, even if the inner lambda were executed multiple times, it would see the same baz, and could even change it. This can be used to implement all kinds of craziness, including generators:

> (defun make-inc (add) ((lambda (base) (lambda () (progn (setq base (+ base add)) base))) 0) ) > (setq plus2 (make-inc 2)) > (plus2) 2 > (plus2) 4

The current implementation of each frame is a simple array of atom/value pairs, with a reference to the parent frame to form the full scope. There are dramatically faster implementations of this same concept, but the goal here was small and simple.

A Tiny Allocator Optimization

With eval consuming heap space for stacks, frames and argument lists, the interpreter was spending a lot of time in the collector. As a simple optimization, I added some free lists for stack frames and cons cells.

Stack frames are never referenced when they're finished, so they can always go on the free list. Cons cells used to construct argument lists for functions are usually free.

Builtin functions have a bit which indicates whether they might hold on to a reference to the argument list. Interpreted lambdas can't get the list while nlambdas, lexprs and macros do.

Each lambda execution creates a new frame, and while it would be possible to discover if that frame 'escapes' the lambda, I decided to not attempt to cache free ones yet.

Save and Restore

To make the lisp interpreter more useful in tiny computers, I added the ability to save and restore the entire heap to flash. This requires leaving enough space in the flash to preserve the heap, further constraining the amount of flash available for the application.

Code

All of this code is in the 'lisp' branch of my AltOS repository:

AltOS

The lisp interpreter is independent from the rest of AltOS and could be re-purposed for another embedded operating system. It runs fine on ChaosKey hardware, and also on the STM32F042 Nucleo-32 board

There's also a test framework which runs on Linux, and is how I developed almost all of the code. That's in the src/test directory in the above repository, and is called 'ao_lisp_test'.

Towers of Hanoi

Here's an implementation of the classic recursive Towers of Hanoi game; it shows most of the current features of the language.

; ; Towers of Hanoi ; ; Copyright © 2016 Keith Packard <keithp@keithp.com> ; ; This program is free software; you can redistribute it and/or modify ; it under the terms of the GNU General Public License as published by ; the Free Software Foundation, either version 2 of the License, or ; (at your option) any later version. ; ; This program is distributed in the hope that it will be useful, but ; WITHOUT ANY WARRANTY; without even the implied warranty of ; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU ; General Public License for more details. ; ; ANSI control sequences (defun move-to (col row) (patom "\033[" row ";" col "H" nil) ) (defun clear () (patom "\033[2J" nil) ) (defun display-string (x y str) (move-to x y) (patom str) ) ; Here's the pieces to display (setq stack '("*" "**" "***" "****" "*****" "******" "*******")) (setq top (+ (length stack) 3)) ; ; Here's all of the stacks of pieces ; This is generated when the program is run ; (setq stacks nil) ; Display one stack, clearing any ; space above it (defun display-stack (x y clear stack) (cond ((= 0 clear) (cond (stack (progn (display-string x y (car stack)) (display-stack x (1+ y) 0 (cdr stack)) ) ) ) ) (t (progn (display-string x y " ") (display-stack x (1+ y) (1- clear) stack) ) ) ) ) ; This should probably be included in the rom image... (defun length (list) (cond (list (1+ (length (cdr list)))) (0) ) ) ; Position of the top of the stack on the screen ; Shorter stacks start further down the screen (defun stack-pos (y stack) (- y (length stack)) ) ; Display all of the stacks, spaced 20 columns apart (defun display-stacks (x y stacks) (cond (stacks (progn (display-stack x 0 (stack-pos y (car stacks)) (car stacks)) (display-stacks (+ x 20) y (cdr stacks))) ) ) ) ; Display all of the stacks, then move the cursor ; out of the way and flush the output (defun display () (display-stacks 0 top stacks) (move-to 1 21) (flush) ) ; Reset stacks to the starting state, with ; all of the pieces in the first stack and the ; other two empty (defun reset-stacks () (setq stacks (list stack nil nil)) (length stack) ) ; more functions which could usefully ; be in the rom image (defun min (a b) (cond ((< a b) a) (b) ) ) (defun nth (list n) (cond ((= n 0) (car list)) ((nth (cdr list) (1- n))) ) ) ; Replace a stack in the list of stacks ; with a new value (defun replace (list pos member) (cond ((= pos 0) (cons member (cdr list))) ((cons (car list) (replace (cdr list) (1- pos) member))) ) ) ; Move a piece from the top of one stack ; to the top of another (defun move-piece (from to) (let ((from-stack (nth stacks from)) (to-stack (nth stacks to)) (piece (car from-stack))) (setq from-stack (cdr from-stack)) (setq to-stack (cons piece to-stack)) (setq stacks (replace stacks from from-stack)) (setq stacks (replace stacks to to-stack)) (display) (delay 100) ) ) ; The implementation of the game (defun _hanoi (n from to use) (cond ((= 1 n) (progn (move-piece from to) nil) ) (t (progn (_hanoi (1- n) from use to) (_hanoi 1 from to use) (_hanoi (1- n) use to from) ) ) ) ) ; A pretty interface which ; resets the state of the game, ; clears the screen and runs ; the program (defun hanoi () (setq len (reset-stacks)) (clear) (_hanoi len 0 1 2) )
Categories: Elsewhere

Keith Packard: AltOS-Lisp

Planet Debian - Tue, 15/11/2016 - 08:11
A Tiny Lisp for AltOS

I took a bit of a diversion over the last week or so when I wondered how small a lisp interpreter I could write, and whether I could fit that into one of the processors that AltOS runs on. It turns out, you can write a tiny lisp interpreter that fits in about 25kB of ram with a 3kB heap for dynamic data.

I decided to target our ChaosKey boards; they're tiny, and I've got a lot of them. That processor offers 28kB of usable flash space (after the 4kB boot loader) and 6kB of ram with the processor running at a steaming 48MHz.

I'm not at all sure this is useful, but I always enjoy doing language implementations, and this one presented some 'interesting' challenges:

  • Limited RAM. I don't have space to do a classic stop/copy collector.

  • Limited stack. A simple lisp implementation uses the C stack for all recursion in execution and memory collection. I don't have enough ram for that.

Iterative Compacting Allocator

I'm betting someone has built one of these before, but I couldn't find one, so I wrote my own.

The basic strategy is to walk the heap to find a subset of the active objects which are allocated sequentially in memory with only unused storage between them. These objects are then compacted in-place, and then the heap is walked again to update all references to the moved objects. Then, the process is restarted to find another subset and move them.

By looking for these subsets starting at the bottom of the heap, and working upwards towards the top, the whole heap can be compacted into a contiguous chunk at the bottom of memory.

Allocation involves moving a pointer along at the top of active memory; when it gets to the top of the heap, collect and see if there's space now.

As always, the hardest part was to make sure all active memory was tied down. The second hardest part was to make sure that all active pointers were updated after any allocation, in case a collect moved the underlying object. That was just bookkeeping, but did consume much of the development time.

One additional trick was to terminate the recursion during heap walking by flagging active cons cell locations in a global bitmap and then walking that separately, iterating until that bitmap is empty. Nested lambdas form another recursion which should probably get the same approach, but I haven't done that yet.

An unexpected "benefit" of the tiny heap is that the collector gets called a lot, so any referencing bugs will have a good chance of being uncovered in even a short program execution.

ROM-able Lisp

Instead of implementing all of the language in C, I wanted to be able to implement various pieces in Lisp itself. Because of the complex nature of the evaluation process, adding things like 'let' or even 'defun' turn out to be dramatically simpler in Lisp. However, I didn't want to consume bunches of precious RAM to hold these basic functions.

What I did was to create two heaps, one in ROM and the other in RAM. References are be tagged as to which heap they're in.

16-bit Values

Lisp programs use a pile of references. Using a full 32 bits for each one would mean having a lot less effective storage. So, instead, I use an offset from the base of the heap. The top bit of the offset is used to distinguish between the ROM heap and the RAM heap.

I needed a place to store type information, so I settled on using the bottom two bits of the references. This allows for four direct type values. One of these values is used to indicate an indirect type, where the type is stored in the first byte of the object. The direct types are:

ValueType 0Cons cell 114-bit int 2String 3Other

With 2 tag bits, the allocator needs to work in 32-bit units as the references couldn't point to individual bytes. Finally, I wanted 0 to be nil, so I add four to the offsets within the heaps.

The result is that the ROM and RAM heaps can each cover up to 32k - 4 bytes.

Note that ints are not stored in the heap; instead they are immediate values stored in 14 bits, providing a range of -8192 to 8191. One can imagine wanting more range in ints at some point.

Heap-based Evaluator

A simple lisp implementation uses the fact that eval is re-entrant and do the operation on the C stack:

val eval(val exprs) { val vals; while (exprs) { vals = append(vals, eval(car(exprs))); exprs = exprs->cdr; } return execute (car(vals), cdr(vals)); }

This makes things really simple and provides for a clean framework for implementing various bits of lisp, including control flow and macros. However, it rapidly consumes all of the available memory for a stack, while also requiring separate bookkeeping for the in-use memory in each frame.

I replaced this design with one which keeps the lisp stack on the heap, and then performs eval with a state machine with all state stored in global variables so that the memory manager can reference them directly.

Each eval operation is performed in a separate 'stack' context, which holds the entire eval state except for the current value, which lives in a separate global variable and is used to pass values out of one stack frame and into another. When the last stack context is finished, the evaluation terminates and the value is returned to the caller.

There are nine states in the state machine, each of which is implemented in a separate function, making the state machine a simple matter of pulling the current state from the top of the stack and invoking the associated function:

while (ao_lisp_stack) { if (!(*evals[ao_lisp_stack->state])() || ao_lisp_exception) { ao_lisp_stack_clear(); return AO_LISP_NIL; } } return ao_lisp_v;

Because there's no C recursion involved, catching exceptions is a simple matter of one test at this level.

Primitives like progn, while, cond and eval all take special magic in the state machine to handle; getting all of that working took several attempts before I found the simple loop shown above.

Lexical Scoping

The last time I did a lisp interpreter, I implemented dynamic scoping. Atoms were all global and had values associated directly with them. Evaluating a lambda started by saving all of the existing global values for the parameter atoms and then binding the new values. When finished, the previous values would be restored. This is almost correct, but provides surprising results for things like:

> (setq baz 1) > (def foo (lambda (bar) (+ baz bar))) > (def bletch (lambda (baz) (foo baz))) > (bletch 2) 4

The value that foo gets for 'baz' is 2 instead of 1 under dynamic scoping, which most people find surprising. This time, I was determined to use lexical scoping, and it turned out to be surprisingly easy.

The first trick was to separate the atoms from their 'value'; each atom can have a different value in different lexical scopes. So, each lexical scope gets a 'frame' object, those contain the value for each atom defined in that scope. There's a global scope which holds all of the globally defined values (like baz, foo and bletch above). Each frame points to its enclosing scope, so you can search upwards to find the right value.

The second trick was to realize that the lexical scope of a lambda is the scope in which the lambda itself is evaluated, and that the evaluation of a lambda expression results in a 'function' object, which contains the lambda and its enclosing scope:

> (def foo (lambda (bar bletch) ((lambda (baz) (+ baz bar)) bletch))) > (foo 2 3) 5

In this case, the inner lambda in foo can 'see' the value of bar from the enclosing lambda. More subtly, even if the inner lambda were executed multiple times, it would see the same baz, and could even change it. This can be used to implement all kinds of craziness, including generators:

> (defun make-inc (add) ((lambda (base) (lambda () (progn (setq base (+ base add)) base))) 0) ) > (setq plus2 (make-inc 2)) > (plus2) 2 > (plus2) 4

The current implementation of each frame is a simple array of atom/value pairs, with a reference to the parent frame to form the full scope. There are dramatically faster implementations of this same concept, but the goal here was small and simple.

A Tiny Allocator Optimization

With eval consuming heap space for stacks, frames and argument lists, the interpreter was spending a lot of time in the collector. As a simple optimization, I added some free lists for stack frames and cons cells.

Stack frames are never referenced when they're finished, so they can always go on the free list. Cons cells used to construct argument lists for functions are usually free.

Builtin functions have a bit which indicates whether they might hold on to a reference to the argument list. Interpreted lambdas can't get the list while nlambdas, lexprs and macros do.

Each lambda execution creates a new frame, and while it would be possible to discover if that frame 'escapes' the lambda, I decided to not attempt to cache free ones yet.

Save and Restore

To make the lisp interpreter more useful in tiny computers, I added the ability to save and restore the entire heap to flash. This requires leaving enough space in the flash to preserve the heap, further constraining the amount of flash available for the application.

Code

All of this code is in the 'lisp' branch of my AltOS repository:

AltOS

The lisp interpreter is independent from the rest of AltOS and could be re-purposed for another embedded operating system. It runs fine on ChaosKey hardware, and also on the STM32F042 Nucleo-32 board

There's also a test framework which runs on Linux, and is how I developed almost all of the code. That's in the src/test directory in the above repository, and is called 'ao_lisp_test'.

Towers of Hanoi

Here's an implementation of the classic recursive Towers of Hanoi game; it shows most of the current features of the language.

; ; Towers of Hanoi ; ; Copyright © 2016 Keith Packard <keithp@keithp.com> ; ; This program is free software; you can redistribute it and/or modify ; it under the terms of the GNU General Public License as published by ; the Free Software Foundation, either version 2 of the License, or ; (at your option) any later version. ; ; This program is distributed in the hope that it will be useful, but ; WITHOUT ANY WARRANTY; without even the implied warranty of ; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU ; General Public License for more details. ; ; ANSI control sequences (defun move-to (col row) (patom "\033[" row ";" col "H" nil) ) (defun clear () (patom "\033[2J" nil) ) (defun display-string (x y str) (move-to x y) (patom str) ) ; Here's the pieces to display (setq stack '("*" "**" "***" "****" "*****" "******" "*******")) (setq top (+ (length stack) 3)) ; ; Here's all of the stacks of pieces ; This is generated when the program is run ; (setq stacks nil) ; Display one stack, clearing any ; space above it (defun display-stack (x y clear stack) (cond ((= 0 clear) (cond (stack (progn (display-string x y (car stack)) (display-stack x (1+ y) 0 (cdr stack)) ) ) ) ) (t (progn (display-string x y " ") (display-stack x (1+ y) (1- clear) stack) ) ) ) ) ; This should probably be included in the rom image... (defun length (list) (cond (list (1+ (length (cdr list)))) (0) ) ) ; Position of the top of the stack on the screen ; Shorter stacks start further down the screen (defun stack-pos (y stack) (- y (length stack)) ) ; Display all of the stacks, spaced 20 columns apart (defun display-stacks (x y stacks) (cond (stacks (progn (display-stack x 0 (stack-pos y (car stacks)) (car stacks)) (display-stacks (+ x 20) y (cdr stacks))) ) ) ) ; Display all of the stacks, then move the cursor ; out of the way and flush the output (defun display () (display-stacks 0 top stacks) (move-to 1 21) (flush) ) ; Reset stacks to the starting state, with ; all of the pieces in the first stack and the ; other two empty (defun reset-stacks () (setq stacks (list stack nil nil)) (length stack) ) ; more functions which could usefully ; be in the rom image (defun min (a b) (cond ((< a b) a) (b) ) ) (defun nth (list n) (cond ((= n 0) (car list)) ((nth (cdr list) (1- n))) ) ) ; Replace a stack in the list of stacks ; with a new value (defun replace (list pos member) (cond ((= pos 0) (cons member (cdr list))) ((cons (car list) (replace (cdr list) (1- pos) member))) ) ) ; Move a piece from the top of one stack ; to the top of another (defun move-piece (from to) (let ((from-stack (nth stacks from)) (to-stack (nth stacks to)) (piece (car from-stack))) (setq from-stack (cdr from-stack)) (setq to-stack (cons piece to-stack)) (setq stacks (replace stacks from from-stack)) (setq stacks (replace stacks to to-stack)) (display) (delay 100) ) ) ; The implementation of the game (defun _hanoi (n from to use) (cond ((= 1 n) (progn (move-piece from to) nil) ) (t (progn (_hanoi (1- n) from use to) (_hanoi 1 from to use) (_hanoi (1- n) use to from) ) ) ) ) ; A pretty interface which ; resets the state of the game, ; clears the screen and runs ; the program (defun hanoi () (setq len (reset-stacks)) (clear) (_hanoi len 0 1 2) )
Categories: Elsewhere

Russ Allbery: Review: The Broken Kingdoms

Planet Debian - Tue, 15/11/2016 - 04:29

Review: The Broken Kingdoms, by N.K. Jemisin

Series: Inheritance #2 Publisher: Orbit Copyright: November 2010 Printing: September 2011 ISBN: 0-316-04395-8 Format: Mass market Pages: 395

The Broken Kingdoms is a fairly direct sequel to The Hundred Thousand Kingdoms and depends heavily on the end of that book. It had been a long time since I'd read the previous book (about five years), and I looked up plot summaries to remind myself what happened. It turned out that I probably didn't have to do that; the explanation does come when it's critical. But this book will definitely spoil the end of The Hundred Thousand Kingdoms.

Oree is an artist who sells her work to tourists in Shadow, the city beneath the World Tree. It's a good enough living, particularly for a blind immigrant from Nimaro, the area settled by the survivors of the destruction of Maro. Oree is not strictly entirely blind, since she can see magic, but that's not particularly helpful in daily life. She's content to keep that quiet, along with her private paintings that carry a strange magic not found in her public trinkets.

One of the many godlings who inhabit Shadow is Oree's former lover, so she has some connection to the powerful of the city. But she prefers her quiet life — until, that is, she finds a man at sunrise in a pile of muck and takes him home to clean him up. A man who she ends up taking care of, despite the fact that he never speaks to her, and despite his total lack of desire or apparent capability to take care of himself or avoid any danger. Not that it seems to matter, since he comes back to life every time he dies.

If you've read The Hundred Thousand Kingdoms, you have a pretty good guess at who the man Oree calls Shiny actually is. But that discovery is not the core plot of this book. Someone is killing the godlings. They're not immortal, although they don't age, but killing them should require immense power or the intervention of the Three, the gods who run the metaphysical universe of this series. Neither of those seem to be happening, and still godlings are being murdered. Nahadoth is not amused: the humans and godlings have one month to find the killer before he does something awful to all of them. Then Shiny somehow kills a bunch of priests of Itempas, and the Order is after both him and Oree. Desperate, she turns to her former boyfriend and the godlings for help, and is pulled into the heart of a dark conspiracy.

The Broken Kingdoms adds a few new elements to Jemisin's world-building, although it never quite builds up to the level of metaphysics of the previous book. But it's mostly a book about Oree: her exasperated care of Shiny, her attempts to navigate her rapidly complicating life, and her determination to do the right thing for her friends. It's the sort of book that pits cosmic power and grand schemes against the determined inner morality of a single person who is more powerful than she thinks she is. That part of the story I liked quite a lot.

Shiny, and Oree's complicated relationship with Shiny, I wasn't as fond of. Oree treats him like a broken and possibly healing person, which is true, but he's also passively abusive in his dark moping. Jemisin tries very hard throughout the book to help the reader try to grasp a bit of what must be going through Shiny's head, and she does succeed at times, but I never much cared for what I found there. And neither Nahadoth nor Yeine, when they finally make their appearance, are very likable. (Yeine in particular I found deeply disappointing and not up to her level of ethics in the first book.) Oree is still quite capable of carrying the story single-handed, and I did like her godling friends. But I felt like the ending required liking Shiny a lot more than I did, or being a lot more sympathetic to Nahadoth and Yeine than I was, and it left a bad taste in my mouth. I enjoyed reading about Oree, but I felt like this story gave her a remarkably depressing ending.

This book is also structured with a long middle section where everything seems to get more and more horrible and the antagonists are doing awful things. It's a common structural way to build tension that I rarely like. Even knowing that there's doubtless an upward arc and protagonist triumph coming, those sections are often unpleasant and difficult to read through, and I had that reaction here.

The Broken Kingdoms is less of a weird romance than The Hundred Thousand Kingdoms (although there is some romance), so you may enjoy it more if you thought that angle was overdone. It does have some interesting world-building, particularly at the godling level, and Lil is one of my favorite characters. I think Oree got a raw deal from the story and would have preferred a different ending, but I'm not sorry I read it.

Followed by The Kingdoms of Gods.

Rating: 7 out of 10

Categories: Elsewhere

Russ Allbery: Review: The Broken Kingdoms

Planet Debian - Tue, 15/11/2016 - 04:29

Review: The Broken Kingdoms, by N.K. Jemisin

Series: Inheritance #2 Publisher: Orbit Copyright: November 2010 Printing: September 2011 ISBN: 0-316-04395-8 Format: Mass market Pages: 395

The Broken Kingdoms is a fairly direct sequel to The Hundred Thousand Kingdoms and depends heavily on the end of that book. It had been a long time since I'd read the previous book (about five years), and I looked up plot summaries to remind myself what happened. It turned out that I probably didn't have to do that; the explanation does come when it's critical. But this book will definitely spoil the end of The Hundred Thousand Kingdoms.

Oree is an artist who sells her work to tourists in Shadow, the city beneath the World Tree. It's a good enough living, particularly for a blind immigrant from Nimaro, the area settled by the survivors of the destruction of Maro. Oree is not strictly entirely blind, since she can see magic, but that's not particularly helpful in daily life. She's content to keep that quiet, along with her private paintings that carry a strange magic not found in her public trinkets.

One of the many godlings who inhabit Shadow is Oree's former lover, so she has some connection to the powerful of the city. But she prefers her quiet life — until, that is, she finds a man at sunrise in a pile of muck and takes him home to clean him up. A man who she ends up taking care of, despite the fact that he never speaks to her, and despite his total lack of desire or apparent capability to take care of himself or avoid any danger. Not that it seems to matter, since he comes back to life every time he dies.

If you've read The Hundred Thousand Kingdoms, you have a pretty good guess at who the man Oree calls Shiny actually is. But that discovery is not the core plot of this book. Someone is killing the godlings. They're not immortal, although they don't age, but killing them should require immense power or the intervention of the Three, the gods who run the metaphysical universe of this series. Neither of those seem to be happening, and still godlings are being murdered. Nahadoth is not amused: the humans and godlings have one month to find the killer before he does something awful to all of them. Then Shiny somehow kills a bunch of priests of Itempas, and the Order is after both him and Oree. Desperate, she turns to her former boyfriend and the godlings for help, and is pulled into the heart of a dark conspiracy.

The Broken Kingdoms adds a few new elements to Jemisin's world-building, although it never quite builds up to the level of metaphysics of the previous book. But it's mostly a book about Oree: her exasperated care of Shiny, her attempts to navigate her rapidly complicating life, and her determination to do the right thing for her friends. It's the sort of book that pits cosmic power and grand schemes against the determined inner morality of a single person who is more powerful than she thinks she is. That part of the story I liked quite a lot.

Shiny, and Oree's complicated relationship with Shiny, I wasn't as fond of. Oree treats him like a broken and possibly healing person, which is true, but he's also passively abusive in his dark moping. Jemisin tries very hard throughout the book to help the reader try to grasp a bit of what must be going through Shiny's head, and she does succeed at times, but I never much cared for what I found there. And neither Nahadoth nor Yeine, when they finally make their appearance, are very likable. (Yeine in particular I found deeply disappointing and not up to her level of ethics in the first book.) Oree is still quite capable of carrying the story single-handed, and I did like her godling friends. But I felt like the ending required liking Shiny a lot more than I did, or being a lot more sympathetic to Nahadoth and Yeine than I was, and it left a bad taste in my mouth. I enjoyed reading about Oree, but I felt like this story gave her a remarkably depressing ending.

This book is also structured with a long middle section where everything seems to get more and more horrible and the antagonists are doing awful things. It's a common structural way to build tension that I rarely like. Even knowing that there's doubtless an upward arc and protagonist triumph coming, those sections are often unpleasant and difficult to read through, and I had that reaction here.

The Broken Kingdoms is less of a weird romance than The Hundred Thousand Kingdoms (although there is some romance), so you may enjoy it more if you thought that angle was overdone. It does have some interesting world-building, particularly at the godling level, and Lil is one of my favorite characters. I think Oree got a raw deal from the story and would have preferred a different ending, but I'm not sorry I read it.

Followed by The Kingdoms of Gods.

Rating: 7 out of 10

Categories: Elsewhere

Savas Labs: Using MailChimp API v3.0 to subscribe users to email lists in Drupal custom modules

Planet Drupal - Tue, 15/11/2016 - 01:00

A tutorial that shows you how to use Composer and ThinkShout's new PHP library for MailChimp API v3.0 to easily subscribe users to mailing lists in Drupal custom modules without using the MailChimp contributed module. This is a follow-up to a previous post that used the old API, and also includes some new Drupal 8 specifics. Continue reading…

Categories: Elsewhere

Mike Gabriel: Debian Edu development sprint in Oslo from Nov 25th - Nov 27th 2016

Planet Debian - Mon, 14/11/2016 - 21:08

For those of you, who already thought about joining us in Oslo for our Debian Edu sprint, here comes your short reminder for signing up on this wiki page and then book your travel.

For those of you, who have learned about our upcoming sprint just now, feel heartily invited to meet and join the Debian Edu team (and friends) in Oslo. Check with your family and friends, if they may let you go. Do that now, put your name onto our wiki page and and book your journey.

Those of you, who cannot travel to Oslo, but feel like being interested in Debian and educational topics around Free Software, put a note into your calendar, so you don't forget to join us on IRC over that weekend (and any other time if you like): #debian-edu on irc.debian.org.

Looking forward to meeting you at end of November,
Mike (aka sunweaver)

Categories: Elsewhere

Mike Gabriel: Debian Edu development sprint in Oslo from Nov 25th - Nov 27th 2016

Planet Debian - Mon, 14/11/2016 - 21:08

For those of you, who already thought about joining us in Oslo for our Debian Edu sprint, here comes your short reminder for signing up on this wiki page and then book your travel.

For those of you, who have learned about our upcoming sprint just now, feel heartily invited to meet and join the Debian Edu team (and friends) in Oslo. Check with your family and friends, if they may let you go. Do that now, put your name onto our wiki page and and book your journey.

Those of you, who cannot travel to Oslo, but feel like being interested in Debian and educational topics around Free Software, put a note into your calendar, so you don't forget to join us on IRC over that weekend (and any other time if you like): #debian-edu on irc.debian.org.

Looking forward to meeting you at end of November,
Mike (aka sunweaver)

Categories: Elsewhere

Mediacurrent: Good Form: 5 Tips for a Smooth Sign-up Process

Planet Drupal - Mon, 14/11/2016 - 20:10

A lot of effort goes into engaging your visitors to ‘Sign-up’ or ‘Contact’ you. You send them a warm and fuzzy invitation to complete the form, tell them all the great reasons why they should complete the form… but who likes to complete a form? You can help guarantee a smooth sign-up process and increase the completion rate of your web forms with these five tips.

#1 Make it Flow

Before you begin designing that web form, it is always good to create a User Flowchart. Working to establish the form completion process from start to finish, a flowchart will help you:

Categories: Elsewhere

Chromatic: Introducing "ShouldIUpgradetoDrupal8.com"

Planet Drupal - Mon, 14/11/2016 - 19:06

We find that there's still uncertainty out there around upgrading to Drupal 8. The natural answer in the Drupal community is, "Yes, of course go with Drupal 8!", but in the world of tight deadlines and tighter budgets, the answer isn't so clear. Enter ShouldIUpgradetoDrupal8.com, an interactive tool we built to help the community answer that very question.

Categories: Elsewhere

Acquia Developer Center Blog: Contribution Stories: Preston So, Decoupled Drupal with Ember

Planet Drupal - Mon, 14/11/2016 - 18:49

Drupal gets better when companies, organizations, and individuals build or fix something they need and then share it with the rest of us. Our community becomes better, stronger, and smarter when others take it upon themselves to make a positive difference contributing their knowledge, time, and energy to Drupal. Acquia is proud to play a part, alongside thousands of others, in some of the stories making tomorrow’s Drupal better than today’s. One of them Preston So’s.

Tags: acquia drupal planetemberjavascriptfront enddrupalconDublin
Categories: Elsewhere

Rapha&#235;l Hertzog: Freexian’s report about Debian Long Term Support, October 2016

Planet Debian - Mon, 14/11/2016 - 18:15

Like each month, here comes a report about the work of paid contributors to Debian LTS.

Individual reports

In October, about 175 work hours have been dispatched among 14 paid contributors. Their reports are available:

Evolution of the situation

The number of sponsored hours did not change this month. We still need a couple of supplementary sponsors to reach our objective of funding the equivalent of a full time position.

The security tracker currently lists 34 packages with a known CVE and the dla-needed.txt file 29. The situation improved slightly compared to last month.

Thanks to our sponsors

New sponsors are in bold.

No comment | Liked this article? Click here. | My blog is Flattr-enabled.

Categories: Elsewhere

Rapha&#235;l Hertzog: Freexian’s report about Debian Long Term Support, October 2016

Planet Debian - Mon, 14/11/2016 - 18:15

Like each month, here comes a report about the work of paid contributors to Debian LTS.

Individual reports

In October, about 175 work hours have been dispatched among 14 paid contributors. Their reports are available:

Evolution of the situation

The number of sponsored hours did not change this month. We still need a couple of supplementary sponsors to reach our objective of funding the equivalent of a full time position.

The security tracker currently lists 34 packages with a known CVE and the dla-needed.txt file 29. The situation improved slightly compared to last month.

Thanks to our sponsors

New sponsors are in bold.

No comment | Liked this article? Click here. | My blog is Flattr-enabled.

Categories: Elsewhere

Ben Hutchings: Debian LTS work, October 2016

Planet Debian - Mon, 14/11/2016 - 18:03

I was assigned 13.75 hours of work by Freexian's Debian LTS initiative and worked all of them.

I reviewed the fix for CVE-2016-7796 in wheezy's systemd, which needed substantial changes and a few iterations to get right.

I updated linux to the 3.2.82 stable release (and 3.2.82-rt119 for PREEMPT_RT), and added fixes for several security issues including CVE-2016-5195 "Dirty Cow". I uploaded and issued DLA-670-1.

In my role as Linux 3.2 stable maintainer, I made a 3.2.83 release fixing just that issue, and started to prepare a 3.2.84 release with many more fixes.

I cleaned up my work on imagemagick, but didn't go further through the backlog of issues. I put the partly updated package on people.debian.org for another LTS maintatainer to pick up.

Categories: Elsewhere

Ben Hutchings: Debian LTS work, October 2016

Planet Debian - Mon, 14/11/2016 - 18:03

I was assigned 13.75 hours of work by Freexian's Debian LTS initiative and worked all of them.

I reviewed the fix for CVE-2016-7796 in wheezy's systemd, which needed substantial changes and a few iterations to get right.

I updated linux to the 3.2.82 stable release (and 3.2.82-rt119 for PREEMPT_RT), and added fixes for several security issues including CVE-2016-5195 "Dirty Cow". I uploaded and issued DLA-670-1.

In my role as Linux 3.2 stable maintainer, I made a 3.2.83 release fixing just that issue, and started to prepare a 3.2.84 release with many more fixes.

I cleaned up my work on imagemagick, but didn't go further through the backlog of issues. I put the partly updated package on people.debian.org for another LTS maintatainer to pick up.

Categories: Elsewhere

Palantir: Palantir.net's Guide to Digital Governance: URL Naming Conventions

Planet Drupal - Mon, 14/11/2016 - 17:50
Palantir.net's Guide to Digital Governance: URL Naming Conventions Palantir.net's Guide to Digital Governance brandt Mon, 11/14/2016 - 10:50 Scott DiPerna Nov 14, 2016

This is the eighth installment of Palantir.net’s Guide to Digital Governance, a comprehensive guide intended to help get you started when developing a governance plan for your institution’s digital communications.

In this post we will cover...
  • A recommended naming convention for URL paths
  • Some tips for choosing section names
  • Questions to consider when defining rules for redirects and aliases

We want to make your project a success.

Let's Chat.

A logical progression from Website organization is defining a naming convention for URL paths. URL paths should follow a consistent naming convention throughout all of your websites. Only under exceptional circumstances should a URL path name deviate from an established naming convention for a Website.

Best practices for URL path naming conventions recommend consistency in how sections, sub-sections, pages, and sub-pages are written. For most websites, I recommend URL paths follow the general naming convention below. 

     http://domain.com/SECTION/SUB-SECTION/PAGE/SUB-PAGE

This basic structure gives users an idea of where they are in the site’s hierarchy of pages. This can be especially important considering the volume of traffic that enters the site from web searches that will bypass the homepage and take visitors directly into deeper pages in the site. It’s also a good practice for improving the SEO value of your site’s pages, as it provides more specific context for the content of the page.

Section

Under this convention, SECTION is the top-level “directory,” and generally refers to the category under which subsequent content resides. For example, in the URL path http://domain.com/about, “About” is a primary category that often appears in a main menu, and thus receives a top-level URL path.

I generally like SECTION names to be one continuous string of letters without hyphens or underscores (e.g. about, services, people, etc.) because that makes for shorter top-level URL paths, however two word hyphens may also be acceptable if they aren’t too long. Given that top-level SECTION names are usually the label-names of your main navigation, it’s additionally wise to keep them clear, simple and concise.

Acronyms and abbreviations should be avoided because they often don’t make sense to visitors unfamiliar with the abbreviations. That being said, some abbreviations, such as http://domain.com/faq, may work so long as they make logical sense to most visitors.

If your Website has multiple users who are able to write URL path names, I recommended defining in the governance plan some limitation for who may write top-level directory names. These are typically the most highly sought-after URLs in a Website, and you will want to have a well-defined process for how those are distributed and assigned. A free-for-all is probably not a good process.

Sub-Section

SUB-SECTION is the second-level directory, if one exists. Using About as an example, “Meet Our Team” is the second-level “directory” in the URL path:

     http://domain.com/about/team

since “Meet Our Team” is just one of the sub-sections under “About” in this example.

SUB-SECTION names also may be one continuous string of letters without hyphens or underscores, such as:

     http://domain.com/about/team

or a string of words separated by hyphens:

     http://domain.com/about/meet-our-team.

The choice between the two really depends on whether the additional words add value to the user’s understanding of location, and/or if the string of words adds SEO value because it captures important descriptive words for the content of the page.

In the example above, the words “meet our” really don’t add much information, and the shorter URL path name is simpler. Simplicity may become more important as you add pages to sub-sections and the URL path names become very long.

Some URL path names may appear to deviate from this rule if a sub-section does not actually exist, in which case the sub-section location would be occupied by the page name.

Page

Pages on the “Meet Our Team” site would then have a URL path structure of:

     http://domain.com/about/team/PAGE-NAME

where PAGE-NAME could be any number of different page names. PAGE-NAMEs should generally describe the content of the page based on the page’s title. This can be expressed either as a single word (if a single word sufficiently describes the page), such as:

     http://domain.com/about/team/consultants

where “consultants” is a page for information about consultants on the team titled “Consultants”; or by a string of hyphenated words, such as:

     http://domain.com/about/team/website-consultants

where “website-consultants” is a page about Website consultants on the team titled “Web Consultants.”

For the purposes of SEO, at the page level, I generally prefer to include all of the keywords in a page’s title (separated by hyphens) in the URL path, especially when it adds descriptive value.

Sub-Page

As follows, sub-pages for any of the pages in the “Meet Our Team” site would have a URL path structure:

     http://domain.com/about/team/PAGE-NAME/SUB-PAGE-NAME SUB-PAGE-NAMEs

should follow the same rules as PAGE-NAMEs, however sub-page names may require longer strings of hyphenated names as pages become more detailed and specific:

     http://domain.com/about/team/consultants/drupal-content-management-system

Conversely, if sub-pages are breaking out content into simpler categories, they may benefit from shorter names:

     http://domain.com/about/services/web-platforms/drupal

rather than:

     http://domain.com/about/services/web-platforms/drupal-content-management-system

All of that being said, you should determine the system that works best for your needs and stick to it. Just keep it simple, logical, and as memorable as possible so that it is easy for all users to implement.

Multiple-Word Names

When writing URL paths with multiple-word names, I recommend using hyphens, such as:

     http://domain.com/about/services/web-platforms/drupal-content-management-system

rather than underscores:

     http://domain.com/about/services/web_platforms/drupal_content_management_system

or concatenation:

     http://domain.com/about/services/webplatforms/drupalcontentmanagementsystem

Use of underscores makes it far too easy for a user to misread an underscore as a space, especially when the URL path is hyperlinked:

     http://domain.com/about/services/web_platforms/drupal_content_management_system

Most hyperlinks are underlined to indicate to users that a section of text is a hyperlink.

Concatenation is more obviously problematic because it simply creates confusing URL paths.

Aliases & Redirects

How URL path aliases and redirected URL paths are handled will depend on the policies of your organization and the platform you use for your Website. I highly recommend you define the rules and processes surrounding URL aliases and redirects in your governance plan, and here are some questions to consider along those lines.

  • How are URL aliases and redirects managed in your Web environment?
  • Who manages URL aliases and redirects?
  • Is there a process or procedure for requesting an alias or a redirect?
  • May anyone request a URL alias or redirect?
  • Are redirects to Websites outside of your domain or server environment permitted?
  • Who determines whether a URL alias or redirected URL path is appropriate or not?
  • Are there any special rules for using top-level directories as URL path aliases or redirected URL paths?

 

This post is part of a larger series of posts, which make up a Guide to Digital Governance Planning. The sections follow a specific order intended to help you start at a high-level of thinking and then focus on greater and greater levels of detail. The sections of the guide are as follows:

  1. Starting at the 10,000ft View – Define the digital ecosystem your governance planning will encompass.
  2. Properties and Platforms – Define all the sites, applications and tools that live in your digital ecosystem.
  3. Ownership – Consider who ultimately owns and is responsible for each site, application and tool.
  4. Intended Use – Establish the fundamental purpose for the use of each site, application and tool.
  5. Roles and Permissions – Define who should be able to do what in each system.
  6. Content – Understand how ownership and permissions should apply to content.
  7. Organization – Establish how the content in your digital properties should be organized and structured.
  8. URL Naming Conventions – Define how URL patterns should be structured in your websites.
  9. Design – Determine who owns and is responsible for the many aspects design plays in digital communications and properties.
  10. Personal Websites – Consider the relationship your organization should have with personal websites of members of your organization.
  11. Private Websites, Intranets and Portals – Determine the policies that should govern site which are not available to the public.
  12. Web-Based Applications – Consider use and ownership of web-based tools and applications.
  13. E-Commerce – Determine the role of e-commerce in your website.
  14. Broadcast Email – Establish guidelines for the use of broadcast email to constituents and customers.
  15. Social Media – Set standards for the establishment and use of social media tools within the organization.
  16. Digital Communications Governance – Keep the guidelines you create updated and relevant.

Stay connected with the latest news on web strategy, design, and development.

Sign up for our newsletter.
Categories: Elsewhere

Dimitri John Ledkov: /boot less LVM rootfs in Zesty

Planet Debian - Mon, 14/11/2016 - 16:11

On Ubuntu many of the default boot loaders support booting kernels located on LVM volumes. This includes following platforms

  • i686, x86_64 bios grub2
  • arm64, armhf, i686, x86_64 UEFI grub2
  • PReP partitions on IBM PowerPC
  • zipl on IBM zSystems
For all of the above the d-i has been modified in Zesty to create LVM based installations without a dedicated /boot partition. We shall celebrate this achievement. Hopefully this means one doesn't need to remove kernels as much, or care about sizing /boot volume appropriately any more.
If there are more bootloaders in Ubuntu that support booting off LVM, please do get in touch with me. I'm interested if I can safely enable following platforms as well:
  • armhf with u-boot
  • arm64 with u-boot
  • ppc64el with PReP volume
ps. boots pic is from here
Categories: Elsewhere

Drupal Console: Drupal Console RC-9 is out

Planet Drupal - Mon, 14/11/2016 - 15:34

Latest DrupalConsole rc-9 is out including several changes and fixes.

Support for command aliases

Aliases for commands added making easy to memorize by typing less. You can find aliases definition at https://github.com/hechoendrupal/drupal-console-core/blob/master/config/dist/aliases.yml

Support to execute the DrupalConsole Launcher on Windows platform

This PR https://github.com/hechoendrupal/drupal-console-launcher/pull/51 fixes the `\vendor\bin\drupal.php` file not found error.

Execute DrupalConsole from any directory within your Drupal site

No need to stay at site root directory. You can now switch to any directory as modules, themes, web/modules/custom or any other directory within your Drupal site. This was possible using the DrupalFinder project https://github.com/webflo/drupal-finder/

NOTE: Having a configuration file containing `root: web` on the site is no longer required. You can keep the file but is required to remove that value from your `path/to/drupal8/console/config.yml`

Improvements on the `init` command 

The interactive mode for the init command now ask you and show a list of directories where to copy the configuration files.

    Update instructions:

    Categories: Elsewhere

    Gregor Herrmann: RC bugs 2016/40-45

    Planet Debian - Sun, 13/11/2016 - 23:23

    time for a quick update, I guess. here's the list of release-critical bugs in debian I've worked on during the last couple of weeks.

    • #825608 – libnet-jifty-perl: "libnet-jifty-perl: FTBFS: t/006-uploads.t failure"
      patch test for compatibility with newer Encode, not uploaded in the end because the problem is more likely in the code (pkg-perl)
    • #826192 – libmath-gsl-perl: "libmath-gsl-perl: FTBFS with GSL 2"
      import new upstream release (pkg-perl)
    • #828386 – src:libcrypt-openssl-pkcs12-perl: "libcrypt-openssl-pkcs12-perl: FTBFS with openssl 1.1.0"
      sponsor upload with upstream patch (pkg-perl)
    • #828388 – src:libcrypt-openssl-x509-perl: "libcrypt-openssl-x509-perl: FTBFS with openssl 1.1.0"
      cherry-pick 2 commits from upstream git repo (pkg-perl)
    • #828389 – src:libcrypt-smime-perl: "libcrypt-smime-perl: FTBFS with openssl 1.1.0"
      import new upstream release (pkg-perl)
    • #828408 – src:libpoe-filter-ssl-perl: "libpoe-filter-ssl-perl: FTBFS with openssl 1.1.0"
      use openssl 1.0.2, & downgrade severity (pkg-perl)
    • #830280 – src:libfurl-perl: "libfurl-perl: accesses the internet during build"
      disable DNS queries during build (pkg-perl)
    • #834730 – src:libdist-zilla-plugins-cjm-perl: "libdist-zilla-plugins-cjm-perl: FTBFS: Failed 1/9 test programs. 2/126 subtests failed."
      add patch from CPAN RT (pkg-perl)
    • #839200 – libcpanplus-perl: "libcpanplus-perl: FTBFS: Failed test 'Cwd has correct version in report'"
      add patch from upstream git (pkg-perl)
    • #839505 – src:mongodb: "mongodb: FTBFS: Tests failures"
      propose a possible solution
    • #839580 – src:request-tracker4: "request-tracker4: FTBFS in testing (failed tests)"
      prepare a workaround patch
    • #839987 – libcompress-raw-lzma-perl: "libcompress-raw-lzma-perl: Version Mismatch due to new src:xz-utils"
      patch out version check at runtime (pkg-perl)
    • #839992 – libmath-quaternion-perl: "libmath-quaternion-perl: autopkgtest failure: not ok 48 - rotation_angle works"
      some triaging (pkg-perl)
    • #840479 – src:libdbd-firebird-perl: "libdbd-firebird-perl: FTBFS: libfbembed.so not found"
      versioned close (pkg-perl)
    • #840980 – libperinci-sub-normalize-perl: "libperinci-sub-normalize-perl: FTBFS: Can't locate Sah/Schema/rinci/function_meta.pm in @INC"
      add new (build) dependency, after packaging it (pkg-perl)
    • #841545 – src:liborlite-perl: "liborlite-perl: FTBFS: Tests failures"
      fix sqlite commands (pkg-perl)
    • #841562 – src:libvideo-fourcc-info-perl: "libvideo-fourcc-info-perl: FTBFS: dh_auto_build: perl Build returned exit code 255"
      fix sqlite commands (pkg-perl)
    • #841573 – src:libdbix-class-perl: "libdbix-class-perl: FTBFS: Tests failures"
      patch test suite as recommended by upstream (pkg-perl)
    • #842460 – libplack-middleware-csrfblock-perl: "libplack-middleware-csrfblock-perl: FTBFS: missing dependencies on HTML::Parser"
      add missing (build) dependency (pkg-perl)
    • #842462 – libweb-simple-perl: "libweb-simple-perl: FTBFS: Can't locate HTTP/Body.pm in @INC"
      add missing (build) dependency (pkg-perl)
    • #842722 – src:kgb-bot: "kgb-bot: FTBFS (failing tests)"
      fix version comparison in test
    • #843704 – libnet-pcap-perl: "libnet-pcap-perl: FTBFS: t/09-error.t fails with newer libpcap"
      add patch from CPAN RT (pkg-perl)
    Categories: Elsewhere

    Gregor Herrmann: RC bugs 2016/40-45

    Planet Debian - Sun, 13/11/2016 - 23:23

    time for a quick update, I guess. here's the list of release-critical bugs in debian I've worked on during the last couple of weeks.

    • #825608 – libnet-jifty-perl: "libnet-jifty-perl: FTBFS: t/006-uploads.t failure"
      patch test for compatibility with newer Encode, not uploaded in the end because the problem is more likely in the code (pkg-perl)
    • #826192 – libmath-gsl-perl: "libmath-gsl-perl: FTBFS with GSL 2"
      import new upstream release (pkg-perl)
    • #828386 – src:libcrypt-openssl-pkcs12-perl: "libcrypt-openssl-pkcs12-perl: FTBFS with openssl 1.1.0"
      sponsor upload with upstream patch (pkg-perl)
    • #828388 – src:libcrypt-openssl-x509-perl: "libcrypt-openssl-x509-perl: FTBFS with openssl 1.1.0"
      cherry-pick 2 commits from upstream git repo (pkg-perl)
    • #828389 – src:libcrypt-smime-perl: "libcrypt-smime-perl: FTBFS with openssl 1.1.0"
      import new upstream release (pkg-perl)
    • #828408 – src:libpoe-filter-ssl-perl: "libpoe-filter-ssl-perl: FTBFS with openssl 1.1.0"
      use openssl 1.0.2, & downgrade severity (pkg-perl)
    • #830280 – src:libfurl-perl: "libfurl-perl: accesses the internet during build"
      disable DNS queries during build (pkg-perl)
    • #834730 – src:libdist-zilla-plugins-cjm-perl: "libdist-zilla-plugins-cjm-perl: FTBFS: Failed 1/9 test programs. 2/126 subtests failed."
      add patch from CPAN RT (pkg-perl)
    • #839200 – libcpanplus-perl: "libcpanplus-perl: FTBFS: Failed test 'Cwd has correct version in report'"
      add patch from upstream git (pkg-perl)
    • #839505 – src:mongodb: "mongodb: FTBFS: Tests failures"
      propose a possible solution
    • #839580 – src:request-tracker4: "request-tracker4: FTBFS in testing (failed tests)"
      prepare a workaround patch
    • #839987 – libcompress-raw-lzma-perl: "libcompress-raw-lzma-perl: Version Mismatch due to new src:xz-utils"
      patch out version check at runtime (pkg-perl)
    • #839992 – libmath-quaternion-perl: "libmath-quaternion-perl: autopkgtest failure: not ok 48 - rotation_angle works"
      some triaging (pkg-perl)
    • #840479 – src:libdbd-firebird-perl: "libdbd-firebird-perl: FTBFS: libfbembed.so not found"
      versioned close (pkg-perl)
    • #840980 – libperinci-sub-normalize-perl: "libperinci-sub-normalize-perl: FTBFS: Can't locate Sah/Schema/rinci/function_meta.pm in @INC"
      add new (build) dependency, after packaging it (pkg-perl)
    • #841545 – src:liborlite-perl: "liborlite-perl: FTBFS: Tests failures"
      fix sqlite commands (pkg-perl)
    • #841562 – src:libvideo-fourcc-info-perl: "libvideo-fourcc-info-perl: FTBFS: dh_auto_build: perl Build returned exit code 255"
      fix sqlite commands (pkg-perl)
    • #841573 – src:libdbix-class-perl: "libdbix-class-perl: FTBFS: Tests failures"
      patch test suite as recommended by upstream (pkg-perl)
    • #842460 – libplack-middleware-csrfblock-perl: "libplack-middleware-csrfblock-perl: FTBFS: missing dependencies on HTML::Parser"
      add missing (build) dependency (pkg-perl)
    • #842462 – libweb-simple-perl: "libweb-simple-perl: FTBFS: Can't locate HTTP/Body.pm in @INC"
      add missing (build) dependency (pkg-perl)
    • #842722 – src:kgb-bot: "kgb-bot: FTBFS (failing tests)"
      fix version comparison in test
    • #843704 – libnet-pcap-perl: "libnet-pcap-perl: FTBFS: t/09-error.t fails with newer libpcap"
      add patch from CPAN RT (pkg-perl)
    Categories: Elsewhere

    Pages

    Subscribe to jfhovinne aggregator - Elsewhere