Bug#822661: ITP: python-et-xmlfile -- low memory Python library for creating large XML files

[Afif Elghraoui]

Package: wnpp
Severity: wishlist
Owner: Afif Elghraoui 
Control: block 822414 by -1

* Package name: python-et-xmlfile
  Version : 1.0.1
  Upstream Author : Charlie Clark  and Elias 
Rabel
* URL : https://bitbucket.org/openpyxl/et_xmlfile
* License : MIT
  Programming Lang: Python
  Description : low memory Python library for creating large XML files

et_xmlfile is a low memory library for creating large XML files.

It is based upon the xmlfile module from lxml with the aim of allowing
code to be developed that will work with both libraries.
It was developed initially for the openpyxl project but is now a standalone
module.


This package is a new dependency of openpyxl, but was swept under the rug in 
the Debian package, resulting in #822414.
It will be maintained in collab-maint.

Re: dedicated live CD for PGP master key management

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 25/04/16 23:06, Christian Seiler wrote:
> On 04/25/2016 08:54 PM, Daniel Pocock wrote:
>> On 25/04/16 19:03, Christian Seiler wrote:
 Does the workflow make sense?
>>> 
>>> In principle yes, however it doesn't quite fit with my the 
>>> workflow I'd like to use something like that for: my master key
>>> is on a two separate SD cards, and I only have one SD card
>>> reader. So what I do when I need to change something on the key
>>> is to insert one SD card, copy the .gnupg directory to a tmpfs,
>>> do the modifications, copy the directory back to the first SD
>>> card, and then copy the directory back to the second SD card.
>>> Any RAID solution wouldn't work for me, as I can't insert both
>>> cards at the same time. (Also, many people only have a limited
>>> amount of USB ports, and not every person wants to buy a hub
>>> just for this, so even with USB keys RAID might not always be
>>> easily possible, especially if you need one port for booting
>>> the system.)
>>> 
>> 
>> We could make it work that way
>> 
>> One of the things that appeals to me about BtrFS is that if one
>> flash drive returns bad data, BtrFS will know which one has the
>> good data and the application won't have to compensate for that.
> 
> Yes, but you'd still have to somehow communicate to the user that 
> one of the drives was bad and that it has to be replaced, so the 
> application will need to provide some kind of interface here.
> 
> Also, in this case, if there really is corruption in essential data
> by the flash drive, this will immediately show up - as the public
> and private keys won't match in that case.
> 
>> The solution you describe is feasible but would possibly require
>> more manual effort if one of the flash drives fail
> 
> I don't believe so. btrfs replacement only works well if you have 
> both the failed and the new drive plugged in (and at least the 
> headers are accessible and good), otherwise you have to mount the 
> device in degraded mode, manually add the new drive and then remove
> the missing one. Doable, but in my view this appears to be more
> complicated than a manual copy logic of a directory.
> 
>> or if they become out of sync by way of human error.
> 
> Yes, this would be the only advantage.
> 
> On the other hand, at least with GnuPG 2.1+ (if I understand it 
> correctly) the private keys are now just the mathematical 
> paraemters required for usage. This in turn means that only the 
> public keyring carries all the information (uids, expiry, etc.). 
> And public keys can be merged without a problem.
> 
> So for nearly all operations you could conceivably do (renewal, 
> recovation, adding new subkeys [*], signing other people's keys) 
> you don't actually need to keep them in sync explicitly, because 
> you always take your public key with you to your normal system, so
> every time you boot the master key mgmt live CD, you have the 
> master key drives as input for the secret key, but the public key
> can also come from the USB stick you use to interface the live CD
> with the rest of the world.
> 
> I therefore don't see any real issue with synchronizing them. 
> Additionally, I think there is a perfectly valid workflow where you
> don't modify all of the copies of the master key disk. For example,
> let's say I want to store one of the copies with family or in a
> safety deposit box, just as an additional backup against the house
> burning down or so. Then I generate the GPG key, make 3 copies,
> keep 1 of those copies for myself, store one in a safety deposit
> box at a local bank and give the other to e.g. my parents for
> safekeeping. For daily usage I just use my own copy of the master
> key, but if that fails (due to e.g. the flash drive giving up), I
> can use one of the other backups.
> 
>> The Live DVD will have a terminal, like the installer, so anybody
>> who doesn't want to use the workflow can drop into the shell and
>> do whatever they want using the utilities that are present in the
>> filesystem.
> 
> Sure. I still think semi-automatic copies are easier to handle from
> an application standpoint than filesystem or block device RAID.
> 
> Think of it this way: you need to put in 3 flash drives (be it USB
> sticks or SD cards) for normal operation if you only have a single
> copy: one for booting the live key management (unless you still
> have a CD drive, which my laptop e.g. doesn't), one that contains
> the master key, and one for exchanging data with the outside
> world.
> 
> But if you just use copies, this is far easier: at the beginning 
> you ask the user to plug in the master key flash drive. The .gnupg
> directory is then copied to a tmpfs ramdisk. The user is then told
> that they can remove the master key flash drive again and may now
> insert the flash drive used for data exchange with the outside
> world. The user then performs the operations they want to do (key
> renewal, signing of other users' keys, e

Re: Extending the build profile namespace

[Johannes Schauer]

Hi,

Quoting Helmut Grohne (2016-04-25 20:06:07)
> >  2. Require the implementation of a new bootstrap planner which would be
> > able to mine the profile-specific build-dependency information to
> > construct a bootstrap plan.
> 
> There is another reason to require a bootstrap planner: prevail sanity.
> The days of manually ordering architecture bootstrap have long passed.
> Everyone uses at least partially automatic ordering in one way or
> another.
> 
> For instance, rebootstrap orders builds and decides which packages to
> build by running dose-builddebcheck. That tooling allows selecting 30%
> and ordering 70% of the packages (increasing as more maintainers apply
> patches) even though it doesn't do any profile selection yet. The major
> problem with adding profile selection currently is the lack of metadata
> and well-defined semantics.
> 
> So in a way, I agree: It requires a bootstrap planner. Johannes Schauer
> spent a gsoc and much more to lay the groundwork for it. Though it can
> only start working once we clean the mess created by inconsistent stage
> profiles with no meaning.
> 
> The hard part is not the writing of the planner. The hard part is
> getting sufficiently correct and complete metadata for it to operate.

I agree with Helmut. We already have the planner: It is called botch. The
missing bit is the part which does not read droppable build dependencies from a
ASCII text file but instead from the package metadata itself. Back when I
started implementing botch during my GSoC in 2012 build profiles didn't exist
yet and now that we have them, we are still changing bits here and there. Once
Stretch is out, I plan to add build profile parsing support to botch. The
existing algorithms will be able to deal even with large amounts of profiles.
There is no reason to limit oneself to just a "stage1" profile. One of the main
reasons I wrote botch in the first place was to automate the process of
choosing the correct profile to build source packages with and the algorithms
to do that in a computationally efficient manner exist. See my master thesis
[1], these publications [2] [3] and some of the talks I gave about the topic
[4] [5] for more details.

[1] http://mister-muffin.de/bootstrap/thesis.pdf
[2] http://mister-muffin.de/bootstrap/cbse2013.pdf
[3] http://mister-muffin.de/bootstrap/informatiktage2013.pdf#page=96
[4] https://fosdem.org/2013/schedule/event/debian_bootstrap/
[5] http://penta.debconf.org/dc13_schedule/events/984.en.html

The main remaining problem, as Helmut already pointed out is that currently,
the metadata botch is working on is missing or wrong [6]. Until that is fixed,
there is little a bootstrap planner can do. But continuous integration efforts
like rebootstrap will help to find these problems and get them fixed.

[6] https://wiki.debian.org/Sprints/2014/BootstrapSprint/Results

Thanks!

cheers, josch


signature.asc
Description: signature

Re: making a Debian Live CD for managing GnuPG master key and smartcards

[Dashamir Hoxha]

On Tue, Apr 26, 2016 at 9:53 AM, Daniel Pocock  wrote:

>
> There has been some discussion on debian-devel[1] about making a
> bootable Debian Live CD specifically for GnuPG
>
> The benefit is that everything on the CD is self-contained, it can't be
> tampered with, it can run without network support in the kernel and the
> workflow would be controlled by a script.  All the details, including
> workflow, are described in a wiki[2]
>
> I have some questions about this:
>
> - has anybody already seen anything like this?  Nobody likes
> re-inventing the wheel
>
> - can we call all the necessary GnuPG commands from a script without the
> user interacting directly with GnuPG, using "--batch" / unattanded
> operation?  The sequence of commands involved would be similar to this
> blog[3]
>
> - what would be the preferred way for the GUI to obtain and keep the
> master key passphrase without prompting the user to re-enter it for
> every operation?
>
> - would anybody else like to suggest improvements to the workflow?
>

A project similar in goals (simplifying GnuPG by automating tasks and
emphasising best practices) is this one: https://github.com/dashohoxha/egpg
You can find the answer to some of the questions above by looking at its
code.
But I really think that you can incorporate it in your project, maybe
extending it with new workflows that it doesn't have yet (related to using
smartcards etc.).

In my opinion, the first thing to be done is to build a .deb package for
it, so that it can be installed easily on all Debian derived systems, then
you can also use it in your special Live CD system.
This is the task about it: https://github.com/dashohoxha/egpg/issues/19

Re: making a Debian Live CD for managing GnuPG master key and smartcards

[Daniel Pocock]

On 26/04/16 12:52, Dashamir Hoxha wrote:
> On Tue, Apr 26, 2016 at 9:53 AM, Daniel Pocock  > wrote:
> 
> 
> There has been some discussion on debian-devel[1] about making a
> bootable Debian Live CD specifically for GnuPG
> 
> The benefit is that everything on the CD is self-contained, it can't be
> tampered with, it can run without network support in the kernel and the
> workflow would be controlled by a script.  All the details, including
> workflow, are described in a wiki[2]
> 
> I have some questions about this:
> 
> - has anybody already seen anything like this?  Nobody likes
> re-inventing the wheel
> 
> - can we call all the necessary GnuPG commands from a script without the
> user interacting directly with GnuPG, using "--batch" / unattanded
> operation?  The sequence of commands involved would be similar to this
> blog[3]
> 
> - what would be the preferred way for the GUI to obtain and keep the
> master key passphrase without prompting the user to re-enter it for
> every operation?
> 
> - would anybody else like to suggest improvements to the workflow?
> 
> 
> A project similar in goals (simplifying GnuPG by automating tasks and
> emphasising best practices) is this one: https://github.com/dashohoxha/egpg
> You can find the answer to some of the questions above by looking at its
> code.
> But I really think that you can incorporate it in your project, maybe
> extending it with new workflows that it doesn't have yet (related to
> using smartcards etc.).
> 
> In my opinion, the first thing to be done is to build a .deb package for
> it, so that it can be installed easily on all Debian derived systems,
> then you can also use it in your special Live CD system.
> This is the task about it: https://github.com/dashohoxha/egpg/issues/19
> 

Thanks for pointing this out

Could you add a section to the wiki about this, with an itemized list of
the tasks that need to be done, e.g.

 * packaging egpg and uploading to Debian
  * anybody can upload it to https://mentors.debian.net for a DD to sponsor
 * creating whiptail front-end for egpg
 * creating smartcard support for egpg

Please add any other individual tasks that would be necessary

Regards,

Daniel

Re: making a Debian Live CD for managing GnuPG master key and smartcards

[Peter Lebbing]

On 26/04/16 12:52, Dashamir Hoxha wrote:
> A project similar in goals (simplifying GnuPG by automating tasks and
> emphasising best practices) is this one: https://github.com/dashohoxha/egpg
> You can find the answer to some of the questions above by looking at its
> code.

I think you are taking the "plugging my project" approach too far. While
generating exposure is definitely a good component of making your
project succesful, I think a bit more modesty is in order. If I had a
say in it: Just create your own threads (not too many please :), don't
mention your project in every thread where it has some common ground.

This is my personal opinion. I don't get to say what you do. But I feel
the need to express this opinion now.

Regarding your choice of words and also modesty, the answers to the
questions are not in your code. Your /opinions/ on the matter are in
your code. You do not get to decide what is truth, what is the answer.
Incidentally, the answer is 42, so you're late to the party... ;P

I hadn't even read the following until I almost trimmed it from the mail
and it caught my eye... so ...

> In my opinion, the first thing to be done is to build a .deb package for
> it, so that it can be installed easily on all Debian derived systems,
> then you can also use it in your special Live CD system.
> This is the task about it: https://github.com/dashohoxha/egpg/issues/19

Wait, wait, wait... I sincerely hope you're not suggesting that the
first thing Daniel Pocock and others need to do is build a .deb package
for your project, that instead you meant this to read as "the first
thing /I/ should do is build a .deb package for egpg", so that they can
play with your code. I wouldn't even agree with the latter; but the
former is just... I hope you can pick your own adjective.

Cheers,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

Re: Popular packages in Ubuntu that is missing in Debian/main

[Petter Reinholdtsen]

A while back, I made a list of popular packages in Ubuntu that were
missing in Debian/main.  Just for fun, I created the list again today.
It look at all packages with more than 5000 votes in the Ubuntu
popularity contest results, and compare the packages to Debian main.

  adobe-flashplugin appmenu-gtk appmenu-gtk3 apport busybox-initramfs
  compiz-plugins-default compiz-plugins-main-default firefox-locale-en
  gconf-service-backend geoclue-ubuntu-geoip gir1.2-unity-5.0
  gnome-icon-theme-full google-chrome-stable humanity-icon-theme
  indicator-appmenu indicator-datetime indicator-power
  indicator-printers indicator-sound initramfs-tools-bin
  kerneloops-daemon language-selector-common libapt-inst1.4
  libboost-serialization1.46.1 libcamel-1.2-29 libebook-1.2-12
  libecal-1.2-10 libedataserver-1.2-15 libevince3-3 libglew1.6
  libglewmx1.6 libgnome-bluetooth8 libgnome-control-center1 libgrail5
  libjpeg-turbo8 liblaunchpad-integration-3.0-1
  liblaunchpad-integration-common libminiupnpc8 libplymouth2
  libreoffice-style-human librhythmbox-core5 libunity9 libx264-120
  linux-firmware linux-image-3.13.0-49-generic
  linux-image-3.13.0-53-generic linux-image-3.13.0-55-generic
  linux-image-3.13.0-57-generic linux-image-3.13.0-61-generic
  linux-image-3.13.0-62-generic linux-image-3.13.0-63-generic
  linux-image-3.13.0-65-generic linux-image-3.13.0-66-generic
  linux-image-3.13.0-68-generic linux-image-3.13.0-71-generic
  linux-image-3.13.0-74-generic linux-image-3.13.0-76-generic
  linux-image-3.13.0-77-generic linux-image-3.13.0-79-generic
  linux-image-3.13.0-83-generic linux-image-3.13.0-85-generic
  mysql-client-core-5.5 nux-tools nvidia-common nvidia-settings oneconf
  plymouth-label plymouth-theme-ubuntu-logo plymouth-theme-ubuntu-text
  python3-update-manager python-apport python-piston-mini-client
  python-problem-report python-ubuntuone-client
  python-ubuntuone-control-panel python-ubuntuone-storageprotocol
  python-ubuntu-sso-client python-xkit rhythmbox-mozilla
  rhythmbox-ubuntuone screen-resolution-extra session-migration
  signon-ui software-center-aptdaemon-plugins
  system-config-printer-common system-config-printer-gnome
  systemd-services telepathy-indicator thunderbird-locale-en
  ubuntu-drivers-common ubuntu-extras-keyring ubuntu-keyring
  ubuntuone-client ubuntuone-client-gnome ubuntuone-couch
  ubuntuone-installer ubuntu-release-upgrader-core ubuntu-sso-client
  ubuntu-system-service unity unity-greeter unity-lens-applications
  unity-lens-files unity-lens-music unity-lens-video
  unity-scope-musicstores unity-scope-video-remote unity-services
  unity-settings-daemon ureadahead whoopsie wine1.6 wine1.6-i386
  xdiagnose

Perhaps there are some pieces here we should try to get into Debian?

This is the script I used to create the list:

GET http://popcon.ubuntu.com/by_vote.gz | gunzip > ubuntu-by_vote-all
GET http://popcon.debian.org/main/by_vote.gz | gunzip > debian-by_vote-main
grep -v '#' ubuntu-by_vote-all | \
awk '$4 > 5000 {print $2}' | \
sort > ubuntu-popular
awk '{print $2}' debian-by_vote-main | sort > debian-main
comm -23 ubuntu-popular debian-main

I am not currently subscribed to debian-devel@, so please keep me on CC
if there is a reply I should see. :)

-- 
Happy hacking,
Petter Reinholdtsen

Re: making a Debian Live CD for managing GnuPG master key and smartcards

[Daniel Pocock]

On 26/04/16 14:16, Dashamir Hoxha wrote:
> On Tue, Apr 26, 2016 at 1:16 PM, Daniel Pocock  > wrote:
> 
> Could you add a section to the wiki about this, with an itemized list of
> the tasks that need to be done, e.g.
> 
>  * packaging egpg and uploading to Debian
>   * anybody can upload it to https://mentors.debian.net for a DD to
> sponsor
>  * creating whiptail front-end for egpg
>  * creating smartcard support for egpg
> 
> Please add any other individual tasks that would be necessary
> 
> 
> I manage the tasks of the project on GitHub:
> https://github.com/dashohoxha/egpg/issues 
> 

You can use the wiki to link to the Github tasks that are relevant to
using epgp in the Live CD, you don't have to copy the details of each
task, just link to them

Re: Popular packages in Ubuntu that is missing in Debian/main

[Dimitri John Ledkov]

Hello,

Looking at the list none of it makes sense in Debian, and the query is
inherently biased.

This is simply the list of packages installed by default on an Ubuntu
Desktop default installation.
There are some additions - e.g. nvidia stuff is automatically
installed through ubuntu-drivers, if nvidia graphics are detected and
user chooses to install proprietary drivers.
A bunch of other things are simply different package naming schemes and/or ABI.
Some are third-party packages all togeter (e.g. google-chrome-stable).

No human was involved in choosing to install any of these, apart from
like adobe-flashplugin/google-chrome-stable which are unsuitable for
debian main for obvious reasons.

Regards,

Dimitri.

On 26 April 2016 at 13:05, Petter Reinholdtsen  wrote:
>
> A while back, I made a list of popular packages in Ubuntu that were
> missing in Debian/main.  Just for fun, I created the list again today.
> It look at all packages with more than 5000 votes in the Ubuntu
> popularity contest results, and compare the packages to Debian main.
>
>   adobe-flashplugin appmenu-gtk appmenu-gtk3 apport busybox-initramfs
>   compiz-plugins-default compiz-plugins-main-default firefox-locale-en
>   gconf-service-backend geoclue-ubuntu-geoip gir1.2-unity-5.0
>   gnome-icon-theme-full google-chrome-stable humanity-icon-theme
>   indicator-appmenu indicator-datetime indicator-power
>   indicator-printers indicator-sound initramfs-tools-bin
>   kerneloops-daemon language-selector-common libapt-inst1.4
>   libboost-serialization1.46.1 libcamel-1.2-29 libebook-1.2-12
>   libecal-1.2-10 libedataserver-1.2-15 libevince3-3 libglew1.6
>   libglewmx1.6 libgnome-bluetooth8 libgnome-control-center1 libgrail5
>   libjpeg-turbo8 liblaunchpad-integration-3.0-1
>   liblaunchpad-integration-common libminiupnpc8 libplymouth2
>   libreoffice-style-human librhythmbox-core5 libunity9 libx264-120
>   linux-firmware linux-image-3.13.0-49-generic
>   linux-image-3.13.0-53-generic linux-image-3.13.0-55-generic
>   linux-image-3.13.0-57-generic linux-image-3.13.0-61-generic
>   linux-image-3.13.0-62-generic linux-image-3.13.0-63-generic
>   linux-image-3.13.0-65-generic linux-image-3.13.0-66-generic
>   linux-image-3.13.0-68-generic linux-image-3.13.0-71-generic
>   linux-image-3.13.0-74-generic linux-image-3.13.0-76-generic
>   linux-image-3.13.0-77-generic linux-image-3.13.0-79-generic
>   linux-image-3.13.0-83-generic linux-image-3.13.0-85-generic
>   mysql-client-core-5.5 nux-tools nvidia-common nvidia-settings oneconf
>   plymouth-label plymouth-theme-ubuntu-logo plymouth-theme-ubuntu-text
>   python3-update-manager python-apport python-piston-mini-client
>   python-problem-report python-ubuntuone-client
>   python-ubuntuone-control-panel python-ubuntuone-storageprotocol
>   python-ubuntu-sso-client python-xkit rhythmbox-mozilla
>   rhythmbox-ubuntuone screen-resolution-extra session-migration
>   signon-ui software-center-aptdaemon-plugins
>   system-config-printer-common system-config-printer-gnome
>   systemd-services telepathy-indicator thunderbird-locale-en
>   ubuntu-drivers-common ubuntu-extras-keyring ubuntu-keyring
>   ubuntuone-client ubuntuone-client-gnome ubuntuone-couch
>   ubuntuone-installer ubuntu-release-upgrader-core ubuntu-sso-client
>   ubuntu-system-service unity unity-greeter unity-lens-applications
>   unity-lens-files unity-lens-music unity-lens-video
>   unity-scope-musicstores unity-scope-video-remote unity-services
>   unity-settings-daemon ureadahead whoopsie wine1.6 wine1.6-i386
>   xdiagnose
>
> Perhaps there are some pieces here we should try to get into Debian?
>
> This is the script I used to create the list:
>
> GET http://popcon.ubuntu.com/by_vote.gz | gunzip > ubuntu-by_vote-all
> GET http://popcon.debian.org/main/by_vote.gz | gunzip > debian-by_vote-main
> grep -v '#' ubuntu-by_vote-all | \
> awk '$4 > 5000 {print $2}' | \
> sort > ubuntu-popular
> awk '{print $2}' debian-by_vote-main | sort > debian-main
> comm -23 ubuntu-popular debian-main
>
> I am not currently subscribed to debian-devel@, so please keep me on CC
> if there is a reply I should see. :)
>
> --
> Happy hacking,
> Petter Reinholdtsen
>

