=== vicky_ is now known as Guest59152
=== pjarnahomzz is now known as pjarnahom
mohit_hi all i am new to linux05:08
mohit_please tell me how to get package from net05:09
=== jsimmons_ is now known as jsimmons
=== ext2 is now known as ext3
=== persia` is now known as persia
=== daker_ is now known as daker
=== pjarnahom is now known as pjarnahomzz
=== ext2 is now known as ext3
=== bauerj|away is now known as bauerj
RhondaJust to be sure noone is here too early - my talk is at 18:00 UTC, which is in two hours earliest. :)16:50
SvenGThu Jul 22 17:51:46 CEST 201016:51
SvenGcest = utc+216:51
RhondaAlso, I'd like to point out to not make this too messy, this channel will get muted at that time with only me being able to speak up. Be invited to also hang out in #ubuntu-classroom-chat and ask your questions in there. If you prefix them with QUESTION ClassBot will pick them up and offer them to me for relaying into here.16:53
pleia2make sure you don't forget the colon, so QUESTION:17:10
=== tenach_ is now known as tenach[Laptop]
=== tenach[Laptop] is now known as tenach
=== MichealH_ is now known as MichealH
Robi_yo ppl18:58
=== ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Packaging Training Session - Current Session: Working with Debian BTS for (not only) Ubuntu Contributors - Instructor: Rhonda
RhondaLike mentioned before, this channel will become moderated soonishly, so be reminded again to take questions prefixed with QUESTION: to #ubuntu-classroom-chat so that the ClassBot can pick them up.19:00
RhondaWelcome everybody. Todays topic for this talk is the Debian BTS.19:01
RhondaBTS stands for Bug Tracking System. Some might question themself, why being bothered? We are Ubuntu, right?19:01
RhondaWrong. ;)19:02
RhondaAs lined out in last weeks devweek talk that Laney gave together with me it is important to work together with the Debian people.19:02
RhondaIf you might want to catch up on the why - read up its log from the archive: https://wiki.ubuntu.com/MeetingLogs/devweek1007/WorkDebian19:02
RhondaI'd like to start off with the basic web interface that the BTS offers. Contrary to what launchpad offers, this is a readonly interface, so it only offers query possibilities.19:03
Rhondahttp://bugs.debian.org/ redirects you to a basic page in which you have some few forms that allow you to query the web interface. But there are very handy shortcut options that are useful to keep in mind.19:04
RhondaIf you would be a package maintainer, or might want to track the open bugs of a specific maintainer, you would query e.g. http://bugs.debian.org/rhonda@debian.at (this is my own overview)19:05
RhondaPlease notice that this doesn't contain co-maintained packages - this is a wishlist bugreport that is open against the BTS.19:06
RhondaIf on the other hand as user you would like to know which of the bugs you have reported are still open, you would use the from: keyword, like http://bugs.debian.org/from:rhonda@debian.at to get an overview of the still outstanding bugreports that you opened, to be able to remind yourself of the status and potential send a followup to question what's going on.19:07
RhondaThere is also the posibility to query for bugreports against specific packages one is interested in. One approach would be to query for a specific binary package, like e.g. http://bugs.debian.org/wesnoth-1.819:09
RhondaTo refer to a specific _source_ package (which would list all bugreports against the individual binary packages) you use the src: prefix, like http://bugs.debian.org/src:wesnoth-1.819:10
RhondaFinally, if you know a specific bugnumber, you would just query http://bugs.debian.org/45993519:11
RhondaThese are the most important shortcuts for querying the webinterface, at least the basic ones. You can see at the end of the overview queries a form with which you can tweak the overview a bit, too.19:12
RhondaAlso in the overview you have for each bugreport several information listed:19:14
RhondaFirst of all obviously the unique bug number by which the bug is referenced. Next is a group of flags which give information about the bug status. If you hover with your mouse over the individual entries you'll receive a tooltip expansion what they stand for.19:15
RhondaAlso you can click into that part to get a bit more information about the bug at hand. Next would be the binary package the bug is filed against, and then the subject. The rest of the information should also be pretty self explaining.19:16
RhondaPlease notice that package maintainers (or maintenance teams) can tweak the grouping of the bugs in their overview page, like you can see on e.g. http://bugs.debian.org/qa.debian.org or on http://bugs.debian.org/ftp.debian.org19:17
RhondaHow to do that would explode the context of this session though, so I won't cover it here.19:18
RhondaThis covers the webinterface pretty well me thinks, let's move on to reporting some bugs, won't we. :)19:19
RhondaI mentioned that the web interface is read-only, so how to report bugs? While the web interface is pretty useful, you might have noticed download links for mailbox files in individual bugreports.19:20
RhondaThis gives somehow the impression as wether it would work by emails - and you are right on that! The real main interface to the BTS is email based.19:20
RhondaThe webpage http://www.debian.org/Bugs/Reporting gives a short guide how to use it, I'll cover a few bits of here though.19:22
RhondaThere is are some helpful tools that I can encourage to report bugs with, they though depend on a local running mailserver. Laney encourages you to use ssmtp which is pretty easy to set up and get used to for sending out mails.19:23
ClassBotnigelb asked: Is there any plan for a web manipulatable interface for BTS?19:23
RhondaThere is a GSoC project proposed since a while, unfortunately noone signed up to do it, especially since the BTS depends so heavily on emails and would require some sort of login mechanism or challenge-response style things.19:24
RhondaSo plans are there, noone though did pick up on it to work on it. Most people are happy enough with the email approach.19:25
RhondaAnyway, about the tools for reporting, there is reportbug to be run in a terminal, and reportbug-ng for a graphical interface.19:26
RhondaPersonally I have to admit that I didn't use the later so I can talk about the former. To not have a confusion for regular Ubuntu users reportbug is changed in Ubuntu to _not_ send mails to the Debian BTS by default.19:27
RhondaOne either has to use the "-B debian" switch, or put "bts debian" into the .reportbugrc (thanks for mentioning that, cjwatson)19:28
RhondaEven though reportbug is a textbased interface it is extremely helpful in the way that it gathers additional information that the package maintainer might want to know, like dependencies or debconf answers that were given on installation.19:29
Rhondareportbug has different operating modes that one can set - those tweak what kind of additional information the user is asked about. The default mode is set to novice and can also be tweaked through the .reportbugrc file.19:30
RhondaAnother very very handy tool is called "bts" (nomen est omen) and is included in the devscripts package.19:31
RhondaIt can be used to change meta information of different bugreports from the commandline. If you more regularly have to change bugreports you really should get used to this tool, it can increase your performance a fair bit. Just in case, if you do, please don't forget to also leave a helpful comment with adding "# some remark" on why the change was done so it's more obvious.19:33
RhondaBut like said, the main interface is emails, and all these tools only actually craft emails in the background for you.19:34
RhondaThus, I also like to mention the format of said emails. There are three important mail addresses that the BTS recognizes:19:34
Rhondasubmit@bugs.debian.org - mails sent to this address will open a new bugreport.19:35
RhondaThese mails require some additional "Pseudo" headerlines at the start of your email body to do something useful. ;)19:35
RhondaThe subject of the mail itself will be taken as subject of the bugreport, so be sure to make it as clear as possible (like you try to do with all your emails anyway, right? ;))19:36
RhondaThe most important pseudo header is "Package: foo". This means that this newly submitted bugreport is for the package named foo.19:37
RhondaSecond important pseudo header is "Version: 1.2.3". This is important because the Debian BTS has this special thing called version tracking.19:37
RhondaThrough the version information it knows which bugs apply to which release, and it is also an important information to the package maintainer obviously.19:38
ClassBotsense asked: In Ubuntu we have a lot of packageless bugs that are reported by people who don't know against what package to report the bugs. The Bug Squad has to find time and people to assign these bugs against the correct package. Does Debian have packageless bugs?19:38
RhondaYes, there is. There are several different approaches here. One thing is the "Package: general". Bugreports against that pseudo package gets sent to debian-devel and get addressed though that.19:40
RhondaAlso bugreports against non-existing packages aren't lost or go to the void, there are people explicitly hunting those down, and I think also bugreports with no Package: header do land in some special place where interested people can check on them.19:41
RhondaThere are also some more things in the submit mails that can get set: "Severity: important" for the importance of the bugreport (known values are critical, grave, serious, important, normal (default), minor and wishlist)19:43
RhondaSo a wishlist type report is also filed through the same interface as "bugreport".19:44
RhondaAlso, one can set "Tags: patch" on a bugreport when one adds a patch to it to make it easy for people who like to check patches and fast-track such bugreports (so adding patches is always a good idea ;))19:45
ClassBotmistrynitesh asked: won't every reporter set the Severity: Critical? Is there a way to govern this?19:46
RhondaNo, they don't. :)  Most users don't bother at all setting a severity and have the bugs dropped in as normal.19:46
RhondaAlso, tweaking these things is easy and is usually done quickly, which I want to come to now. :)19:47
RhondaThere is also the control@bugs.debian.org mailaddress which is the one that the former mentioned "bts" tool sends its mails to.19:48
RhondaIt can be often seen when package maintainers followup to a bugreport that they send a Cc to this address in addition to the bugnumber mailaddress (which is <bugnumber>@bugs.debian.org btw.) and add some other pseudo headers.19:48
RhondaThe control facility take a tiny bit different syntax than the submit one.19:49
ClassBotThere are are 10 minutes remaining in the current session.19:50
RhondaAnd it is mainly documented on http://www.debian.org/Bugs/server-control19:50
RhondaThings that are often used is "reassign <bugnumber> <otherpackage>". This will reassign the given bugnumber to a different package.19:51
RhondaPlease notice that this will lose the bugs version information so if you are aware that this affects a specific version of the other package add it as additional argument.19:51
RhondaQuick strawpoll question: What I feared happened - the time did run faster than I was able to type, and I still have stuff on my agenda to adress.19:52
RhondaDo people prefer if I continue the session (there is nothing planed after this one) or if we cut it and continue another time?19:53
RhondaI will in the meantime continue anyway so that we don't lose time by this dilemma. Please raise your voice on this topic in #ubntu-classroom-chat19:53
RhondaAddressing mistrynitesh's question there is the "severity <bugnumber> <newseverity>" command which can fix the severity in case a bugreporter has a non-fitting opinion in comparison to the package maintainer. ;)19:54
ClassBotThere are are 5 minutes remaining in the current session.19:55
RhondaPlease also notice that anyone can change bugreports - so at times it happens that bugreports switch the severity back and forth, this is not a good style, please respect the package maintainer's opinion on it and try to convince them with reasoning - repeated severity inflation have resulted in getting banned from the control address in the past.19:56
RhondaIf you notice that the bugreport is found in a specific version you can use the "found <bugnumber> <version>" to mark that.19:57
RhondaPlease notice that this is often enough only useful when you have found it in an _older_ version too, like in the stable release when a bug was reported against the version in Debian testing.19:57
Rhondaforwarded is also a pretty useful control command to mark that a bugreport has got forwarded. You set it to the URL or email address where you forwarded the bug to.19:58
RhondaIf you set it to a URL it can be pretty helpful because there is a service that checks known upstream bug trackers and can set specific tags as notification for the maintainer.20:00
RhondaWhich brings me to the "tags" command. With this one can set some helpful marks onto a bugreport.20:00
RhondaThe syntax is "tags <bugnumber> + tag1 tag2 - tag3 tag4" - so one can add tags and remove in a single line.20:01
RhondaOr set the tags explicit to a specific set with =20:01
RhondaOften used tags are moreinfo when the user is asked to submit additional information, unreproducible if the maintainer isn't able to reproduce the issue, pending when the bug is fixed within the maintainer's VCS but not uploaded yet, security for bugreports that are relevant for the security team, upstream to mark bugreports that aren't happening just because of the packaging, confirmed, and many more.20:03
RhondaAlso there are tags for each release. Please notice that those have change its meaning since version tracking got implemented, so please don't use them unless you know what you are doing. I will mention an example for them a bit later. ;)20:04
RhondaThere are more commands that control accepts, you can find them all listed in the former mentioned URL, http://www.debian.org/Bugs/server-control - and usually these control mails are ended with "thanks" or "stop" to tell the control server to stop processing the mail here so it doesn't produce errors.20:05
RhondaThis ending markers are especially useful when following up to bugreports and sending a cc to control@20:05
RhondaOne _very_ common problem people stumble into is using the <bugnumber>@bugs.debian.org mail address.20:06
RhondaOften enough people expect this such mails to get sent to the bug reporter - but they won't.20:06
RhondaThese bugs only go the maintainer of the package (and people subscribed through the http://packages.qa.debian.org/ to the according package)20:07
RhondaIf one want to reach out to the submitter of the bugreport they have to explicitly be put in the to line, but there is a helpful bugs address: <bugnumber>-submitter@bugs.debian.org20:08
RhondaThis will get to the submitter of the bugreport then too. Keep that in mind, otherwise you will fall into the pit that many package maintainers did fall into and wonder why you don't receive any response from the submitter at all.20:09
RhondaAlright. This is the main part of my talk. Thanks for your attention!20:10
Rhonda… though, I won't end here, because I mentioned in my announce that there is the question pending why some bugreports won't get archived.20:10
RhondaAnd you want to know why so, right?20:10
RhondaSome part of this is rooted in the version tracking, which I want to try to explain now.20:11
ClassBotmistrynitesh asked: When one reports a bug, is he/she subscribed to that bug and receive updates on it?20:12
RhondaTo some degree yes, to some no.20:12
RhondaLike mentioned, <bugnumber>@bugs.debian.org doesn't reach the submitter of the bugreport.20:13
RhondaBut one thing that _always_ reaches the submitter is closing a bugreport.20:13
RhondaClosing a bugreport is either done by adding a "Closes: #1234" into the debian/changelog and uploading the package (the way to do it when the bug requires changes to the package)20:14
RhondaOtherwise people can send mails to <bugnumber>-done@bugs.debian.org explaining why the bugreport is closed. If it was closed in a former upload already but reported later or forgotten to be closed with the upload, this mail should contain a "Version: 1.2.4" in its first line so that the version tracking can do its good for this bugreport, too.20:15
ClassBotyofel asked: there is a possibility to subscribe to bug reports.. <bug>-subscribe@b.d.o - what mails do you get if you do that?20:16
RhondaFrom what I perceived this makes one receive all mails that are sent to <bug>@b.d.o, including control@ processing mails, but don't pin me down on that.20:18
RhondaSo, back to version tracking: When you go to an individual bug page, let's take http://bugs.debian.org/580391 as example here, you'll notice a graph in the upper corner.20:18
RhondaThat graph shows the information that version tracking works on.20:19
RhondaYou will notice that there is a green box with (testing, unstable) in it, and a red circle with (stable) in it.20:21
Rhondagreen means good versions, the bug is fixed in those, red means bad versions, the bug is not fixed in those.20:21
RhondaOn the left hand side you see the information of the bug, like Severity: grave, Found and Fixed in versions, and that the bug actually is Done.20:22
RhondaUsually a bugreport gets archived after being done for 28 days in testing.20:22
RhondaGiven that this bugreport is of severity grave, it is considered release-critical.20:23
Rhondarelease-critical means that Debian doesn't want to release with a package that contains such a bugreport.20:23
RhondaSo how did this bugreport happen to be affecting stable, then? It was reported after stable was released, that's why.20:24
RhondaActually though, this bugreport doesn't really affect stable, because the cause of this happened after the release, squeakvm did still exist in the stable release. It's just that the found version was the same in unstable at the time this was reported.20:25
Rhondaso this is where the release tags come into play. I am going to mark this bugreport as not affecting stable by tagging it with squeeze sid, like this:20:26
Rhondabts tag 580391 + squeeze sid '# not affecting stable'20:26
RhondaWe will have to wait for the mail to arrive at the BTS to se its reult.20:26
RhondaIf you click on the "etoys" link at the top now you see the overview of the bugreports against the etoys package.20:27
RhondaLike mentioned when you click on the [G|+|☺] part in that page you get the additional information.20:28
RhondaYou'll see that there is no information about archival in there currently. We'll come back to this in a few minutes,.20:28
RhondaWhen you look at http://bugs.debian.org/581337 now, which is another release critical bugreport, you can see it also be seen as affecting stable.20:29
RhondaYou will notice that this bugreport doesn't has any found version.20:29
RhondaThis makes the BTS think that the bugreport affects every version it is aware of.20:30
RhondaThe root of this is that the bug got reassigned without any version information. This is also easy to fix because the version information in the original report is actual correct.20:30
Rhondabts found 581337 0.18-1 "# readd found version lost in reassign"20:31
RhondaThis will fix the version information for this done bugreport and mark get it closed for real and archiveable. :)20:31
RhondaThis now is a more difficult issue now to decypher: http://bugs.debian.org/src:isync - who gets an idea why there are so many resolved bugreports that doesn't get archived?20:33
RhondaIf we choose any individual bugreport of those, e.g. http://bugs.debian.org/177280 the graph has some interesting content.20:33
RhondaYou can click on it to receive a larger version in case you still don't see it. ;)20:34
RhondaThe topmost green box contains (testing, unstable, stable) while the topmost red circle contains (unstable)20:34
RhondaNow how is that possible? Having unstable both fixed and not-fixed?20:34
RhondaHere the packages interface comes handy: http://packages.debian.org/unstable/isync gives us some more information on this confusing graph.20:36
RhondaYou will notice that almost all architectures have the same version - except one.20:37
RhondaGiven that hurd-i386 is in a special state, it's not part of testing and not a release architecture, the way to fix the isync issues is to request removal of the package for this architecture.20:37
RhondaI found the same issue last week in another package: wormux. You can see still some not-yet archived bugreports on http://bugs.debian.org/src:wormux - but when you click on the informational part there you'll see that they "Can be archived in 8 days" now that the removal of the outdated package on the hurd architecture was processed.20:39
RhondaIf we now look back at http://bugs.debian.org/etoys ypi20:40
RhondaIf we now look back at http://bugs.debian.org/etoys you'll see when you click on [G|+|☺] after a reload that the bugreport is set to be able to get archived in 28 days and also the added squeeze sid tags.20:41
RhondaLikewise in http://bugs.debian.org/581337 you see the fixed adjusted version graph, it doesn't contain the stable version in there anymore and will be able to get archived.20:42
RhondaI guess this should cover the most confusing things that can happen with version tracking and how to get them fixed. Please don't refrain to ask when you are unsure - even though almost all changes can be undone easily it might annoy someone.20:43
Rhonda… and I hope I didn't bore you too much and you all fell asleep in the meantime!20:44
RhondaI guess we can start a final round of questions, if I didn't overflow your brains with too many information in too short time.20:45
RhondaAs final reminder, there are some Debian Developer still hanging out in #ubuntu-debian which are working on better collaboration so if you don't want to expose yourself on more specific Debian channels feel invited to come by and ask in there if unsure.20:46
Rhonda… scratch that "still", we won't run away when you come. ;)20:47
=== ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - http://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi
=== daker_ is now known as daker

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!