Oddity in repo history

0 views
Skip to first unread message

Reuben Thomas

unread,
Oct 30, 2012, 9:00:30 AM10/30/12
to wa...@googlegroups.com
I just noticed, while filing a minor bug report, that my
bash-completion file was modified compared to the Debian package of
2.7.3. I compared it with the file in the repository, and it's
identical. But the last change to bash-completion was in changeset
353264b561cb, whereas 2.7.3 is tagged at changeset a2d95ea8f0a9, a
month later.

Hence it's a bit of a mystery how that version of bash-completion
didn't make it into the 2.7.3 package…I thought you might want to know
something odd happened!

--
http://rrt.sc3d.org

Tshepang Lekhonkhobe

unread,
May 23, 2013, 12:27:40 AM5/23/13
to wa...@googlegroups.com
Maybe I misunderstand, but the last change to the file was one commit
later than 353264b561cb, which is 3e61db57eb3.

Reuben Thomas

unread,
May 23, 2013, 4:15:59 AM5/23/13
to wa...@googlegroups.com
OK, that doesn't change the logic (2.7.3 was tagged a month later).

However, I failed to notice that the bash-completion file in my repo checkout was actually modified compared to the master repo, as per my recent post with attachment.

--
http://rrt.sc3d.org

Reuben Thomas

unread,
May 29, 2013, 7:41:51 PM5/29/13
to wa...@googlegroups.com
Here's that patch again, against latest tip.
bash-completion.patch

Reuben Thomas

unread,
Jul 7, 2013, 7:04:51 PM7/7/13
to wa...@googlegroups.com

Tshepang Lekhonkhobe

unread,
Jul 8, 2013, 3:34:15 AM7/8/13
to wa...@googlegroups.com
On Mon, Jul 8, 2013 at 1:04 AM, Reuben Thomas <r...@sc3d.org> wrote:
> Ping?

I will soon (hopefully later today) get back to you.

Tshepang Lekhonkhobe

unread,
Jul 8, 2013, 4:00:00 PM7/8/13
to wa...@googlegroups.com
Change pushed.

Karl Schmidt

unread,
Aug 12, 2013, 4:53:01 PM8/12/13
to wa...@googlegroups.com
There is the feature :

Lets say I want to install the testing version of some package

wajig install --dist testing package

This will do that - an pull in testing version of the package AND the libs required just for that
package. ( doing this as a dry run

There are often times I want to do just this - I tend not to as I worry about breaking other
packages with upgraded libs.


So first:

$ wajig distupgrade --dist experimental would update everything to experimental ( this is in the
documentation) , but $ wajig install --dist testing package isn't in the docs.


Second:

Take a real situation - I have a stable(wheezy) desktop that I would like to have use the latest
pulseaudio from testing - I don't - as I need this system to be really reliable and sadly there is
not a backports of pulseaudio.

In the past, I broke systems and spent a long messy time downgrading - don't want to do that very
often. Is that still likely today? It seems to me that there has to be a better way?






--------------------------------------------------------------------------------
Karl Schmidt EMail Ka...@xtronics.com
Transtronics, Inc. WEB http://secure.transtronics.com
3209 West 9th Street Ph (785) 841-3089
Lawrence, KS 66049 FAX (785) 841-0434

A patent provides one a license to enrich his lawyer. -kps
--------------------------------------------------------------------------------

Tshepang Lekhonkhobe

unread,
Aug 12, 2013, 5:44:32 PM8/12/13
to wa...@googlegroups.com
On Mon, Aug 12, 2013 at 10:53 PM, Karl Schmidt <ka...@xtronics.com> wrote:
> There is the feature :
>
> Lets say I want to install the testing version of some package
>
> wajig install --dist testing package
>
> This will do that - an pull in testing version of the package AND the libs
> required just for that package. ( doing this as a dry run
>
> There are often times I want to do just this - I tend not to as I worry
> about breaking other packages with upgraded libs.
>
>
> So first:
>
> $ wajig distupgrade --dist experimental would update everything to
> experimental ( this is in the documentation) , but $ wajig install --dist
> testing package isn't in the docs.
>
>
> Second:
>
> Take a real situation - I have a stable(wheezy) desktop that I would like to
> have use the latest pulseaudio from testing - I don't - as I need this
> system to be really reliable and sadly there is not a backports of
> pulseaudio.
>
> In the past, I broke systems and spent a long messy time downgrading - don't
> want to do that very often. Is that still likely today? It seems to me that
> there has to be a better way?

The only safe way is to use a backported package, and I think Ubuntu
has a tool that makes this easy. I forgot the name.
Reply all
Reply to author
Forward
0 new messages