-- 
Regards,

Dimitri.

Re: making a Debian Live CD for managing GnuPG master key and smartcards

[Dashamir Hoxha]

On Tue, Apr 26, 2016 at 1:16 PM, Daniel Pocock  wrote:
>
> Could you add a section to the wiki about this, with an itemized list of
> the tasks that need to be done, e.g.
>
>  * packaging egpg and uploading to Debian
>   * anybody can upload it to https://mentors.debian.net for a DD to
> sponsor
>  * creating whiptail front-end for egpg
>  * creating smartcard support for egpg
>
> Please add any other individual tasks that would be necessary
>

I manage the tasks of the project on GitHub:
https://github.com/dashohoxha/egpg/issues

Re: Popular packages in Ubuntu that is missing in Debian/main

[Jonas Smedegaard]

Quoting Petter Reinholdtsen (2016-04-26 14:05:44)
> 
> A while back, I made a list of popular packages in Ubuntu that were
> missing in Debian/main.  Just for fun, I created the list again today.
> It look at all packages with more than 5000 votes in the Ubuntu
> popularity contest results, and compare the packages to Debian main.

Interesting.

Here's the list, stripped of...

  * libraries
  * packages ending in -common
  * kernels available in different version
  * firmware available under different name
  * contrib/non-free stuff
  * english locale data embedded in regular package

  appmenu-gtk appmenu-gtk3 apport busybox-initramfs
  compiz-plugins-default compiz-plugins-main-default
  gconf-service-backend geoclue-ubuntu-geoip gir1.2-unity-5.0
  gnome-icon-theme-full humanity-icon-theme
  indicator-appmenu indicator-datetime indicator-power
  indicator-printers indicator-sound initramfs-tools-bin
  kerneloops-daemon
  liblaunchpad-integration-3.0-1
  libreoffice-style-human
  nux-tools oneconf
  plymouth-label plymouth-theme-ubuntu-logo plymouth-theme-ubuntu-text
  python3-update-manager python-apport python-piston-mini-client
  python-problem-report python-ubuntuone-client
  python-ubuntuone-control-panel python-ubuntuone-storageprotocol
  python-ubuntu-sso-client python-xkit rhythmbox-mozilla
  rhythmbox-ubuntuone screen-resolution-extra session-migration
  signon-ui software-center-aptdaemon-plugins
  system-config-printer-common system-config-printer-gnome
  systemd-services telepathy-indicator
  ubuntu-extras-keyring ubuntu-keyring
  ubuntuone-client ubuntuone-client-gnome ubuntuone-couch
  ubuntuone-installer ubuntu-release-upgrader-core ubuntu-sso-client
  ubuntu-system-service unity unity-greeter unity-lens-applications
  unity-lens-files unity-lens-music unity-lens-video
  unity-scope-musicstores unity-scope-video-remote unity-services
  unity-settings-daemon ureadahead whoopsie wine1.6 wine1.6-i386
  xdiagnose

