Re: Forwarding bugs upstream

[Sune Vuorela]

On 2011-01-13, Andreas Tille  wrote:
> In short: The Debian maintainer is responsible that a bug will be
> reported upstream.  I don't see a problem if he delegates the actual
> work to somebody else who is able and willing to do the job (but please
> be nice to the user when asking for this kind of help).  Free software
> lives from cooperation.

Hi Andreas. Would you like to be delegated to help reporting bugs in
packages maintained by Qt/KDE team upstream?

/Sune


-- 
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/slrnij035o.rvp.nos...@sshway.ssh.pusling.com

Re: Forwarding bugs upstream

[Peter Samuelson]

[Jesús M. Navarro]
> > Dear Jesus. Are you seriously saying that
> >  - the kernel mainatiners should step down
> >  - the xorg maintainers should step down
> >  - the mozilla maintainers should step down
> >  - the gnome maintainers should step down
> >  - the kde maintainers should step down
> >  - the xfce maintainers should step down
> >  - the openoffice/libre office maintainers should step down
> 
> If they are not ready to take over their shoulders what it takes to do it 
> properly, undoubtly yes.

> > And who do you think should step up ?
> 
> Not my problem.

I grepped through the Sources file but couldn't find your name
anywhere, as maintainer or comaintainer.  I guess that means when
you say it isn't your problem, you really mean it.

Got any more advice for those of us actually doing the work, while
you're here anyway?
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


-- 
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/20110114093612.gh13...@p12n.org

Re: Forwarding bugs upstream

[Peter Samuelson]

[Jesús M. Navarro]
> If any, bugs you (properly) pass to the upstream developer are bugs
> that will cost you not a dime of your valuable time from them on.

You didn't read the rest of the thread, did you?

> If you understand what I said, good; if you didn't, please, make me
> the honour of considering me as an authority and act accordingly

No.

> If you don't like our parties, you are free not to come here.  In
> other words: if you find Bacula to be too hard a package to deal with
> you are free to orphan it.

Why is it that none of the people who keep calling for everyone to
orphan their packages because they're not taking on enough of what a
maintainer is supposed to do, seem to be stepping up to maintain,
co-maintain, or otherwise help out with these packages that are
apparently so poorly maintained?
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


-- 
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/20110114092957.gg13...@p12n.org

Re: Forwarding bugs upstream

[Andreas Tille]

On Fri, Jan 14, 2011 at 08:43:36AM +, Sune Vuorela wrote:
> On 2011-01-13, Andreas Tille  wrote:
> > In short: The Debian maintainer is responsible that a bug will be
> > reported upstream.  I don't see a problem if he delegates the actual
> > work to somebody else who is able and willing to do the job (but please
> > be nice to the user when asking for this kind of help).  Free software
> > lives from cooperation.
> 
> Hi Andreas. Would you like to be delegated to help reporting bugs in
> packages maintained by Qt/KDE team upstream?

In case this is no intentional missunderstanding of my mail some
additional answer for you:  In case I would report a bug against Qt/KDE
and you consider the problem concerns upstream and you (or somebody who
maintains the Qt/KDE related package in question) think that my
understanding of the problem is deep enough to have some reasonable
conversation with upstream about this topic - yes for sure, I would not
be astonished if you ask me to take over the job of forewarding exactly
this problem.

Kind regards

   Andreas.

-- 
http://fam-tille.de


-- 
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/2011011410.ga17...@an3as.eu

Re: Forwarding bugs upstream

[Jesús M. Navarro]

Hi, Peter:

On Friday 14 January 2011 10:29:57 Peter Samuelson wrote:
> [Jesús M. Navarro]
>
> > If any, bugs you (properly) pass to the upstream developer are bugs
> > that will cost you not a dime of your valuable time from them on.
>
> You didn't read the rest of the thread, did you?

Yes I did.  And I stay with what I said.  It seems that passing info around is 
wasting the maintainer's time because (so I assume, since there's no 
indication implying otherwise) he is just acting as a man-in-the-middle.  
Once he is able to reproduce the bug himself then he is not acting as the 
maintainer in front of the upstream developer but as end user with a bug in 
his hands.  If that's not the case, well, I already stated what should be 
done (basically, close the bug as "non reproducible here").  You did read the 
rest of the thread, did you?

> > If you understand what I said, good; if you didn't, please, make me
> > the honour of considering me as an authority and act accordingly
>
> No.

Whatever.

> > If you don't like our parties, you are free not to come here.  In
> > other words: if you find Bacula to be too hard a package to deal with
> > you are free to orphan it.
>
> Why is it that none of the people who keep calling for everyone to
> orphan their packages because they're not taking on enough of what a
> maintainer is supposed to do, seem to be stepping up to maintain,
> co-maintain, or otherwise help out with these packages that are
> apparently so poorly maintained?

Because, for whatever reason, they (me) are not debian developers, therefore 
they didn't make their issue to maintain, co-maintain or otherwise help out 
with these packages.  Those opting to be or in fact being debian developers 
do it.

That said, asking for help prior to orphan a package its maintainer is not up 
to properly cope with by himself is certainly a valuable option.

Cheers.


--
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/201101141132.48667.jesus.nava...@undominio.net

Re: Forwarding bugs upstream

[Iker Salmón San Millán]

As new (sponsored) mantainer i have a few things to say about this thread.

First of all. If i receive a bug report, i do my best to handle it in the
rigth way, i am in contact with upstream author and fortunately i have no
bugs in my package. I personally don't care to forward bugs to upstream.
But i only mantain one package, and it's very simple to handle it.

But  i am also debian user (looks like some people forgets that DD, DM, and
Contributors are also debian users),  and as a RESPONSIBLE user i also try
to report the bugs i found where they belong.

Someone has said that this is comunity project and colaborate is the only
way to handle it. Yes, BUT, again, some people think that only DD, DM, and
Contributors have to colaborate and not only that, it seems that they are
ONLY there to provide a service to the user.

If this is really a comunity everyone has to do his little effort.  Not only
DD or DM.

I can underestand Jesus in a way, because time ago i received what i think
it was a despective and bad response from a mantainer when i asked some help
to adopt one of his packages.  But I also have received good words and a lot
of help from others (one of them has responsed to this thread).

I used to be a really active member of forums but i get tired because i felt
that users tend to use forums as a Service of attention to the client
instead of a place to exchange knowledge.  I see now that it is not only a
forums issue.


2011/1/14 Sune Vuorela 

>
> Hi Andreas. Would you like to be delegated to help reporting bugs in
> packages maintained by Qt/KDE team upstream?
>
> /Sune
>
>
I would be glad if i could help you in that (or any) way sune.
Unfortunately mi knowledge is not good enough as i would like to,  but
anyway feel free to CC me some bugs and i'll see if i am ready enough to
help in that way.

Iker

Re: Forwarding bugs upstream

[Sune Vuorela]

On 2011-01-14, Iker Salmón San Millán  wrote:
> 2011/1/14 Sune Vuorela 
>
>>
>> Hi Andreas. Would you like to be delegated to help reporting bugs in
>> packages maintained by Qt/KDE team upstream?
>>
>> /Sune
>>
>>
> I would be glad if i could help you in that (or any) way sune.
> Unfortunately mi knowledge is not good enough as i would like to,  but
> anyway feel free to CC me some bugs and i'll see if i am ready enough to
> help in that way.

Any help is most appreciated, especially with handling the bug load. And
it really doesn't require any special skills for most bugs.

We have written a bit about what's needed here:
http://pkg-kde.alioth.debian.org/bugs.html

and feel free to contact me in #debian-qt-kde on irc.debian.org, (but
I'm away for the weekend, so please wait until monday)

/Sune


-- 
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/slrnij0ctm.rvp.nos...@sshway.ssh.pusling.com

Re: network-manager rant

[Josselin Mouette]

Le mercredi 12 janvier 2011 à 20:58 +0200, Anssi Kolehmainen a écrit : 
> My workaround was to purge network-manager and I'm planning to fix this by
> creating a package which Conflicts: network-manager. Maybe you could provide
> this kind of package by default :)

Unless you have more useful suggestions, mine will be to go write your
rants to places nobody will read them.

-- 
 .''`.
: :' : “You would need to ask a lawyer if you don't know
`. `'   that a handshake of course makes a valid contract.”
  `---  J???rg Schilling


--
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/1295004624.7025.42.camel@meh

Re: Forwarding bugs upstream

[Josselin Mouette]

Le jeudi 13 janvier 2011 à 11:54 +0100, Olaf van der Spek a écrit : 
> Instead of stepping down, it might be better to ask for a co-maintainer.

I hereby request a new co-maintainer for the GNOME packages.

-- 
 .''`.
: :' : “You would need to ask a lawyer if you don't know
`. `'   that a handshake of course makes a valid contract.”
  `---  J???rg Schilling


--
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/1295005031.7025.44.camel@meh

Re: Forwarding bugs upstream

[Alexander Reichle-Schmehl]

Hi!

Am 13.01.2011 11:54, schrieb Olaf van der Spek:

>> Now we just need to define what a proper job is.
> Instead of stepping down, it might be better to ask for a co-maintainer.

You mean like this http://www.debian.org/devel/wnpp/help_requested?
Let's have a look:

# chromium-browser [..] requested 228 days ago.
# dpkg [..] requested 2245 days ago.
# grub2 [..] requested 2439 days ago.
# libreoffice [..] requested 1368 days ago.

Any other good ideas?  Perhaps something new ideas, which isn't already
practices?


Best regards,
  Alexander


-- 
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/4d3038d4.50...@schmehl.info

Re: Forwarding bugs upstream

[Olaf van der Spek]

On Fri, Jan 14, 2011 at 12:51 PM, Alexander Reichle-Schmehl
 wrote:
> Hi!
>
> Am 13.01.2011 11:54, schrieb Olaf van der Spek:
>
>>> Now we just need to define what a proper job is.
>> Instead of stepping down, it might be better to ask for a co-maintainer.
>
> You mean like this http://www.debian.org/devel/wnpp/help_requested?
> Let's have a look:
>
> # chromium-browser [..] requested 228 days ago.
> # dpkg [..] requested 2245 days ago.
> # grub2 [..] requested 2439 days ago.
> # libreoffice [..] requested 1368 days ago.
>
> Any other good ideas?  Perhaps something new ideas, which isn't already
> practices?

There are lots of packages with old bugs without any comments that are
not on that list.

Olaf


--
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/aanlktikbtzecpfqqz_0mfgpycxtyq5tnh_i+yycvq...@mail.gmail.com

Re: Forwarding bugs upstream

[Stefano Zacchiroli]

On Fri, Jan 14, 2011 at 11:29:58AM +, Sune Vuorela wrote:
> We have written a bit about what's needed here:
> http://pkg-kde.alioth.debian.org/bugs.html

A while ago I've reviewed a little bit which kind of contributions
distros are looking for, from people who are willing to get involved
with the distro (see #608400 for a corresponding goal).

Most distros are looking for "bug triager" and providing specific
documentation to train contributors in that direction. Historically in
Debian we haven't looked for that, beside the very much understandable
periodic cries for help from maintainers of popular package suites
(GNOME, KDE, etc.).

Maybe its time to generalize that? For instance, it seems to me that
most of the above documentation by the KDE team is general and can be
used to document a general "bug triaging" task on our "how to
contribute" pages? Looking on wiki.d.o and www.d.o we don't seem to have
much (any?) of it.

Would anyone be against inviting explicitly that kind of contributions?

Note: I'm well aware that some contributors are going to make mistakes
and do bad triaging at times, there's now way around that, but I don't
think it's a valid reason not to try.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams


signature.asc
Description: Digital signature

Re: network-manager rant

[Michael Biebl]

On 14.01.2011 12:30, Josselin Mouette wrote:
> Le mercredi 12 janvier 2011 à 20:58 +0200, Anssi Kolehmainen a écrit : 
>> My workaround was to purge network-manager and I'm planning to fix this by
>> creating a package which Conflicts: network-manager. Maybe you could provide
>> this kind of package by default :)
> 
> Unless you have more useful suggestions, mine will be to go write your
> rants to places nobody will read them.

Usually, I don't read emails which have "rant" in their topic.

That said, I contacted Anssi privately and after some debugging the problem was
quickly found, resulting in #609831, which is easy to fix.

Next time I hope, Anssi consider filing a bug report as a first step.


Cheers,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Help!

[Cyril Brulebois]

Olaf van der Spek  (14/01/2011):
> There are lots of packages with old bugs without any comments that
> are not on that list.

Oh, indeed! Crap! I hereby request help for the 167 following
packages:

ccsm
compiz
compizconfig-backend-gconf
compizconfig-backend-kconfig
compizconfig-python
compiz-fusion-plugins-extra
compiz-fusion-plugins-main
compiz-fusion-plugins-unsupported
grandr
libcompizconfig
libdmx
libdrm
libfontenc
libfs
libice
libpciaccess
libsm
libx11
libxau
libxaw
libxcomposite
libxcursor
libxdamage
libxdmcp
libxext
libxfixes
libxfont
libxfontp
libxi
libxinerama
libxkbfile
libxmu
libxp
libxpm
libxprintapputil
libxprintutil
libxrandr
libxrender
libxres
libxss
libxt
libxtst
libxv
libxvmc
libxxf86dga
libxxf86vm
mesa
mesa-demos
pixman
twm
x11-apps
x11proto-bigreqs
x11proto-composite
x11proto-core
x11proto-damage
x11proto-dmx
x11proto-dri2
x11proto-fixes
x11proto-fonts
x11proto-gl
x11proto-input
x11proto-kb
x11proto-print
x11proto-randr
x11proto-record
x11proto-render
x11proto-resource
x11proto-scrnsaver
x11proto-video
x11proto-xcmisc
x11proto-xext
x11proto-xf86bigfont
x11proto-xf86dga
x11proto-xf86dri
x11proto-xf86misc
x11proto-xf86vidmode
x11proto-xinerama
x11-session-utils
x11-utils
x11-xfs-utils
x11-xkb-utils
x11-xserver-utils
xauth
xbacklight
xbitmaps
xcursor-themes
xdm
xf86-input-evtouch
xfonts-100dpi
xfonts-75dpi
xfonts-base
xfonts-cyrillic
xfonts-encodings
xfonts-scalable
xfonts-utils
xft
xinit
xkeyboard-config
xorg
xorg-docs
xorg-server
xorg-sgml-doctools
xprint
xprint-utils
xresprobe
xserver-xorg-input-acecad
xserver-xorg-input-aiptek
xserver-xorg-input-citron
xserver-xorg-input-elographics
xserver-xorg-input-evdev
xserver-xorg-input-fpit
xserver-xorg-input-hyperpen
xserver-xorg-input-joystick
xserver-xorg-input-keyboard
xserver-xorg-input-mouse
xserver-xorg-input-mutouch
xserver-xorg-input-penmount
xserver-xorg-input-synaptics
xserver-xorg-input-vmmouse
xserver-xorg-input-void
xserver-xorg-video-apm
xserver-xorg-video-ark
xserver-xorg-video-ati
xserver-xorg-video-chips
xserver-xorg-video-cirrus
xserver-xorg-video-dummy
xserver-xorg-video-fbdev
xserver-xorg-video-glide
xserver-xorg-video-glint
xserver-xorg-video-i128
xserver-xorg-video-i740
xserver-xorg-video-intel
xserver-xorg-video-ivtvdev
xserver-xorg-video-mach64
xserver-xorg-video-mga
xserver-xorg-video-neomagic
xserver-xorg-video-newport
xserver-xorg-video-nouveau
xserver-xorg-video-nv
xserver-xorg-video-openchrome
xserver-xorg-video-qxl
xserver-xorg-video-r128
xserver-xorg-video-radeonhd
xserver-xorg-video-rendition
xserver-xorg-video-s3
xserver-xorg-video-s3virge
xserver-xorg-video-savage
xserver-xorg-video-siliconmotion
xserver-xorg-video-sis
xserver-xorg-video-sisusb
xserver-xorg-video-suncg14
xserver-xorg-video-suncg3
xserver-xorg-video-suncg6
xserver-xorg-video-sunffb
xserver-xorg-video-sunleo
xserver-xorg-video-suntcx
xserver-xorg-video-tdfx
xserver-xorg-video-tga
xserver-xorg-video-trident
xserver-xorg-video-tseng
xserver-xorg-video-v4l
xserver-xorg-video-vesa
xserver-xorg-video-vmware
xserver-xorg-video-voodoo
xterm
xtrans
xutils-dev

KiBi.


signature.asc
Description: Digital signature

Re: Forwarding bugs upstream

[Felipe Sateler]

On Thu, 13 Jan 2011 00:38:37 +, Ian Jackson wrote:

> Felipe Sateler writes ("Re: Forwarding bugs upstream"):
>> On Wed, 12 Jan 2011 16:56:56 +, Ian Jackson wrote:
>> > I think it is always reasonable for the maintainer to forward the bug
>> > upstream.
>> > 
>> > But what I think is bad is _demanding_ or _requiring_ the maintainer
>> > to forward the bug upstream.  If they don't want to do that for
>> > whatever reason then asking the submitter to do so is IMO perfectly
>> > acceptable.
>> 
>> We can't demand or require anyone to do anything. Yet we expect
>> maintainers to answer bug reports, provide packages, etc. The fact that
>> you can't force anyone to do anything doesn't mean you can't say that
>> some behavior is preferred or considered best practice.
> 
> Yes.
> 
> But in this case I don't think we should be "expecting" maintainers to
> necessarily shepherd bug reports upstream.  I don't think a maintainer
> who fails to do so is failing in their job as maintainer.
> 
> The maintainer should decide whether they think doing that is a useful
> thing to be doing for that package or that bug, and communicate this
> decision to the user (and set the bug state accordingly).

Just like they do about their whole debian work: prioritizing work and 
their own free time.

My point is more along the lines of Bernhard's comment: packages where 
the maintainer takes (well-defined) reports upstream are better 
maintained than packages where the maintainer does no such thing.

Going back to the OP's comment, when one takes the time to fill a well-
described report, maybe even write a patch for it, the maintainer should 
(again, time permitting) forward the request upstream. I do not think it 
is reasonable to expect every bug reporter to register in upstream's bug 
tracker (unfortunately, a big bunch of upstreams require registration, 
even for their mailing lists!), specially when the maintainer should have 
already an account.


-- 
Saludos,
Felipe Sateler


-- 
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/igpja8$inb$1...@dough.gmane.org

Re: DEP5 CANDIDATE parser/editor/validator/migrator is released in libconfig-model-perl

[Dominique Dumont]

On Thursday 13 January 2011 22:27:02 Joey Hess wrote:
> Thanks for your work, here are a few things I stumbled on.

Thanks for trying and reporting issues :-)

> Worst problem: -save *removes* all Comment fields except for one
> in the header section.

Looks like I messed up the routine that transform a file written with dpkg 
syntax into a data structure (list of list). I'm working on it.

> Also, -save converted in the header "Disclaimer:\n Foo" into "Disclaimer:
> Foo". If I'm reading DEP-5 right, that's not correct, the Disclaimer is
> not supposed to have a synopsis. That is also done for a Comment field in
> the header section.
>
> Also, note that "Comment: foo" is not flagged as a problem (despite
> being apparently illegal -- DEP-5 puzzlingly does not allow a comment
> to have a synopsis).

Now that I have finally understood this notion of synopsis, I can fix these 
issues.

> With -save, two trailing license blocks with identical content got
> reordered, which was surprising. 

Licences sections are written back using an alphabetical sort of the short 
licence names.

> (I dislike that DEP-5 seems to require
> I duplicate content here; I considered making the second block say "See
> above", but it seems likely it could be presented out of order by some
> future tool.)

Actually, the full text of GPL-2 and GPL-2+ should be slightly different. The 
latter should mention something like "version 2 or above". From a legal point 
of view, I guess that point should be spelled out explicitly and not only 
implied by the "+" at the end of the short name. 

But this point is more Lars' territory than mine ;-)

> The following seemed to be caused by a Comment field at the end of a
> section. I had to move it to above the License field.

That was a bug in dpkg parser. This is fixed now (well, on my laptop...)

> Missing 'Files:' specification at top of section number 4. Adding 'Files:
> *' spec Configuration item 'Files:* License short_name' has a wrong value:
> license other is not declared in main Licence section. Expected GPL-2
> GPL-2+ zsh: exit 25config-edit -application dpkg-copyright -ui none
> -save

Since the license short names are a fuzzy moving target, I'm more and more 
tempted to drop the warning in case of unknown keyword. 

> Unfortunatly I didn't preserve the input that caused this crash:
> 
> joey@gnu:~/src/moreutils>config-edit -application dpkg-copyright -ui none
> You should install Config::Model::TkUI or Config::Model::CursesUI for a
> more friendly user interface Can't call method "fetch_element" on an
> undefined value at
> /usr/share/perl5/Config/Model/Backend/Debian/Dpkg/Copyright.pm line 111.

This is probably due to the dpkg parser problem. We'll see if this problem 
happens again. 

All the best

Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/


-- 
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/201101141417.44636.d...@komarr.gre.hp.com

Re: Forwarding bugs upstream

[Felipe Sateler]

On Thu, 13 Jan 2011 10:27:12 +, Sune Vuorela wrote:

> On 2011-01-13, Felipe Sateler  wrote:
>> We can't demand or require anyone to do anything. Yet we expect
> 
> I think this is mostly wrong.
> 
> We can demand or require people to step down. And we should if we don't
> think they do a proper job.

I don't agree. First of all, we don't require people to step down, we 
hijack their packages (which means we force them to not do something). 
Second, we do that not when they are not doing a proper job, but when 
they actually block others from doing the proper job.


-- 
Saludos,
Felipe Sateler


-- 
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/igpk3k$inb$2...@dough.gmane.org

Re: DEP5 CANDIDATE parser/editor/validator/migrator is released in libconfig-model-perl

[Dominique Dumont]

On Thursday 13 January 2011 22:48:48 Joey Hess wrote:
> Also, it's missing BSD-2-clause etc.

ok. Fixed. Unless I remove all these license keyword check... Still thinking 
...

> The original format from the wiki page uses comma to separate
> Files. Might be worth detecting and converting those?

Done.

All the best

Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/


-- 
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/201101141436.55511.d...@komarr.gre.hp.com

Re: Forwarding bugs upstream

[Lisandro Damián Nicanor Pérez Meyer]

On Fri, Jan 14, 2011 at 9:27 AM, Stefano Zacchiroli  wrote:
> On Fri, Jan 14, 2011 at 11:29:58AM +, Sune Vuorela wrote:
>> We have written a bit about what's needed here:
>> http://pkg-kde.alioth.debian.org/bugs.html
>
> A while ago I've reviewed a little bit which kind of contributions
> distros are looking for, from people who are willing to get involved
> with the distro (see #608400 for a corresponding goal).
>
> Most distros are looking for "bug triager" and providing specific
> documentation to train contributors in that direction. Historically in
> Debian we haven't looked for that, beside the very much understandable
> periodic cries for help from maintainers of popular package suites
> (GNOME, KDE, etc.).
>
> Maybe its time to generalize that? For instance, it seems to me that
> most of the above documentation by the KDE team is general and can be
> used to document a general "bug triaging" task on our "how to
> contribute" pages? Looking on wiki.d.o and www.d.o we don't seem to have
> much (any?) of it.

If it's worth anything, that same document + the help from the Qt/KDE
team helped me a lot to understand the workflow for bug triaging.
Understanding the technical part was not difficult, but the workflow
tends to be the the most obscure part.

+1 for a general doc for that.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


--
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/AANLkTikoCgu1-PPnmTYGz+Jh0TsU-g9=wej4zxie4...@mail.gmail.com

Re: network-manager rant

[Gunnar Wolf]

Michael Biebl dijo [Fri, Jan 14, 2011 at 01:34:45PM +0100]:
> >> My workaround was to purge network-manager and I'm planning to fix this by
> >> creating a package which Conflicts: network-manager. Maybe you could 
> >> provide
> >> this kind of package by default :)
> > 
> > Unless you have more useful suggestions, mine will be to go write your
> > rants to places nobody will read them.
> 
> Usually, I don't read emails which have "rant" in their topic.
> 
> That said, I contacted Anssi privately and after some debugging the problem 
> was
> quickly found, resulting in #609831, which is easy to fix.
> 
> Next time I hope, Anssi consider filing a bug report as a first step.

But even if this is not the right place for bug reports, our users
might not know it. Yes, Anssi's message was not in the best tone - But
the right answer would be to direct him to the right place
(submit@bugs.d.o) _without_insulting_him_.

Please, lets all try to keep d-devel civil.


-- 
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/20110114152424.gc7...@gwolf.org

Re: Forwarding bugs upstream

[Gunnar Wolf]

John Goerzen dijo [Thu, Jan 13, 2011 at 05:08:26PM -0600]:
> So let's run out your scenario a bit: upstream asks user to test with  
> upstream version X.  Bug isn't reproducible by maintainer.  Does the  
> maintainer now have to provide user with binaries?  This gets  
> complicated when packaging isn't ready for the version in question, when  
> the user has an arch the maintainer doesn't, etc.

Often, users with not-so-mainstream architectures will have better
technical understanding and more ability to help following up a
report. 


-- 
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/20110114152919.ga7...@gwolf.org

Re: Forwarding bugs upstream

[John Goerzen]

On 01/13/2011 06:19 PM, Jesús M. Navarro wrote:

Hi, Sune:

On Thursday 13 January 2011 00:12:06 Sune Vuorela wrote:

On 2011-01-12, Jesús M. Navarro  wrote:

I have considered to take this one step further. Close bugs reported in
Debian BTS with a severity of important or less that is a bug that
should primarily be fixed upstream.


Will this mean that the problem will somehow disappear from Debian?
Because if it's a problem detected within Debian it's my feeling that it
will have to be tracked within Debian till the problem is in Debian no
more.


No. but it is a way to be honest about teh issue: We are not spending
debian time on fixing it.


Then tag is as such.  It is quite good to be honest: if you are not going to
deal with it, plainly say so, no problem.  But *don't* close them as long as
the problem is still there.


I think it is a huge waste of time to expect DDs to go through 400 bugs 
just to see if the problem is still there.  Just close them outright.


It is no better to have bugs tagged wontfix that are really fixed than 
to have bugs closed in our BTS and filed upstream.


- John


--
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/4d30707e.1040...@complete.org

Re: DEP5 CANDIDATE parser/editor/validator/migrator is released in libconfig-model-perl

[Joey Hess]

Dominique Dumont wrote:
> > Also, note that "Comment: foo" is not flagged as a problem (despite
> > being apparently illegal -- DEP-5 puzzlingly does not allow a comment
> > to have a synopsis).
> 
> Now that I have finally understood this notion of synopsis, I can fix these 
> issues.

I probably misread DEP5 -- when it says "formatted text, no synopsis",
it probably means that the entire field including the first line
is treated as one thing. So both "Comment: foo\n" and "Comment:\n foo\n" are
the same value.

FWIW, I think that its complex set of fields that all have different
encoding rules is a weakness of DEP5. I basically have to rely on
your tool to make sure that I keep all of these cases straight:

- 4 pure RFC822 fields (just a blob of text, possibly spread over multilines)
- 3 fields that use the synopsis as the first line of a multiline list
- 2 fields that can only use a synopsis, no extended text
  (sort of a degnerate case of pure RFC822 fields, where the field value cannot
  contain whitespace)
- 1 field that uses the synopsis for one thing, followed by extended text
  for another thing

We earlier perverted RFC822 in control files with the adoption of
synopsis+extended for Description, and single-line Depends fields. Depends
field parsing has since been fixed to allow multi-line wrapped fields,
only in time for things to be taken much further by this.
 
-- 
see shy jo, who still prefers this to XML.. just.


signature.asc
Description: Digital signature

Why is help so hard to find?

[Mike Bird]

On Fri January 14 2011 03:51:48 Alexander Reichle-Schmehl wrote:
> Am 13.01.2011 11:54, schrieb Olaf van der Spek:
> > Instead of stepping down, it might be better to ask for a co-maintainer.
>
> You mean like this http://www.debian.org/devel/wnpp/help_requested?
> Let's have a look:
>
> # chromium-browser [..] requested 228 days ago.
> # dpkg [..] requested 2245 days ago.
> # grub2 [..] requested 2439 days ago.
> # libreoffice [..] requested 1368 days ago.
>
> Any other good ideas?  Perhaps something new ideas, which isn't already
> practices?

On occasion when I've found a kernel bug or gcc bug or perl
bug, or wanted to add a new feature to inn, I've been able
to scratch my itch immediately.

The impression I get of Debian is that in order to contribute
I need to spend a year or so humoring somebody with a tenth my
programming experience.

If that impression is wrong, I'd really like to fix at least
two major bugs in Squeeze:

(1) sysv-rc upgrade should not bring in insserv and wreck
startup on systems more complicated than a basic laptops,
without adequate warning, and "irreversibly".  (Note that due
to ass-backward design, restoring /etc does not prevent insserv
from wreaking havoc again.  You have to also
"touch /etc/init.d/.legacy-bootordering".)

(2) KDE4 is not an upgrade from KDE3.  It is despicable to
push KDE4 onto KDE3 users.  The correct upgrade path is
Trinity.  Not only is Trinity a continuation of KDE3, unlike
KDE4, but it is also far more stable and reliable.  Debian's
KDE maintainers can't even keep up with the torrent of KDE4
bugs now, and that will increase enormously when Squeeze is
released.  Last time I checked, and also six months ago, KDE4
doesn't even create a working KMail account due to missing
MySQL dependencies.  If people want to install a kde4 package
in Squeeze that should be permitted if Debian's KDE maintainers
are willing to support it, but the correct upgrade path from
Lenny's kde is Trinity, not KDE4.  (Thank you to Debian's KDE
maintainers for getting this right for Lenny.)

Note that we're not talking coding errors here.  We're talking
about abuse of the Debian packaging system so that people can
push their favorite software at the expense of Debian's users.

Apart from the above, Squeeze is looking to be another excellent
Debian release.

--Mike Bird


-- 
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/201101141011.51907.mgb-deb...@yosemite.net

binNMU for Arch: all packages.

[Marco Silva]

Hi.

In the Debian Haskell Group we are with the following problem.  When the
compiler (ghc) is updated, we binNMU all the stack of libraries to make them
compiled with the new compiler.  Each library has the documentation in a -doc
package, which is Arch: all.  This documentation is generated automatically
from the source code, using a documentation generator called haddock.  Haddock
is part of the compiler and is also updated when the ghc is.  It would be
good to regenerate the documentation for each library too, when a new ghc
arrives.

This seems to be a use case for binNMUs in Arch: all packages.  Is there any
reason for why it's not possible to binNMU Arch: all packages?  Do you have a
suggestion of procedure that would solve this problem?

Note that compiler updates is not such a rarely thing, and that the stack
contains about 200 packages now.

Thanks in advance.
-- 
marcot
http://marcot.eti.br/
[Flattr=54498]


signature.asc
Description: PGP signature

Bug#610009: ITP: xboxdrv -- A Xbox360 gamepad driver for the userspace

[Andrey Rahmatullin]

Package: wnpp
Severity: wishlist
Owner: Andrey Rahmatullin 

* Package name: xboxdrv
  Version : 0.6.4
  Upstream Author : Ingo Ruhnke 
* URL : http://pingus.seul.org/~grumbel/xboxdrv/
* License : GPL3+
  Programming Lang: C++
  Description : A Xbox360 gamepad driver for the userspace



-- 
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/20110114203651.9773.99893.report...@belkar.wrar.name

Re: binNMU for Arch: all packages.

[Yves-Alexis Perez]

On ven., 2011-01-14 at 18:05 -0200, Marco Silva wrote:
> This documentation is generated automatically
> from the source code, using a documentation generator called haddock.  Haddock
> is part of the compiler and is also updated when the ghc is.  It would be
> good to regenerate the documentation for each library too, when a new ghc
> arrives. 

I don't really know anything about haskell, but is it really needed to
regenerate library docs each time the compiler is updated? What does it
give?
-- 
Yves-Alexis


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

Re: Why is help so hard to find?

[Ben Hutchings]

On Fri, Jan 14, 2011 at 10:11:51AM -0800, Mike Bird wrote:
> On Fri January 14 2011 03:51:48 Alexander Reichle-Schmehl wrote:
> > Am 13.01.2011 11:54, schrieb Olaf van der Spek:
> > > Instead of stepping down, it might be better to ask for a co-maintainer.
> >
> > You mean like this http://www.debian.org/devel/wnpp/help_requested?
> > Let's have a look:
> >
> > # chromium-browser [..] requested 228 days ago.
> > # dpkg [..] requested 2245 days ago.
> > # grub2 [..] requested 2439 days ago.
> > # libreoffice [..] requested 1368 days ago.
> >
> > Any other good ideas?  Perhaps something new ideas, which isn't already
> > practices?
> 
> On occasion when I've found a kernel bug or gcc bug or perl
> bug, or wanted to add a new feature to inn, I've been able
> to scratch my itch immediately.
> 
> The impression I get of Debian is that in order to contribute
> I need to spend a year or so humoring somebody with a tenth my
> programming experience.
 
Debian maintainers are not necessarily master programmers, but they
will generally have more experience of packaging and bug triage than
you.  These are very different skills.

> If that impression is wrong, I'd really like to fix at least
> two major bugs in Squeeze:
> 
> (1) sysv-rc upgrade should not bring in insserv and wreck
> startup on systems more complicated than a basic laptops,

This is an exaggeration.

> without adequate warning, and "irreversibly".  (Note that due
> to ass-backward design, restoring /etc does not prevent insserv
> from wreaking havoc again.  You have to also
> "touch /etc/init.d/.legacy-bootordering".)

So, a *critical* priority debconf question is not enough control
for you?

> (2) KDE4 is not an upgrade from KDE3.  It is despicable to
> push KDE4 onto KDE3 users.  The correct upgrade path is
> Trinity.
[...]

Strange, I can't find your ITP for Trinity.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/20110114214412.gb3...@decadent.org.uk

Re: Why is help so hard to find?

[Mike Bird]

On Fri January 14 2011 13:44:12 Ben Hutchings wrote:
> On Fri, Jan 14, 2011 at 10:11:51AM -0800, Mike Bird wrote:
> > The impression I get of Debian is that in order to contribute
> > I need to spend a year or so humoring somebody with a tenth my
> > programming experience.

> > (1) sysv-rc upgrade should not bring in insserv and wreck
> > startup on systems more complicated than a basic laptops,
>
> This is an exaggeration.

How many systems with complex interelated services have you tested?
Why didn't your testing pick up on the problem with request-tracker
and Apache?  Or the problem with Apache and bind?

You have no idea what configurations are in use on stable servers.

You have no idea how many stable servers you're going to break.

> > without adequate warning, and "irreversibly".  (Note that due
> > to ass-backward design, restoring /etc does not prevent insserv
> > from wreaking havoc again.  You have to also
> > "touch /etc/init.d/.legacy-bootordering".)
>
> So, a *critical* priority debconf question is not enough control
> for you?

No.  It does not warn that years of work by Debian Developers is
to be thrown away, and without documentation on how to recover (a
restore of /etc doesn't fix it).  The question says only:

 The boot system is prepared to migrate to dependency-based sequencing.
 This is an irreversible step, but one that is recommended: it allows
 the boot process to be optimized for speed and efficiency, and provides
 a more resilient framework for development.
 .
 A full rationale is detailed in /usr/share/doc/sysv-rc/README.Debian.
 If you choose not to migrate now, you can do so later by running
 "dpkg-reconfigure sysv-rc".

There is nothing there about the very serious problems caused by
insserv.

No sane person could possible "recommend" insserv for a server.  One
second a year saved in reboot versus hours or days repairing damage.

> > (2) KDE4 is not an upgrade from KDE3.  It is despicable to
> > push KDE4 onto KDE3 users.  The correct upgrade path is
> > Trinity.
>
> [...]
>
> Strange, I can't find your ITP for Trinity.

See my first paragraph.

Fortunately, it's very easy add Trinity to sources.list.  There are a
couple of minor issues which I'm discussing with Tim but overall it's
a thousand percent more stable and user-friendly than KDE 4.

--Mike Bird


-- 
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/201101141501.22431.mgb-deb...@yosemite.net

Re: Why is help so hard to find?

[Stephen Gran]

This one time, at band camp, Ben Hutchings said:
> Strange, I can't find your ITP for Trinity.

That's because he trolls without ever actually doing anything.  Don't
feed the waste of time.

Cheers,
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :sg...@debian.org |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Forwarding bugs upstream

[Jesús M. Navarro]

Hi, John:

On Friday 14 January 2011 16:49:18 John Goerzen wrote:
[...]

> I think it is a huge waste of time to expect DDs to go through 400 bugs
> just to see if the problem is still there.  Just close them outright.

Why the package(s) got 400 bugs to start with?  If the problem is there, then 
it's there.  If somebody opened the bug then there was a bug at least on his 
opinion which nobody challenged.  If there was a bug, then it need to be 
supposed that it will be there till there exists clear indication on the 
contrary.  Anything else is awful practice.

> It is no better to have bugs tagged wontfix that are really fixed than
> to have bugs closed in our BTS and filed upstream.

It's no better?  It's probably orders of magnitude better (basically as the 
ratio between Debian users versus Debian developers).

What are the chances of me looking for info about a bug I'm not suffering 
(because it's already fixed)?  I'd bet nil, so that's the effect of a still 
opened -but already corrected bug.

But if I'm suffering a bug and it's already declared on Debian's bug database 
I want to know and it'll save not only my time but that of any other people 
that will certainly suffer it if I know what to expect about it.  Even you, 
as a Debian developer want to avoid me and others like me to open duplicate 
bugs.

Cheers.


-- 
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/201101150040.39563.jesus.nava...@undominio.net

Re: Why is help so hard to find?

[Roger Leigh]

On Fri, Jan 14, 2011 at 09:44:12PM +, Ben Hutchings wrote:
> On Fri, Jan 14, 2011 at 10:11:51AM -0800, Mike Bird wrote:
> > If that impression is wrong, I'd really like to fix at least
> > two major bugs in Squeeze:
> > 
> > (1) sysv-rc upgrade should not bring in insserv and wreck
> > startup on systems more complicated than a basic laptops,
> 
> This is an exaggeration.

I've yet to find a single system which upgraded to insserv cleanly.
This is mostly due to removed packages which need fully purging to
remove the last traces of old init scripts which break the process.

I'm not sure that there's a great deal that can be done to mitigate
this without user intervention, but IMHO this one is a real concern
since it makes it virtually impossible to upgrade without having a
manual purge of all deinstalled packages with conffiles remaining.
This has proven to be the case on every system I've migrated so far,
and it is a real pain to identify each offending script and then
find which package it belonged to and purge it.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: Forwarding bugs upstream

[Russ Allbery]

"Jesús M. Navarro"  writes:

> Why the package(s) got 400 bugs to start with?  If the problem is there,
> then it's there.  If somebody opened the bug then there was a bug at
> least on his opinion which nobody challenged.  If there was a bug, then
> it need to be supposed that it will be there till there exists clear
> indication on the contrary.  Anything else is awful practice.

I would argue that by the time the package reaches several thousand open
bugs, all of which are some random mix of upstream, fixed, unreproducible,
packaging, and incomplete reports, the BTS has become essentially unusable
for everyone.  The maintainers rarely have time to go back and look at
those thousands of bugs in any meaningful way, and users are not going to
be able to reasonably search through that many bugs to see if any of them
are the problem that they're running into.  At that point, the BTS is
about as useful as a mailing list archive and the only chance that
anything in there is going to be helpful is if Google happens to index it.

In my personal experience, generally at that point the mailing list
archive of wherever the bugs were originally sent is actually *more*
useful since it's better-indexed.

I think we have a significant failure mode here with packages that get
large numbers of bugs.  The BTS becomes pretty much unusable without very
active triaging for those packages.  And this is not a Debian-specific
problem; for example, it's essentially impossible to extract any useful
information from the Ubuntu nvidia-graphics-drivers bug page, and it only
has 350 bugs.  (Launchpad is, in my experience, worse than the Debian BTS
at handling large bug volumes and becomes unusable faster.)

There are a lot of things that have been said on this thread that I
completely agree with for the average Debian package that gets a handful
of bugs a month and doesn't have more than 50-100 bugs open at a time.  I
think most of the people commenting here have dealt primarily with those
sorts of packages, and that's the experience in which the comments are
grounded.

Packages with thousands of bugs are another world, and while I agree with
the drawbacks of aggressive bug triaging, I think aggressive bug triaging
is still a better approach than letting the BTS page become a junk pile of
abandoned reports no one is ever going to look at again.

Obviously, the ideal is to have teams that scale with the incoming bug
count for the package, who will stay on top of all those bugs and
categorize them appropriately and ping unreproducible bugs, forward
upstream bugs, and do all the great things that make the world a better
place.  But in the world in which we live, that manpower simply doesn't
exist.  If wishes were horses, beggars would ride.  We have to apply
strategies that are realistic given the manpower that we actually have,
not the manpower that we wish we had.

-- 
Russ Allbery (r...@debian.org)   


--
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/87vd1rt4i0@windlord.stanford.edu

Re: Why is help so hard to find?

[Russ Allbery]

Roger Leigh  writes:

> I've yet to find a single system which upgraded to insserv cleanly.
> This is mostly due to removed packages which need fully purging to
> remove the last traces of old init scripts which break the process.

Huh.  Every system I've upgraded had no problems.  What is the failure
mode?  What happens on those systems?

> This has proven to be the case on every system I've migrated so far, and
> it is a real pain to identify each offending script and then find which
> package it belonged to and purge it.

dpkg -S would generally tell you, no?  We could document how to do that in
the release notes.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87oc7jt4f5@windlord.stanford.edu

Re: Why is help so hard to find?

[Mike Bird]

On Fri January 14 2011 15:08:13 Stephen Gran wrote:
> This one time, at band camp, Ben Hutchings said:
> > Strange, I can't find your ITP for Trinity.
>
> That's because he trolls without ever actually doing anything.  Don't
> feed the waste of time.

The problem is not a lack of ITP.  Lenny already has KDE 3.5.

The problem is that KDE 4 is hijacking the kde package
name from KDE 3.5 and kicking KDE 3.5 out of Debian.

KDE 4 exists in Lenny as kde4.  It should remain kde4.

There is absolutely no legitimate reason for KDE 4 to kick
KDE 3.5 out.  KDE 3.5 and KDE 4 co-existed just fine in Lenny. 
KDE 3.5 has upstream support, an excellent code base, a stable
and well-loved product, and far far fewer bugs than KDE 4.

Kicking KDE 3.5 out of Debian is a grave disservice to
loyal Debian users.

--Mike Bird


-- 
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/201101141615.13128.mgb-deb...@yosemite.net

Re: Why is help so hard to find?

[Mike Bird]

On Fri January 14 2011 16:07:58 Russ Allbery wrote:
> Roger Leigh  writes:
> > I've yet to find a single system which upgraded to insserv cleanly.
> > This is mostly due to removed packages which need fully purging to
> > remove the last traces of old init scripts which break the process.
>
> Huh.  Every system I've upgraded had no problems.  What is the failure
> mode?  What happens on those systems?

FWIW, roughly one third of our test systems "failed to upgrade" for this
reason.  It's not really a failure.  sysv-rc.postinst simply says

 Tests have determined that problems in the boot system exist which
 prevent migration to dependency-based boot sequencing:
 .
 ${PROBLEMATIC}
 .
 If the reported problem is a local modification, it needs to be fixed
 manually. If it's a bug in the package, it should be reported to the
 BTS and fixed in the package. See
 http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot for more
 information about how to fix the problems preventing migration.
 .
 To reattempt the migration process after the problems have been
 fixed, run "dpkg-reconfigure sysv-rc".

We regard those systems as the lucky ones as they kept the reliable
legacy boot mechanism.

--Mike Bird


-- 
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/201101141621.13380.mgb-deb...@yosemite.net

Re: binNMU for Arch: all packages.

[Marco Túlio Gontijo e Silva]

Hi Yves-Alexis.

Excerpts from Yves-Alexis Perez's message of Sex Jan 14 19:22:31 -0200 2011:
> On ven., 2011-01-14 at 18:05 -0200, Marco Silva wrote:
> > This documentation is generated automatically
> > from the source code, using a documentation generator called haddock.  
> > Haddock
> > is part of the compiler and is also updated when the ghc is.  It would be
> > good to regenerate the documentation for each library too, when a new ghc
> > arrives. 
> 
> I don't really know anything about haskell, but is it really needed to
> regenerate library docs each time the compiler is updated?

Yes, in the current scheme, unfortunately it is.

> What does it give?

There are two issues.  The first one is related to the indexer.  Whenever a new
haskell package is installed, there's a code that includes the modules that it
export in the main index of the documentation.  If the version of haddock
installed is different from the version of haddock that produced the
documentation being installed, it won't show this package in the main index.
This happens because when the compiler is updated, the representation of the
Haskell code changes, and this affects haddock.

It is possible to deal with this issue by changing the way the index is
generated.  But the other issue is that sometimes the haddock version changes
during compiler updates, and the documentation produced change very much.  For
instance, [0] was the documentation produced in ghc-6.12.3, and [1] is the
documentation produced in ghc-7.0.1.  I believe it's better for the user to
have access to all features and bug fixes of newer haddock, instead of sticking
with older haddock versions to avoid recompilation.

Currently, we move the .haddock file to -dev packages (which are Arch: any) in
order to avoid the first issue.  This causes [2].  Also, it makes the whole
documentation be generated when a -dev package is built, so it's already
generated in all arches, only ignored.

The best option to fix this issue I can see is if it was possible to do binNMUs
for Arch: all packages.  There are some options to workaround the fact that we
can't binNMUs Arch: all packages, which are: change the -doc package to Arch:
any; do sourceful uploads instead of binNMUs.  Both options are not ideal, but
I prefer the first, because sourceful uploads for a 200 package stack would
need a lot of work.

I talked about this issue on #debian-devel and mrvn asked me to change the
wanna-build / buildd / sbuild interface to accept this.  Well, I have no idea
about how to do it, since I've never worked on these packages, but if this is
something the developers of these package are willing to accept, I could help
on the implementation.

Thanks for your answer.

0: http://haskell.org/ghc/docs/6.12.3/html/libraries/index.html
1: http://haskell.org/ghc/docs/7.0.1/html/libraries/index.html
2: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586723
-- 
marcot
http://marcot.eti.br/
[Flattr=54498]


signature.asc
Description: PGP signature

Re: Why is help so hard to find?

[Roger Leigh]

On Fri, Jan 14, 2011 at 04:07:58PM -0800, Russ Allbery wrote:
> Roger Leigh  writes:
> 
> > I've yet to find a single system which upgraded to insserv cleanly.
> > This is mostly due to removed packages which need fully purging to
> > remove the last traces of old init scripts which break the process.
> 
> Huh.  Every system I've upgraded had no problems.  What is the failure
> mode?  What happens on those systems?

Like Mike said in his reply, sysv-rc fails to configure fully due to
the presence of init scripts incompatible with insserv.  It refuses
to complete until they are gone.  You can live with this, but it's not
ideal.

> > This has proven to be the case on every system I've migrated so far, and
> > it is a real pain to identify each offending script and then find which
> > package it belonged to and purge it.
> 
> dpkg -S would generally tell you, no?  We could document how to do that in
> the release notes.

Yes, and this is what I did.  It's just rather tedious to (IIRC)
repeatedly run "dpkg-reconfigure sysv-rc" and then find out which file
is offending, run "dpkg -S $file", and then purge it.  Because the error
message only lists the first offending file, rather than listing them
all, you then need to repeat this until you've weeded out all the files
one by one until eventually it succeeds.

It would be better if an upgrade was possible without all this manual
work.  It's been tedious for the handful of systems I've done this on
so far; I wouldn't like to need to do it for many more.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: Why is help so hard to find?

[Russ Allbery]

Roger Leigh  writes:

> Yes, and this is what I did.  It's just rather tedious to (IIRC)
> repeatedly run "dpkg-reconfigure sysv-rc" and then find out which file
> is offending, run "dpkg -S $file", and then purge it.

I've not looked at the mechanism involved at all, but it does seem like we
should be able to print out all of the files that would cause failures.
Maybe it's hard to continue from an error long enough to find additional
files?

That sounds like it's the thing that makes this the most tedious.  If you
got a list of all offending init scripts, we could document in the release
notes that you need to run dpkg -S on each one to locate the relevant
package and purge that package if you're no longer using it.

> It would be better if an upgrade was possible without all this manual
> work.  It's been tedious for the handful of systems I've done this on so
> far; I wouldn't like to need to do it for many more.

It does make sense to not continue with enabling inserv if it can't be
done safely, though, and I don't know how to distinguish programmatically
between init scripts that can just be removed and ones the local admin
needs to keep and fix.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87ei8ft2de@windlord.stanford.edu

Re: Why is help so hard to find?

[Roger Leigh]

On Fri, Jan 14, 2011 at 04:52:13PM -0800, Russ Allbery wrote:
> Roger Leigh  writes:
> 
> > Yes, and this is what I did.  It's just rather tedious to (IIRC)
> > repeatedly run "dpkg-reconfigure sysv-rc" and then find out which file
> > is offending, run "dpkg -S $file", and then purge it.
> 
> I've not looked at the mechanism involved at all, but it does seem like we
> should be able to print out all of the files that would cause failures.
> Maybe it's hard to continue from an error long enough to find additional
> files?

I've not looked at how it does its checking.  IIRC, it's mainly down
to not having LSB dependency info in the header, so it should be
possible to check all the files and list them all in one shot.

> That sounds like it's the thing that makes this the most tedious.  If you
> got a list of all offending init scripts, we could document in the release
> notes that you need to run dpkg -S on each one to locate the relevant
> package and purge that package if you're no longer using it.

It's even be possible to automate that and list them all, then
you could just copy the entire list and purge them in one go.

> > It would be better if an upgrade was possible without all this manual
> > work.  It's been tedious for the handful of systems I've done this on so
> > far; I wouldn't like to need to do it for many more.
> 
> It does make sense to not continue with enabling inserv if it can't be
> done safely, though, and I don't know how to distinguish programmatically
> between init scripts that can just be removed and ones the local admin
> needs to keep and fix.

I agree completely that it's doing the right thing.  In the vast majority
of cases though we're just dealing with cruft left over from old removals,
which could be cleaned up.  Deinstalled packages still have the conffile
md5sums available, so we /could/ quite easily remove them if they haven't
been locally modified, which would allow a rather smoother upgrade for the
majority of users.  Are there any existing de-crufting tools that can
automatically purge packages where there are no local changes?
[I currently have Apt::Get::Purge set to true, but having the option to
only purge when no modified conffiles exist would be a better alternative
to either true or false in many situations.]


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: Why is help so hard to find?

[Don Armstrong]

On Fri, 14 Jan 2011, Russ Allbery wrote:
> Roger Leigh  writes:
> > I've yet to find a single system which upgraded to insserv cleanly.
> > This is mostly due to removed packages which need fully purging to
> > remove the last traces of old init scripts which break the process.
> 
> Huh. Every system I've upgraded had no problems. What is the failure
> mode? What happens on those systems?

One of the things which happens is #606588 because insserv doesn't do
#606593 yet. Also, #598020.


Don Armstrong

#606588 [i|  |☺] [unscd] unscd: Uninstallable if NSCD already installed and 
using dependency based boot
#598020 [S|  | ] [insserv] barfs when there are "invalid" init scripts
#606593 [i|  |♔] [insserv] insserv needs to support multiple packages providing 
the same service
-- 
Never underestimate the power of human stupidity. 
 -- Robert Heinlein

http://www.donarmstrong.com  http://rzlab.ucr.edu


--
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/20110115060008.ge5...@teltox.donarmstrong.com

Re: Why is help so hard to find?

[Christian PERRIER]

Quoting Mike Bird (mgb-deb...@yosemite.net):

> You have no idea what configurations are in use on stable servers.
> 
> You have no idea how many stable servers you're going to break.


You're right. No Debian developer is involved in large institutions or
corporations where hundreds of such servers are in use. All Debian
developers are kids playing on their parents' computer to build a
distro, during hacking nights, instead of doing their home work and
learn at school.

I'm really happy that you finally found the fundamental problem of
this project.



signature.asc
Description: Digital signature

Re: Why is help so hard to find?

[Tollef Fog Heen]

]] Roger Leigh 

| On Fri, Jan 14, 2011 at 04:07:58PM -0800, Russ Allbery wrote:
| > Roger Leigh  writes:
| > 
| > > I've yet to find a single system which upgraded to insserv cleanly.
| > > This is mostly due to removed packages which need fully purging to
| > > remove the last traces of old init scripts which break the process.
| > 
| > Huh.  Every system I've upgraded had no problems.  What is the failure
| > mode?  What happens on those systems?
| 
| Like Mike said in his reply, sysv-rc fails to configure fully due to
| the presence of init scripts incompatible with insserv.  It refuses
| to complete until they are gone.  You can live with this, but it's not
| ideal.

And more annoyingly, it keeps prompting on each and every upgrade of
sysv-rc with no ability to say «No, please go away, I don't want you to
convert my system».

| > > This has proven to be the case on every system I've migrated so
| > > far, and it is a real pain to identify each offending script and
| > > then find which package it belonged to and purge it.
| > 
| > dpkg -S would generally tell you, no?  We could document how to do
| > that in the release notes.

This would also purge the configuration of packages where I have no wish
to do so.  I sometimes uninstall packages without purging them, just
because I want to keep the configuration around.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
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/87d3ny1usp@qurzaw.varnish-software.com

Re: Why is help so hard to find?

[Mike Bird]

