looking for a sponsor for calligra
Hi, Calligra, the fork of KOffice, has released its beta 2 version : http://www.calligra-suite.org/news/announcements/calligra-2-4-beta-2/ The debian koffice package has been updated for follow these changes : http://anonscm.debian.org/gitweb/?p=pkg-kde/kde-std/calligra.git;a=summary The packaging is now ready and we are looking for a sponsor to include it in the qt-kde repository (http://qt-kde.debian.net/). So experienced users can test it before the official stable release, planned for november or december. If you are interested for uploading the package or if you want more information on it, please let me know :-) Adrien Grellier -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/j728ut$mc5$1...@dough.gmane.org
Re: looking for a sponsor for calligra
Hi, Ana Guerrero wrote: > Adrien, for this please ask in pkg-kde-talk@lists.alioth or in irc > #debian-qt-kde. thanks for the answer. So I will continue the discussion on pkg-kde-talk ;-) Adrien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/j74e1s$921$1...@dough.gmane.org
cannot log into git.debian.org
Hi, Since the work on alioth, I cannot use anymore ssh on alioth.debian.org or git.debian.org, I got this message : Permission denied (publickey). I also put a public key on the web interface on alioth, but the message is still there. What should I do to log on and commit again on git.debian.org ? Regards, Adrien Grellier -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ittfl9$nu9$1...@dough.gmane.org
Bug#816609: ITP: yamllint -- A linter for YAML files
Package: wnpp Severity: wishlist Owner: Adrien Vergé * Package name: yamllint Version : 1.0.3 Upstream Author : Adrien Vergé * URL : https://github.com/adrienverge/yamllint * License : GPL-3+ Programming Lang: Python Description : A linter for YAML files yamllint is a linter / validity checker for YAML files. It does not only check for syntax validity, but for weirdnesses like key repetition and cosmetic problems such as lines length, trailing spaces, indentation, etc. It is used by developers and teams that need to check their YAML sources, as well as continuous integration tools. A complete documentation is available at http://yamllint.readthedocs.org/en/latest/ yamllint is already available natively for Fedora, CentOS, and for Ubuntu using a PPA. To the best of my knowledge, there is no equivalent software for YAML (although such linters already exist for Python, C, Javascript, etc.)
Re: New project goal: Get rid of Berkeley DB (post jessie)
Le 19/06/2014 11:38, Ondřej Surý a écrit : > List of affected maintainers follows: > > Loic Minier >evolution-data-server (U) >rpm (U) > I am just a simple user of rpm. Yes, I use rpm for inspecting, debugging, and so on. I don't use it for managing packages on my Debian box, but I guess that removing BerkeleyDB from rpm is not an option. If I'm wrong, I'll be glad to hear it :) Adrien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53a2bae8.2040...@antipoul.fr
Re: Can a leaf package require SSE2 on i386?
Le 14/09/2014 08:47, Sébastien Villemot a écrit : > So I have two options: either ship a i386 package that only works on > SSE2 processors (ideally giving a meaningful error message when run on > older CPUs); or drop support for i386, which is a disservice to our > users (the few who have a SSE2-capable but not x86-64-capable processor > will be left out; and those who are running the i386 arch on a > x86-64-capable processor will have to cross-grade to amd64 or at least > use multi-arch with a 64-bit kernel). > I'm in the category of people who installed their Debian 8 years ago, on an old AMD processor, only i686. My hardware was upgraded since, but the system remains. I've searched for cross-grade, but nothing serious comes out, except "reinstall everything". If you have some clear documentation (at least some steps, I'm curious enough to read some apt manuals), I think you can go on dropping i386 architecture. Otherwise, even if I'm not a julia user, I'll be really sad to see a package lost only because SSE2 is needed. Adrien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5415a8ce.1020...@antipoul.fr
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
And SysVInit just works well and it is simply enough. It has much less dependencies than systemd. Do not make unneeded weight on people to learn systemd in addition to shell scripts, if systemd is powerful that also means there is a lot to learn. I really doubt non-standards task can be solved with systemd without shell scripts (or similar), and every serious UNIX admin must know shell programming anyway. This is like saying "A horse drawn carrage works well enough, why do you need an airplane". You need an airplane because Earth is 40,000 km in round and because you have a reason to travel to a distant location. Or just you want to do some sport? But I know my possibilities and I wouldn't spend my money on an airplane just for sport, to produce an airplane you have to take raw materials out of this planet, you have to spend power, human time, make pollution, etc. That's exactly how I feel when I want to create a small daemon using a SystemV init script. I feel like building an airplane from scratch while I would just use a bike. Introducing the concept of "possibilities" is interesting: sometimes, you need some choices in your available tools to perform the same task, depending on your current need… Adrien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527a3e75.5050...@antipoul.fr
[Composer] Creating a music jingle for Debian -> Musical
Hello, As a composer I would like to help if possible. Apparently there is no login-jingle for Debian, and if I would be pleased to help providing one. This could build a auditive identity for this distribution... Where should I post the information when I have made it ? Thanks, -- ** *Adrien.* --
Re: [Composer] Creating a music jingle for Debian -> Musical
@Jon Dowland and Thibaut Paumard : Thanks a lot, I will work on that base.
--
*Adrien
*
--
Le 14 mars 2012 11:23, Jon Dowland a écrit :
> Hi Adrian, thanks for your interest in working with Debian!
>
> On Wed, Mar 14, 2012 at 06:11:09PM +0800, Paul Wise wrote:
> > In general that sort of thing is done upstream, please contact the
> > developers for your favourite desktop (GNOME, KDE, XFCE, Unity etc) if
> > you want to contribute to the relevant sound themes.
>
> On the other hand, there is an effort to build a Debian-specific visual
> identity, which these days is coordinated on the Debian Desktop mailing
> list:
>
> I see no reason why we should not be interested in considering an auditive
> identity as well. ('auditive': I like that word!)
>
> I'd recommending reposting to the -desktop list and seeing if anyone there
> is prepared to work on this.
>
>
> Thanks,
>
> --
> Jon Dowland
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: http://lists.debian.org/20120314102310.GA8511@debian
>
>
Re: Debian Developers team in Launchpad
Le 17/12/2013 12:44, Tae Wong a écrit : You've asked Launchpad Feedback to restore seotaewong40 but the account remains suspended. Please remove your ban for the account in Mozilla Bugzilla (seotaewong40) as well. Tae Wong, how do you prefer to eat? Sitting on a chair or on the ground? By the way, I think you forgot your sunglasses last time we met in South Pole. You could have them back, but only if you told me how to make broomsticks fly. Is it OK for you? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52b05413.1090...@antipoul.fr
Re: Bug#727708: init multiple instances of a daemon
Le 23/12/2013 00:37, Zbigniew Jędrzejewski-Szmek a écrit : It looks like both upstart and systemd don't provide direct mechanisms to manage all instances. That's true (I'm only speaking about systemd). There have been requests for such functionality before, but nothing was implemented. But I think we should revisit this topic... I recently added globbing to a bunch of systemctl verbs for listing stuff (list-units, list-sockets, etc.), and it was actually trivial. I felt that allowing globing for verbs that influence state (start, stop, enable, disable, ...) was too dangerous. But this should be safe for instance units, so I'd like to see 'systemctl stop/status/... server@*.service' implemented. Zbyszek This could be controlled via a setting inside the unit file, like AllowGlobControl, default set to false in template unit files. Adrien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52b7e940.2000...@antipoul.fr
Re: ca-certificates: no more cacert.org certificates?!?
Le 24/03/2014 14:23, Raphael Geissert a écrit : >> Anyway, I strongly recommend that nobody waste their time on an issue >> which in a couple of years will be much less relevant thanks to DANE. > If only people actually used DNSSEC and DANE - Chromium/Google Chrome dropped > support for the latter due to the lack of use[1]. > > [1]https://www.imperialviolet.org/2011/06/16/dnssecchrome.html > Lack of use? No kidding. TLSA RRs have been promoted to IETF proposed standard in August 2012[1]. And DNS servers haven't support for them since recently (I'd say 6 months to 1 year). If I understood correctly, Chromium/Google Chrome only supported DNSSEC validation. The issue with that kind of protocol is that you must trust your resolver, or have a resolver on your machine, bypassing any existing resolver cache of your network provider. However, I'm using DNSSEC Validator[2] on Firefox for quite a long time, and I'm very happy with it. I'll be glad to see it merged, so that we can really get rid of those EV x509 certificates, and be able to provide secure self-hosting solutions for everyone without big scary warnings. [1]http://tools.ietf.org/html/rfc6698 [2]https://www.dnssec-validator.cz/ Have a good day, Adrien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53303829.4020...@antipoul.fr
Re: ca-certificates: no more cacert.org certificates?!?
Le 24/03/2014 22:18, Edward Allcutt a écrit : > I believe you are mistaken. That blog post is about Google's own > design for "DNSSEC stapled certificates" . Not DANE. I figured it out after a more careful reading. I forgot about this trial from Google, that was obviously not used enough to be useful. DANE is not really used yet, but I think it is easier to setup. Adrien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5330a4d8.7020...@antipoul.fr
Re: systemd patent fees - who pays?
Le 28/03/2014 11:40, Sebastian Feld a écrit : > Now that Redhat and Suse have been contacted by ORACLE regarding to > licensing the SMF patents a question arises for Debian: > > SystemD violates a couple of patents SUN Microsystems filed for their > SMF system used in Solaris. > > Now, who is going to pay the patent and license fees for each Debian > installation which uses SystemD? > > Seb No one in Europe. There's no such thing as software patent here. Yet. I hope this will stay forever. (And yes, maybe I'm wrong, but please enlighten me!) Adrien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53355a3f.5040...@antipoul.fr
Re: correct use of su
Le 11/05/2014 09:22, Marc Haber a écrit : >> Systemd (as upstart) sidesteps this problem to a large degree by handling >> uid switching as a native directive, avoiding the need to call out to a >> separate command. > Just out of curiosity: What do I do when I convert an init script that > parses a mode 600 configuration file (containing passwords), does > necessary things as root and then starts a non-root daemon to systemd? > How do I do that with using a "native directive"? > In systemd, the ExecStartPre directive can be helpful. But the documentation doesn't say if it is executed as the user defined in the User directive, or as root. I guess the latter is done, but I'm too lazy right now to test it :) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/536f2d21.8070...@antipoul.fr
Re: ITP: bitstring -- Python module for manipulation of binary data
Le 30/03/2015 20:50, Ghislain Vaillant a écrit : > Package: wnpp > Severity: wishlist > Owner: Ghislain Antony Vaillant <mailto:ghisv...@gmail.com>> > > * Package name: bitstring > Version : 3.1.3 > Upstream Author : Scott Griffiths <mailto:sc...@griffiths.name>> > * URL : https://code.google.com/p/python-bitstring/ > If it's a new package, it shouldn't be hosted on Google Code right now. Or I'm missing something. Adrien
Re: Bug#790399: ITP: structlog -- tructured Logging for Python
Le 29/06/2015 02:51, Filippo Giunchedi a écrit : > * Package name: structlog Hi, It seems to be a Python library (in the main site, I can read that it is used as an imported module), it should be named python-structlog. Have a nice day, Adrien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55910046.7060...@antipoul.fr
Re: The Spirit of Free Software, or The Reality
Le 17/07/2015 12:57, Mike Hommey a écrit : > On Fri, Jul 17, 2015 at 02:38:12PM +0800, Paul Wise wrote: >> On Thu, Jul 16, 2015 at 6:17 AM, Mike Hommey wrote: >> >>> I, myself, find our DFSG-freeness pickiness going too far, and I'm sick >>> of this icon thing. So, here's what I'm going to do: unless I hear >>> non-IANAL objection until the next upstream release due on august 11 >>> (and I'm BCCing the DPL in case he wants to have the SPI lawyer(s) look >>> into this), I will remove the replacement of the bundled icons with >>> urls. >> How about just disabling the icons altogether? They seem unnessecary >> to me. Removing them would avoid both the potential DFSG issue and the >> privacy issue. > Would you dare say this is useful? > http://i.imgur.com/duKHZKF.png > > Mike > > This seems to be the new DFSG game. Pick an icon, and get random results. Adrien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55a8ef44.7000...@antipoul.fr
Re: The Spirit of Free Software, or The Reality
Le 17/07/2015 15:09, Thorsten Glaser a écrit : > OK, wrong place to complain about RequestPolicy, admittedly. > It’s just that it’s the only actually effective ad blocker, > for use by me when lynx, my default webbrowser, isn’t enough. > > Maybe you should try the "I am an advanced user" of uBlock (or uBlock Origin, it's up to you). It replaces AdblockPlus and RequestPolicy in a much more efficient UI for me. More complex also… Adrien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55a90c84.40...@antipoul.fr
Re: Improving your archive and package system for small package
Le 03/09/2015 13:36, Bastien ROUCARIES a écrit : > Hi, > > In order to improve node situation we need to improve the small > packages problems. > > What are the main bottlenet ? What could be done to improve the situation ? > > The node small package does not change often so it could be a win to > your archive size. > Moreover if we could solve this problem we could think about small > perl package or even tex package. > Hi, This may have been discussed before, but could we achieve something like this with virtual package? For example, define virtual packages for every small package (nodejs-myfunkyoneliner) that is only provided by a bigger package (e.g. nodejs-libraries1, so we can split those bigger packages), containing a compilation of those librairies. Then, another packaged software can just depends on those virtual packages. The real files will be installed with potentially uneeded other ones, but it will reduce overhead. This may be a bad idea, though. I'm not a dpkg expert. Adrien
Re: libselinux1t64 (et al): breaks system in upgrade from unstable
Hi, On Thu, Feb 15, 2024, Steve Langasek wrote: > > For libfuse2, I think the ABI analysis is broken. The base-to-lfs report > > supposedly is ok > > https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/libfuse-dev/base_to_lfs/compat_report.html > > and then going lfs-to-time changes ino_t > > https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/libfuse-dev/lfs_to_time_t/compat_report.html > > while I would have expected ino_t to change with lfs already. Are we > > sure about this? In any case, this is more of an academic question as > > adding ABI-duality would be more involved here. > > Are we *sure* about it, no. But I'm not sure it's worth the effort to get a > definitive answer here. libfuse2 should be deprecated in favor of libfuse3 > and if there's pushback I'd rather just allow it to be broken for 64-bit > time_t and use this as a forcing factor to complete the transition, rather > than putting effort into fixing libfuse2. (the number of > reverse-dependencies is unfortunately still quite large.) fuse.pc uses -D_FILE_OFFSET_BITS=64 and I see no reason it would apply only when doing two of the ABI dumps and not the third one. Abi-compliance-checker reports type changes but not size changes so I'm inclined to think it's just hitting different paths in the glibc headers and the type name is different (which makes sense since there is no non-lfs in time64). > > Moreover, I don't see > > any ACC report for libfuse3-dev. Did that fail to analyze? > > Yes: > > https://adrien.dcln.fr/misc/armhf-time_t/2024-02-09T15%3A12%3A00/logs/libfuse3-dev/time_t/log.txt The analysis is fixed now and no ABI change has been detected (for LFS or for time_t). > looks like a bug in the quirking script. The same bug appears to be present > for libhiredis-dev. Analysis is fixed too and no ABI change has been detected for it either. I'm not publishing consolidated results yet; unless there is a need before, I'll do it on Friday. -- Adrien
Re: CentOS and Debian/Ubuntu release cycles
Le 10/12/2020 à 08:05, Marco d'Itri a écrit : On Dec 10, Joel Wirāmu Pauling wrote: is. Binary compat is mostly a thing of the past in modern Rhel due to containerization. Container tooling in userspace is one of the reasons RH Cool narrative, but the reality is a bit more complex than that. Fibre Channel users need very specific kernels or else the hardware vendors will refuse support (and their vendor drivers will not compile). For example, my current employee use CentOS for videosurveillance. In a lot of locations (100+), we still have analog cameras, that use V4L2 grabbing cards with an out-of-tree kernel driver that I painfully maintain myself (it is unclear if we only have the rights to modify its source). Containers are completely impossible for this use case. And because of our decentralized installation, we almost need one server by geographical location anyway, so it's a bit useless to have one server with two containers. I also have to admit that I'm a bit tired of this containerization-mania. Container orchestration requires a lot of tooling, and I guess that selling tools (of support for them) is a valid business strategy. But we also have the right to say no to it :) Adrien
Re: Intel CET Support?
Le 05/09/2022 à 22:44, Felix Potthast a écrit : objdump -d /usr/bin/mv | grep endbr | wc -l I got 2 on my current Bookworm/testing with 5.18.0-4-amd64
Re: Unlock LUKS with login/password
Le 08/03/2023 à 16:28, Alexey Kuznetsov a écrit : Hello! I have an idea about how modern linux should work with encrypted LUKS partitions. Hi, I'm using LUKS for a long time on both my personal (desktop) and professional (laptop) computers. Since they are single user (me), I use autologin in the display manager, lightdm in my case. Because there is only one slot configured in LUKS, I'm sure this is me, so lightdm can autologin safely. However, you are proposing to solve the case for multiple user computers. In that case, I would think about a much simpler design: - Remember which slot was used to unlock the LUKS root partition - Make a map with slot -> user to autologin - Autologin that user on boot No more passing password, no more password update headache. But only a root user can update the map "slot -> user". Adrien
Re: Bug#841279: ITP: golang-github-gogits-go-gogs-client -- Gogs API client in Go.
Le 19/10/2016 à 11:29, Michael Lustfield a écrit : > * Package name: golang-github-gogits-go-gogs-client > Funniest package name I've ever seen. Thanks for that :) Adrien
Re: Bug#847809: ITP: tcvt -- multicolumn virtual terminal
Le 11/12/2016 à 23:39, Ferenc Wágner a écrit : > * Package name: tcvt > Version : git snapshot 82c24e2 > Upstream Author : Helmut Grohne > * URL : http://subdivi.de/~helmut/tcvt/ >From the main page: Multibyte encodings such as utf8 are not supported, because Python is buggy. Is that still an issue? I highly doubt that a terminal application that doesn't support UTF8 is useful nowadays. Adrien
Re: IPv6 problem for one debian mirror
Le 08/02/2017 à 01:05, Vincent Danjean a écrit : > However, the machine answers to IPv4 connections but not to IPv6 > $ time wget -4 ftp.fr.debian.org > --2017-02-08 00:53:54-- http://ftp.fr.debian.org/ > Résolution de ftp.fr.debian.org (ftp.fr.debian.org)… 212.27.32.66 > Connexion à ftp.fr.debian.org (ftp.fr.debian.org)|212.27.32.66|:80… connecté. > requête HTTP transmise, en attente de la réponse… 200 OK > Taille : 1915 (1,9K) [text/html] > [...] > real 0m0,108s > user 0m0,000s > sys 0m0,000s > $ time wget -6 ftp.fr.debian.org > --2017-02-08 00:53:58-- http://ftp.fr.debian.org/ > Résolution de ftp.fr.debian.org (ftp.fr.debian.org)… 2a01:e0c:1:1598::2 > Connexion à ftp.fr.debian.org (ftp.fr.debian.org)|2a01:e0c:1:1598::2|:80… ^C > > real 1m52,272s > user 0m0,000s > sys 0m0,000s > [I did a C-c in the shell to interrupt] > > My IPv6 connection is ok for other sites, for example: > > $ time wget -6 www.debian.org > URL transformed to HTTPS due to an HSTS policy > --2017-02-08 00:57:00-- https://www.debian.org/ > Résolution de www.debian.org (www.debian.org)… 2001:610:1908:b000::148:14, > 2001:41c8:1000:21::21:4 > Connexion à www.debian.org (www.debian.org)|2001:610:1908:b000::148:14|:443… > connecté. > requête HTTP transmise, en attente de la réponse… 200 OK > Taille : 14926 (15K) [text/html] > [...] > real 0m1,079s > user 0m0,012s > sys 0m0,000s Hi, I can only but encourages you to try lower MTU. Here is an example: ip -6 route change default via fe80::207:cbff:feb1:7dd7 dev eth_adsl mtu 1480 You can also try with a lower value, such as 1456 or 1440. Yes, the MTU discovery is not working on proxad network, and I don't know why. Maybe it's my own firewall, I don't know, and I don't have the time to investigate. Note however that this might be a peering issue. After all, IPv6 is only 18 years old, it's a young technology preview ;) Adrien
Re: What can Debian do to provide complex applications to its users?
> What do you think? Do you have other ideas? Are there other persons > who are annoyed by the current situation? Yes, indeed. I am more a simple user of Debian than a real Debian Developer, but my feeling is paradoxical. On one hand, I'd love to see some complex application in Debian, or at least most of its dependencies. On the other hand, I can only be angry against people than only release minified source. The usual answer to this is "performance" or "everyone does this". The debate has been opened for a long time, but a minification operation is somewhat like a compilation: it is hard to get the human readable form from it. So I'd vote "no" to relax, even if some application are taken out. As an example, there is this grafana issue on https://github.com/grafana/grafana/issues/5046. The usual answer: > torkelo commented on 15 May 2016 > > Github source tar has never been 100% comprehensive, Grafana has > always required "npm install" to build (like most web apps) This is incredibly dangerous since the build rely on NPM repository which is far from trusty. And it relies on minified files everywhere, that break the social contract. I installed Grafana on my Debian/testing when the package was available, because then I knew it could be trusted. Now, it is more appealing than before (Grafana is a good software), but trust has gone away. It is true that software are harder to review nowadays, because they rely on lots of libraries. But there is a real difference to me between "hard" and "impossible". For the JavaScript world, a solution would require a well-known standard about minification and optimization. The WebAssembly is coming, and this will worst.
Re: Bug#891211: ITP: impass -- Simple and secure password management and retrieval system
> * URL : https://salsa.debian.org/impass Is it normal that this URL requires a login? I guess not, but anyway, this is not as open-source as it should be ;) Adrien
Re: APT 1.2 preview uploaded to experimental -- please test
Le 08/01/2016 22:13, Julian Andres Klode a écrit : > So roughly speaking, we only take 2/3 of the time now compared > to 1.1.8 after which I started optimising the code. > And I wish to say to you that you made a very good job at this. On my personal self-hosted server, the difference is huge (Intel(R) Atom(TM) CPU D2550). Thank you! Adrien
Re: Bug#815893: ITP: python-jpy -- Bi-directional Python-Java bridge
Le 25/02/2016 13:59, Alastair McKinstry a écrit : > Upstream Author : Brockmann Consult GmbH > * URL : http://www.brockmann-consult.de > Hi, I understand that the author want some credits, but unless I misread the webpage, there is no mention of this project on it. It should be better to have a link to https://github.com/bcdev/jpy or https://pypi.python.org/pypi/jpy/ or http://jpy.readthedocs.org/en/latest/ Adrien
Bug#820377: ITP: photocollage -- Graphical tool to make photo collage posters
Package: wnpp Severity: wishlist Owner: "Adrien Vergé" * Package name: photocollage Version : 1.4.0 Upstream Author : Adrien Vergé * URL : https://github.com/adrienverge/PhotoCollage * License : GPL-2+ Programming Lang: Python Description : Graphical tool to make photo collage posters PhotoCollage allows you to create photo collage posters. It assembles the input photographs it is given to generate a big poster. Photos are automatically arranged to fill the whole poster, then you can change the final layout, dimensions, border or swap photos in the generated grid. Eventually the final poster image can be saved in any size. It is already widely used and described on the internet as well as in printed magazines. PhotoCollage is already available natively in Fedora since 2014.
Re: Opt out style recommends
Le 08/04/2016 05:49, Harlan Lieberman-Berg a écrit : > [1]: I say default here, but really, systems which turn off installing > things which are Recommended are almost unusuable; I know for a while > it was the policy of #debian to just turn away people who had done > that because the system would be in such a strange state. Sincerely, While I think installing recommended packages by default is a good choice, disabling it is also a really good option on servers. Installing every recommended packages is sometimes the best way to bloat your system. It makes me think I'd love a system where Apt::Install-Recommends could be set to "ask" and let apt ask me if I want the recommended packages for my current request. Adrien
Re: Opt out style recommends
Le 08/04/2016 10:10, Neil Williams a écrit : > On Fri, 8 Apr 2016 09:58:04 +0200 > Adrien CLERC wrote: > >> Le 08/04/2016 05:49, Harlan Lieberman-Berg a écrit : >>> [1]: I say default here, but really, systems which turn off >>> installing things which are Recommended are almost unusuable; I >>> know for a while it was the policy of #debian to just turn away >>> people who had done that because the system would be in such a >>> strange state. Sincerely, >> While I think installing recommended packages by default is a good >> choice, disabling it is also a really good option on servers. >> Installing every recommended packages is sometimes the best way to >> bloat your system. >> >> It makes me think I'd love a system where Apt::Install-Recommends >> could be set to "ask" and let apt ask me if I want the recommended >> packages for my current request. > apt already shows you which packages are to be brought in as Recommends > on every invocation and unless you use the -y option you get the > option to quit. You can already choose to quit and call apt with the > --no-install-recommends option for this specific invocation of apt. > This involves a lot of keypresses, and I'm incredibly lazy ;) I was just wondering if apt could be more interactive, or if it is a design choice not to ask too many questions. Adrien
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
Le 08/06/2016 à 10:53, Christiaan de Die le Clercq a écrit : > > +1 > > Though I am not involved in this discussion and didn't read a lot of > previous emails about this. I am going to assume it would be hosted on > Debian's servers and not with Gitlab's hosted services. We use Gogs at > the office, a (MIT licensed) Gitlab alternative. > https://github.com/gogits/gogs > It might be worth checking out. > Let me add another one: GitBlit (http://gitblit.com/) It may not be as active as others, but it is quite simple, and provide me a huge benefits over Gogs, since it knows how to handle git repositories created by third-party on disk. Using Gogs, all git repositories must have been imported. It's in Java, and I don't know if the "Pull request" thing is really useful. Adrien