List could probably be cleaned even more by identifying and listing only 
main package of things tightly related - e.g. for apport, ubuntuone, 
ubuntu-sso, plymouth.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: making a Debian Live CD for managing GnuPG master key and smartcards

[Dashamir Hoxha]

On Tue, Apr 26, 2016 at 1:32 PM, Peter Lebbing 
wrote:

>
> I think you are taking the "plugging my project" approach too far. While
> generating exposure is definitely a good component of making your
> project succesful, I think a bit more modesty is in order. If I had a
>

Peter, I already know your opinion on my project and my modesty,
you don't have to bash every message that I write.
I hope that you will tolerate my lack of modesty, what else can I do?

Cheers,
Dashamir

Re: making a Debian Live CD for managing GnuPG master key and smartcards

[Dashamir Hoxha]

On Tue, Apr 26, 2016 at 2:20 PM, Daniel Pocock  wrote:
>
> > I manage the tasks of the project on GitHub:
> > https://github.com/dashohoxha/egpg/issues
> >
>
> You can use the wiki to link to the Github tasks that are relevant to
> using epgp in the Live CD, you don't have to copy the details of each
> task, just link to them
>

It doesn't seem reasonable to me.

Re: making a Debian Live CD for managing GnuPG master key and smartcards

[Peter Lebbing]

