Your message dated Mon, 28 Dec 2015 19:43:52 +0000
with message-id <[email protected]>
and subject line Bug#746741: Removed package(s) from unstable
has caused the Debian Bug report #535611,
regarding please add a way to force the creation of __init__.py
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
535611: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535611
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: python-support
Version: 1.0.3
Severity: wishlist

Stuff like the genshi templating system, uses .html (or other) files
mapped into the Python module namespace; in particular, a dir "foo"
containing only .html files can be referred to from the module
namespace as "foo.something" when "something.html" exists under foo/.

Usually this happens in user code (e.g. the templates/ dir in several
MVC frameworks). I've just stumbled upon a case where a python library
does that and gets side stepped by python-support. In the
"python-toscawidgets" package (currently in experimental), there is a
module path "tw.forms.templates" corresponding to a dir that just
contains *.html and *.mak files [1].

To ensure "tw.forms.templates" is a valid module, upstream ships a
__init__.py file in that dir. But when that dir gets handled by
update-python-modules, the __init__.py file is removed, on the
assumption that not containing any *.py (or *.so) files, that dir
should not be a module.

While that is probably a sane default behaviour (to work around many
dump upstreams which put __init__.py everywhere), in this particular
case I need a way to tell update-python-modules that that dir should
really be mapped to the module namespace. With the current
implementation, I did not find the way to do that, hence I'm filing a
wishlist request about it

My current (horrible) work around is to touch a dummy and empty .py
file in the appropriate dir before the build start. Please get me away
from such hack :)

Keep up the good work.
Cheers.

[1] zack@usha:~$ ls /usr/share/pyshared/tw/forms/templates/
    calendar.html         fieldset.html     label_hidden.html   list_form.mak   
     table_fieldset.html
    calendar.mak          fieldset.mak      label_hidden.mak    
select_field.html    table_fieldset.mak
    check_box_table.html  form.html         label.html          
select_field.mak     table_form.html
    check_box_table.mak   form.mak          label.mak           
selection_list.html  table_form.mak
    datagrid.html         i_dont_exist.py   list_fieldset.html  
selection_list.mak   textarea.html
    datagrid.mak          input_field.html  list_fieldset.mak   spacer.html     
     textarea.mak
                          input_field.mak   list_form.html      spacer.mak

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable-i386
  APT policy: (500, 'unstable-i386'), (500, 'transitional-i386'), (500, 
'transitional'), (500, 'testing-i386'), (500, 'stable-i386'), (500, 
'unstable'), (500, 'testing'), (1, 'experimental-i386')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages python-support depends on:
ii  dpkg                          1.15.3     Debian package management system
ii  python                        2.5.4-2    An interactive high-level object-o

python-support recommends no packages.

python-support suggests no packages.

-- no debconf information



--- End Message ---
--- Begin Message ---
Version: 1.0.15+rm

Dear submitter,

as the package python-support has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/746741

The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
[email protected].

Debian distribution maintenance software
pp.
Chris Lamb (the ftpmaster behind the curtain)

--- End Message ---

Reply via email to