On Fri January 14 2011 22:06:21 Christian PERRIER wrote:
> You're right. No Debian developer is involved in large institutions or
> corporations where hundreds of such servers are in use. All Debian
> developers are kids playing on their parents' computer to build a
> distro, during hacking nights, instead of doing their home work and
> learn at school.

You're mistaken Christian.  Most Debian developers are dedicated
individuals who work hard to provide an excellent and stable
distribution.

But there are indeed a few who abuse the Debian packaging system
in order to force their unwanted software on the world.  I know
of two current examples - insserv and KDE 4.

It is perfectly OK for people to package those softwares and to
maintain them if they wish.

And it is perfectly OK for people to choose to use softwares which
have been packaged by Debian developers.

It is not OK for people to use packaging tricks to force their
softwares on people who don't want them.

insserv breaks complex systems.  It throws away years of DD work
and substitutes a few inane and inadequate rules.  It does so
without adequate warning, and irreversibly.  And the overrides
are undocumented - tell me which locations are for Debian packaging
and which are for sysadmins in order to avoid conflicts?  You can't
because there is no policy.  insserv would be laughable if it were
not infecting Debian right now.  Compared to the rest of the Debian
core, insserv is Windows 1.0.  It is so awful, in fact, that everyone
knows that it will have to be replaced.  But not until Squeeze+1.

FOR A SERVER, ANY SERVER, WHICH MIGHT BE BOOTED ONCE A YEAR OR SO,
THE RISK OF DOWNTIME DUE TO INSSERV LOSSAGE VASTLY OUTWEIGHS ANY
POSSIBLE SAVINGS IN BOOT TIME.  INSSERV SHOULD BE STRONGLY
DEPRECATED, NOT RECOMMENDED, FOR SERVERS AND COMPLEX WORKSTATIONS.

And KDE 4 is a well known and very old and very stale joke.  Fun
at parties, maybe, but not really appropriate for the workplace.

Some people like these softwares.  Use them if you wish.  HONESTLY
encourage people to use them if you wish.

But don't force them on people.  Don't trick people into using them
by saying they're recommended when they can in fact be disastrous.
The mere fact that they have to be forced on people shows just how
awful they are.

--Mike Bird


-- 
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/201101142346.53380.mgb-deb...@yosemite.net