On 26/04/16 14:23, Dashamir Hoxha wrote:
> Peter, I already know your opinion on my project and my modesty,
> you don't have to bash every message that I write.

Quote or it didn't happen. I think I've treated you respectfully, though
I already noted my first reply to your first message here could have
been framed nicer. But that was the single exception.

The respect is starting to evaporate a bit at the moment, though.
Besides, I haven't spent much time on a lot of your messages, let alone
respond to every one of them or anything near such a thing.

> I hope that you will tolerate my lack of modesty, what else can I do?

Not impose extra work on random people[1], put your personal opinions in
proper perspective and represent your project as what it is, i.e., a
brand-spanking-new piece of code, one developer and a very small user
base? Or am I also wrong about that?

By the way, if I disagree with advice you give others here, such as here
advising to include your tool on the live CD, or the other day pointing
a new user to some webpage claiming he needed something more than the
default settings and do difficult stuff without knowing anything about
their requirements other than that they were already having some
difficulty with GnuPG in the first place, I will say so. Even if it
takes a ridicully long sentence that should probably be split into
proper parts. And I do it without bashing your messages, even though you
seem to take it personal.

Peter.

[1] I'm thinking of suggesting to someone they translate your project
when this person clearly indicates they'd like to reach a broad user
base with the effort they spend on that, and other instances.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

