Re: [Neurodebian-devel] Help needed for pandas bug: Could anybody verify the suspicion that tzdata might have some influence?
On Tue, 28 Mar 2017, Andreas Tille wrote:
> > - I have already stated many times that if you want to move any of the
> > core packages under bigger (-med, -science, etc) maintenance -- I
> > don't mind. But it shouldn't complicate my own work on those
> > packages. Someone's "mess" might as well be my "consistency" and I
> > often can't afford spending time figuring out how this are now. And
> > even worse time "fixing" up packaging (e.g. re-enabling testing,
> > re-introducing dropped patches, etc) to make it as "messy" as it
> > was before ;)
> It might be interesting to know what part of the "mess" is important to
> you.
itemize "mess"y aspects (I was not the one to provide this
qualification) and I will let you know. Could as well happen that
the answer will be "none"
> For instance it might help to know in advance if you are fine with
> the gbp layout specified by the packaging policy of the target team. :-)
yes -- it is fine. I use gbp as well
> I fully agree that a migration of packaging to a team VCS should not
> include changing / dropping any patches in the first place.
good
> > - so far I still see only myself as the one who took care about pandas
> > even after I cried out loud for help. So helping instead of
> > complaining (again) would be more helpful (I started reading
> > this with an idea that we are talking about tzdata issue, but
> > apparently we are just making water harder)
> While I know that you always was cooperating when we started discussing
> about some issue this discussion used to start only after rdepends of
> one of the Neurodebian packages were affected by removal from testing
> warnings. When checking the bug log no response to those RC bugs was
> logged. This is simply frustrating since this means a time delay of at
> least 10 days until somebody starts reacting while beeing totally
> unclear whether some work was done or not. I fully understand if you
> are swamped with more important things but responding to an RC bug by
> tagging it help and forwarding the mail to interested parties - in this
> case Debian Science for instance - would help a lot.
would be great indeed
> May be you consider all this making water harder, but I consider not
> responding to RC bugs (without an appropriate VAC message) in times of
> freeze not responsible maintenance.
yeah, agree. In the long run, I may indeed need to shorten the list of
packages I maintain. I am NOT on VAC virtually ever but indeed
seems getting short of time to provide adequate oversight at times.
Again -- actual help is welcome.
> I'd like to repeat here that I
> would not say so if there would be *any* message crying for help. Since
> I also personally have no idea about Pandas and this issue I simply took
> some action and involved tzdata maintainers. This could have happened
> 10 days ago and this is my main point. (And sorry if I'm to German
> here. :-P )
it is ok -- I like Germans in general ;-)
> > - regarding original tzdata issue -- since we are just expressing
> > sentiments here -- it would have been cool if maintainers of
> > core packages would do 'reverse depends testing' before uploading (as
> > I am trying to do in such cases) so we stop running after a gone train
> > [see e.g. our ad-hoc messy helper
> > https://github.com/neurodebian/neurodebian/blob/master/tools/nd_build_testrdepends
> > which I usually use successfully when preparing next uploads for
> > cython, nibabel, etc]
> Perfectly valid argument, yes. This again shows that you are doing
> really cool stuff in NeuroDebian which I totally appreciate.
> Unfortunately this does not make its way where it IMHO belongs like for
> instance at debian-qa@lists.debian.org. Well, you wrote some helpful
> tool and have hidden it nicely out of reach for those people who are
> obviously in need of this.
apt-get install neurodebian-dev
I have pointed to it multiple times.
I think there is a (possibly better) alternative now
$> apt-cache show ratt
Package: ratt
...
Description-en: Rebuild All The Things!
ratt (“Rebuild All The Things!”) operates on a Debian .changes file of a
just-built package, identifies all reverse-build-dependencies and rebuilds
them with the .debs from the .changes file.
.
The intended use-case is, for example, to package a new snapshot of
a Go library and verify that the new version does not break any other
Go libraries/binaries.
but I haven't tried it so YMMV.
You can help leading the initiative to promote it/them to debian-qa@ or
-devel@ or any other appropriate in your opinion channel. I would
really appreciate!
> > - outdated (not pushed) git on github or alioth is all the same -- just
> > me forgetting to push. "Fixed now" (thanks) - and present on
> > both github and alioth git://git.debian.org/git/pkg-exppsy/pandas.git
> Thanks.
> > Thanks in advance for your help!
> You are welcome - please ask actively next time. :-)
Hereby I am officially announcing (again) what is already known (I
thought that RC bugsquashing is a normal procedure and not requiring
special invitation, but if it helps, here you go)
Everyone is welcome to address RC bugs (unless tagged as pending) in
packages I maintain, especially during the freeze. NMUs etc are more
than welcome. Your help will be very much appreciated!
If I don't react to RC bug, it might be that I have missed it. If you want
to tackle it, and really need my official blessing to get it fixed by you --
email me and I will bless you officially for that endeavor. Adding
"bless me to fix RC bug" in the subject line would help to attract
my attention.
I do not think I can add more to this line of the discussion ATM.
--
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
Reply to: