Bug#988298: ITP: fidi -- (φίδι) service mock system for testing infrastructure
Package: wnpp Owner: Manoj Srivastava Severity: wishlist * Package name: fidi Version : 1.0.1 Upstream Author : Manoj Srivastava * URL or Web page : https://github.com/google/fidi * License : Apache-2.0 Description : (φίδι) service mock system for testing infrastructure The goal of φίδι (fidi) is to model some aspects of arbitrarily complex services, and simulate the behaviour of the service business logic (without actually containing any real business logic or complexity) in presence of external stimuli. Each instance of the φίδι (fidi) application can mock a node in the complex, client serfver service that it is mocking. Different instances of φίδι (fidi) talk to other instanceds of themselves, like a snake (φίδι) eating its tail. φίδι (fidi) also simulates fault injection symptoms, which allows the simulation of normal behaviour as well as incidents and recovery. The motivation is to test the behaviour of the infrastructure, monitoring, alerting and logging systems, while mocking an actual service. Manoj -- Win95 is not a virus; a virus does something. -- unknown source Manoj Srivastava 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C
Still (mostly) around after 25 years
Hi, A little over 25 years ago, I started looking into contributing to Debian, instead of just using it. 1) https://lists.debian.org/debian-devel/1995/10/msg00331.html 2) https://lists.debian.org/debian-devel/1995/10/msg00376.html 3) https://lists.debian.org/debian-user/1995/10/msg00441.html Here is me exploring the (hah!) new maintainer process: 4) https://lists.debian.org/debian-devel/1995/11/msg00343.html And my first package upload: 5) https://lists.debian.org/debian-changes/1995/11/msg00134.html Others followed: 6) https://lists.debian.org/debian-devel/1995/12/msg00266.html 7) https://lists.debian.org/debian-devel/1995/12/msg00265.html I have had the honor to serve as a charter member of the ctte, and I think I was the reason we added term limits to ctte membership. I served as project secretary for 6 years or so, writing devotee while running an election, finishing components just in time, before flaming out spectalurarily. I may no longer be as active in Debian as I once was, but I am still around. A quarter of a century. It has been an honour, and a pfivilege, to have benn in here with y’all, and Debian still feels like family. Manoj -- Girls who throw themselves at men, are actually taking very careful aim. Manoj Srivastava <http://www.debian.org/~srivasta/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C
Bug#898229: ITP: cloudsql-proxy -- Securely connect to CloudSQL databases
Package: wnpp Severity: wishlist Owner: Manoj Srivastava * Package name: cloudsql-proxy Version : 1.11+git20180420.74e2f41-1 Upstream Author : Google Cloud Platform * URL : https://github.com/GoogleCloudPlatform/cloudsql-proxy * License : Apache-2.0 Programming Lang: Go Description : Securely connect to CloudSQL databases The Cloud SQL Proxy allows a user with the appropriate permissions to connect to a Second Generation Cloud SQL database without having to deal with IP whitelisting or SSL certificates manually. It works by opening unix/tcp sockets on the local machine and proxying connections to the associated Cloud SQL instances when the sockets are used. See https://cloud.google.com/sql/docs/mysql/sql-proxy for details. -- This life is a test. It is only a test. Had this been an actual life, you would have received further instructions as to what to do and where to go. Manoj Srivastava <http://www.golden-gryphon.com/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C smime.p7s Description: S/MIME cryptographic signature
Re: a poll for Dgit workflows
On Wed, Mar 23 2016, Adam Borowski wrote: > On Wed, Mar 23, 2016 at 12:57:59PM -0700, Manoj Srivastava wrote: >> On Wed, Mar 23 2016, Adam Borowski wrote: >> And creates a source package that does not correspond to my >> repository. I don’t need to have a ./debian/patches in my repository; >> all that information, along with a rich history of changes, is already >> in git. > echo .pc/ >>.gitignore > echo debian/patches/ >>.gitignore OK. I guess I could do that. Scrub that. >> I admit, I don’t much care whether the source debian.tar.xz >> reflects my repository or not, if it didn’t leave artifacts that >> dirtied my working tree when creating the source package. > These artifacts are no different from the rest of build droppings, ie, they > can be gitignored just the same. No, since the other artifact are created on my build daemon remotely; just the dpkg-source -b bits are left. However, adding to the .gitignore would address that. >> I also sometimes unpack debian source packages on machines without dpkg >> on them; source format 1.0 makes it somewhat easier. > Valid point. :-) The bit about my source repo not being the same as tghe source package does irritate dgit; and I care more about that publication channel than I do about 3.0 (quilt) manoj -- "Don't hate me because I'm beautiful. Hate me because I'm beautiful, smart and rich." -- Calvin Keegan Manoj Srivastava <http://www.debian.org/~srivasta/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C smime.p7s Description: S/MIME cryptographic signature
Re: a poll for Dgit workflows
On Wed, Mar 23 2016, Adam Borowski wrote:
> On Wed, Mar 23, 2016 at 01:32:59PM +, Ian Jackson wrote:
>> Adam Borowski writes ("Re: a poll for Dgit workflows"):
>> > On Mon, Mar 21, 2016 at 10:19:01AM +0100, Daniel Stender wrote:
>> > > Ah yes, source format 1.0 fits better here. Thanks for the pointer and
>> > > comments (Manoj, too).
>> >
>> > Please don't use source format 1.0, it sucks. Instead, you can:
>> > echo single-debian-patch >debian/source/options
>> > which gives you all upsides of 3.0 without the big downside, aka quilt.
And creates a source package that does not correspond to my
repository. I don’t need to have a ./debian/patches in my repository;
all that information, along with a rich history of changes, is already
in git.
I admit, I don’t much care whether the source debian.tar.xz
reflects my repository or not, if it didn’t leave artifacts that
dirtied my working tree when creating the source package. I also
sometimes unpack debian source packages on machines without dpkg on
them; source format 1.0 makes it somewhat easier.
And it does interfere with using dgit as a publication
mechanism.
>> Please don't use source format `3.0 (quilt)', it sucks.
>
> Could you tell us what other downsides it has, besides quilt?
> All other differences I'm aware of are upsides: .xz, multiple tarballs
> or ambivalent: purging upstream debian/
The source format 1.0 can also use .xz, if it so desired, right?
Or a source format 1.1? Perhaps at some point someone, perhaps I, will
take a stab at that.
And, if I ma channel Marco here, multiple tarballs and purging
upstream debian/ does nothing for me. But there is nothing in that that
is tied to source format 3.0 (quilt); in theory all these features, if
deemed important enough an itch to scratch, can be addressed.
As long as arbitrarily serialized patch sets are not my
preferred form of modification, ./debian/patches seems like busy work.
manoj
--
Everyone has a purpose in life. Perhaps yours is watching
television. David Letterman
Manoj Srivastava <http://www.golden-gryphon.com/>
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C
smime.p7s
Description: S/MIME cryptographic signature
Re: a poll for Dgit workflows
On Wed, Mar 23 2016, Marco d'Itri wrote:
> On Mar 23, Ian Jackson wrote:
>
>> Obviously, for dgit to be useful, it has to define a standard
>> interchange format. That format has to be patches-applied because
>> otherwise naive users can't work with the source code properly.
> Having the alleged needs of naive users dictate the design of our tools
> looks like a very bad choice to me...
That would be correct, it it were only true
> I want something that is useful to me, not to mythical random naive
> users who may want to work on Debian packages without understanding the
> basics of how they are created.
I think dgit should address the needs of all kinds of people,
as it does not. Not all the people who disagree with you are mythic
(though I quite like the appelation).
I appreciate the fact that dgit does indeed do things that are
useful to me. Thanks, Ian.
>
>> But that doesn't necessarily mean that a maintainer who likes to work
>> with patches-unapplied trees has to change their workflow to use dgit.
> No, I do not want to have patches-applied *repositories*.
Sure. I do. Always have. Now er both have opinions, but I doubt
mere opinions are useful to the rest of the readers here.
>> I have a work-in-progress dgit branch which will convert,
>> automatically, a patches-unapplied branch, to a patches-applied
>> branch, during dgit push. The maintainer never has to look at the
>> patches-applied branch, but it appears on the dgit git server for
>> other dgit users to see.
> I am not sure of what benefits dgit would bring to me if I am not going
> to use the repositories that it creates.
I don’t think there is a contention that dgit is for everyone. I
think it offers a useful publication medium; and if it allos other
people to work with developers who do or do not prefer the repositories
to reflect the tree the software is actually built from, then it is a
net plus.
manoj
--
Life is like an egg stain on your chin -- you can lick it, but it still
won't go away.
Manoj Srivastava <http://www.debian.org/~srivasta/>
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C
smime.p7s
Description: S/MIME cryptographic signature
Re: a poll for Dgit workflows
On Wed, Mar 23 2016, Ian Jackson wrote:
> Marco d'Itri writes ("Re: a poll for Dgit workflows"):
>> I like the general idea of dgit, but I will never use it as long as it
>> requires committing patched trees.
>
> Obviously, for dgit to be useful, it has to define a standard
> interchange format. That format has to be patches-applied because
> otherwise naive users can't work with the source code properly.
It’s not just naive users that prefer working with git and
branches natively. My preferred form of modification is pull requests
for my git repositories (my packaging repositories are mirrored on
alioth and github). I can build and test the tip of any of my feature
branches or upstream, or the fully merged debian branch, so I can make
sure that the features I submit upstream actually work. I think that is
harder to do if the repository has just a jumble of patches in a
directory, and is missing the development history of the features.
While git-debcherry does automate the pain
point of serializing commits on different feature branches, the
commits are out of order for each feature, and it is a lot of busy work
getting the series of patches properly ordered, and there are always
merge artifacts in the patch series as slightly overlapping branches
are brought back into conformance.
I prefer not to get patches to the source predicated on how the
feature branches have been serialized; most people in this era of
github can and do work with remote git repositories, and others can
still send me patches by mail that I’ll break down into changes to a
fix branch that I shall send upstream.
Given the number of times that most projects get sent changes
versus the maintainer having to work with version control themselves, I
think that debian-single-patch is acceptable (well, in my opinion, of
course).
manoj
--
Today is the first day of the rest of your life.
Manoj Srivastava <http://www.debian.org/~srivasta/>
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C
smime.p7s
Description: S/MIME cryptographic signature
Re: a poll for Dgit workflows
On March 19, 2016 8:27:43 AM PDT, Daniel Stender wrote: >Hi, > >dealing with Dgit beyond a "simple" workflow (clone/fetch - make >changes - dgit push) I >wanted to poll for workflows towards new upstream tarballs and, >connected to that, the >treatment of patches. My work flow is probably not what you are looking for, but here goes. I have adopted dgit into my usual vcs based model. There is an development branch that tracks upstream development. Based on that there is upstream, that occasionally also imports tarballs, which have artifacts not in upstream git at times. I use pristine tar to reproduce the tarballs. For each feature or fix that I carry, there is a feature branch based off the upstream branch, so I can feed changes back. All these branches are merged into the matter branch. Dgit/Sid is identical to master. git co development git pull git co upstream git merge -S development git import-tar-pristine git co master git merge -S upstream git merge -S some-fix-branch edit debian/changelog git ci -S -S git co dgit/sid git merge -S --ff-only master gitpkg HEAD Test dgit push I use gitpkg to build on a KVM or remote virtual machine. Source format 1.0 means this is pure git schema, no serialized patches. Manoj -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
{MBF}: Upcoming changes in flex to accommodate multiarch
: gcc-h8300-hms twinkle: gnuift: bip: aegis: gtkpod: splint: libfl-dev mig: libfl-dev comedilib: tth: pajeng: libfl-dev libvc: buici-clock: eegdev: gnubg: amanda: a2ps: kamailio: grap: grib-api: extsmail: orafce: unbound: #809055 android-platform-frameworks-base: ldm: alliance knot: tagcoll2: gnat-4.9 delta: mira: libfl-dev wfrench: libfl-dev tcpxtract: libfl-dev xmlindent: libfl-dev pcb: olsrd: tacacs+: gcc-mingw-w64 ola snacc iverilog: fwlogwatch: cfengine3: nftables: avrdude: cfengine2: prime-phylo: gnats: pcsc-lite: libghemical: vala: php7.0: flasm: cscope: sip4: kdevelop-pg-qt: ghemical: mesa: taopm: automake-1.14 openscad: picviz: glusterfs: mysql-workbench: contextfree: libfl-dev gcc-arm-none-eabi java2html: libfl-dev ball hp48cc: broccoli: faumachine cross-binutils guile-1.8: ircd-ircu: libfl-dev sfst: zmap: kfreebsd-10: faust: cproto: cross-gcc-4.9-mipsel openafs: vala-0.28: fdm: wine: crossfire: twm: cross-gcc-4.9-arm64 fauhdlc: libfl-dev libzerg: gcc-m68hc1x slony1-2: gutenprint: genparse sloccount: binutils-arm-none-eabi: libhdf4: llvm-toolchain-3.7 cyrus-imapd-2.4: chuck: iproute2: libguestfs gpick: grok: imagevis3d: kbuild: urjtag: gpsim: gcc-avr nmap: am-utils: gcc-4.8 gcc-3.3 lm-sensors: hurd gtkwave: cc: fuse-emulator: geda-gaf: vips: gcc-5-cross-ports opensm: netpbm-free: usepackage: opencryptoki: qtwebkit-opensource-src libnl3: pcmciautils: scotch: zimpl: ns3: flow-tools: libfl-dev setools: virtuoso-opensource: php5.6 coala: libfl-dev vile: guile-2.0: ike: mailutils: opensc: conntrack-tools: binutils-z80: maude: flobopuyo: libstdc++-arm-none-eabi: lyskom-server: trafficserver: hkgerman: swftools: gregorio: remem: nas: wine-development: gcc-5 cbmc: sylpheed: routino: acpica-unix: mailfilter: libfl-dev ug: lowpan-tools: octave apertium: jack-tools: qt4-x11: nagios-plugins-contrib: slashem: php5 bro: syslog-ng: 3dldf: libaacs: cross-gcc-4.9-mips miller: freebsd-utils heimdal texlive-bin: psicode: afterstep: dreamchess: warzone2100: libfl-dev pyg: #713183 ddd: binutils-mingw-w64: pretzel: #800198 gnokii: bc: asn1c: boost1.58: gobject-introspection: Agustin Martin Domingo linuxdoc-tools (U) Alastair McKinstry libdap Andreas Tille acedb (U) ctn (U) mira (U) Andy Spencer librsl (U) Ansgar Burchardt at (U) Blars Blarson xview Bram Senders contextfree Branden Robinson vtwm Charles Plessy mira (U) Christian Hofstaedtler ipsec-tools (U) Christoph Egger undertaker warzone2100 (U) Debian Electronics Team verilator Debian Games Team bsdgames warzone2100 Debian Med Packaging Team acedb ctn mira Debian QA Group libidl Debian Science Maintainers coala libmatheval librsl surf-alggeo Debian SELinux maintainers checkpolicy Debian XML/SGML Group linuxdoc-tools Don Armstrong lilypond Dr. Tobias Quathamer bsdgames (U) Ernesto Nadir Crespo Avila flow-tools (U) FAUmachine Team fauhdlc Georges Khaznadar chemeq units-filter GNU Hurd Maintainers mig Ian Lynagh (wibble) haskell98-tutorial Jack Bates libzdb Jari Aalto ccbuild Jerome Benoit surf-alggeo (U) Joao Eriberto Mota Filho detox tcpxtract Joerg Jaspert mailfilter Jose M Calhariz at Julian Taylor libmatheval (U) Khalid El Fathi wfrench Loic Dachary (OuoU) jaula LTSP Debian Maintainers ltsp Lucas Nussbaum pajeng (U) Manoj Srivastava checkpolicy (U) Marco d'Itri ifmail Marius Gavrilescu filters Martin Loschwitz ircd-ircu Martin Quinson pajeng Matt Brown srg Matt Grant ipsec-tools (U) Michael R. Crusoe mira (U) Michele Martone fim Mike Gerber poc-streamer Miriam Ruiz xmlindent Noah Meyerhans ipsec-tools (U) Ola Lundqvist jaula (U) Paul Cager java2html Paul Martin milter-greylist Paul van Tilburg contextfree (U) Paul Wise warzone2100 (U) Peter De Schrijver (p2) linux-atm pkg-ipsec-tools team ipsec-tools Radu Spineanu flow-tools Ralf Treinen mccs Reinhard Tartler undertaker (U) Rene Mayrhofer strongswan (U) Ricardo Mones mailfilter (U) Robert Lemmen dicelab Roger Leigh pam (U) Roger Shimizu wide-dhcpv6 Romain Francoise strongswan (U) Russell Coker checkpolicy (U) Sam Hartman pam (U) Samuel Thibault mig (U) Stefan Potyra fauhdlc (U) Steffen Moeller acedb (U) mira (U) Steve Langasek pam strongSwan Maintainers strongswan Thomas Krennwallner coala (U) Thorsten Alteholz mira (U) Tim Booth mira (U) tony mancill ccbuild (U) Vagrant Cascadian ltsp (U) Volkmar Sieh fauhdlc (U) Xiangfu Liu fped Y Giridhar Appaji Nag splint Yves-Alexis Perez strongswan (U) أحمد المحمودي (Ahmed El-Mahmoudy) verilator (U) References: [0] https://lists.debian.org/debian-cross/2016/02/msg00017.html [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=6
Communicating about the change in behaviour for ar
Hi, I was trying to import the new version of make into unstable, and I discovered that t/10 tests about the archive related part of makes test suite failed. The reason was a change in the behaviour of ar, which is now configured with --enable-deterministic-archives. When adding files and the archive index use zero for UIDs, GIDs, timestamps, and use consistent file modes for all files. When this option is used, if ar is used with identical options and identical input files, multiple runs will create identical output files regardless of the input files' owners, groups, file modes, or modification times. This seems like good news for reproducible builds. Unfortunately, when using makes libxx(*.a) syntax for creating archives, make needs the timestamp of the file in order to decide to update it or not. With the current deterministic behavior of ar, the timestamp is always 0. This is behaviour that is not backwards compatible (as can be seen in the bug report #798804 and #798913). Some operations, instead of being no-ops, now rebuild theg/Lunar archive. T think the change, because of the benefits of the reproducible builds, are a good thing, but I also think that they are not visible to the general user base (not all the users of ar and make are debian developers, and the release is not the only thing built using ar and make). My recommendations is a NEWS file entry for binutils and make; and a mention in the release announcement for reproducible builds. I have uploaded a version of make the defaults to adding U to the ARFLAGS, but, on research and reflection, I would be open to reverting that and adding a NEWS entry. Manoj -- Anything worth doing is worth overdoing. Manoj Srivastava <http://www.debian.org/~srivasta/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C
Re: Ideas to improve dpkg/ucf with hooks
I am open to suggestions. Manoj On November 16, 2015 9:38:23 AM PST, Marc Haber wrote: >On Mon, 16 Nov 2015 20:29:48 +0800, Paul Wise wrote: >>On Mon, Nov 16, 2015 at 8:15 PM, Marc Haber wrote: >>> I am aware of that. That's one of my reasons for advocating giving >the >>> needed love to ucf and to deprecate dpkg's conffile functions in >favor >>> of ucf. A extended / enhanced ucf can replace dpkg with a lot less >>> work than would be necessary to bring dpkg's conffile handling into >>> the 2020ies decade. >> >>I note that merging ucf into dpkg is on the dpkg roadmap: >> >>https://wiki.debian.org/Teams/Dpkg/RoadMap > >I advocate doing things exactly the other way roud. Give package >maintainers the power! > >Greetings >Marc >-- >-- !! No courtesy copies, please !! >- >Marc Haber | " Questions are the | Mailadresse im >Header >Mannheim, Germany | Beginning of Wisdom " | >http://www.zugschlus.de/ >Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 >72739834 -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: Ideas to improve dpkg/ucf with hooks [was: Putting default config files in /usr]
Hi, Adding in his or callbacks would be easy enough. Do you have an idea of what you would need for your use case? Manoj On November 13, 2015 9:22:45 AM PST, Vincent Danjean wrote: >Le 13/11/2015 17:47, Marc Haber a écrit : >> Actually, I don't quite see why ucf would need hooks since it is >> called from the maintainer scripts, giving the local admin full power >> of creativity anyway. Chances are that ucf is already the right tool >> to maintain systemd and friends the Debian way if the Debian >packaging >> team would be willing to. > >Because I cannot see a way (but diverting ucf itself) to interface it >with etckeeper so that original maintainer files will be kept in a >different git branch with merges in the master branch to keep the >modified config. > > Regards >Vincent > >-- >Vincent Danjean GPG key ID 0xD17897FA vdanj...@debian.org >GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA >Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html >APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: Trimming priority:standard
Hi, Huh. I have been waiting for emacs/lisp/systemd.el Manoj On September 12, 2014 7:49:45 PM PDT, John Goerzen wrote: >On 09/12/2014 02:27 PM, Barry Warsaw wrote: >> On Sep 12, 2014, at 07:18 PM, Jakub Wilk wrote: >> >>> I'm looking forward for systemd-mta. >> >> It's inevitable. ;) >> >> http://catb.org/jargon/html/Z/Zawinskis-Law.html >> >> -Barry >Just wait for systemd-emacs. It would obsolete... all of gnuserv! -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: Standardizing the layout of git packaging repositories
hi, ill send out a concrete example when I get back home Manoj On September 7, 2014 8:41:45 PM PDT, Brian May wrote: >On 8 September 2014 04:05, Ben Hutchings wrote: > >> How does git-debcherry cope with the overlapping changes when >generating >> debian/patches? What can you do if it fails to linearise the changes >> (as, apparently, it may sometimes do)? >> > >Just did some fiddling. > >I have no idea if this is the git-debcherry I should be using or not, >so >far it is the only copy I have found: git://pivot.cs.unb.ca/gitpkg.git > >I created a script that generates a some commits on different feature >branches, with a deliberate conflict. > >Unexpectedly, this means there is only one patch generating with both >feature branches included. However the results appear to be technically >correct. > >My random thought: I like being able to predict what will happen to >patches >in git-dpm. For example, if I supply the git-debcherry produced patch >file >name, when upstream get around to looking at it, that patch may no >longer >exist because I (accidentally?) created a newer patch that conflicts. > >Not sure if there is an easy way to tell if two feature branches >conflict >or not. This might be me and/or something that can be fixed in >git-debcherry though. > >Regardless, if you need to make a sequence of changes, say to one >file, git-dpm would appear to be the better choice, I think. > >Note the script does a "rm -rf a", so don't do this on anything >important. git-debcherry location is also hard coded. > > >=== cut === >#!/bin/sh > >set -ex > >rm -rf a > >mkdir a >cd a >git init > >touch readme.txt >git add readme.txt >git commit -m "upstream" > >git branch upstream > ># feature a version 1 >git checkout -b feature_a upstream >echo "My line 1" > readme.txt >echo "My line 1" > readme0.txt >git add readme.txt readme0.txt >git commit -m "feature a version 1" > ># feature b version 1 >git checkout -b feature_b upstream >echo "My line 2" > readme2.txt >git add readme2.txt >git commit -m "feature b version 1" > ># merge feature a and feature b into debian >git checkout -b debian upstream >git merge feature_a -m "merge feature a" >git merge feature_b -m "merge feature b" > ># modify feature a >git checkout feature_a >echo "My line 1 (modified)" > readme.txt >git add readme.txt >git commit -m "feature a version 2" > ># merge feature a into debian >git checkout debian >git merge feature_a -m "merge feature a" > ># modify feature b, make it conflict with feature a >git checkout feature_b >echo "My line 1 (extra modified)" > readme.txt >echo "My line 2 (extra modified)" > readme2.txt >git add readme.txt readme2.txt >git commit -m "feature b version 2" > ># merge feature b into debian, resolve conflict >git checkout debian >git merge feature_b -m "merge feature b" -X theirs > ># generate patch >../gitpkg/git-debcherry -o debian/patches upstream >../gitpkg/git-debcherry --stat upstream >=== cut === > >The gives me one patch file, with all the changes: > >=== cut === >>From 71ed7d5182996226fdaa4c1195a3e0dd0bb3fce7 Mon Sep 17 00:00:00 2001 >From: Brian May >Date: Mon, 8 Sep 2014 13:13:35 +1000 >Subject: [PATCH] debcherry fixup patch > >18eb718 feature b version 2 > - no changes against upstream or conflicts >558086e feature a version 2 > - extra changes or conflicts >a898018 feature b version 1 > - extra changes or conflicts >daa2cc6 feature a version 1 > - extra changes or conflicts >--- > readme.txt | 1 + > readme0.txt | 1 + > readme2.txt | 1 + > 3 files changed, 3 insertions(+) > create mode 100644 readme0.txt > create mode 100644 readme2.txt > >diff --git a/readme.txt b/readme.txt >index e69de29..2f782d4 100644 >--- a/readme.txt >+++ b/readme.txt >@@ -0,0 +1 @@ >+My line 1 (extra modified) >diff --git a/readme0.txt b/readme0.txt >new file mode 100644 >index 000..d6d5ab4 >--- /dev/null >+++ b/readme0.txt >@@ -0,0 +1 @@ >+My line 1 >diff --git a/readme2.txt b/readme2.txt >new file mode 100644 >index 000..977df1d >--- /dev/null >+++ b/readme2.txt >@@ -0,0 +1 @@ >+My line 2 (extra modified) >-- >1.9.1 >=== cut === >-- >Brian May -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: Standardizing the layout of git packaging repositories
hi, no, I get one patch per commit, plus a fixup patch. no squashing. Manoj On September 7, 2014 8:53:04 PM PDT, Brian May wrote: >On 7 September 2014 13:30, Manoj Srivastava >wrote: > >> >> | I commit | Ephemeral gbranch contains | Master contains | >> |--++-| >> | B2 | A11, B12, B21 | D6 | >> >> There are there nodes in the ephemeral branch, and three >patches >> are produced -- Corresponding to A1, B1, and B2. >> > >Oh, so you want separate patches for each stage, B1, B2, etc? > >I assumed you would want to combine them into one patch. > >If I understand this correctly, I think your git debcherry example >would >squash them into one commit. Or at least, that seems to be what happens >for >my specific test case. >-- >Brian May -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: Standardizing the layout of git packaging repositories
Hi, You need to bag Ron, or pull from the hit repositories directly. Manoj On September 7, 2014 5:24:18 PM PDT, Brian May wrote: >On 8 September 2014 04:05, Ben Hutchings wrote: > >> How does git-debcherry cope with the overlapping changes when >generating >> debian/patches? What can you do if it fails to linearise the changes >> (as, apparently, it may sometimes do)? >> > >I am not sure this needs to be an issue. Or maybe I am just not seeing >the >problem correctly... > >Where do I get git-debcherry from? > >Would like to get a copy so I can prove my preconceived and fixed ideas >on >which one is better .^C^C^C^C^C^C^C >Would like to get a copy so I can understand some of these issues >better >myself. >-- >Brian May -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: Standardizing the layout of git packaging repositories
Hi, You have to ask Paul Bremer that. Me, I am merely a happy user. I did grok it at one point, but I no longer recall that. Manoj On September 7, 2014 11:05:50 AM PDT, Ben Hutchings wrote: >On Sat, 2014-09-06 at 22:03 -0700, Manoj Srivastava wrote: >> On Sun, Sep 07 2014, Scott Kitterman wrote: >> >> > On September 6, 2014 11:30:11 PM EDT, Manoj Srivastava > wrote: >> >> > I'll confess up front that I'm a neophyte when it comes to git. >From >> > what I can tell though we've been using git-dpm for feature >branches >> > in pkg-clamav and it seems to me to work fine. >> >> Oh, it works mostly fine, with some finicky handling of the >> ephemeral patched branch. I must worry about checking out the >patched >> branch, sherry picking commits to it, handling conflicts, rebasing, >> squashing, rearranging -- and I did all that for a while before I >> discovered git-debcherry, It got old fast. Perhaps it is my fault, >my >> feature branches sometimes have slightly overlapping changes. I >never >> ever want to muck with something merely to create serialized linear >> patches for packaging. >[...] > >How does git-debcherry cope with the overlapping changes when >generating >debian/patches? What can you do if it fails to linearise the changes >(as, apparently, it may sometimes do)? > >Ben. > >-- >Ben Hutchings >Experience is directly proportional to the value of equipment >destroyed. >- Carolyn Scheppner -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: Standardizing the layout of git packaging repositories
On Sun, Sep 07 2014, Scott Kitterman wrote: > On September 6, 2014 11:30:11 PM EDT, Manoj Srivastava > wrote: > I'll confess up front that I'm a neophyte when it comes to git. From > what I can tell though we've been using git-dpm for feature branches > in pkg-clamav and it seems to me to work fine. Oh, it works mostly fine, with some finicky handling of the ephemeral patched branch. I must worry about checking out the patched branch, sherry picking commits to it, handling conflicts, rebasing, squashing, rearranging -- and I did all that for a while before I discovered git-debcherry, It got old fast. Perhaps it is my fault, my feature branches sometimes have slightly overlapping changes. I never ever want to muck with something merely to create serialized linear patches for packaging. With git-debcherry I ignore ./debian/patches and ever needing to worry about what lives in it. I work with pure git feature branches, say: gitpkg-build HEAD upstream and I am done. It creates the ./debian/patches directory while checking out the source, knows about pristine-tar, creates the source package, ssh's into my build virt (starting it as needed), builds it, runs lintian and piuparts checks, and stuff is there for me to install, test, sign, and upload. All the tags are done for me. No twiddling with stuff for 3.0 (quilt). I am too lazy to ever want to deal with it. > I'd be curious what you'd find if you had a look at the team > repository for clamav to see if what we're doing matches your concept > of feature branches? I'll have a look once I get back in town. manoj -- The Golden Rule of Arts and Sciences: He who has the gold makes the rules. Manoj Srivastava <http://www.debian.org/~srivasta/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C signature.asc Description: PGP signature
Re: Standardizing the layout of git packaging repositories
On Sun, Sep 07 2014, Brian May wrote: > In another email by Manoj Srivastava: > >> That is really a matter of displaying history. The diagram > displays Git history, not the patches; when B21 is committed, > there is no > patch representing B12, however, that commit is still in /.git/objects > since it is a parent of the Node D3. This > is relevant when I am trying to > trying to bisect and understand history. git-debcherry has fewer commits > being carried around, > which makes it easier on my aging brain. > Sorry, I think you have this wrong. (also nitpick: B12 is a parent of D5, > not D3). I aplogize, I I have not conveyed what is happening correctly, and you are confused by my diagrams. I shall try to do better. > When you commit B21, you have to replace B12 in the git history (e.g. git > commit --amend). Otherwise, when the patches are exported, you will get > both B12 and B21 appearing as separate patches debian/patches in D6. dpm > has no way of knowing that B12 and B21 are part of the same patch and > should be merged. That is the outcome I want. I commit B1, and later, B2. git-dpm creates ephemeral branches, | I commit | Ephemeral gbranch contains | Master contains | |--++-| | A1 | A10| D2 | | B1 | A10, B11 | D3 | | U2 | A11. B12 | D5 | At this point B11 ans A10 are gone, apart from living in .git/objects. | I commit | Ephemeral gbranch contains | Master contains | |--++-| | B2 | A11, B12, B21 | D6 | There are there nodes in the ephemeral branch, and three patches are produced -- Corresponding to A1, B1, and B2. | I commit | Ephemeral gbranch contains | Master contains | |--++-| | A2 | A11, A21, B13, B22| D7 | Four commits on the feature branches, and the ephemeral branch contains 4 commits -- the older ephemeral branches continue to live in .git/objects, which bothers the purist in me, > Maybe your point that debcherry is better still stands - it appears to work > better with your concept of "feature branches", however I find it hard to > use your document to compare the two when it contains errors like this. I think the errors lie in documentation of what the diagram is and thus the incorrect interpretation, rather than the underlying analysis. I'll try do document better what the diagrams mean. Has this helped you understand what the document is trying to say? manoj -- The sooner all the animals are extinct, the sooner we'll find their money. Ed Bluestone Manoj Srivastava <http://www.debian.org/~srivasta/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C signature.asc Description: PGP signature
Re: Removing < 2048 bit keys from the Debian keyrings
On Tue, Sep 02 2014, Manoj Srivastava wrote: > On Tue, Sep 02 2014, Jeremy T. Bouse wrote: > > >> I don't know how the *-cert-level options in gpg/gpg2 match up with >> that section RFC480. Actually reading the sections in the man pages it >> reads very differently. > > I stand corrected. Now I just need to figure out how to resign > the keys with the new options. I figured out how to do the signatures; I am now torn between whether I should resign just to get the cert-level data in the signature, and effectively obscuring when the signature was actually made (well, or replacing the date when I had checked the ID with the current one). I'll re-sign the keys from the current debconf in a month, if they make their way to the keyservers, but i'll leave the historical signatures alone. I learned something today :-) manoj -- If I have not seen so far it is because I stood in giant's footsteps. Manoj Srivastava <http://www.debian.org/~srivasta/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C signature.asc Description: PGP signature
Re: Removing < 2048 bit keys from the Debian keyrings
On Tue, Sep 02 2014, Jeremy T. Bouse wrote: > I don't know how the *-cert-level options in gpg/gpg2 match up with > that section RFC480. Actually reading the sections in the man pages it > reads very differently. I stand corrected. Now I just need to figure out how to resign the keys with the new options. manoj -- Winning isn't everything, but losing isn't anything. Manoj Srivastava <http://www.debian.org/~srivasta/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/878um1xmyi@glaurung.internal.golden-gryphon.com
Re: Removing < 2048 bit keys from the Debian keyrings
On Tue, Sep 02 2014, Matthias Urlichs wrote: > there's a GPG option (via the the *-cert-level options, see 'man gpg') > to state how carefully you did verify their identity, but ultimately > it's up to you. That is not how I interpreted that option to mean. ,[ http://tools.ietf.org/html/rfc4880#section-5.2.3.13 ] | 5.2.3.13. Trust Signature | | | (1 octet "level" (depth), 1 octet of trust amount) | | Signer asserts that the key is not only valid but also trustworthy at | the specified level. Level 0 has the same meaning as an ordinary | validity signature. Level 1 means that the signed key is asserted to | be a valid trusted introducer, with the 2nd octet of the body | specifying the degree of trust. Level 2 means that the signed key is | asserted to be trusted to issue level 1 trust signatures, i.e., that | it is a "meta introducer". Generally, a level n trust signature | asserts that a key is trusted to issue level n-1 trust signatures. | The trust amount is in a range from 0-255, interpreted such that | values less than 120 indicate partial trust and values of 120 or | greater indicate complete trust. Implementations SHOULD emit values | of 60 for partial trust and 120 for complete trust. ` For a personal (non-work) GPG key, I am not sure I ever want to sign above a level 0, and thus give the key a "right" to sign on my behalf. Also, it indicates a statement of belief in someone's ability to make proper certifications (and avoid improper ones), in addition to a statement of belief that the identity of the keyholder is correctly stated. I have no idea how to assess the former, except for the few people I have had a technical conversation with about their key signing policies, and even then, there are few people whose beliefs and conventions align closely to mine. Here is some more detail from the mailing lists: ,[ http://lists.gnupg.org/pipermail/gnupg-users/2005-May/025612.html ] | tsign is just like sign (or lsign) except that you are asked a few | more questions by GnuPG. Think of tsign as a combination of a regular | signature plus the ownertrust. This combines two different things | from the classic trust model into one signature. | | First you are asked: | |Please decide how far you trust this user to correctly verify other |users' keys (by looking at passports, checking fingerprints from |different sources, etc.) | | 1 = I trust marginally | 2 = I trust fully | | This is similar to the question you get asked when setting ownertrust. | What GnuPG is asking is not how much you trust the user, but how much | you trust the user to make good signatures. | The next question is: | |Please enter the depth of this trust signature. |A depth greater than 1 allows the key you are signing to make |trust signatures on your behalf. | | The signature depth is how many levels "deep" can the power granted by | this signature travel. For example, a level of 1 means that the key | you sign is valid for you (just like a regular signature), but also | that the ownertrust for this key is automatically set to MARGINAL or | FULL (depending on how you answered the first question). A level of 2 | means that the key you sign is valid for you, and the ownertrust is | automatically set, AND (assuming the trust made it to FULL) that this | key can issue signatures up to level 1 on your behalf. A level of 3 | means all that, plus the key can issue signatures up to level 2, etc. | | You can think of a regular signature as a trust signature with a depth | of 0. | | The next question: | |Please enter a domain to restrict this signature, or enter for none. | | This allows you to restrict (by domain name) the power of the | signature. For example, let's say that you wanted to make a level 2 | signature on a CA key for a particular company. You should be careful | with making any level above 1, so you want to restrict this to that | company. By giving a restriction of companyname.com here, only | signatures issued by the CA key on keys in companyname.com will take | effect. ` manoj -- Have at you! Manoj Srivastava <http://www.debian.org/~srivasta/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C signature.asc Description: PGP signature
Re: Standardizing the layout of git packaging repositories
On 08/26/2014 10:53 PM, Brian May wrote: On 26 August 2014 16:12, Manoj Srivastava wrote: http://people.debian.org/~srivasta/Serializing_Git_Branches.pdf has a demonstration of the differences in history given an upstream and two feature branches with two commits each, using git-dpm and git-debcherry. Interesting review. However, I think there might be some errors. I don't think you should use normally be feature branches with git-dpm. Rather you edit the commit directly (whether by rebase or --amend). As I have commented elsewhere in this thread, that restriction makes git-dpm a less viable alternative for complex packages. Also I think there is an error in the way you have done the git-dpm, e.g. when committing B21, you have added to the existing B12 patch instead of replacing it. Similarly when adding A31, you haven't replaced A11. That is really a matter of displaying history. The diagram displays Git history, not the patches; when B21 is committed, there is no patch representing B12, however, that commit is still in /.git/objects since it is a parent of the Node D3. This is relevant when I am trying to trying to bisect and understand history. git-debcherry has fewer commits being carried around, which makes it easier on my aging brain. Manoj -- 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/53ff7a8d.5080...@golden-gryphon.com
Re: Standardizing the layout of git packaging repositories
hi, rebasing is not an option for any branch that is published, and is very ride to your downstream developers. if git-dpm requires that model of software development, one would have to consider it unsuitable for non trivial package development. I certainly hope that is not the case. Manoj On August 26, 2014 11:40:26 PM PDT, Matthias Urlichs wrote: >Hi, > >Brian May: >> I don't think you should use normally be feature branches with >git-dpm. >> Rather you edit the commit directly (whether by rebase or --amend). >> >If Upstream uses git and wants you to send a pull request when you add >a >feature (or fix a bug), then using a feature branch is what you do – so >our >git-aware packaging tools should work well with them. > >-- >-- Matthias Urlichs -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: Standardizing the layout of git packaging repositories
hi, in my analysis, features a and b are indeed long lived branches with multiple commits over time, independently evolving, until such time they are folded in upstream. I will address the other point when I an motte awake, I recognize that git-dpm creates ephemeral branches, but the commits there live as parents accessible from the commits on the integration branch Manoj On August 27, 2014 1:24:21 AM PDT, Raphael Hertzog wrote: >Hi, > >On Wed, 27 Aug 2014, Matthias Urlichs wrote: >> Brian May: >> > I don't think you should use normally be feature branches with >git-dpm. >> > Rather you edit the commit directly (whether by rebase or --amend). >> >> If Upstream uses git and wants you to send a pull request when you >add a >> feature (or fix a bug), then using a feature branch is what you do – >so our >> git-aware packaging tools should work well with them. > >I think you're not understanding each other. > >Unless the "feature" is complex enough to require multiple commits, >Brian >is saying that evolving the feature is done by amending the commit that >is in the feature branch instead of adding supplementary commits in the >feature branch. > >debian/patches should be seen as stacked/linearized series of features >branches. > >HTH. >-- >Raphaël Hertzog ◈ Debian Developer > >Discover the Debian Administrator's Handbook: >→ http://debian-handbook.info/get/ > > >-- >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/20140827082421.gb23...@x230-buxy.home.ouaza.com -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: Standardizing the layout of git packaging repositories
hi. http://people.debian.org/~srivasta/Serializing_Git_Branches.pdf has a demonstration of the differences in history given an upstream and two feature branches with two commits each, using git-dpm and git-debcherry. Manoj On August 25, 2014 11:01:17 PM PDT, Brian May wrote: >Ok, so I have looked at both gbp-pq and git-dpm. > >To me, the key difference is different way they store the patches. >There >are minor differences in user interfaces, etc, however I don't consider >these to be so important. > >(apologies if this has already been said or contradicted, I am finding >it >hard to keep up with these threads) > > >gbp-pq >- >Tutorial: >https://honk.sigxcpu.org/piki/development/debian_packages_in_git/ > >In gbp-pq, the authoritative source is always the patches in >debian/patches. The patch-queue is just for convenience, so you can >update >patches with standard git commands. There is no history kept of the >patch-queue branch. Possibly the patch-queue branch shouldn't be pushed >to >remote repositories, because rebasing is expected. This makes it >simple. >History is kept of debian/patches. It is not possible to refer to >patches >with commit id, because this won't last a rebase or reedit. However, >comparing different Debian versions with patches applied won't be so >easy, >you will have to check out two copies, manually apply the patches, and >then >do a diff. > >git-dpm >-- >Tutorial: http://git-dpm.alioth.debian.org/examples.html > >git-dpm keeps every version of every patch in git. As a result, every >patch >in debian/patches has a hash referencing the git commit. After merged >into >the Debian branch, this hash will not disappear even if the patch is >deleted or changed. You can provide the commit id of the patch, if ever >required (most cases the latest patch file might be better choice). As >above, history is also kept of the debian/patches directory. I believe >if >you do a diff between two debian tags you will get the patches >included. > >summary >--- >There are two options I haven't looked at: dgit and git-debcherry (or >is >that got-debcherry?) - mainly because I can't find these using Google. > >gbp-pq and git-dpm are not compatible methods. It is not possible to >use git-dpm or a gbp-pq repostory or vis versa. If you use gbp-pq on >a git-dpm repository, it will work, however, you will not preserve the >patches in git where git-dpm expects to find them. So git-dpm will get >confused and do the wrong thing the next time it is run. > >Somebody mentioned the ease of bisect. If you bisect a gbp-pq tree, you >won't get the patches applied unless your testing does this. If you >bisect >the git-dpm tree, you will get the patches applied. bisecting on the >Debian >branch should be easy enough I think, despite the extra merges. I >haven't >done this myself. > >I am tending to side towards the git-dpm, because I like the idea of >every >git commit being preserved. > >gbp-pq feels to me like a version of quilt enhanced to support git for >making local changes. As such if you want to work locally on a project >without git-dpm support, and you don't want to change that, gbp-pq >might be >the best choice. Which is a lot better then basic quilt, however not as >good as git-dpm for distributed development. > >I hope I haven't made too many mistakes :-) >-- >Brian May -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: Standardizing the layout of git packaging repositories
hi, habit looked at both, I think I prefer got-debcherry. since it created a (IMHO) cleaner history, easier for me to understand and bisect. Manoj On August 24, 2014 9:34:29 PM PDT, Barry Warsaw wrote: >On Aug 24, 2014, at 08:33 PM, Russ Allbery wrote: > >>git-buildpackage's gbp pq system is what I use. I believe git-dpm is >more >>complicated and comprehensive, but gbp pq is simple enough in its >>operations that it doesn't take long to wrap your mind around it. > >git-dpm seems pretty easy to use as well. YMMV, but ultimately I think >both >helpers achieve the same goals. Over in debian-python@ we're having >some good >discussions related to moving the Debian Python team over to git, and >many >folks have contributed useful stories and experiences. > >I'm beginning to think that what we want is for gbp and git-dpm to >interoperate, such that any individual maintainer can use whichever >tool they >choose, but would still allow the team to adhere to consensus >recommendations, >so there's no guesswork involved. E.g. the ultimate artifacts would >end up >being the same, regardless of whether you used gbp, git-dpm, or plain >vanilla >git + quilt. One example of a superficial differences is the tag names >used >by default. They're different between the two helpers, but really >needn't be. > >-Barry -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: Redefining critical bug severity
On Tue, May 20 2014, Russ Allbery wrote: > Arto Jantunen writes: > >> Because a package that doesn't work at all (and thus breaks rdeps) isn't >> as broken as a package that wipes the root fs on installation. > > Note that the latter breaks the whole system, and hence is critical > regardless of this distinction. True. But we might have a package whose breakage is not as extreme: It does not remove the roof file system, it just cases another package (say, xtank, or flex pr ccache) to break. It is not breaking all the system, so is not by itself critical. There is a gap in the wording, an unless the bug happens to match other criteria that make it more than serious, it will default to normal. Having an subset of the system, where the software does not explicitly depend on the package in question, without breaking the system as a whole -- is that release critical? What if a package turns /var/games immutable? Does nto break the system -- until something wants to write there. As long as such breakage remains serious, I can't, as Russ put it, become too excited about it. It was not clear to me that braeking independent packages is covered under some other clause, though, s long as the whole system is not compromised. manoj -- The shortest measurable interval of time is the time between the moment I put a little extra aside for a sudden emergency and the arrival of that emergency. Manoj Srivastava <http://www.golden-gryphon.com/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C signature.asc Description: PGP signature
Re: Redefining critical bug severity
On Sat, May 17 2014, Russ Allbery wrote: > Over the years, I've seen endless confusion about the current definition > of a critical bug severity: > makes unrelated software on the system (or the whole system) break, or > causes serious data loss, or introduces a security hole on systems > where you install the package. > The confusion seems to always be around the "unrelated software" part of > that definition. The intended meaning is completely unrelated software on > the system, indicating a package that's mangling the system in some > fundamental way, but I've frequently seen people believe, sincerely, that > reverse dependencies, Perl programs that use a buggy module, or X programs > on a system with a buggy video driver qualify as unrelated software. > This makes me think that part of the bug definition is adding more > confusion than clarity. Should we just drop it? Could this explanation instead be added as an informative footnote? Packages that declrare a direct or indirect dependency are not unrelated? >makes the entire system unusable, or causes serious data loss, or >introduces a security hole on systems where you install the package There is a gap, I think, between the previous meaning and this statement. If you upload a change to a java-xsml-parser library, and it breaks make, that does not cause the whole system to be unusable, or data loss, or a security hole. Under the old reading, this is a critical bug, but not under the new reading. In my opinion, it remains a critical bug, to berak totally unrelated software. manoj -- "Rembrandt's first name was Beauregard, which is why he never used it." Dave Barry Manoj Srivastava <http://www.debian.org/~srivasta/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C signature.asc Description: PGP signature
Re: Guile language support in make
On Wed, May 14 2014, Ian Jackson wrote: >> I know I can't do that until Jess is released and dpkg 1.17.2 is >> in stable. > > Is it acceptable to put off providing a guile-enabled make.deb until > jessie+1 ? Talking to various people I was convinced I was overthinking this, and as long as there were separate packages for guile, adding build profiles to the package as needed would not be a blocker. > If not then perhaps you could make two source packages and a script to > turn one into the other. You could even leave the guileish version > for someone else to build. That would not have been a problem: just adding guile-2.0-dev to the installed packages list used to build a guile enabled make (and this was reported as a bug as well :-) However, the cirrent status is that the make-dfsg source package builds both make and make-guile; currently without build profiles, and once jessie is out I shall add build profiles to the control file. In the meanwhile, of anyone is bootstrapping, and needs help, I would be happy to be of assistance. manoj -- "We're the weirdest monkeys ever." Karl Lehenbauer Manoj Srivastava <http://www.debian.org/~srivasta/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C signature.asc Description: PGP signature
Re: Guile language support in make
On Sun, May 11 2014, Marco d'Itri wrote: > I do this for the inn2 package and it has worked well for years. > Another (much simpler) example is kmod, which build a deb and a udeb. > If ./configure is not buggy and works when called from a build directory > then building two binary packages from the same source is trivial. Thanks for all the pointers. I have used a combination of stuff I found in the example to create a make-guile package, now in NEW processing. > Since it is installed on so many systems, I believe that a lean make > package is still worthwhile. make remains lean; make-guile is identical exept for the added guile support. manoj -- Trespassers will be shot. Survivors will be SHOT AGAIN! Manoj Srivastava <http://www.debian.org/~srivasta/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C signature.asc Description: PGP signature
Re: Guile language support in make
<#secure method=pgpmime mode=sign> On Sun, May 11 2014, Steve McIntyre wrote: > Thinking about the poor people trying to bootstrap things, I'm tempted > to suggest doing this as two separate source packages. Make is *so* > far down the bottom of the stack that adding a dependency on another > language could cause significant problems. Well, I was thinking of build profiles for that. --8<---cut here---start->8--- Build-Depends: guile-2.0-dev Packagte: make Build-Profiles: !withguile Package: make-guile Build-Profiles: withguile --8<---cut here---end--->8--- I know I can't do that until Jess is released and dpkg 1.17.2 is in stable. In the meanwhile, looking at gnuplot and kerrberos, I see how I can do detached build directories and dh overrides to actually build two binary packages from the same source package. What I don't see is how to manage to add the build dependency without inconveniencing bootstrapping with a single source package. I don't have the energy to create a brand new source package from the same mangled make upstream source. manoj -- "Of course power tools and alcohol don't mix. Everyone knows power tools aren't soluble in alcohol..." -- Crazy Nigel Manoj Srivastava <http://www.debian.org/~srivasta/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/874n0wyhw5@glaurung.internal.golden-gryphon.com
Guile language support in make
Hi, I have two constituencies here; people who would like to see guile support in make, and to explore the new features. And people who expect a sensibly small set of packages essential to building other packages in Debin. Without guile suport, make just depends on libc, and nothing else. Guile support adds the allowing packages to the dependencies: guile-2.0-libs, libgc1c2 (>= 1:7.2d) Since make is build essential, I am not going to pull in these extra dependencies without due consideration, so I have put the wishlist bug to add the support as wontfix, for the moment. However, just install guile-2.0-dev, apt-get source make, and rebuilding should give you a guile supporting make, so it is a low barrier of entry. I have labeled wontfix a bug report to prevent that from happening, since that would change the behaviour of make compiled on a machine (not a sterile build environment) somewhat different than the official package. I suspect that there are a lot of things in the environment that could change the resulting binaries, which is why most deterministic build scanarios start with a well defined build environment; and in such an environment the current make package will indeed build consistently without guile support (unless build-essential or debhelper grow guile dependencies, and I';; of course watch for that). But, enough rambling. How do we move forward with enabling guile support in make? Building two binary packages from a single source seems hackish, since make and make-guile would require ./configure to be run again, and each target of the ./debin/rules might need cleanup/restart. Not unsolvable, but messy, and I do not have the motivation to do that. Patches welcome, of course. I would like to solicit the opinion of the developers about the value of adding Guile support to the default make package, at the expense of two smallish additional dependencies. http://blog.melski.net/2013/11/29/whats-new-in-gnu-make-4-0/ has a write up on what guile support would bring. Thanks for listening manoj -- Perl itself is usually pretty good about telling you what you shouldn't do. :-) --Larry Wall in <11...@jpl-devvax.jpl.nasa.gov> Manoj Srivastava 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C signature.asc Description: PGP signature
Re: systemd-fsck?
<#secure method=pgpmime mode=sign> On Fri, May 09 2014, Russ Allbery wrote: > Josh Triplett writes: >> Russ Allbery wrote: > >>> I think we need some sort of critical debconf prompt here for the >>> jessie release, similar to how we handled the change of /bin/sh to dash >>> and how we handled the switch to startpar. Probably in systemd-sysv, >>> which is the package that forces the conversion. It's quite surprising >>> to, for example, install network-manager (which is an application that >>> ca be used with non-GNOME window managers) and end up with a new init >>> system. > >> I strongly disagree: if the maintainers of the various packages have >> done their jobs well (which they have), upgrading should be entirely >> transparent. When things are working well, of course there is little to worry about. I myself got converted and did not notice. But there is more to this than the happy lane: What happens when the init system breaks? I am currently very familiar with sysvinit, and am comfortable debugging and hacking at shell scripts to get my system back in single user mode. Am I similarly knowledgeable about recovering a sick systemd environment? No, not yet, I am not. I do mean to learn about it at some point, perhaps soon. But by pushing ahead the timetable, I have been left with a system I am not at all confident of being able to debug and fix. Not asking me has led to a gap in my disaster recovery preparedness :P I do not think silently swapping out a critical piece of infrastructure, where the underlying technology is so different, without asking is serving our users well. manoj -- To be able to be caught up into the world of thought--that is being educated. Edith Hamilton Manoj Srivastava <http://www.debian.org/~srivasta/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/87ppjmxib7@glaurung.internal.golden-gryphon.com
Re: make 4.0: archive rebuild resulted in 73 packages broken (help wanted)
On Thu, May 01 2014, Paul Smith wrote: > On Wed, 2014-04-30 at 10:55 -0700, Manoj Srivastava wrote: >> Opened bug in Savannah BTS: >> https://savannah.gnu.org/bugs/?42249 > I pushed a fix for this. See if it helps. I have built a new version into experimental with that patch. Of the ~60 packages previously broken with make 4.0, I have now successfully built 6 (or roughly 10%) with a newly patched make. With the other patches back ported from the savannah git repo, I think we have now addressed the issues uncovered by the archive rebuild. I am currently uoploading to experimental, and will hold it there for 24 hours, and upload it to unstable in 24 hours. Many thanks to Paul for the quick turn around on this bug. manoj -- QOTD: "This is a one line proof... if we start sufficiently far to the left." Manoj Srivastava <http://www.golden-gryphon.com/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C signature.asc Description: PGP signature
Re: make 4.0: archive rebuild resulted in 73 packages broken (help wanted)
On Wed, Apr 30 2014, Paul Smith wrote: > On Wed, 2014-04-30 at 18:19 +0200, Guillem Jover wrote: >> build-stamp: >> echo $@ >> >> build-arch: build-stamp > >> $ make --version | head -n1 >> GNU Make 4.0 >> $ make -f detect.mk -qn build-arch; echo $? >> 2 > > This is definitely a bug in GNU make 4.0 in handling -q (note the -n is > not relevant: you can leave it out and get the same behavior). The docs > are clear on what the exit codes should be, and with -q make should exit > with 1 if something needs to be updated and no error was detected. Opened bug in Savannah BTS: https://savannah.gnu.org/bugs/?42249 -- Having a wonderful wine, wish you were beer. Manoj Srivastava <http://www.golden-gryphon.com/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C signature.asc Description: PGP signature
Re: make 4.0: archive rebuild resulted in 73 packages broken (help wanted)
On Tue, Apr 29 2014, Felipe Sateler wrote: > On Mon, 28 Apr 2014 23:01:58 -0700, Manoj Srivastava wrote: > > >> Felipe Sateler >>csound (U) >>pulseaudio (U) Add to that: > Kari Pahula >gecode > Russ Allbery >krb5 (U) Missing Build-Depends-Indep is a common pattern among the 60 or so remaining build failures. > On both I'm getting this: > dpkg-buildpackage: warning: debian/rules must be updated to support the > 'build-arch' and 'build-indep' targets (at least 'build-arch' seems to be > missing) > Looks like the new make is not doing the expected thing when called as > make -f debian/rules -qn build-arch With the old make (3.8,1), it correctly loads B-D-I and calls build-indep, with make 4.0-[12], it fails to determine of the target exists, and calls ./debian/rules build > (And by expected is return 2 when not found, any other return code > otherwise). Right. Since dpkg-buildpackage cannot ascertain that 'build-arch' and 'build-indep' targets exist, it calls build, and does not load B-D-I first. Most of the archive works, since B-D-I was not paid any attention to on the buildds, and every package used to build with ./debian/rules build and all the dependencies used to be in Build-Depends. Since then, B-D-I has been fixed, and we see empirical evidence that around 60 packages have made us of that. I don't know why the behaviour has changed; but I have tested it on apt and opusfile, and a couple of other packages. I will cut a normal bug on dpkg, and a serious one on make, and make the former block the latter while we figure otu what to do. The options, as I see it are: 1) Do nothing. retain make-3.81 in Debian forever more. Needless to say, this is not very attractive. Pro: There is no action to take. Con: Almost every other distro is shipping a more recent make. We will continue to diverge from everyone else, and already the featires have diverged enough that people are having to add special cases in the vuild system for the Debian family of distributions. 2) Hack dpkg-buildpackage to always load B-D-I, and go back to just calling ./debian/rules build. This is what we used to do. Pro: it is pretty easy to do (umm, I would think, but I don't know the dpkg code base so well anymore). This has the con of the inefficiency we have tried to eliminate, in that all the build dependencies are loaded for every build, even when not strictly needed. 3) We state that packages must provide build-arch and build-indep for Jessie. This should trivially be true for every package using cdbs or debhelper (or, heaven forbid, my old home brew build system), and have dpkg-buildpackage call them without testing to see if they exist. We would need to do another archive rebuild with the modified dpkg-buildpackage to see how many packages do not actually not implement these targets. None of these are very pretty. manoj -- Just because he's dead is no reason to lay off work. Manoj Srivastava <http://www.golden-gryphon.com/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C signature.asc Description: PGP signature
make 4.0: archive rebuild resulted in 73 packages broken (help wanted)
Hi, David Suárez kindly did an archive rebuild with the new version of make in experimental, and the results of the build are at: http://aws-logs.debian.net/ftbfs-logs/results-make4/ The summary: 73 packages have failed, though not all seem obviously related to make. Out of the 73, I can see 10 failed due to a known backward incompatibility in make; I am building a new version that reverts that change, though we should still fix the makefiles. At the link above, you have: - make4.res: results for make4 rebuild - normal.res results for normal sid rebuild - compare.list: comparison of normal.res against make4.res - make4.failed: failed results for make4 rebuild - logs-failed-make4: dir with the build logs of make4 rebuild failed packages The DD list for the packages that failed follows: I am requesting help to investigate the failures (I'll be working through the package list one the new version of make is built and hits experimental again) manoj "Adam C. Powell, IV" aster (U) spooles (U) Adam Majer lpe Alastair McKinstry ferret-vis Andrea Palazzi aster (U) Anton Gladky spooles (U) APT Development Team apt Aurelien Jarno libusb-1.0 Balint Reczey pulseaudio (U) Barak A. Pearlmutter ikarus nbibtex scheme2c Barry deFreese xnee (U) Barry deFreese tecnoballz (U) Bas Couwenberg postgis (U) Bdale Garbee gzip sdcc (U) Benjamin Kaduk krb5 (U) Carl Worth gzip (U) Christian Perrier apt (U) Christophe Trophime getdp (U) Clint Adams haskell-tasty-golden (U) Cyril Brulebois xserver-xorg-video-vmware (U) Daniel Glassey grcompiler (U) Debian Apache Maintainers apr apr-util Debian Fonts Task Force grcompiler Debian Games Team tecnoballz Debian GIS Project postgis Debian GNOME Maintainers libgksu (U) Debian Haskell Group haskell-tasty-golden haskell-terminal-progress-bar Debian Julia Team julia Debian LibreOffice Maintainers libreoffice Debian Med Packaging Team proftmb Debian Multimedia Maintainers csound Debian OCaml Maintainers galax ocaml-melt Debian QA Group gwhere socks4-server xenwatch Debian Science Maintainers cernlib geant321 mclibs paw spooles Debian Science Team aster getdp Debian VoIP Team portaudio Debian X Strike Force xserver-xorg-video-vmware Denis Laxalde aster (U) Dmitry Smirnov nocache Don Armstrong lilypond Drew Parsons xserver-xorg-video-vmware (U) Felipe Sateler csound (U) pulseaudio (U) Filippo Rusconi r-cran-base64enc (U) r-cran-maldiquant (U) Forrest Cahoon csound (U) Francesco Paolo Lovergine postgis (U) Frank Lin PIAT amtterm (U) Gerrit Pape git Gudjon I. Gudjonsson sdcc Gustavo Noronha Silva libgksu J.H.M. Dassen (Ray) spellutils Jakub Adam jikespg James Troup gimp-dimage-color Jeroen Dekkers sogo Joachim Breitner haskell-terminal-progress-bar (U) Jochen Friedrich isakmpd pinball Jonas Smedegaard csound (U) Jonathan Nieder git (U) xz-utils Jose Carlos Garcia Sogo portaudio (U) Josselin Mouette libgksu (U) Julian Andres Klode apt (U) Kari Pahula gecode Kilian Krause portaudio (U) Laszlo Kajan proftmb (U) Lifeng Sun cernlib (U) geant321 (U) mclibs (U) paw (U) Ludovic Rousseau plucker Marcus Better input-utils Mark Purcell portaudio (U) smstools Markus Wanner postgis (U) Martin Hosken grcompiler (U) Michael Biebl libgksu (U) Michael Gernoth amtterm (U) Michael Vogt apt (U) vdkbuilder2 Mikael Magnusson portaudio (U) Mohammed Adnène Trojette xz-utils (U) Moritz Muehlenhoff fbi Neil Roeth openjade openjade1.3 Patrick Schoenfeld smstools (U) Peter Samuelson apr (U) apr-util (U) Pulseaudio maintenance team pulseaudio Raphael Geissert readahead-fedora Reinhard Tartler amtterm aspectc++ Rene Engelhard libreoffice (U) RISKO Gergely slmon Ron Lee opusfile speex Rudy Godoy lletters Russ Allbery krb5 (U) Sam Hartman krb5 Sebastian Gibb r-cran-base64enc Simon Kelley dhcpcd Simon Richter foundry Sjoerd Simons pulseaudio (U) Stefan Fritsch apr (U) apr-util (U) Stephen Frost postgis (U) Stephen Kitt mingw-w64 Stéphane Glondu ocaml-melt (U) Sébastien Villemot julia (U) The Debichem Group r-cran-maldiquant Theodore Y. Ts'o e2fsprogs Thibaut Gridel routino Uwe Steinmann routino (U) Vincent Bernat xnee Wesley W. Terpstra (Debian) st Ying-Chun Liu (PaulLiu) xracer -- God, I ask for patience -- and I want it right now! Manoj Srivastava <http://www.golden-gryphon.com/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C sign
Re: Why Debian
On Sat, Apr 12 2014, Alberto Salvia Novella wrote: > Why you choose to develop in Debian over any other distribution? Because I could contribute. I looked at other UNIX like operating systems, and Linux, and then Debian, had the least barriers to entry for contribution. Why is being able to contribute important (apart from making one feel good -- which is a good reason, but too highly subjective to be of interest to most people)? Well, it gives one a voice in how the distribution co-evolves with you. I can honestly say that after all the time I have been using it, now Debian works like my brain thinks and OS should :-) manoj -- "Cats are smarter than dogs. You can't get eight cats to pull a sled through snow." --Jeff Valdez Manoj Srivastava <http://www.golden-gryphon.com/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C signature.asc Description: PGP signature
Re: --> APT's New Version <--
On Tue, Apr 01 2014, Andrew M.A. Cater wrote: > On Tue, Apr 01, 2014 at 05:39:04PM +0200, The deity team wrote: >> >> Who would have guessed that 16 years ago? Do you remember what you did >> on the first April in 1998? What is the first thing you thought while >> reading this mail? And most important of all: Have you mooed today? >> > > I think I was just pleased that I'd thought of the name and that Jason, > Manoj and others had accepted it - it defused an almighty flamewar :) Under protest. I still think it really ought to be called deity. Or one of 64 million other names used for it in south asia. I think those other names are equally apt. manoj -- It's amazing how many people you could be friends with if only they'd make the first approach. Manoj Srivastava <http://www.golden-gryphon.com/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/87r45g33s1@glaurung.internal.golden-gryphon.com
A new version of make-dfsg has been uploaded to experimental, please test
Hi, make 3.82 will require some transitions due to backward incompatibility on GNU-make-specific features. Some bug reports have already occurred for build issues with make 3.82, such as http://bugs.debian.org/603759 . Since there are known backward incompatibilities, make has been uploaded to experimental. NEWS.Debian has an incompatibility list. Testing this new version of make will be appreciated. manoj -- The minute a man is convinced that he is interesting, he isn't. Manoj Srivastava <http://www.golden-gryphon.com/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/87aaccklc1@golden-gryphon.com
Re: Lintian check for missing desktop files?
On Sun, Mar 06 2011, Andreas Tille wrote: > On Sat, Mar 05, 2011 at 04:22:01PM -0800, Manoj Srivastava wrote: >> Do you have concrete data to add here, apart from speculation? I >> would be interested in such data (as the once and perhaps future >> maintainer of fvwm in Debian). > > I have no idea whether it is pure speculation or wrong intuition. I > accept your argument as insider that the menu function in fvwm is > actually used by some users. Thanks > However, the other arguments to prefer desktop files over menu files > remain valid unregarded this fact and there was also a solution > suggested in this thread for fvwm users. Agreed. > So the point remains: We should start issuing lintian warnings about > missing desktop files where it makes sense to be able to start a > smooth transition. These files will be needed in any case if we > might want to get rid of Debian menu completely, provide conversions > or just leave menu files untouched. If I recall correctly, there was some objection to creating a desktop file for every menu file that exists, have those objections been withdrawn (if memory serves me, the objection was to the sheer mass of menu files for applications and docs that did not make sense in a GNOME/KDE menu like hack or worm)? If not, are there criteria lintian will use to warn about some menu files not having a desktop file, and not others? manoj -- Old programmers never die, they just become managers. Manoj Srivastava <http://www.golden-gryphon.com/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/874o7g6qat@anzu.internal.golden-gryphon.com
Re: Lintian check for missing desktop files?
On Sat, Mar 05 2011, Andreas Tille wrote: > On Fri, Mar 04, 2011 at 06:52:39PM -0800, Manoj Srivastava wrote: >> > I was a fan of fvwm for years and I even have configured my xfce with >> > fvwm keycodes to have the same handling. However, if you ask me the >> > typical fvwm user (if something like this exists at all) is most >> > probably ignoring the menu and has rather configured his environment >> > to fire up applications via key codes or fires up an xterm and types >> > the command for an application. So while I do not really want to >> >> I would be surprised if that were indeed the case. If you look >> at the exemplar configuration file providedat fvwm.org, there is >> extensive use of menus -- and for non debian folk, yes, they tend to >> manually hard code application paths in menus; for Debian folks >> upstream even ships the default system.fvwm2rc with: >> Test (f /etc/X11/fvwm/menudefs.hook) + "Debian Menu" Popup /Debian >> Test (f /etc/X11/fvwm/menudefs.hook) + "Re-read System Menu" Read >> "/etc/X11/fvwm/menudefs.hook" >> Test (f /etc/X11/fvwm/menudefs.hook) + "Update My Debian Menu" PipeRead >> 'update-menus && echo "Read $./menudefs.hook"' > > I do not question that these files *exist*. I simply question that they > are *used* in real life. Fair enough. Would you, then, be satisfied by my answer that they are used? I am a current real life user of fvwm, and I am on the mailing lists for the fvwm project with other real life users and developers; and my expeirnces, and the chatter on the list, do not lead me to believe that menus are unused. Do you have concrete data to add here, apart from speculation? I would be interested in such data (as the once and perhaps future maintainer of fvwm in Debian). manoj -- If I can have honesty, it's easier to overlook mistakes. Kirk, "Space Seed", stardate 3141.9 Manoj Srivastava <http://www.golden-gryphon.com/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/87fwr16qty@anzu.internal.golden-gryphon.com
Re: Lintian check for missing desktop files?
On Fri, Mar 04 2011, Andreas Tille wrote: > On Thu, Mar 03, 2011 at 09:27:07PM -0800, Manoj Srivastava wrote: >> > (isn't it only icewm and ratpoison and blackbox we might 'lose' by >> > simply killing the debian menu) >> >> And fvwm, > > I was a fan of fvwm for years and I even have configured my xfce with > fvwm keycodes to have the same handling. However, if you ask me the > typical fvwm user (if something like this exists at all) is most > probably ignoring the menu and has rather configured his environment > to fire up applications via key codes or fires up an xterm and types > the command for an application. So while I do not really want to I would be surprised if that were indeed the case. If you look at the exemplar configuration file providedat fvwm.org, there is extensive use of menus -- and for non debian folk, yes, they tend to manually hard code application paths in menus; for Debian folks upstream even ships the default system.fvwm2rc with: Test (f /etc/X11/fvwm/menudefs.hook) + "Debian Menu" Popup /Debian Test (f /etc/X11/fvwm/menudefs.hook) + "Re-read System Menu" Read "/etc/X11/fvwm/menudefs.hook" Test (f /etc/X11/fvwm/menudefs.hook) + "Update My Debian Menu" PipeRead 'update-menus && echo "Read $./menudefs.hook"' > loose fvwm menu in case there might be some constraints in a potential > to be written desktop2menu I would not really regard this issue as > urgent enough to stop what we would gain with overall proper desktop > files. That is a decision that the project can of course make, though I think that would be a pity, and hope it shall not come to that. Could you please remind me why, given that we currently have a large number of menu files, that a menu2xdg script is not being considered as the better path moving forward? manoj -- The difference between a career and a job is about 20 hours a week. Manoj Srivastava <http://www.golden-gryphon.com/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/87oc5qnurs@anzu.internal.golden-gryphon.com
Re: Lintian check for missing desktop files?
On Thu, Mar 03 2011, Sune Vuorela wrote: > On 2011-03-03, Ben Hutchings wrote: >> and per-WM hooks should take care of any conversion required at >> installation time. Let's make that a release goal for wheezy instead of >> perpetuating these parallel menu systems. > Down with the debian menu! Long live the fdo menu. > (isn't it only icewm and ratpoison and blackbox we might 'lose' by > simply killing the debian menu) And fvwm, manoj -- Mirrors should reflect a little before throwing back images. Jean Cocteau Manoj Srivastava <http://www.golden-gryphon.com/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/8739n3piac@anzu.internal.golden-gryphon.com
Re: Branching changelogs or not
On Sun, Feb 06 2011, Andreas Tille wrote: > > 2. Whether upstream changelogs should be copied fully or in > parts copied into Debian changelog and I think the New > maintainers guide[3] gives a clear answer to mention only > the changes of this *new* release specifically if these are > closing known bugs in Debian and not just random features > of the new release and definitely not changes of old > releases. My take on this has been that we should do what is most important for the users: The changelog can be presented to the users on upgrade, and when users chose to see it, and in those cases the users arepresented with an option to abort the upgrade. The other audience for the changelog entry us people looking into it in /usr/doc, and perhaps fr dignificant changes or feature addtions; and lastly, the future maintainers. I would suggest we copy over from the upstream changelog any information that might be relevant to the users; and that does mean major features and significant changes, specifically backwards incompatible changes. So I tend to favour a changelog by changelog decision, not a hard ruling one way or the other. > > [1] http://lists.debian.org/debian-med/2011/02/msg00048.html > [2] http://www.debian.org/doc/maint-guide/ch-update.en.html#s-newupstream > [3] http://lists.debian.org/debian-release/2010/12/msg01054.html manoj almost through the long tunnel with the legal department -- Comedy, like Medicine, was never meant to be practiced by the general public. Manoj Srivastava <http://www.golden-gryphon.com/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/87aai9yqbs@anzu.internal.golden-gryphon.com
Re: Bits from keyring-maint
On Wed, Sep 15 2010, Henrique de Moraes Holschuh wrote: > As for the large keysize, it is seen as too large. It was recommended > that Debian should try to do something that would help reduce the > overall threat to the Debian PKI instead of promoting very large key > sizes *in order to acommodate for very large key lifetimes*. > > The recommendation for that one was: smartcards, use main key as a KSK > only, and don't let it leave the smartcard. subkeys have several > advantages, they can be smaller than the main key, and they can be > replaced without web of trust issues (so you could replace them often, > and give them a validity of only 1-2 years). I did not like that, since the card presumably travels with the person, and thus has the potential of getting lost. I prefer to generate my main key and than store it on read-only media, away from any network or computer. The subkeys are what live on the card. > One would use the smartcard only to generate new subkeys and UIDs, and > to sign other keys (otherwise, you'd need to re-sign already-signed UIDs > when the subkey is about to expire. I didn't check if gnupg lets you use > subkeys to sign UIDs on other keys). I use my card for everyday uses, and to sign emails. Signing keys is more involved, though that has ony happened 15 times for me so far. manoj -- If you keep anything long enough, you can throw it away. Manoj Srivastava <http://www.golden-gryphon.com/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/87pqweiqe6@anzu.internal.golden-gryphon.com
Re: Bug#592839: dpkg-source option to remove files on unpack: debian/source/remove-files
On Wed, Aug 25 2010, Ian Jackson wrote:
> Goswin von Brederlow writes ("Re: Bug#592839: dpkg-source option to remove
> files on unpack: debian/source/remove-files"):
>> That was my point. Legally we CAN use those files. But we don't WANT to
>> use them for DFSG reasons.
>
> I think we are in vigorous agreement, but your tone makes me hesitate.
> Let me summarise my understanding:
>
> File status: DFSG-free non-free butNot
> redistributable redistributable
> --- -- --
>
> Presence Can and Currently removed Must be removed,
> in .orig should be from .orig's by someso .orig tarball
>.tar.gz included. maintainers. I think must be repacked.
> this is a waste of
> time.
>
> Removal or May sometimes IMO necessary toInsufficient.
> inhibition be useful toprevent accidental
> by dpkg-srcavoid acci- use, and to facilitate
> pattern or dental use. licence review
> rm by rules
>
> Do you agree ? In particular, do you agree that repacking .orig
> tarballs to remove non-free-but-redistributable files (such as RFCs
> and non-free-GFDL docs) is a waste of time ?
Once I have written my watch file, and the urepack script, I
find that the time being wasted lies in the sub-second range. Hardly
something I worry about, really.
manoj
--8<---cut here---start->8---
version=3
opts=pasv,dversionmangle=s/\.ds// http://www.fvwm.org/download/ \
ftp://ftp.fvwm.org/pub/fvwm/version-2/fvwm-([\d\.]*)\.tar\.gz\
debian debian/urepack
--8<---cut here---end--->8---
--
The sheep died in the wool.
Manoj Srivastava <http://www.golden-gryphon.com/>
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C
--
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/87sk22vlai@anzu.internal.golden-gryphon.com
Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling
On Wed, Jul 21 2010, Will wrote: > Also I imagine that it helps that they have some kind of commercial > support behind their projects, whereas Debian has little/none of that. One of the issues I have faced in trying to get Debian introduced in big companies is the percieved lack of a coherent copyright; and company lawyers being uncomfortable with the concept that most licesnse pass the dfsg, but we can't guarantee that, please go read several thoudand individual license docs to figure out what you are getting. manoj -- Knowing that one is dear to oneself, one should guard oneself well. For one out of the three watches of the night a wise man should keep watch. Manoj Srivastava <http://www.golden-gryphon.com/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/87r5iwp02s@anzu.internal.golden-gryphon.com
Re: Parallellizing the boot in Debian Squeeze - ready for wider testing
On Fri, May 14 2010, Scott James Remnant wrote: >> One of my concerns about upstart is that systems that want to >> use SELinux and upstart _have_ to also use an initramfs, which is yet >> another component of the system that has to be audited. There have >> been patches proposed, and semi-rejected b the upstart folks, who are >> of the opinions that only systems using initramfs need apply. >> > Have to jump in here, but this is simply not true. > > I have never rejected any SELinux patches for Upstart; I have simply > never been *sent* any. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543420#10 > I've always said I'm quite happy to sit down with the SELinux folks and > work out the right way to do this. We can start with: http://etbe.coker.com.au/2008/07/24/se-linux-policy-loading/ manoj -- The first is to ensure your partner understands that nature has root privileges - nature doesn't have to make sense. -- Telsa Gwynne Manoj Srivastava <http://www.golden-gryphon.com/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/87wrv4zxiz@anzu.internal.golden-gryphon.com
Re: Parallellizing the boot in Debian Squeeze - ready for wider testing
On Sun, May 09 2010, Steve Langasek wrote:
> On Sun, May 09, 2010 at 02:45:39PM -0700, Manoj Srivastava wrote:
>> One of my concerns about upstart is that systems that want to
>> use SELinux and upstart _have_ to also use an initramfs, which is yet
>> another component of the system that has to be audited. There have
>> been patches proposed, and semi-rejected b the upstart folks, who are
>> of the opinions that only systems using initramfs need apply.
>
>> The bug report in question is #543420, please read it for the
>> details (I am arguably biased). I am also willing to re-work the patch
>> to not link with libsepol, so minimizing the dependencies to
>> libselinux.
>
> In speaking with upstart upstream, I understand that the argument against
> linking to libselinux is that, as the kernel is neutral wrt the choice of
> LSM, the init process should be also. Linking it against libselinux would
> not be LSM-neutral.
Could you perhaps expand on this a bit? The patch I submitted by
no means makes upstart require SELinux, nor does it preclude supporting
other security modules. Indeed, any other LSM support that is needed
can still be patched in. I think that we could get an upstart that
support all LSM's natively, as opposed to supporting none, at very
little added in the way of maintenance overhead.
> And you don't have to use an initramfs; the same result could be
> achieved with a shim init on the root filesystem that does nothing but
> set up the SELinux context correctly and then exec upstart.
err, does that mean sham init? If so, I suppose that is
something that can be explored. Russell, comments?
manoj
--
All the world's a stage and most of us are desperately unrehearsed. Sean
O'Casey
Manoj Srivastava <http://www.golden-gryphon.com/>
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C
--
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/87sk60wojt@anzu.internal.golden-gryphon.com
Re: Parallellizing the boot in Debian Squeeze - ready for wider testing
On Sat, May 08 2010, Marco d'Itri wrote: > On May 07, Julien Cristau wrote: > >> > - a decision to drop kfreebsd as a release architecture >> Since 1 and 2 aren't happening, I think we should consider going with >> the third option. > Me too, I believe that the people interested in kfreebsd-* have had more > than enough time to provide the compatibility framework and we cannot > hold back Debian forever for the benefit of a toy port. One of my concerns about upstart is that systems that want to use SELinux and upstart _have_ to also use an initramfs, which is yet another component of the system that has to be audited. There have been patches proposed, and semi-rejected b the upstart folks, who are of the opinions that only systems using initramfs need apply. The bug report in question is #543420, please read it for the details (I am arguably biased). I am also willing to re-work the patch to not link with libsepol, so minimizing the dependencies to libselinux. manoj -- There is always something new out of Africa. Gaius Plinius Secundus Manoj Srivastava <http://www.golden-gryphon.com/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/87wrvcwxz0@anzu.internal.golden-gryphon.com
Re: Best practices for development workstations
On Mon, Mar 29 2010, John Goerzen wrote: > Hi folks, > > I'm trying to solicit comments on what people are using for development > environments and how well it's working. Here are some situations I > imagine are common: > > 1. workstation running sid > > 2b. Xen, KVM, qemu, or VirtualBox I have a desktop (and a separate laptop) both running Sid. I have a virtual machine that runs SELinux in strict mode for package building on the desktop. I do not test on the build virtual machine; most of my testing is done on my desktop. manoj -- Kill Ugly Radio Frank Zappa Manoj Srivastava <http://www.golden-gryphon.com/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/87k4su33ez@anzu.internal.golden-gryphon.com
Re: Status of kernel patch packages
On Tue, Mar 23 2010, Yann Dirson wrote: > Let's maybe stay focussed on the initial problem: we *had* a way to > handle kernel patches as part of a self-contained distribution, but > there is no support for this any more. Moreover that support we had > was not 100% satisfactory (eg. bad handling of conflicting patches > needing manual merge - although that was something I wanted to address > in the never-finished dh-kpatches 0.100). My idea is to rethink the > whole thing using today's tools - namely, git. > > Anyway, to get back to the initial problem of the current linux-patch > packages, we currently still have patches in the distro, which were > packaged for a mechanism that is not to be shipped in squeeze (and > referencing that obsolete mechanism in their /usr/share/doc/), and > this in itself is a problem of quality of the overal distro, right ? So all we really need is a little script that does the patch/unpatch that make-kpkg used to do on the fly, and have the user run the patch script, call make-kpkg (or make deb-pkg, or what have you), and call the unpatch script later if the feel like it. This should be pretty simple to do, really. manoj -- When one is overcome by this wretched, clinging desire in the world, one's sorrows increase like grass growing up after a lot of rain. 335 Manoj Srivastava <http://www.golden-gryphon.com/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/87wrx2ifgs@anzu.internal.golden-gryphon.com
Re: Invite to join the Release Team
On Sat, Mar 13 2010, Luk Claes wrote: > Hi Clint > > You seem to send the message that you can judge from the sideline how > things should be run, so I hereby invite you to join the Release Team > and do a proper job. > > If you don't take the challenge I'll interpret that as you being a > coward who does not deserve to be heard in the future. > > Please be responsible and do help us out here. Wow. Are we back in kindergarten here? manoj -- 'Ooohh.. "FreeBSD is faster over loopback, when compared to Linux over the wire". Film at 11.' -- Linus Torvalds Manoj Srivastava <http://www.golden-gryphon.com/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/87sk83pk03@anzu.internal.golden-gryphon.com
Re: Bug#540215: Introduce dh_checksums
On Tue, Mar 09 2010, Jean-Christophe Dubacq wrote: > On 09/03/2010 14:24, Bernhard R. Link wrote: > >> >> It it's that straight forward, please help with the cruft package. >> Last time I looked (several years ago) it was severly limited by that >> problem (there not being a way to know which files should be there and >> which not). >> >> I personally think without something in this direction, intrusion >> detection based on file lists is not really possible. > > I for one pledge the addition of a dpkg-register (or dpkg --register or > anything), bound with dpkg, that would allow maintainers to specify that > a file belongs to their package (it could be managed through postinsts, > via ucf...) The number of files under /etc that belong to no package (in > the sense of dpkg -S) makes it very hard to keep a clean system. For what it is worth, ucf can also tell dpkg about the files and hashes that it manages (it already stores the data, all that has to be added is calls to the hypothetical dpkg-register). manoj -- Oliver's Law: Experience is something you don't get until just after you need it. Manoj Srivastava <http://www.golden-gryphon.com/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/87pr3dbib2@anzu.internal.golden-gryphon.com
Re: Should ucf be of priority required?
On Sun, Jan 03 2010, Magnus Holmgren wrote: > On måndagen den 7 december 2009, Wouter Verhelst wrote: >> On Sun, Dec 06, 2009 at 01:17:30PM +0100, Patrick Schoenfeld wrote: >> > But how do you fix a package to do what its supposed to do, >> > when it isn't installed anymore? >> >> You don't need to. When the package is purged, and ucf doesn't exist >> anymore, what you do is rm -f the relevant files. >> >> Unregistering those files in ucf is necessary so that ucf throws away >> the correct checksums from its database, too. However, if ucf itself is >> no longer on the system, then the same is true for that database, and >> unregistering stuff from that database is no longer necessary. > > Unless ucf is removed but not purged, right? Not really. If ucf is removed, then it's database can no longer be trusted to be accurate anyway. So the fact that the removal of the package is not registered in ucf's database makes no difference really (an untrusted DB expected to be out of date is now known to meet expectations). manoj -- "Even more amazing was the realization that God has Internet access. I wonder if He has a full newsfeed?" (By Matt Welsh) Manoj Srivastava <http://www.golden-gryphon.com/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sun, Jan 03 2010, Magnus Holmgren wrote: > On måndagen den 7 december 2009, Wouter Verhelst wrote: >> On Sun, Dec 06, 2009 at 01:17:30PM +0100, Patrick Schoenfeld wrote: >> > But how do you fix a package to do what its supposed to do, >> > when it isn't installed anymore? >> >> You don't need to. When the package is purged, and ucf doesn't exist >> anymore, what you do is rm -f the relevant files. >> >> Unregistering those files in ucf is necessary so that ucf throws away >> the correct checksums from its database, too. However, if ucf itself is >> no longer on the system, then the same is true for that database, and >> unregistering stuff from that database is no longer necessary. > > Unless ucf is removed but not purged, right? Not really. If ucf is removed, then it's database can no longer be trusted to be accurate anyway. So the fact that the removal of the package is not registered in ucf's database makes no difference really (an untrusted DB expected to be out of date is now known to meet expectations). manoj -- He who hesitates is sometimes saved. Manoj Srivastava <http://www.golden-gryphon.com/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: quilt 3.0 source format and dpkg-source/dpkg-buildpackage
On Tue, Dec 29 2009, Russ Allbery wrote: > I think the way forward for Git-maintained packages is the 3.0 (git) > format, but changed to ship a bundle. That way, relevant branches and > history can be included, and Git is fairly space-efficient so the > additional cost of doing so isn't that bad. As far as I can tell, git-bundle is not submodule friendly. I would appreciate 3.0 (git) supporting submodules; and I'd be willing to write code for that (once I am done relocating, that is) manoj -- With your bare hands?!? Manoj Srivastava <http://www.golden-gryphon.com/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Wed, Dec 09 2009, Patrick Schoenfeld wrote:
> Hi Manoj,
>
> On Mon, Dec 07, 2009 at 12:12:36PM -0600, Manoj Srivastava wrote:
>> > For me this assumes that data created during this task belongs to
>> > the package that requested the creation of the data in the first
>> > place.
>>
>> That breaks abstraction and encapsulation.
>
> I'm not sure if I share that view point. The point is to provide
> a certain interface to a different application to store and access
> data whereas the using application does not have to take care of the
> internal structures and consistency of the data.
That would be fine if ucf did that: but it does not. You should
not look at ucf as something that provides an application an interface
to store stuff without having to worry about structure and
consistency. It his here to help your package ask questions about
whether or not the end user wants to use you configuration file, or
theirs, or something else.
> That doesn't mean that the data in question (generally) generally
> becomes a part that belongs to the interface provider. Consider a
> database for example. It is encapsulated in the sense, that its only
> public interface is a query language. But anyways the data stored in
> the database does not belong to the database. Or would you say it
> does? But still, you have a right point, in the matter that the
> database could say that a DROP-operation only removes the data from
> the working set, not from the history. For example if this is required
> for consistency reasons.
>
> I know that this comparison has its flaws, because in the ucf case
> the data in question is just a file registration and therefore more a
> state information as data.
The comparison is false because you start with a wrong premise:
that ucf is here to help your app store data in the first place. The
data storage is incidental to the primary operation, asking the user
questions. And the data is a cache: all it does is help optimize away
questions that need not be asked based on the enteries in the
registry. You can blow away the registry and still only pay the penalty
of ucf asking the user once again what they want to do with a
configuration file.
> BUT according to the manpage not purging the data from the ucf
> database has practical effects for the package, so its of high
> interest for the database that the purge operation happened.
Yes, and the man page says how you should do the purge
*assuming that ucfr is on the system*. If it is not, don't bother.
The common case usage is not when you decide to dump ucf before
the purge, in which case it is no longer so important since when you
remove ucf you render all data collected so far as untrustworthy.
> That leads to the point where I have to ask you about something
> in the manpage.
>
> Lets say I'd do the following:
> - Install a package that uses ucf
> - Remove the package
> - Remove ucf
> - Purge the package using ucf
> - Re-install the purged package (and therefore pull ucf in again)
>
> What would happen? The manpage says that running ucf purge in the
> postrm *is required* because otherwise a new installation wouldn't
> work properly ("no action is taken"). That would mean that in this
> case something would go wrong.
> Now I had a quick look at your maintainer scripts and noticed that you
> divert the old data away on installation. Would that mean that whats
> beeing said in the manpage is not true in the above stated case,
> because ucf starts with a new registry anyway?
Right. The man page does not mention every corner case, but the
software still does the right thing.
> Apart from this: If you always start with a new registry on
> installation how does that play together with packages that are
> removed, but not purged and reinstalled later on? E.g. they wouldn't
> be registered anymore although their modified configuration is still
> laying around?
Sure. And the worst case effect is that the user is asked a
question on next update. All the registry does is to optimize away some
questions the users have been asked before.
If the user removes and re-installs ucf, they get to answer the
questions again. That's what you get for dumping a precious, cute, and
useful package like ucf, only to realize the error of your ways and
have to reinstall it 'cause you can't live without it.
manoj
--
I develop for Linux for a living, I used to develop for DOS. Going from
DOS to Linux is like trading a glider for an F117. -- Lawrence Foard,
entr...@world.std.com
Manoj Srivastava <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New Menu category Applictions/Multimedia
On Tue, Dec 08 2009, Andreas Marschke wrote:
>> Personally I think we should have gotten rid of the Debian menu years
>> ago, I don't think my opinion is shared by many people in Debian
>> though.
>>
>
> It is truely kind of doubled effort to have the debian menu extra to
> the actual menu. The question is who will step forward and propose the
> removal?
Whoever does the work to implement the replacement menu
infrastructure in all the places that the Debian menu is
implemented. And also helps flush out all the entries missing from the
xdg menu which are in the Debian one.
> We can make a new thread for this.
manoj
--
There are new messages.
Manoj Srivastava <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Mon, Dec 07 2009, Joe Smith wrote: > I suspect Patrick might be worried about a scenario like the following. > > Lets assume there is a package Foo that depends on and uses > ucf. Further the package is the only one ucing UCF on the system. > > At some point the admin decides to remove Foo. Since there are no > other packages that use ucf on this hypothetical system, the admin > also chooses to remove ucf. > > The admin purges Foo, but not ucf. Later the user installs some other > package that uses ucf. > The net result here is that ucf may be keeping excess state related to > package foo. But it is not. ucf knows well that when it is reinstalled the state information can't be trusted, it is merely historical, and takes steps to preserve, but not trust, that data. > Since it was not around to be alerted when Foo was purged, ucf is > unaware that this excess data may no longer needed. Thus any state of > ucf related to the package Foo will live on until some point when ucf > is purged, or perhaps if Foo is reinstalled, and then re-removed and > re-purged. That would have been very bad design, and a bug. > On the other hand, had the admin purged ucf at the same time that he > purged Foo, when ucf was reinstalled later it would start from a clean > slate and not keep around this old state that is not terribly useful > anymore. And lose all historical data about the state of the system. I prefer to not throw away information when it can reasonably be kept. > Now I'm not familar enough with ucf to know if this is a real > possibility. Perhaps ucf's design has something to prevent such a > thing from occuring. It is not a possibility. > I'm not sure. Then perhaps asking, rather than insisting on breaking encapsulation, should be the first thing to try to do? Either read the code, or ask first? > It certainly sounds like a plausible way to leak disk space. And again, ucf has a limit on the historical data that it keeps. Next? manoj not really a novice in software design anymore. -- Pudder's Law: Anything that begins well will end badly. (Note: The converse of Pudder's law is not true.) Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Mon, Dec 07 2009, Patrick Schoenfeld wrote: > Hi, > > (uhm.. I really hate it, if I can't hold the promises to myself I made; > in this case: not further discussing it, but still here is > another answer) > > On Mon, Dec 07, 2009 at 10:04:14AM -0600, Manoj Srivastava wrote: >> On Mon, Dec 07 2009, Patrick Schoenfeld wrote: >> >> > On Sun, Dec 06, 2009 at 11:47:11PM -0600, Manoj Srivastava wrote: >> >> >> In this particular case, what is the harm befalling the user? >> >> > >> >> > Well, I don't think that making an Operating System is just about >> >> > keeping harm away from our users. >> >> >> >> But it is a tenet of software design that to change something >> >> that is working, you have to have some justification beyond I wish >> >> things were different. >> > >> > Making the software better, in this case. >> >> Again, you make an assertion, without any basis for it. Why is >> it better, apart from the fact you seem to think it would be? What use >> case is being negatively impacted? > > Yes, I do make an assertion. But not "without any basis". Its just not a > basis that you accept. > > All boils down to the points where we disagree the most: > - I consider data that is used *nowhere* as garbage. You think its not > garbage, because you could use it some time in the future. Right. > - I consider ucf just a tool doing a certain duty on behalf of the > package requesting it. Yup. The task is to ask the user about how they want to handle what is done to files when the package is being upgraded. > For me this assumes that data created during this task belongs to > the package that requested the creation of the data in the first > place. That breaks abstraction and encapsulation. > And it includes providing an interface that does exactly what > is it told to do. Sorry. This is not the software paradigm you are looking for. In keeping with modular (and object oriented) design, ucf provides certain facilities. It keeps internal state, but that is opaque to the user. > For you the data belongs to ucf and it can do with it whatever it > wants to do. So if a postrm requested to purge the file from the > database it would also be okay, if ucf didn't do that. Nope. No other package gets to muck around with the internal structures and data for any utility, and that includes files hidden from the application. The API is provided for a purpose: use it, and do not break encapsulation by delving into internal details of the implementation. > Apart from this you made clear that you don't want to discuss your > software design, because "its not my business". Good to know. No, I meant it is not the business of any application that uses the interfaces that ucf provides. I'll be happy to discuss the design. I'll be even happier to support any use cases you can bring up and advocate. > I won't go further trying to change what I think is wrong. You as the > ucf maintainer decided that collecting garbage is okay, because > its not garbage in your opinion. Most other people agreed to that or > didn't comment at all (including those persons who agree with me). > It doesn't matter anyway. Its been a corner case from the beginning, > a seldom one additionally. There is work on-going or at least planned > to merge ucf functionality into dpkg, which is the better solution > IMHO anyway and will probably fix my "problem". I was not aware that dpkg was going to expand and work with non conffiles: most of the work is for providing ucf-like handling of conffiles, not for configuration files, unless I am misreading something. > You won't change my mind. I will not change your mind. > So to save us from discussing the topic to death, let us just agree to > disagree, ok? That's a cop out. It is, as you said, my package, and I will listen to people pointing out what are flaws, but I reserve the right to also say why it is not a flaw. As I see it, internal state of a utility is its own, and the very reason it provides an API is to abstract the functionality (so internal implementation can change), encapsulate internal state and data (so other applications and users don't have to worry about how things are implemented). If any supported use cases are broken, that would be a bug. I do not see there is indeed a bug. manoj -- The hearing ear is always found close to the speaking tongue, a custom whereof the memory of man runneth not howsomever to the contrary, nohow. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Mon, Dec 07 2009, Patrick Schoenfeld wrote: > On Sun, Dec 06, 2009 at 11:47:11PM -0600, Manoj Srivastava wrote: >> >> In this particular case, what is the harm befalling the user? >> > >> > Well, I don't think that making an Operating System is just about >> > keeping harm away from our users. >> >> But it is a tenet of software design that to change something >> that is working, you have to have some justification beyond I wish >> things were different. > > Making the software better, in this case. Again, you make an assertion, without any basis for it. Why is it better, apart from the fact you seem to think it would be? What use case is being negatively impacted? > But this is quiet abstract in this case, because this is not changing > the design of a specific tool, its about making the tool *always* > perform its duties. The tool is always performing its duties, really. What it needs to do depends on state, and the environment, which you don't take into account. >> > In this case there is not even almost a reason to keep the data. >> >> The package that calls ucf does not get to decide this. > > No, thats wrong. The package that calls ucf does already decide this, > in the moment it gets purged and calls out to ucf to let it remove > this data, because its not used anymore. The usual case if ucf is > installed. No. It does not decide what ucf does. It does not decide that ucf actually does anything; or puts it into a RDBMS, or into a file, or ignores it. All it does is to make a call to ucf. ucf decides how to handle the call, or whether even to offer the interface. > Well, its a fact. ucf does not need this data, the package does not need > that data. Not even the administrator needs that data. True. But when the internal staate information is discarded depends on ucf. It can keep the data around for historical reasons if it wants. >> If ucf does something wrong with it, >> point it out, and file a bug. > > I never said that ucf does something wrong. I said that it does not > have the chance to do its duties. And I say it does do its duties. Point me to what duties are failed as far as its use case actors are concerned (don't talk to me about internal details of the abstraction, which are none of your business). > Well, in this point we simply disagree. The data in question is not > needed by ucf at this point. In fact ucf would never have needed this > data, if the package wasn't installed in the first place. And even > since it has been installed the data has more relevance to the package > itself, because ucf is just a tool to aid the maintainer scripts in > getting a job done. And ucf gets to decide what it does with its internal state information. It can keep data no longer needed if it wants, for historical purposes (and tomorrow, provide a log of activities -- not that I am promising to code that). Stay the hell out of the internal details of the service, and how it provides the functionality beneath it's API. > And the fact that purging a package, which uses ucf, usually would > remove the data from the ucf registry as well weakens your point. > If it would belong to ucf why bother with removing it at all? usually, ucf would be in a different part of its internal state diagram, and its behaviour would be different. ucf gets to decide how it behaves in different internal states with respect to internal state data. manoj -- The system was down for backups from 5am to 10am last Saturday. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sun, Dec 06 2009, Patrick Schoenfeld wrote: > On Sun, Dec 06, 2009 at 09:28:11AM -0600, Manoj Srivastava wrote: >> On Sun, Dec 06 2009, Patrick Schoenfeld wrote: >> >> > On Sat, Dec 05, 2009 at 11:44:39AM -0600, Manoj Srivastava wrote: >> >> Making a package essential in order to avoid a if clause in >> >> postinsts is very likely too frivolous a reason to pass muster, yes. >> > >> > I do not want to avoid the if-clause. I want to avoid leaving modified >> > files around when removing a package, that modified them (indirectly) >> > in the first place. >> >> In this particular case, what is the harm befalling the user? > > Well, I don't think that making an Operating System is just about > keeping harm away from our users. But it is a tenet of software design that to change something that is working, you have to have some justification beyond I wish things were different. > >> What is the use case that will present an actual bad thing happening, >> apart from your wish that modified files for packages no longer >> installed but not purged do not remain on the system? > > Why are you talking about modified files to remain on the system? These file belongs to ucf, so they live on while ucf is not purged. > I'm not sure you've got the point. I, on the other hand, _know_ you are not getting it. > To make it more clear: > - I'm _not_ saying that ucf database has to removed, when its removed > but not purged. Cool. > - I'm not talking about the configuration files of package xyz itself. > Its clearly the job of the postrm to remove those files and this can > happen properly. Sure. > - I'm not saying that apart from the configuration files any file needs > to be *removed* from the system (your statement "your wish... files > ... do not remain on the system" makes me think you imply that) OK > All I'm talking about is: The package that is beeing purged created data > during its installation. If it is beeing purged, it should remove this > data unless there is a good reason to keep it. No it did not. The data is all internal to ucf, the package has no idea what the data is -- and ucf can change it internally in any way it wants, and the package will not be able to do anything about it. You see, this is called, CS, abstraction. The package calls ucf, and sends it a message. ucf does something about it. > In this case there is not even almost a reason to keep the data. The package that calls ucf does not get to decide this. > It has no use on a fresh installation of the package (and in fact it > must not, because the package has been purged). It has no use without > reinstalling the package (contrary to logfiles for example). > Basically its garbage. Not your call to make. If ucf does something wrong with it, point it out, and file a bug. > So under this aspect I do not see how you can argue that I would need > to make a case why this should not happen. Shouldn't it be the other > way round? Shouldn't we make a case why we should or can leave > *garbage* on the users system when *purging* the package who created > that garbage? Internal state information of icf is not garbage. It is not anyone's business but ucf's. If purging ucf left garbage on the system it would be a bug. This is not. > Shouldn't we make a case, why its ok to have things in our manpages, > such as dpkg(1) which are not true? > Just to rememember: > purge The package is selected to be purged (i.e. we want to remove >everything, even configuration files). Bingo. These files do not belong to the package. They belong to ucf. Why is that so hard to understand? > Otherwise how would your argumentation be different from saying > its okay to leave configuration backup files around when uninstalling? Bullshit. If ucf left state files around after purging, youmight have some grounds to say that. > The package did not install/create them, dpkg did it. What harm is it > causing to the user? What bad thing would actually happen? > Thats obvious not a good line to follow and if we'd do it would be in > contrast to how Debian solutions in the past seeked to get near > perfection. I think you are very mistaken. manoj -- * SynrG notes that the number of configuration questions to answer in sendmail is NON-TRIVIAL -- Seen on #Debian Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sun, Dec 06 2009, Patrick Schoenfeld wrote: > Hello, > > On Sat, Dec 05, 2009 at 08:35:38PM -0600, Manoj Srivastava wrote: >> >> > I never said that. The problem are not the files owned by the package, >> >> > but the files owned by ucf, which are modified by ucfr, while not >> >> > restoring the changes if ucf is not around. >> >> >> >> Well, if ucf is not around, one should not expect the internal >> >> state of ucf to be up to date. Is this a problem? > > depends on what you expect. I would expect or no lets say I wish that > purging a package removes all traces that the package where installed > in the first place, except the cases where this is inappropriate (for > example: there is a good reason not to remove logfiles on purge). > Basically this is a very common assumption for using a package > management at all, I think. You have expressed an opinion, no, a wish, that something happens one way. What you have not demonstrated a concrete harm that happens in this case when your wish is not granted. >> > Yep. This is the whole point of asking this: Is this a problem for us >> > or do we simply ignore it? E.g. the fact that a package can change the >> > state of an external program, but eventually not restore it. The >> > problem with it that the change is bound to the package removed, not >> > to ucf, thats why I'm wondering at all. >> >> That's pretty abstract. And this generally, there might not be >> something one may say one way or the other, and have to deal with it on >> a case by case basis. > > Is it? The case with ucf and $random_package is a concrete example > of leaving modified files around when purging a package that is > associated to the change. For no good reason, except technical > inability. What harm comes of it? Youhave already removed ucf at this point. What is the sue case you are presenting that suffers? Saying I wish this not to happen, and thus when it happens, that is the harm is circular logic, not a concrete example. > >> In this particular case, do you see I concrete problem that I do >> not? If you think there is a concrete problem, can you explain? I >> can't see a problem here, and the ucf man page has wat I beliece to be >> the correct advice. > > again, depends on what you expect. Reinstalling the package will not > cause any harm when the package is in the ucf registry, will it? If ucf is not around, it does not make a difference one way or the other. Indeed, without ucf being around, the code to manipulate ucf internal data structures is not around either. Your argument seems to be that if a package called ucf in order to have ucf change its internal state, ucf should be kept around to make changes to the internal state, willy nilly? What would that solve, apart from granting your wish? > So, it doesn't have any practical effect (tough luck!), except that > there are still modified files around, when you purge the package and > ucf is not around. These files belong to ucf. When ucf is purged, those files would be removed too. > Considering other cases we are not yet aware of, would be abstract, but > I don't think this is. So it is a hypothetical harm, with no concrete examples you can think of. manoj -- Complex system: One with real problems and imaginary profits. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sun, Dec 06 2009, Norbert Preining wrote: > On So, 06 Dez 2009, Manoj Srivastava wrote: >> So, policy does not require dependencies to be around at least >> during purge. > > Ah yes of course, sorry. I was referring to the remove phase, where it > is also not present, although policy states it. Are you sure this is the case being discussed? The thread is dealing with ucf -p, which is called when you are purging your package. ,[ Manual page ucf(1) ] | -p, --purge |Removes all vestiges of the file from the state hashfile. This is |required to allow a package to be reinstalled after it is purged; |since otherwise, the real configuration file is removed, but it |remains in the hash file; and on reinstall no action is taken, |since the md5sum of the new file matches that in the hashfile. |In short, remember to use this option in the postrm for every |configuration file managed by ucf when the package is being |purged (assuming ucf itself exists). Note: ucf does not actually |touch the file on disk in this operation, so any file removals |are still the responsibility of the calling package. ` So, I see no indication that dpkg is not following policy, based on this thread. What makes you think it is? manoj -- We are using Linux daily to UP our productivity - so UP yours! (Adapted from Pat Paulsen by Joe Sloan) Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sun, Dec 06 2009, Patrick Schoenfeld wrote: > On Sat, Dec 05, 2009 at 11:44:39AM -0600, Manoj Srivastava wrote: >> Making a package essential in order to avoid a if clause in >> postinsts is very likely too frivolous a reason to pass muster, yes. > > I do not want to avoid the if-clause. I want to avoid leaving modified > files around when removing a package, that modified them (indirectly) > in the first place. In this particular case, what is the harm befalling the user? What is the use case that will present an actual bad thing happening, apart from your wish that modified files for packages no longer installed but not purged do not remain on the system? manoj -- "It's a dog-eat-dog world out there, and I'm wearing Milkbone underwear." Norm, from _Cheers_ Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sun, Dec 06 2009, Patrick Schoenfeld wrote: > Actually the point is what a random package should do if it is beeing > purged in order to undo what it has done on installation in the > corner-case when ucf is beeing removed. Remove your files, and make a best effort attempt to call other utilities to clean up indirect mods, iff they exist. Which is what is happening here. If you want tohter things to happen, you have to make a case for why (a case that goes beyond I wish it were so). manoj -- To be, or what? Sylvester Stallone Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sat, Dec 05 2009, Norbert Preining wrote: > Not wanting to start another flame war, but ... > > On Sa, 05 Dez 2009, Patrick Schoenfeld wrote: >> The crux is the last point. For a good reason postrm must not require >> tools it depends on to be around when removing the package itself. > > making dpkg policy compliant would help, too, then we removed package > can expect dependcies to be present. Umm, what parts of policy would that be? ,[ 7.2. Binary Dependencies - `Depends' ... ] | `Depends' | This declares an absolute dependency. A package will not be | configured unless all of the packages listed in its `Depends' | field have been correctly configured. | | The `Depends' field should be used if the depended-on package is | required for the depending package to provide a significant | amount of functionality. | | The `Depends' field should also be used if the `postinst', | `prerm' or `postrm' scripts require the package to be present in | order to run. Note, however, that the `postrm' cannot rely on | any non-essential packages to be present during the `purge' | phase. ` So, policy does not require dependencies to be around at least during purge. manoj -- My only love sprung from my only hate! Too early seen unknown, and known too late! -- William Shakespeare, "Romeo and Juliet" Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sat, Dec 05 2009, Patrick Schoenfeld wrote: > On Sat, Dec 05, 2009 at 05:25:29PM -0600, Manoj Srivastava wrote: >> On Sat, Dec 05 2009, Patrick Schoenfeld wrote: >> >> > On Sat, Dec 05, 2009 at 06:37:45PM +0100, Sven Joachim wrote: >> >> It is the package's responsibility to remove those files, "ucf --purge" >> >> does not do that, see ucf(1). >> > >> > I never said that. The problem are not the files owned by the package, >> > but the files owned by ucf, which are modified by ucfr, while not >> > restoring the changes if ucf is not around. >> >> Well, if ucf is not around, one should not expect the internal >> state of ucf to be up to date. Is this a problem? > > Yep. This is the whole point of asking this: Is this a problem for us > or do we simply ignore it? E.g. the fact that a package can change the > state of an external program, but eventually not restore it. The > problem with it that the change is bound to the package removed, not > to ucf, thats why I'm wondering at all. That's pretty abstract. And this generally, there might not be something one may say one way or the other, and have to deal with it on a case by case basis. In this particular case, do you see I concrete problem that I do not? If you think there is a concrete problem, can you explain? I can't see a problem here, and the ucf man page has wat I beliece to be the correct advice. manoj -- It is bad luck to be superstitious. Andrew W. Mathis Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sat, Dec 05 2009, Patrick Schoenfeld wrote: > On Sat, Dec 05, 2009 at 06:37:45PM +0100, Sven Joachim wrote: >> It is the package's responsibility to remove those files, "ucf --purge" >> does not do that, see ucf(1). > > I never said that. The problem are not the files owned by the package, > but the files owned by ucf, which are modified by ucfr, while not > restoring the changes if ucf is not around. Well, if ucf is not around, one should not expect the internal state of ucf to be up to date. Is this a problem? manoj -- "You can't make a program without broken egos." Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sat, Dec 05 2009, Patrick Schoenfeld wrote: > What speaks against it? Its basically a mini tool (Installed-Size: 260) > and not making it essential leads to the mentioned situations. I am afraid I do not follow -- what situations are improved by making ucf essential? > The only bad thing is, that it depends on a tool which is not essential > (debconf) and seems not to be able to render questions without debconf. Actually, the ask questions without debconf functionality was ripped out just a couple of months ago, since not using debconf is now a policy violation. > Or should we simply not care about packages modifying files (via > external tools) and not reverting those changes when beeing removed? If you are going to remove the file, why bother reverting any changes? manoj -- It is a poor judge who cannot award a prize. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sat, Dec 05 2009, Patrick Schoenfeld wrote:
Short Answer: hell no.
Read below for why that would be a bad idea.
> when testing my packages with piuparts I noticed an inability of
> our package management. Dpkg does not have support for management
> of dynamically generated configuration files. Therefore some packages
> now use ucf.
>
> The basic usage is somewhat like
> - Registering config files to ucf on installation
> - Using it when configuring the package to merge configuration updates
> and local changes
> - Unregistering config files to ucf on purge
> The crux is the last point. For a good reason postrm must not require
> tools it depends on to be around when removing the package itself.
> So the call of ucf looks something like that:
>
> if which ucf >/dev/null; then
> ucf --purge /etc/foo.conf
> fi
>
> That is okay, as long as ucf is around.
And if ucf is not around, why bother cleaning up the ucf cache?
When ucf is purged, it will remove its own darned cache.
> But as soon as it isn't the purge of a package is succesful while
> leaving modified files around. So the effect is that a purge does not
> "remove everything".
This is where things break down. ucf --purge does not do what
you think it does, it by no means removes the configuration files. You
remove the configuration files, not ucf.
> Do we really want that? Should ucf be 'required' to avoid that?
What purpose would that serve?
manoj
--
Never try to teach a pig to sing; it wastes your time and it annoys the
pig.
Manoj Srivastava <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sat, Dec 05 2009, brian m. carlson wrote: > On Sat, Dec 05, 2009 at 04:47:18PM +0100, Patrick Schoenfeld wrote: >> That is okay, as long as ucf is around. But as soon as it isn't >> the purge of a package is succesful while leaving modified files around. >> So the effect is that a purge does not "remove everything". >> >> Do we really want that? Should ucf be 'required' to avoid that? > > ucf being priority required is not sufficient. It is still possible to > remove such a package (mawk is a good example) and therefore you would > still need to execute ucf conditionally. The only way around that is to > make ucf essential, and I don't think that's a good idea. Making a package essential in order to avoid a if clause in postinsts is very likely too frivolous a reason to pass muster, yes. manoj -- The Constitution may not be perfect, but it's a lot better than what we've got! Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Has Debian abandoned Python?
On Fri, Dec 04 2009, Lucas Nussbaum wrote: > On 03/12/09 at 23:55 -0600, Manoj Srivastava wrote: >> On Thu, Dec 03 2009, Piotr Ożarowski wrote: >> >> > Right now we're working on updating the Debian Python Policy. Once we'll >> > be happy with the first set of patches, we'll send them to debian-python >> > mailing list. I don't see a reason to make it public right now as it's >> > simply not ready. Does it really matter that I'm not preparing it alone? >> > If I would work on it alone would I still be obligated to make >> > everything public? >> >> Policy decisions, even drafting policy, does not have to be held >> in deep dark secret; indeed, policy creation in Debian has usually >> been held right out in the open. Going away and crafting what you >> think is going to be a finished policy and expecting wide adoption of >> the fait accompli is likely to have surprising outcomes for you. > > Were did Piotr say that he expected the updated policy to be > immediately adopted without changes? Did I say he said it? > I don't have a problem with people drafting stuff privately if it is > more efficient (and it's very probably more efficient there, with all > the social issue involved). BUT people drafting stuff privately should > not expect DDs to blindly and automatically accept their proposal, > and be ready to rewrite it completely during the public discussion. Past experience has shown me (and I do have a modicum of experience guiding technical policy development in Debian) that people drafting policy by themselves are much more likely to balk at having to rewrite the policy, and often are frustrated by having to repeat arguments expressed in private -- but hey, maybe this time it will be all different from those previous times. > What I have a problem with, is people _deciding_ stuff privately, and > then announcing changes on d-d-a, expecting them to be accepted without > discussion. > I think that most of us are OK with the "private drafting / public > discussion with lots of changes if necessary" process. But we so much > fear that the "private decision taking / announce on d-d-a" process > will be used again that people ask that all discussions are public. > We really need to trust Piotr (and others) to do the right thing here. The right thing, I think, is to do it in the open. It is not as if drafting technical policy in the open results in open flammage -- technical issues are, as a rule, less cause for endless flammage than non technical subjective issues [like this one]. manoj -- If the odds are a million to one against something occurring, chances are 50-50 it will. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian as open project
On Fri, Dec 04 2009, Russell Coker wrote: > On Fri, 4 Dec 2009, Manoj Srivastava wrote: >> Nothing wrong with that. But when people are told to shut up >> since Supe Speshul Sekrit discussions are going one betwen Really Ver >> Important People, and the people partaking in the open discussions are >> not important enough to be heard, well, that is a horse of a very >> different color. > > They were asked to take it to private email - which is not the same as > telling them to shut up. Since it is shutting down public discussion, I fail to see the distinction. > Is there any reason to expect that anyone who wanted to join the > off-list discussion would be excluded if they had sensible things to > say? How would I know about this so called discussion? What if I might have things to add to it, after listening in for a bit? Who is the target audience for suvh off list discussion? Only people who have participated earlier? (I mean, I participated, and I have had no emails sent to me. And I even contributed to the whole python policy thing -- one of the documents people were bandying about in an earlier incarnation of this discussion was written by me). manoj -- The difference between us is not very far, cruising for burgers in daddy's new car. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Has Debian abandoned Python?
On Thu, Dec 03 2009, Piotr Ożarowski wrote: > Right now we're working on updating the Debian Python Policy. Once we'll > be happy with the first set of patches, we'll send them to debian-python > mailing list. I don't see a reason to make it public right now as it's > simply not ready. Does it really matter that I'm not preparing it alone? > If I would work on it alone would I still be obligated to make > everything public? Policy decisions, even drafting policy, does not have to be held in deep dark secret; indeed, policy creation in Debian has usually been held right out in the open. Going away and crafting what you think is going to be a finished policy and expecting wide adoption of the fait accompli is likely to have surprising outcomes for you. manoj -- Love the sea? I dote upon it -- from the beach. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian as open project
On Thu, Dec 03 2009, Russell Coker wrote: > It's really not uncommon for small groups of developers to discuss things > privately before raising matters for discussion on the lists or for list > discussions to be continued in private mail. Nothing wrong with that. But when people are told to shut up since Supe Speshul Sekrit discussions are going one betwen Really Ver Important People, and the people partaking in the open discussions are not important enough to be heard, well, that is a horse of a very different color. manoj -- Trying to define yourself is like trying to bite your own teeth. Alan Watts Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian as open project
On Thu, Dec 03 2009, Joey Hess wrote: > Luk Claes wrote: >> Unfortunately Debian does not seem to be able to also have real >> constructive discussion about complex issues on the lists. So for these >> issues we usually have real discussions on IRC, real life, phone or >> private mail. The final result of these discussions is normally also on >> the lists as proposals or announcements. >> >> So I still think that Debian is an open project. > > If you dislike the mailing lists, use some other, open communications > medium. However, communication via press-release to d-d-a does not an > open project make. I agree with Joey here. The exhortations for people to stop discussing our problems in the open, and instead replacing the open medium of conversation with deals struck in smokey backrooms amongst the powerful few who matter probably do more harm than the flames. Ideally, one would not need either, but the maturity level of the people in the discussion often leaves much to be desired. Despite that, hiding our problems in smoky backrooms is contrary to our charter, no? manoj -- The man on tops walks a lonely street; the "chain" of command is often a noose. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#559134: ITP: shc -- a generic shell script compiler
On Wed, Dec 02 2009, Milan P. Stanic wrote: > On Wed, 2009-12-02 at 15:58, Karl Goetz wrote: >> On Wed, 02 Dec 2009 05:58:17 +0100 >> "Dario Minnucci \(midget\)" wrote: >> > * Package name: shc >> >> > shc's main purpose is to protect your shell scripts from >> > modification or inspection. You can use it if you wish to >> > distribute your scripts but don't want them to be easily >> > readable by other people. >> Does this mean its a tool to make software no longer DFSG compatible? >> seems a bit odd to include in Debian. > > Then gcc (and other compilers) are at the odd with DFSG because they > produce unreadable code for most people. (some can read machine code) What this argument is missing is the point that the primary (and stated) goal of gcc and the ilk is not obfuscation. And the goal of obfuscation is not preventing tampering (since one may still modify obfuscated code, just not as easily (access control mechanisms do the non tampering bit)). The goal of obfuscation seems to be to prevent people from gaining knowledge; and obfuscation is pointless when the sources are available, so it is facile to argue that the issues are orthogonal. So there is some merit to the argument that this package is against the spirit free software. Having said that, I am not advocating blocking this package (nor am I advocating accepting it), I am just commenting on the arguments being presented here. manoj -- No matter how many reporters share a cab, and no matter who pays, each puts the full fare on his own expense account. -- Edward P. O'Doyle Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Linux image packages going to depend on python
Hi, On Sun, Nov 29 2009, Frank Lin PIAT wrote: > Find attached an initial attempt to use shell only. Let me know if you > are interested. > > The script is configurable, so a sysadmin can decide to re-rewrite fstab > using DM/LVM names rather than UUID, or volume LABEL, or legacy /dev/hd* > names. > > Known bugs/limitation: > * Should accept command line arguments > * Some devices may need to be blacklisted > * What about removable media? (UUID of media in CDROM? ouch) > * Should actually write fstab ;) > > I have hesitated to probe the current /dev or to use blkid... I can > change that easily. > > I think this script should have a companion, to insert/update a comments > line above each fstab entry (à-la Debian-Installer) Perhaps you should consider making the script just create a ./fstab.new file, and not overwriting /etc/fstab? makes it easier to test the script out without altering current setup. manoj -- There's such a thing as too much point on a pencil. Allen Smith, "Let the Crabgrass Grow" Manoj Srivastava <http://www.golden-gryphon.com/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Linux image packages going to depend on python
On Sat, Nov 28 2009, Ben Hutchings wrote:
> On Sat, 2009-11-28 at 16:43 -0600, Manoj Srivastava wrote:
>> On Sat, Nov 28 2009, Neil Williams wrote:
>>
>> > On Sat, 28 Nov 2009 18:56:01 +0100
>> > Patrick Matthäi wrote:
>> >
>> >> Am 28.11.2009 18:52, schrieb Bastian Blank:
>> >> > Hi folks
>> >> >
>> >> > The Linux image packages needs to do some modifications to core
>> >> > configuration files like fstab in the future to allow newer kernels to
>> >> > work. To do this and the planned further extension I intend to make all
>> >> > linux image packages depend on python.
>> >
>> > This sounds like a maintainer-script issue rather than a direct
>> > requirement of the image itself. Would it be possible for the scripts
>> > to check for python support and continue *without error* if python is
>> > not found? This way, systems that do not have python but *do* have a
>> > setup capable of implementing whatever changes are suitable can still
>> > use a vanilla Debian kernel, e.g. during debugging.
>> >
>> > Note 'suitable' - no matter what the kernel does or thinks it needs, it
>> > is not necessarily suitable for the maintainer scripts to fiddle with
>> > system config files on every system.
>>
>> Indeed. Editing configuration files that belong to other
>> packages is a policy violation; and even editing configuration files
>> blonging to he package itself must preserve all user changes.
>>
>> It seems to be that a better approach is to inform the user, and
>> let the admin make the changes needed.
>
> The specific requirement here is to prepare for a transition from old
> PATA ("IDE") drivers to libata-based drivers. libata presents ATA/ATAPI
> drives as SCSI devices, so hard drive partitions will change
> from /dev/hdX to /dev/sdX.
This is fine. /etc/fstab is used by mountall.sh, mount, and
swapon explicitly -- so arguably mount is the related package that
"owns" the configuration file. Here is what policy has to say about it:
,[ 10.7.4. Sharing configuration files ]
| If two or more packages use the same configuration file and it is
| reasonable for both to be installed at the same time, one of these
| packages must be defined as _owner_ of the configuration file, i.e.,
| it will be the package which handles that file as a configuration
| file. Other packages that use the configuration file must depend on
| the owning package if they require the configuration file to operate.
| If the other package will use the configuration file if present, but
| is capable of operating without it, no dependency need be declared.
|
| If it is desirable for two or more related packages to share a
| configuration file _and_ for all of the related packages to be able to
| modify that configuration file, then the following should be done:
| 1. One of the related packages (the "owning" package) will manage
| the configuration file with maintainer scripts as described in
| the previous section.
| 2. The owning package should also provide a program that the other
| packages may use to modify the configuration file.
| 3. The related packages must use the provided program to make any
| desired modifications to the configuration file. They should
| either depend on the core package to guarantee that the
| configuration modifier program is available or accept gracefully
| that they cannot modify the configuration file if it is not.
| (This is in addition to the fact that the configuration file may
| not even be present in the latter scenario.)
|
| Sometimes it's appropriate to create a new package which provides the
| basic infrastructure for the other packages and which manages the
| shared configuration files. (The `sgml-base' package is a good
| example.)
`
> In preparation for this partition, /etc/fstab and the kernel parameters
> in boot-loader configs should be changed to specify partitions by UUID
> or label name so that they work with both old and new kernel versions.
> There will be a debconf question as to whether this should be done
> automatically, but it is not appropriate to expect all users to make
> this change manually.
While it is not appropriate for the user to do it manually,
there is still a policy compliant way to do what is needed:
A) Have mount provide the use-uuids-in-fstab script, and have ask the
user if one may call it. If so, call it in the postinst
B) Detect if the fstab changes have happe
Re: Linux image packages going to depend on python
On Sat, Nov 28 2009, Neil Williams wrote: > On Sat, 28 Nov 2009 18:56:01 +0100 > Patrick Matthäi wrote: > >> Am 28.11.2009 18:52, schrieb Bastian Blank: >> > Hi folks >> > >> > The Linux image packages needs to do some modifications to core >> > configuration files like fstab in the future to allow newer kernels to >> > work. To do this and the planned further extension I intend to make all >> > linux image packages depend on python. > > This sounds like a maintainer-script issue rather than a direct > requirement of the image itself. Would it be possible for the scripts > to check for python support and continue *without error* if python is > not found? This way, systems that do not have python but *do* have a > setup capable of implementing whatever changes are suitable can still > use a vanilla Debian kernel, e.g. during debugging. > > Note 'suitable' - no matter what the kernel does or thinks it needs, it > is not necessarily suitable for the maintainer scripts to fiddle with > system config files on every system. Indeed. Editing configuration files that belong to other packages is a policy violation; and even editing configuration files blonging to he package itself must preserve all user changes. It seems to be that a better approach is to inform the user, and let the admin make the changes needed. manoj -- Any clod can have the facts, but having opinions is an art. Charles McCabe Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Tue, Nov 24 2009, Stefano Zacchiroli wrote: > On Mon, Nov 23, 2009 at 09:02:05PM +, Philipp Kern wrote: >> Everybody should pipe his uploads through lintian. That's nothing >> that should be in the upload tool, IMHO. A unixy tool does one job, >> not two. > > Counter example: everybody should pipe his .changes through > debchange. Umm, what? I thought dch was something used to create or modify ./debian/changelog file. What does piping .changes file through debchange buy one? manoj -- 'Course, that doesn't work when 'a' contains parentheses. Larry Wall in <199710211647.jaa17...@wall.org> Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
On Mon, Nov 23 2009, Joey Hess wrote: > Perhaps Raphael in turn was sensing that I didn't have a deep knowledge > of git -- I had only used it for a month or so at the time. And in fact, > we now know a much better way to do a git based format. I have been > considering working on it again, after #554682 is fixed. I would like to help, especially when it comes to support for submodules. manoj -- Youth had been a habit of hers so long that she could not part with it. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the FTPMaster meeting
On Sun, Nov 22 2009, Steve Langasek wrote: > On Wed, Nov 18, 2009 at 11:14:29PM +0900, Charles Plessy wrote: >> You are member of the technical comittee, which means that I should trust >> your experience. I want you and this list to understand that I take your >> advice to orphan my packages very seriously. > Well, that's unfortunate, because Manoj isn't speaking for the > Technical Committee. Right. > As a fellow member of the TC, Does that mean you are speaking with your TC hat on? If so, that is wildly inappropriate, if not, mentioning it here is mostly irrelevant, and distracting, unless, of course, you want to appear to argue from a position of authority. > I think Manoj was being inappropriately inflammatory and insulting > with these comments, While we are bandying opinions around, let me say that the developer with the mind set "Works for my pet architecture(s)", and their near kin "Works for me™", and would prefer not to take care of bugs on their packages unless their own pet usages are imacted are a liability that a project, with the avowed goal of being a universal OS and also of being the "best" OS, can not possibly afford. > and I think by the time he was done purging the rolls of everyone he > thought we "shouldn't support" as a maintainer, there'd be nothing of > Debian left. And I think your judgment on what is acceptable quality has become dangerously lax. I can only speculate this might be the influence of your day job; but down here he have not fully abrogated package quality on a fuller range of architectures, and not yet cast away quality of implementation for the ease of use for novices. It is not enough for people to just not stand in the way of other people trying to fix their packages; Developers should still be expected to have an active hand in improving the quality of software they maintain, to the best of their abilities. We are not glorified packages with exotic titles like over master of the multiverse; we are called "Developers" for a reason. mannoj -- Don't make a big deal out of everything; just deal with everything. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the FTPMaster meeting
On Wed, Nov 18 2009, Charles Plessy wrote: > Le Wed, Nov 18, 2009 at 02:49:46PM +, Mark Brown a écrit : >> >> The flip side of this is that it's just inviting maintainers to >> decide they can't be bothered with porting effort and leaving ports >> as second class citizens. > > It seems that the trend this year is to not trust the maintainers for > anything… It would seem that your remark below somewhat validate > How about the porters responsability towards the project ? For They are also jointly responsible for trying to port stuff to their machines. We are, like, you know, in it together? Which is why the "project" is a plurality? > instance, hppa is blocking the testing migration of a couple of my > packages, and probably the packages of many other maintainers as > well. Why would it be my duty to help people running Debian on > machines that are not used in my profession, and for which I have no > qualification at all? I do not want to prevent people having fun with To try and make Debian better, rather than just be narrowly focused on your little fiefdom? The package maintianer is the resident expert Debian has for the package. If there are problems building it, the first line of defense is the package maintainer. I mean, dude, they are _your_ packages that are not building on a supported architecture. If the problem is in the tool chain, the porters should take lead, but that is the lower probability scenario. Chances are the fix lies in your domain of expertise, namely, the package source. > Debian on this arch, so wouldn't the best solution to never build my > package on their arch in the first place? No. The best solution is to fix the buggy package. Or deem it too buggy to be in Debian, of course. > It would reduce the number of issues to solve in both groups, Debian > Med and the hppa porters, which like every other group in Debian > severely lack manpower. If some package is so straining the resources of the teams, by being so fragile as to require a huge amount of effort on a couple of architectures with no legitimate reason for being included in P-a-s, then the consideration should be to fix the package, or drop it, before relegating users of hppa to second class citizens -- as long as the project still supports hppa. manoj -- "Mind if I smoke?" "I don't care if you burst into flames and die!" Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the FTPMaster meeting
On Wed, Nov 18 2009, Clint Adams wrote: > On Wed, Nov 18, 2009 at 07:41:51AM +0100, Luk Claes wrote: >> I don't think it's good to waste buildd time on failing to build packages. >> I also don't think anyone is stopped from setting up a service that >> allows source-only uploads as a go-between. > > Do you mean set up an unofficial upload queue that builds a source > package, autosigns the .changes, and uploads it to Debian? If such a system is set into play, I promise to help test it by funneling my uploads through it. manoj -- It would be nice to be sure of anything the way some people are of everything. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the FTPMaster meeting
On Wed, Nov 18 2009, Charles Plessy wrote:
> Le Wed, Nov 18, 2009 at 12:42:47AM -0600, Manoj Srivastava a écrit :
>>
>> I beg to differ. This sounds like a maintainer that is not
>> providing the support for their package, and needs to orphan that
>> package; not building on some architecture is often a symptom of
>> problems elsewhere as well. I am not sure we ought to support
>> maintainers that are neglectful of their packages.
>
> You are member of the technical comittee, which means that I should
> trust your experience. I want you and this list to understand that I
> take your advice to orphan my packages very seriously.
While I am flattered, I don't think you should pay special
attention to my words based on who I am. That is the flip side of
arguing to the man; arguing by authority. You should pay attention to
my argument only if it makes sense.
> For the programs I am interested in, I do not share Debian's goal to
> make them run on all existing platforms we support.
I don't think that that is the rationale for making packages
build everywhere; if it were, we would not have P-a-s. The rationale is
that making packages portable unmasks bugs that are present everywhere,
but not yet triggered,
Now, there are of course packages that do not make sense to
build on all architectures, or to not build on specific arches. My
SELinux related packages are an example -- they do not make sense to
have on the kfreebsd or the HURD. Which is why we have mechanisms to
exclude packages from architectures -- and by default, if a package has
never built on an architecture, it is not a testing migration blocker.
The answer is to utilize these exception mechanisms.
> Trust me, it is not only to save my time, but also because I do not
> want my packages to be a burden to the communauty. It is my experience
> that for bioinformatics packages, when a bug is found by the buildd
> network on an unsupported architecture, neither upstream nor the
> porters show much interest for it. I do not mean this as a criticism,
> since I share this point of view that there is better to do than
> fixing those bugs.
Right. But it is not for upstream or the porters alone: this is
what we, as Debian developers, do. We are not just glorified
packagers; we are supposed to be "Developers", we take an active role
in improving and fixing our packages. Anything less does not do justice
to the project's goal of creating the "BEst" OS ever.
> I am of course pleased to see my work re-used, but I would be even
> more pleased if people would use Debian Med. To attract more users, we
> need a good release and good medical packages. I do think that not
> speding time on porting some of our bioinformatics packages would help
> the two sides of the coin.
Firstly, if it requires that much porting, it might point to a
defect in design, which should be fixed. Secondly, if there is a
legitimate reason (and of course there are legitimate reasons to not
build stuff on some arches) -- then talk to your fellow Debian
developers, and get an entry added to the P-a-s. It is not hard.
manoj
--
"...and scantily clad females, of course. Who cares if it's below zero
outside" (By Linus Torvalds)
Manoj Srivastava <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the FTPMaster meeting
On Tue, Nov 17 2009, Charles Plessy wrote: > Le Tue, Nov 17, 2009 at 08:27:22AM +0100, Yves-Alexis Perez a écrit : >> >> Unless your proposal is just for unstable but doesn't want to change the >> policy for testing migration? > > Hi, > > Testing migration works the way it should: if a package is never built > on an architecture, testing migration is not prevented. The problem is > that for the sake of universality, some programs are built where > nobody wants them. Then when there is a build failure, nobody wants > the ‘hot potato’. Upstream does not support non-mainstream arches, the > porters are busy porting more central packages, the package maintainer > has user requests to answer and knows that nobody will send him kudos > for building the package where it is not used. I beg to differ. This sounds like a maintainer that is not providing the support for their package, and needs to orphan that package; not building on some architecture is often a symptom of problems elsewhere as well. I am not sure we ought to support maintainers that are neglectful of their packages. manoj -- There are some things worth dying for. Kirk, "Errand of Mercy", stardate 3201.7 Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: possible MBF about Policy 8.2 (Shared library support files)
On Tue, Nov 17 2009, Goswin von Brederlow wrote: > I mentioned before that there are a lot of packages that violate > Policy 8.2 Shared library support files: > > | If your package contains files whose names do not change with each > | change in the library shared object version, you must not put them > | in the shared library package. Otherwise, several versions of the > | shared library cannot be installed at the same time without > | filename clashes, making upgrades and transitions unnecessarily > | difficult. > Manoj Srivastava >libsemanage Split up into libsemanage-common in VCS, build testing in progress. Shall upload in a couple of hours at most. manoj -- The absence of labels [in ECL] is probably a good thing. Cheatham Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Wed, Nov 04 2009, Steve Langasek wrote: > I'm not complaining about you filing bugs on *my* packages. I'm > complaining about a mass bug filing on *any* packages, using standards > that have not previously been approved by the project, because *doing > so skews priorities for the project as a whole*. Marking bugs as > severity: serious means *the project* has to deal with the resulting > bugs. The bugs get mixed into the RC bug list and take up resources > of participants in bug squashing parties; the release team has to go > back and mark bugs as release-ignore or downgrade them if they're not > actually release-critical issues; the QA team winds up with these > packages on their radar even if the package quality doesn't warrant > it. Now that the ftp-masters have changed the blacklist, all the bugs that were reported at serious severity due to the blacklist have been downgraded to important, and it was fairly trivial to do the severity change. All must violations of policy remain at severity serious; if you think policy needs to be changed, please follow the policy change process. If you do not understand policy, please ask for help. If you think your package is special, and should get an exemption from policy MUST directives, please explain why on the debian-policy list; it might be an indication that the debian policy needs changing. Please do not just downgrade the bugs. manoj -- Prejudice: A vagrant opinion without visible means of support. Ambrose Bierce Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Wed, Nov 04 2009, Joerg Jaspert wrote: >>> Please do. For now, and I think until squeeze or this tag no longer >>> visible on lintian.d.o (ie no package affected), whatever comes first, >>> this tag is in nonfatal. >> I think you shall find that most already have bugs filed. > > Yes, and I really like that I do not have to do this myself, thanks. So. An overview of the policy related bug filing I have been doing recently can be found at: http://tinyurl.com/yk8p3rx Coming up with that URL was ... interesting. manoj -- We promise according to our hopes, and perform according to our fears. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Wed, Nov 04 2009, Steve Langasek wrote: > On Tue, Nov 03, 2009 at 11:29:53PM -0600, Manoj Srivastava wrote: > >> > Do you understand why people are getting annoyed ? > >> They have a lot of bloody gall to be annoyed thatpeople file >> bugs about serious policy violations that they have signed up to >> follow, and neglected in their packages, and instead of thanking peple >> who find out and point to these policy violations, they feel angry at >> the bug reporter, instead of ashamed at how they neglect bugs in their >> packages. > > Yes, you have completely failed to understand the issue. > > I'm not complaining about you filing bugs on *my* packages. I'm > complaining about a mass bug filing on *any* packages, using standards > that have not previously been approved by the project, because *doing > so skews priorities for the project as a whole*. Marking bugs as > severity: serious means *the project* has to deal with the resulting I think this is mostly false. 90% of the bugs filed were on target, and the remaining were only bumped up one level; and usertagged for easy changes. Note that the vast majority of bugs I have filed as serious are violations of Must directives: ,[ http://www.debian.org/Bugs/Developer#severities ] | serious | is a severe violation of Debian policy (roughly, it violates a | "must" or "required" directive), or, in the package maintainer's or | release manager's opinion, makes the package unsuitable for release. ` 25 out of 240 bugs were upgraded from important to serious, and these are the tags in these 25 bugs: arch-dependent-file-in-usr-share binary-with-bad-dynamic-table control-file-has-bad-permissions depends-on-build-essential-package-without-using-version dir-or-file-in-tmp invalid-standards-version missing-build-dependency missing-build-dependency-for-dh_-command no-standards-version-field package-installs-python-pyc All of these are policy violations, and would normally result in at least important bugs. > bugs. The bugs get mixed into the RC bug list and take up resources > of participants in bug squashing parties; the release team has to go > back and mark bugs as release-ignore or downgrade them if they're not > actually release-critical issues; The amount of effort needed to fix these is about comparable to kvetching about it or downgrading them, And, anyway, given that the bugs are all usertagged, it is trivial to reset them. These would be low hanging fruit in bug squash parties, and > the QA team winds up with these packages on their radar even if the > package quality doesn't warrant it. None of the packages belonging to the QA team are affected. > All because you're jumping at the chance to slap serious bugs on > people's packages without waiting for consensus to emerge on whether > those issues, some of which are entirely cosmetic, should actually be > serious. There is already consensus on the severity of bugs that violate must directives in policy. That is 90% of the bugs filed. The other bugs are still important. And trivial for the maintainer to download/ > That's not improving the quality of Debian, that's just being a jerk. Bullshit. A researched, usertagged set of bugs that takes 5 minutes to change the severity gets your panties in such a twist? Where rules lawyering about who is entitled to file what bugs is more important than discovering long neglected bugs? >>Finally, these violations of policy are added to the blacklist, >> since these serious policy violations are adjudged too buggy for Debian > > The use of passive voice here masks the fact that the adjuge-er is not the > Debian project as a whole. The debian project as a whole does not adjudicate a whole lot of things -- like which bugs ought to get a pass in a release. There are a whole lot of decisions made by the DPL and delegates, and I for one think that the people in charge of the archive get the same leeway that the people in charge of the release do. manoj -- Professional wrestling: ballet for the common man. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Tue, Nov 03 2009, Charles Plessy wrote: > Le Tue, Nov 03, 2009 at 01:01:02PM -0600, Manoj Srivastava a écrit : >> >> when we do add such a lintian check to the blacklist, we also file serious >> bugs against those packages in the archive; and aggressively work to either >> fix the packages, or remove them from the archive. > > It is very unclear who ‘we’ is in this sentence. To me, the situation looks > more like: Sigh*. Why is it relevant who it is? > when [they] do add such a lintian check to the blacklist, [you] file > serious bugs against those packages in the archive; and [expect > others to] aggressively work to either fix the packages, or [go > through the long process that may allow to] remove them from the > archive. So. Given what the process being talked about is, we first create policy via a consensus based process, and policy has these directives. Policy tries not to create directives where tonns of packages are insta-buggy. Lintian checks are written for these directives, and over time, people get to see if their packages are affected. Again, new policy directives do not come in as must rules, so these have been in effect for ages. Finally, these violations of policy are added to the blacklist, since these serious policy violations are adjudged too buggy for Debian -- but this is after a looong period of time after people have known that their packages are buggy. Someone (perhaps me), now files these violations as bugs that they are. In other words, after people ignore what lintian tells them are policy violations, someone does a lot of research, verifies there is a bug, and files reports. > Do you understand why people are getting annoyed ? They have a lot of bloody gall to be annoyed thatpeople file bugs about serious policy violations that they have signed up to follow, and neglected in their packages, and instead of thanking peple who find out and point to these policy violations, they feel angry at the bug reporter, instead of ashamed at how they neglect bugs in their packages. manoj irritated -- Sex, Drugs & Linux Rules MaDsen Wikholm, mwikh...@at8.abo.fi Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Tue, Nov 03 2009, Joerg Jaspert wrote: >> I don't think it's appropriate to make, for instance, >> dir-or-file-in-var-www instantly fatal without following the usual >> mass-bug-filing procedure. If you'd like mass bugs to be filed based >> on these lintian tags but don't have time, let me know if I can help >> (I can't promise to deal with all of them). > > Please do. For now, and I think until squeeze or this tag no longer > visible on lintian.d.o (ie no package affected), whatever comes first, > this tag is in nonfatal. I think you shall find that most already have bugs filed. > >> Some examples of tags where I do not consider this reasonable until >> bugs have been filed: >> - statically-linked-binary >> - mknod-in-maintainer-script > > These are nonfatal for the reason that they are, unless the maintainer > did think about it, something that shouldn't be there. So if they > really need to be there, fine, override. Bugs already filed about the latter. I have not gotten around to the statically-linked-binary ones yet. >> - debian-rules-not-a-makefile > > Policy must. > >> - dir-or-file-in-var-www > Nonfatal with my next commit. Bugs already filed. >> E: ftp-master: wrong-file-owner-uid-or-gid Policy 9.2 does /not/ >> prohibit shipping files with owners outside these ranges; it >> prohibits relying on user or group IDs outside these ranges being >> static, but there doesn't appear to be anything in Policy that >> prohibits creating the user in the package preinst and then unpacking >> the package such that ownership is applied by /name/. (Unless I'm >> mistaken, this is precisely what dpkg does.) > >> So false-positives are possible with this lintian check, and it >> should be overrideable. > We currently only have 1 package in the whole archive triggering > this. Thats why it is listed. > Fine, moved to nonfatal. Bugs filed after manual checks to remove false positives. > >> E: ftp-master: >> copyright-lists-upstream-authors-with-dh_make-boilerplate This one >> has been mentioned previously in the thread. Yes, it's a blemish in >> the package to list "Upstream Author(s)", but the lintian maintainers >> have correctly marked this as being of "normal" severity. We should >> not be blocking packages from the archive for such low-severity >> issues; please drop this check. > > Already removed this check, instead added > copyright-contains-dh_make-todo-boilerplate to nonfatal (will move to > fatal at some point). Bugs filed after manual checks. Yes, there were a huge number of false positives. > >> E: ftp-master: section-is-dh_make-template >> Sections in source packages have minimal impact; the section that matters is >> the one specified in the archive override. There's no reason that the >> invalid default value given by dh_make should result in a package being >> rejected, when arbitrary other values for the field would not. Please drop >> this check. > > We tend to simply reject such packages from NEW. So the maintainer can > see it instantly triggered this way or has to wait until NEW is > processed. I tend to think this way is better. Have not yet gotten around to this one. >> E: ftp-master: executable-in-usr-share-doc >> Clearly a bug, but just as clearly not anything that breaks the package to >> the point of making it unsuitable for the archive. Please drop. > > I do think it should stay out, but fine. Bugs filed. >> E: ftp-master: build-depends-on-essential-package-without-using-version >> E: ftp-master: depends-on-build-essential-package-without-using-version >> E: ftp-master: build-depends-on-build-essential >> E: ftp-master: no-standards-version-field >> E: ftp-master: invalid-standards-version Bugs filed for these. >> E: ftp-master: html-changelog-without-text-version >> E: ftp-master: upstream-version-not-numeric > I dont buy your reasoning *at all*, but until further notice I removed > them. manoj -- Pick another fortune cookie. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Tue, Nov 03 2009, Stefano Zacchiroli wrote: > On Tue, Nov 03, 2009 at 09:30:04AM -0600, Manoj Srivastava wrote: >> > The ideal solution would be to have dak know the previous state and do >> > not accept _regressions_ wrt the previous set of fatal upload errors >> > (according to the proposed wording). I'm not sure it is worth though, >> >> I beg to differ. In the long run, there should not be *any* such >> violations in the archive; so it is not really worth spending time >> writing code for dak that will shortly be a dead path. > > For packages that are now in the archive with lintian errors that would > have prevented them to be uploaded, you're right. However, as a corner > case, you can imagine a new lintian check added 10 years from now, and > that check be used to refuse uploads. All packages upload starting from > now to that moment might be prone to that error. That error would upload > to upload NMUs which do not fix it (but possibly fix other serious > errors). > > This argument is moot only if you assume that we will never add a new > check to the dak black list which has at least one matching package in > the archive. Are you sure that will never be the case? I'm not that > confident. That is not what I meant. I meant that when we do add such a lintian check to the blacklist, we also file serious bugs against those packages in the archive; and aggressively work to either fix the packages, or remove them from the archive. I think our effort should be spent in the fixing/removal, rather than perpetuating buggy packages in the archive. If a package is too buggy to be i Debian, we should not do more work in order for it to remain in. manoj -- How wonderful opera would be if there were no singers. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Tue, Nov 03 2009, Stefano Zacchiroli wrote: > I don't think it is that simple. For once, we need to refine > some of our guidelines (that's the easy part). Devref §5.11.1 authorizes > to upload only changes that fix RC bugs older than X days, so if lintian > is complaining about issues not corresponding to RC bugs (e.g. because > it is a new check in lintian, not yet reported), in theory you shouldn't > upload with specific delays. (As I anticipated, that's the > easy part, just fix the guidelines.) Or recall that guidelines do not trump common sense, and do the only thing that works in this case. > In general though, I wonder whether that would be the right > approach. Why should the NMUer be forced to fix other issues than her > own (RC) itch, considering that other (indubitably grave) issues were in > the archive _before_? Thanks for asking. The solution, past a transition period, is to get these packages fixed or removed from the archive; hence we should be aggressively filing RC bugs on them. > The ideal solution would be to have dak know the previous state and do > not accept _regressions_ wrt the previous set of fatal upload errors > (according to the proposed wording). I'm not sure it is worth though, I beg to differ. In the long run, there should not be *any* such violations in the archive; so it is not really worth spending time writing code for dak that will shortly be a dead path. > maybe Russ' solutions is the one NMUers would implement anyhow and > hence is overkilling to look for something more complicated. > >> This answer is independent of what we decide should go into that set of >> checks. > > ACK. manoj -- My, how you've changed since I've changed. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Mon, Nov 02 2009, Luk Claes wrote: > Exactly, I have only a limited amount of time and don't want to spend it > on demotivating discussions with Manoj about why he uses two standards. > Though just ignoring these is also of no help, so in general I just > point out when he does it (probably not in a very objective way due to > how hard it demotivates me to see people in such positions doing that). If you could actually point out which two standards I am using, it could be somewhat useful. But in this case you were factually incorrect, in others you jump to conclusions and ascribe motivations to me that you make out of whole cloth, and none of that is even remotely helpful. > For the actual matter at hand I think it's very wrong to do a MBF > without going through d-devel for several reasons: > - it gives developers a chance to fix bugs before they are filed to > decrease high bug traffic that is normal for MBFs The same developers who have been ignoring lintian telling them that their packages are buggy for ages? > - it gives developers a chance to discuss the severity and tags that > should be used without the need to change them afterwards There are standard definitions for tags for bugs that are violations of must directives in policy (look at policy and bugs.d.o), as well as packages determined too buggy to be in the archive by folks to are in charge of what goes in the archive. Any opinion contrary to that would not likely have changed my set of bug filings at all. > - it gives developers a chance to change the preconditions for bugs > before they are filed Why was this not done long ago, when lintian has been screaming its little head off? > - it gives developers a chance to share ideas on how to fix the bugs and > include that information in the bug reports They can do so now. It is not as if these bugs did not have a user tag. > - it gives developers a chance to update any relevant documentation > before the bugs are filed Why had this not been done when lintian was warning them about these errors, then? manoj -- Trespassers will be violated! Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