Re: Popular packages in Ubuntu that is missing in Debian/main

[Petter Reinholdtsen]

[Dimitri John Ledkov]
> Hello,

Hi. :)

> Looking at the list none of it makes sense in Debian,

Aha.  Thank you for looking into it.  I was not sure about a few of
them, for example the OpenGL toolkit nux-tools/nux, the Gnome screen
resolution applet extention screen-resolution-extra and the readahead
implementation ureadahead, and hoped for more eyes to check if there
were some gems there.

> and the query is inherently biased.

Sure, that was also the point of the list.  It is supposed to check the
most used packages in Ubuntu, which of course will be among the packages
installed by default.

> This is simply the list of packages installed by default on an Ubuntu
> Desktop default installation.

Not quite.  It would be if I used the installation count instead of the
vote.  I used the vote, to get the packages with programs or files being
used the last week in Ubuntu instead of simply looking at the
installation count.

The last time I made such list, there were several packages that should
be brought into Debian (for example dkms, which was the package
triggering my post this time), but it is good to know that none of the
packages in the list make sense to get into Debian this time.

-- 
Happy hacking,
Petter Reinholdtsen

Re: making a Debian Live CD for managing GnuPG master key and smartcards

[Dashamir Hoxha]

On Tue, Apr 26, 2016 at 2:52 PM, Peter Lebbing 
wrote:
>
> And I do it without bashing your messages, even though you
> seem to take it personal.
>

Please keep the discussion technical. If you don't agree with me this is
fine.
But when you express your opinion about my lack of modesty, this is getting
personal. And I don't care about your personal opinion about me, whoever
you are.

Respectfully,
Dashamir

Re: making a Debian Live CD for managing GnuPG master key and smartcards

[Peter Lebbing]

On 26/04/16 15:05, Dashamir Hoxha wrote:
> Please keep the discussion technical. If you don't agree with me
> this is fine. But when you express your opinion about my lack of
> modesty, this is getting personal.

This is not true: you are taking the word modesty out of the context I
used it in.

> And I don't care about your personal opinion about me, whoever you 
> are.

What you care about affects only you, and you can do to yourself
whatever you wish. I only butt in when it affects others. I've also
never until the previous message said anything about my personal opinion
of you ("respect evaporating a bit"), since it is, indeed, irrelevant.
You are inventing your own version of me, someone with who's responses
are emotionally motivated, a version that has little basis in reality.

I'm done with this topic. After some doubt, I will post this to the
list, though.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

Does anyone know the whereabouts of Risko Gergely [a Debian Developer who seems to be MIA?]

[Shlomi Fish]

Hi all!

Does anyone know the whereabout of Riso Gergely
( https://qa.debian.org/developer.php?login=ri...@debian.org - CCed to this
message. ) He seems to be missing in action (MIA) since 2014, and he maintains
freecell-solver for which I am the upstream.

Any help would be appreciated.

-- Shlomi Fish

Re: Popular packages in Ubuntu that is missing in Debian/main

[Ben Hutchings]

On Tue, 2016-04-26 at 14:40 +0200, Jonas Smedegaard wrote:
> Quoting Petter Reinholdtsen (2016-04-26 14:05:44)
> > 
> > 
> > A while back, I made a list of popular packages in Ubuntu that were
> > missing in Debian/main.  Just for fun, I created the list again
> > today.
> > It look at all packages with more than 5000 votes in the Ubuntu
> > popularity contest results, and compare the packages to Debian
> > main.
> Interesting.
> 
> Here's the list, stripped of...
> 
>   * libraries
>   * packages ending in -common
>   * kernels available in different version
>   * firmware available under different name
>   * contrib/non-free stuff
>   * english locale data embedded in regular package
[...]

Please map these back to *source* packages and then compare with source
packages in Debian.

Then you would see that, for example, busybox-initramfs is not really
missing from Debian (it's an extra binary built from busybox, while in
Debian the regular busybox binary package provides binaries for the
initramfs).

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert Coveyou


signature.asc
Description: This is a digitally signed message part

Bug#822680: ITP: libdancer-plugin-email-perl -- Simple email sending plugin for Dancer applications

[Axel Beckert]

Package: wnpp
Owner: Axel Beckert 
Severity: wishlist

* Package name: libdancer-plugin-email-perl
  Version : 1.0400
  Upstream Author : Naveed Massjouni , Al Newkirk 

* URL : https://metacpan.org/release/Dancer-Plugin-Email
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Simple email sending plugin for Dancer applications

Dancer::Plugin::Email tries to make sending emails from Dancer
applications as simple as possible. It uses Email::Sender under the
hood. In a lot of cases, no configuration is required. For example, if
your app is hosted on a unix-like server with sendmail installed,
calling email() will just do the right thing.

The package will be maintained under the umbrella of the Debian Perl
Group.

Re: making a Debian Live CD for managing GnuPG master key and smartcards

[Peter Lebbing]

On 26/04/16 15:43, Peter Lebbing wrote:
> I will post this to the list, though.

It was brought to my attention this also goes to debian-devel. This was
never my intention; I constantly misread that as gnupg-devel. If I had
known this was going to debian-devel I would have long removed it from
CC, since this was all about behaviour shown on gnupg-users. I'm sorry
for all the noise on debian-devel!

Greets,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

Re: Extending the build profile namespace

[Ian Jackson]

Johannes Schauer writes ("Re: Extending the build profile namespace"):
> I agree with Helmut [and implicitly, disagree with Ian]

Well, from what you say things are much further advanced than I
thought.  You may well be right - certainly I'm no expert in this area
and I think both of you are.

Regards,
Ian.

Bug#822697: general: qt5 apps in gnome do not use the gtk style as they should

[Miguel Negrao]

Package: general
Severity: normal

Dear Maintainer,

Qt5 apps (e.g. qmapshack) do not use the gtk style as should be the default.
Because of this they look a bit more ugly, for instance the buttons to close
panes have a black X instead of a white X on red background. Launching the qt5
binary with '-style=gtk' gives the right look, but the system should be
configured such that this is not necessary.

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-1-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=pt_PT.utf8, LC_CTYPE=pt_PT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

using whiptail and translated strings from arbitrary scripts

[Daniel Pocock]

It is well documented how developers should create po files for i18n
support in their debconf configuration questions during package install[1].

What about arbitrary scripts that are run from the command line and
don't use debconf to store the user responses?  How should they interact
with whiptail and translated strings?  Is there either a document
explaining how to do this or any existing script that provides a good
example, in a way that makes it easy for Debian translators to support
the package containing the script?


One use case I'm thinking of is the live CD for PGP key management
discussed already[2].  After booting, instead of showing a login
prompt on tty1 it will go into a whiptail/dialog interface, like the
installer and ask some questions like:

  Do you want to create a new master key or work with an existing one?

   New key Existing key


  Has your master key or any subkey been compromised?

YesNoMaybe, I don't remember anything from last night




1.
https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintscriptprompt
2.
https://wiki.debian.org/OpenPGP/CleanRoomLiveEnvironment#First_time_workflow

Re: using whiptail and translated strings from arbitrary scripts

[Paul Wise]

On Wed, Apr 27, 2016 at 3:32 AM, Daniel Pocock wrote:

> One use case I'm thinking of is the live CD for PGP key management
> discussed already[2].  After booting, instead of showing a login
> prompt on tty1 it will go into a whiptail/dialog interface, like the
> installer and ask some questions like:

I would suggest using Python and Urwid instead of shell and whiptail/dialog.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: using whiptail and translated strings from arbitrary scripts

[Eduard Bloch]

Hallo,
* Daniel Pocock [Tue, Apr 26 2016, 09:32:02PM]:
> 
> 
> It is well documented how developers should create po files for i18n
> support in their debconf configuration questions during package install[1].
> 
> What about arbitrary scripts that are run from the command line and
> don't use debconf to store the user responses?  How should they interact
> with whiptail and translated strings?  Is there either a document
> explaining how to do this or any existing script that provides a good
> example, in a way that makes it easy for Debian translators to support
> the package containing the script?

Long time ago, I used bash's builtin mechanism to enable i18n in
pppoeconf, and it worked sufficiently well.

Not sure about good documents. I remember finding a couple of blog
entries documenting the initial process, the rest was usual Makefile
scripting.

Best regards,
Eduard.

-- 
Die meisten unserer Fehler sind verzeihlicher als die Mittel, die wir
anwenden, um sie zu verbergen.
-- François de La Rochefoucauld